Last week I talked about the scoping of a BPM implementation and argued that you need to determine what process domain or end to end process would benefit the most from having a BPM framework applied to it. This week I’ll discuss the next step in your project: the planning of a BPM implementation.

And just to set the right level of expectations, this blog will not deal with all of the detailed little parts of setting up a project plan for the roll out of BPM, but it will try to paint a picture of the elements that are needed and some pitfalls to avoid. 

In the picture below I put together a number of important topics to deal with when thinking about and defining a planning for your BPM roll out project. Now before I go into any of the content in this picture, I would like to describe the biggest pitfall I have encountered during a number of the roll outs I managed myself or reviewed afterwards at our customers. 

The single biggest pitfall is to not communicate frequently from the get go and there might be plenty of people disagreeing with me here, but since this is my blog I have sort of a veto on this. A just to put the gravity of this pitfall into perspective let me pull out an old hobby of mine: astronomy. If your average pitfall in the roll out project is the size of earth, not communicating frequently from the start is about the size of our Sun. How do they compare, you ask? Look at the picture below: see the four little specs at the bottom, the left one (the darkest) is our earth. The orange giant is the Sun. Johnny Depp would say: savvy?

Seriously, the reason for over-exaggerating the impact of this pitfall lies in the fact that building up a stakeholder community, a group of ambassadors if you like, from the very start is of vital importance for a BPM project. I’ve seen too many BPM implementation fail because despite the excellent work the project team did, they forgot to communicate about it (and by doing so, failed to engage the end users and owner for the deliverables of the project). Silence means, the stakeholder disengages and starts to wonder what happened with the budget that was allocated to the BPM project. The project team then has to go into full accountability mode (which is a defensive move) and that is the same as getting stuck in quicksand. 

So, how to mitigate this major pitfall? First and foremost, make sure you have a communications professional in your project team (and later one make sure you hire those services for your CoE as well) and set up a number of different messages (for different audience groups). Decide on the drumbeat (frequency) of the communications and make sure this drumbeat aligns with the frequency of delivering milestones (to make sure you got something to talk about). If your project team is planning on making quarterly deliveries (and this can be anything, from installing the platform, or finalizing the modeling conventions to the go live of the first wave) then make sure that your communication drumbeat also is quarterly. Sounds simple, is less obvious than you would imagine.

In the light of this pitfall, the other one I would like to give some attention is the definition of the milestones. The saying “ time flies when you’re having fun” of course is true, but also when you’re struggling to make the deadline, time seems to go very fast. In other words, make your milestones achievable. It’s better to take one or two milestones more, but you do deliver every milestone than it is to stack too much into the milestones and fail to deliver. 

Basically, come to think of it while writing this down, planning a BPM project has a lot of similarities with planning any kind of project, really. Stakeholder management and realistic planning are two key ingredients of any good project plan, but for BPM projects, that for a long time have been the sole responsibility of IT, this is particularly true. That is also why I think that the trend where BPM is becoming more and more a business matter is a very positive and desirable trend. 

Having said that (and the rest), please do not forget to communicate frequently. It’s sort of like writing a weekly blog: sometimes it’s just not convenient or you simply don’t feel like it, but once it’s done and published, you feel great about it. 

Enjoy your weekends!

Ciao, Caspar