Agile project management is indeed the time, especially in IT projects announced total. More and more companies are interested in Scrum, XP and Co. fail because many projects are carried out by conventional PM methods. The reasons are often the complexity of projects and poor communication.

The same problems I also know from BPM projects. It loses itself in process modeling, analysis and design in detail. These phases often take several months. The processes are designed according to the analysis are no longer at the beginning of the design-date, but after yet implemented in any system. In effect, the processes are not fit to the already long been a changed real business.

Works best in this environment, an agile approach?

Scrum is not only suitable for development projects, but can also be a "normal" project management method used , and also pure outside the development . In the area of ​​BPM, we are indeed only a part of IT. Large parts can be realized only with IT support (eg, modeling, analysis, design, optimization, etc.). Here I have noticed time and again that some companies are already intensively documenting their processes. Unfortunately, the processes after the initial recording is updated only seldom. Moreover, it takes very long until the processes modeled to the smallest detail, is designed and analyzed. If these steps are passed, no one dares often times very easy to customize the process. Here is an agile approach would be interesting.

Agile process models are particularly suitable when editing complex issues or the exact amount at the beginning of the project can not be fully detailed. That's true of very many projects. Often the processes are not known prior to modeling or out of date, so that these need to be rebuilt or upgraded. When I process model for the first time, then I can start modeling the roughly mark out the scope and content of the process. Anyone who claims to be able to make more lies. According to the modeling and analysis and more detail and identifies the information must be built into the process. Here one could proceed agile and iterative. First, a process roughly be staked out and modeled. This modeling can be analyzed and worked out with the known details in the design. In the next cycle can be created to validate the process model and enriched with new insights. Could just as the processes with BPM technologies are implemented. This would very quickly get a first runnable process, the first reflects the real Geschäftsprotzess rudimentary and can be expanded gradually.

This reminds me of, but immediately the first problem. A process should have a specified input and output. If in the various iterations of the process input and output must be adjusted, if necessary, other dependent processes are influenced by it. The interfaces between the individual processes are not consistent. So you should make sure that in the first iteration the interfaces of a process described as clean and complete. In subsequent cycles, the process can then be filled with more and more content. It should be noted that the process with new activities to be enriched, the activities should be implemented directly as possible but in itself completely. Individual activities to be implemented iteratively results in various disadvantages: If a user is involved in this activity, must adapt to this with each iteration, a new way of processing activity. Moreover, the familiar phenomenon could occur, which is an interim solution to the final solution, and so not the full optimization potential is exhausted.

The thinking about how to divide a process into several work packages for the Scrum team is also of great importance. What are the activities of a process must necessarily be implemented jointly. An iterative approach in my opinion is especially useful processes, which have extensive ramifications with several parallel activities. These can be added gradually and the parallel processes are extended.

In the next few days, I would like to sit still like to deal with the possibility of agility in the other areas of BPM (process implementation / introduction, performance measurement process, Sub marriage Mens process management) and especially with the point process documentation. Because the documentation is loud BPM CBOK ® is a critical success factor for BPM.

So soon for more agile business process management.