Despite the revolutionary concepts behind Business Process Management, we found that there are specific reasons why Business Process Management development projects tend to fail in the long term. Since Business Process Management should be a long-term initiative in all cases to get the maximum benefit, addressing these reasons are crucial to gaining a return on investment over time.
The first problem, and the one most common across software projects of all types, is scope creep. I have never seen a system that does not involve, and often suffer badly from, scope creep.
Although it may appear difficult to manage these issues, there are simple and effective ways, as long as they are adhered to. Our original concept of 'goal-driven' development was expanded to provide more detail and rigour around the definition of Goals. We coupled this with the Feature selection process to ensure that:
* All Goals are fully defined in terms of metrics and timescale.
* All Features must support a Goal.
* The rest become a 'Wish List' that may be addressed if time and resources allow.
The second area that suffers is documentation. Again, this probably tends to suffer across all software projects types, but definitely in all Rapid Development projects.
To be honest, documentation is generally boring. It is hard work, and does not immediately appear to benefit anyone much. It is even often called 'shelf-ware' for this very reason.
Well, we know it is not true. A well-documented system is a pleasure to maintain and a poorly (or un-) documented system can be a nightmare.
The challenges we set ourselves were:
* To fully document Business Rules against Features.
* To keep the technical documentation to a minimum, in order to keep it manageable.
* To make it as simple to achieve as possible, thus ensuring that documentation is actually created as part of and during the development process, not as an adjunct and later.
* To make it as thoroughly useful as possible, so that the effort expended is not wasteful, and the documentation is actually constantly used.
We believe we have achieved these goals.
For many reasons, success is rarely measured in the long term. This may seem unlikely, but it is definitely true. The problem is often one of attention span, most notably of upper management.
Once the system is underway, and actually working, it is no longer 'exciting'. As such, people naturally tend to move their focus towards more interesting areas, where effective changes can be made. This is natural, and indeed should be expected.
The problem is often that the Business Process Management project, although a success, is in many cases not actually highlighted as such.
Given that a Business Process Management initiative is most effective in the long term, this can severely hamper such an initiative, The momentum can easily falter and be lost, especially with high-level management sponsors, where it needs to be driven from.
We set about finding ways to combat this, and the most effective approach appears to be:
* To build the performance objectives and metrics into the design, typically as part of the goals of the system.
* To build the reports for these metrics into the system itself, so that they are not forgotten at a later date.
* Allow feedback from users in order to improve the user experience, evaluate the success of the system, and generate ideas for improvements and extensions to the system.
* Generate automated user reviews to evaluate the system after a pre-determined interval.