During my work as a consultant I had the opportunity to participate in a number of BPM projects where the process development work started with the business analysts dumping a doorstop sized requirements document on a development team working in agile mode. There was nothing wrong with the document's content per se; in fact they all had a very detailed description of each process involved followed by fancy diagrams. No, the problem wasn't with the document's content or format, but with its underlying assumption which was that its "completion" signified an end to requirement analysis and that all of the processes were completely modeled and ready for implementation.
Things somehow never worked that way: After an iteration or two, the development team inevitably found a number of issues with the processes that were not thought of by the analysts. Also, as some of the processes were implemented and the business analysts had the opportunity to actually "see" them, they invariably found something they didn't quite like and had new ideas for process optimization.
Given that the development team was working in short iterations, they were usually able to adapt to these changes. The issue was on the business analyst's side of the court and the requirement analysis brick that started it all. The changes that were discovered in one process usually impacted many others and therefore rendered much of the process requirement document's content obsolete sending the business analysts back to the drawing board. This led to a vicious circle repeating itself every couple of development iterations.
My experience with this BPM anti-pattern - which closely reflects the same problems that are experienced with waterfall based software development methodologies - along with my bafflement at the realization (during my attendance of the Gartner BPM summit earlier this year) that there was still no significant thinking being done to resolve it, is what led me to write this article: Kaizen, BPM, and Agile Methodologies. I hope that after reading it you will come to the conclusion that heavy-up-front-modeling BPM projects are not a good idea and that an iterative, incremental, and agile approach is more likely to be effective. I look forward to hearing your feedback.
