Why internal BPM projects fail?

[READ TIME: 5 mins]
We have just completed a 12 week project where I have been the Program Manager for a critical business transformation project for a multi-national company that delivers major ($1-10 billion) construction projects. The first phase, which has just finished, was a proof of concept. The objective was to develop a hierarchical process map for their Deliver Construction Project process. But as it is so huge – 90% of the employees are engaged in delivering construction projects – we were asked to only map down a few levels. In fact in many places we went down much further. Down far enough to prove that the approach would work, to build a business case for roll-out, and to develop implementation plans.

Innocent bystanders

Therefore my team facilitated the workshops and developed the process maps. The client staff were the subject matter experts in the workshops; engaged but innocent bystanders.

For the next phase the client has just decided that they want to pick up where we have left off. They want us to train a couple of their team to use the mapping tool and they will take it from there. But I can see that this could be high risk approach. They have been involved in some workshops and mapping. They have not been exposed to what is the most important part; thinking about how to personalize and present the content to their employees so that they actually want to use it, and then encouraging or driving adoption.

Don’t get me wrong. I have absolutely no interest in spending the next year away from home working at the client. So my comments are not a way to generate follow on work for me or the team. But the client doesn’t know what they don’t know. The initial project had no element of skills transfer as it was not scoped or planned that way because it was expected that this would be in a second phase. Plus my team are so polished at facilitating the workshops, they have made it look easy. The client doesn’t really appreciate what is “going on behind what is going on”; the preparation before the workshop, the facilitation techniques, the years of experience of capturing complex processes and making them intelligible.

Sure, we have developed a detailed set of implementation recommendations that include the cost benefit case, implementation plans and technical implementation guidelines. But only when you start implementing the processes for real will you start uncovering the issues that need to be resolved. That will require a deep knowledge of BPM and experience of implementing process-centric programs.

Learning to drive is a lovely analogy.

To date the client has been sitting in the back seat and we have driven down a relatively straight road. The drivers (my team) are so skilled that gear changes and avoiding the odd pothole have been imperceptible from the back of the car. The ride has seemed beautifully calm and easy.

So running a product training course will teach the client how the car works. And we have given them a destination and roadmap; the implementation recommendations. But it will not prepare them for the issues on the open road; other road users, pedestrians stepping out, the driving rain or the odd patch of ice, whilst trying to remember how to change gear. Dealing with those without crashing is built up over years of experience on the road, and the inevitable near misses.

The client is considering asking us to spend a little time supporting them as they get going. That is analogous to sitting in the passenger seat whilst they learn to drive. As any driving instructor or parent of teenage children will tell you is a very scary experience: fighting the urge to grab the wheel. Some of you may remember the fantastic Bob Newhart sketch, “The Driving Instructor”.

Implementing a process-driven approach, changing engrained working approaches and getting engagement across hundreds of construction projects spread around the world makes learning to drive look like “Driving with Miss Daisy”.

Why go it alone?

So why does the client want to do it themselves? It is not because they are unhappy with our work, as they have told us several times how impressed they are with my team. They run huge, complex construction projects so perhaps they believe, having watched us that they understand what to do.

Or maybe it is the normal issue: cost. The value of external BPM consultancy is always questioned, particularly in construction firms who are notoriously tight-fisted. They probably think we are expensive, but we are not nearly as expensive as ignorance. And the cost of ignorance is not “getting it wrong”, but it is about “not getting it right”. We have conservatively identified $4m of savings per project which means $150k per day for the company if it was rolled out to just the major construction projects around the world. And they are running hundreds of these projects around the world concurrently. Implementing successfully in all those projects will have a material affect on the company bottom line.

We were too good

We have spent 12 weeks understanding their project processes.  I have run some large projects in my time, but that doesn’t mean I could do what they do after just 12 weeks. So why would they think that they could do what we can do?  Perhaps that is why BPM projects fail. It doesn’t look that hard. But they didn’t see “what was going on BEHIND what was going on”.   The preparation before workshops, the mapping to reconcile inputs and outputs and rationalize resource types after the workshops. And the experience built up form facilitating hundreds of workshops.

I hope it ends well as the client has been the best we have worked for in the last 15 years; 0pen minded, engaged and super organized. For their long term profitability, growth and success, they desperately need this to work. And they know it.