Instructions Manuals Are For Wimps - Why BPM Needs A Standard Approach

How can you improve your chances of BPMS project success? asks columnist Dan Morris. The answer: formalize your approach. The trouble is, what approach do you adopt?

Why BPM Projects need a consistent approach

In BPM the need for a consistent and methodical approach is becoming especially critical as project numbers increase and complexity follows scope expansion. Why? Because methodologies are like instruction manuals – they tell people how to do things. They save time, effort, frustration, and deliver consistency.

The problem is that few companies trying to use BPMS tools and BPM have formal methodologies, techniques, or approaches. In many companies, every BPM effort is approached uniquely. Different Business Process Management (BPM) project managers follow their own way. Sometimes it works well and other times it doesn’t.

The reason for that is that BPM projects are still fairly new in most companies and project managers, may or may not have any or much BPMS/BPM experience. They may or may not know much about the surrounding IT technology if they are from the business side and if they are from the IT side, they may or may not know anything about how to change a business (beyond asking what the business wants and then writing it in business and technical specs).

Studies by major research organizations show that there is a shortage of management talent with BPMS/BPM experience – especially when the projects become more than fairly simple problem resolution improvements.

How can you reduce the risk of BPM project failure?

In many ways, to quote a movie title, we are now "back to the future." This is much the same problem IT faced in the 1970’s and 1980’s when the use of information technology exploded.

At the time there were simply too few people who knew how to make projects consistently successful – both from the business and the IT perspective. New technologies were becoming available constantly and few people knew any one of them very well. People were also pushing the boundaries of what had been thought possible. Risk was high and failure was common. But we all learned and we created the technical and business environment of today.

The challenge then, as now, was how to control quality and deliver successful projects. In response, the IT industry started to look to formal methodologies to provide guidance and appropriate expertise to everyone involved. These methodologies proved to be indispensable in sharing knowledge on how to use the technology, look at business operations, and manage projects that were increasing in complexity.

They provided directions from those who knew how to use the new technology. They shared knowledge and experience.

This is where I believe BPMS/BPM is today. But formal BPMS/BPM methods are hard to find. A simple internet search finds a lot of things people referred to as methods that are really high level approaches.

Here’s a definition of methodology - a formal, written comprehensive list of organized tasks with supporting documentation on how the tasks should be performed, the data that the team should look for, and the identification of the deliverables from tasks. Together this information should provide direction on how the BPMS/BPM project should be done.

What should a BPM methodology look like?

First, the methodology should be written by experts – either BPMS/BPM experts in your company or brought in from outside. I suggest here that the authors be BPM certified by an organization like ABPMP and possibly be certified Business Architects. At some point Enterprise Architecture links should also be included. The methodology must clearly show how all the parts of the project fit together and what each produces and consumes. This is critical in letting everyone know why everything is done.

Second, the methodology should address the worst case BPMS/BPM project scenario – broad scope, complex, critical. But it must have the flexibility to let the project teams pick the tasks that make sense for any project – thus avoiding unnecessary overhead. The company can declare a core set of tasks for every project, but the overhead must be minimal.

Third, it must provide both lists or organized tasks and a detailed "how to" instruction manual to tell people not only what to do, but how to do it. Given shortages of experienced BPM staff, this is important in controlling the project and limiting risk.

Fourth, it must be easy to use. If it is not, it will be shelf art – if it has pretty binders. If it doesn’t have good looking binders, it had better be useful or it becomes relegated to the storage room where eventually it will take an archaeological expedition to find. It will probably be placed right next to the crumbling or possibly fossilized documentation from past projects. So, your BPMS/BPM methodology cannot be onerous. It cannot simply cause overhead or it will not be used. Even if mandated, it will only be given limited use.

Part of this ease of use is its ability to bring everyone in the project onto the same page with the same understanding. It must show the project manager how everything that is produced is used. It should also change as the BPMS/BPM teams become more experienced and learn more to avoid unneeded overhead – doing things that don’t need to be done.

Finally, the methodology must address project sponsorship and the retention of ongoing commitment to try to make the methodology work and to evolve it to reflect the corporate culture and the way the business really works.

Given that BPMS/BPM is a business environment that supports rapid change, any methodology must differentiate between what the business process team members will do and what the Business Architects, the Enterprise Architects, and IT will do. This involvement of other disciplines drives a need to link to external methods for given deliverables for some sub-products. The BPMS/BPM methodology is thus the center of this approach with the other disciplines and their methods tying into it and producing products that will be consumed in the BPMS/BPM improvement project.

This formalization of approach and steps allows consistency among the BPMS/BPM project teams. It also makes certain that those things that work are reused to promote success. The bottom line is that the use of methodologies in other areas has proven the worth of formal methods in reducing risk and cost.

The flip side of this issue is however, the question of the value of a methodology of any kind. Clearly many BPMS/BPM projects succeed. If they didn’t, the BPM discipline and the BPMS technology would have been rejected long ago. Eventually persistence and diligence will result in success. The fact is that almost anything can be made to work by creative people. Even failures can be changed into success with enough effort. But, the cost is inconsistent results, differing levels of quality, and often solutions that work, but not very well. Where is that hammer? I found where the nail goes!

The problem is that history in other areas has shown that without a formal methodology to guide the team, risk is high, the solution will likely cost more, and benefits may be much more limited than they otherwise could have been.

IT Involvement

IT not only provides the technical environment the BPMS operates in, it also provides the web services, data and interfaces that support the generated applications of the BPMS based BPM solution.

So, IT is critical to the project’s success. But, BPMS tools make these projects very different from traditional application development projects. BPMS tools can go as far as generating the applications that have traditionally been handwritten. The way these tools are used is also very different from traditional IT approaches and they don’t fit the traditional IT model. The result is also unique to BPMS/BPM. This is a fully integrated business/IT operating environment – the business and its applications become a single entity. Change, in this environment, largely becomes a result of modifying models, forms, and rules.

BPMS solutions are fluid and meant to evolve through rapid iteration using generated applications. Traditional application development is meant to be at least fairly static. Application systems today are built to last, not to change easily or constantly.

For this reason, while the methodologies IT may use for the technical work are fine for programming, data management, and interfacing, they do not deal well with changing the business operation or its applications. They also do not do well with the rapid iteration concept of BPM.

Because of this, I believe that companies should find or build a formal BPMS/BPM methodology that reflects their business/IT culture and the way they want BPM to work in their company. This methodology should not however, be kept separate from the other methodologies in the company – including IT methods. It must rather work with them.

The World Today

Our business world today is risk averse, cost conscious, and too often blame focused. Managers are concerned about these realities – as they must be. Any approach, tool or technique that helps provide consistency and control should be viewed as a manager’s friend.

Today it is no longer acceptable to wing it and relegate instructions to the wimps. It is no longer OK to drive around the countryside lost while refusing to look at a map or stop for directions.

BPMS/BPM is the foundation that will change the future of business – yes I am biased (but true is true!). The issue is how you will use what is either available in your company or coming. The issue for the company is how it will govern this new capability to change and manage the operation in ways that were never available before. In all these and many more cases, the answer lies with formal methods that provide guidance and control.

As with all of my columns, I welcome other opinions. Please let me know what you think.