My way or the highway? – 5 recommendations for a successful BPM implementation

People that know me better know that I was educated in Maastricht: A university that trains you to find your own answers to questions, instead of getting them from lectures. One of the questions I got recently was “What do we have to do to make our BPM implementation successful?” I found there is no simple answer, no “My way or the Highway”. But I can certainly mention some aspects that should be agreed upon to make a BPM project a success.

An important aspect of “my” Maastricht University is that the education is “problem based”; targeting at finding answers to the questions yourself from different sources. Because of this I also tend to search for multiple answers to the questions I come across during work. And in my experience the answer to the same question is different from assignment to assignment. What is effective in one situation is not always the best approach in another. Only after balancing the different possible answers and putting them in context I come to a conclusion about the best answer given the circumstances. Therefore I find it hard to give THE answer to the question “What do we have to do to make our BPM implementation successful?” But I do know a number of aspects that are important. How these aspects are organized differs from project to project, and can (or will) be different per situation. I will discuss 5 important aspects below.

1 – Specifications and customer alignment

No BPM project can succeed without clear specifications or use cases. Among this I also include the business objectives and requirements. These specifications provide the guidance for the entire project team to ultimately deliver the BPM application as required. These specifications need to be validated by the future users as soon as possible. In this validation everything is allowed and only asking confirmation on user stories and flow charts is certainly not enough. You also need to think about visualizations, prototypes, mock-ups or whatever you and your project team are capable of creating. My only guideline would be: prevent doing stuff twice and do not make costs you cannot defend yourself.

2 – A clear description of the “Target Architecture”

If you ask 100 questions about architecture you will get 100 different answers. This not a problem. In most cases the answers you do get provide sufficient guidance to make your BPM project more successful. In my opinion the architecture must point out which functions and responsibilities are implemented in which business application. Only after all this is clear, the time has come to successfully implement a coherent process chain without continuous discussion. Or, taking the perspective from the other direction: without a proper architecture you will find many “put-holes in your highway”.

3 – Planning versus realization and lessons learned

If you and your team want to stay focused you have to continuously monitor your productivity. Whether this is in points or optimal man-days is not important. What is important is that real and reliable estimates of the effort are made, and that you monitor whether these estimates proved to be correct. If not, take every opportunity to learn and estimate better. These estimations only add real value if all activity until, or maybe even after go-live, are included.

Personally I think it is important to make the estimates on different levels, from an overall estimate per release until detailed sizing on the level of individual stories. The differences you find in the different levels can provide useful lessons for further improvement.

Even though I don’t like to spend too much time on administration, I think it’s a good practice to periodically perform a detailed analysis on what time is spent on, to find “waste”; productivity loss as a result of unnecessary, double or other activities that do not add value. This waste should be eliminated as much as possible.

4 – Collaborate in a responsible team

A good BPM implementation is teamwork. This does not only mean you utilize the talents and capabilities of each other as much as possible and help each other out in all situations ( even outside the comfort zone of each other). It also means that you take the responsibility together as a team. “I told you so” or similar for me means irresponsible behavior. For example, if specifications are unclear, jointly visit the future users directly, or do some assumptions and clearly communicate the consequences when the assumptions prove to be wrong, but at least act and take responsibility and do this as a team.

5 – Communicate, communicate, communicate

Last but not least my personal threat: communicate a lot. During a day, take sufficient time to communicate what goes well, what could be better, what about the planning, what we worry about, where dependencies appear, what we could do more, what we should do less, what we misunderstood, when we will release, what we expect from users, what our assumptions are, what we will offer, what will be missing etcetera. Communication is one of the most important deliverables for a development team. Too often information is assumed, or communication was postponed because something needed to be finished. That is not good! So… also as a reminder to myself: communicate!