Stakeholders Can Kill You Even if You're Not a Vampire

In my previous post I said that if you don’t manage your stakeholders you are in a lot of trouble, but I didn’t back up the claim. You may believe that stakeholder management is touchy-feely stuff, one of those things management consultants come up with to make the simple appear complicated and justify their fees. After all, people will do what they are told; the important thing is to come up with a project plan and hold everyone accountable for following the schedule, right? Right?

The truth is that a project without stakeholder support is like a vampire with a stake through the heart. But, unlike Dracula, your project is unlikely to return from the grave.

If the stakeholders don’t want the project to end, it never will. In a particularly dramatic case, a company launched a project that would streamline most of its business processes. Of course, everyone knew the end of the project would probably mean the end of many jobs, so those who felt threatened found creative ways to sabotage the project. The sentiment was so widespread in the company that rumor has it that people were saying "Long live the project!" out loud in the hallways. The last time I heard about it, the project was two years late.

Unwilling stakeholders may not perform the tasks that only they can. For example, in every BPM project there is knowledge that is locked inside the brains of key employees. If they don’t want you to have complete and correct information, well, you’ll never get it. When it becomes obvious that the project is off-track and you try to explain why, they can simply claim that you’re making up excuses. How will you prove otherwise?

In one project I worked on, a member of the organization started playing the "what if" game. "What if there is an unrecoverable error in this transaction? How can we roll it back?" This is the concerned citizen ploy. It sounds like a sensible remark, but what it meant was that we had to make the process about five times as complex as necessary to account for an exception that would unlikely never occur. After a customer order had been input in the CRM software and produced a production order and an invoice, this concerned citizen wanted the process to predict the possibility that it wouldn’t be possible to schedule the delivery. The obvious answer would be that someone would have to handle the exception using the existent procedures. But no, no, we can’t risk mistakes; the process must handle explicitly this and every conceivable error condition. And after you’ve done this for one process you have to do it for every process.

Remember also that in most BPM projects you’re an outsider and the disgruntled stakeholder is an insider. You may be a consultant, a Black Belt, a project manager or whatever; the bottom line is that you probably are not part of the team that is most directly affected. If one or more members of that team don’t want the project to succeed, they may have readier access than you have to the people higher up in the hierarchy. Heaven knows what they’ll say to the Powers that Be; you certainly won’t know, but you’ll feel the effects.

Even if they’re not actively against you, stakeholders may not bother to help you. In one project the line manager whose team I had to interview cautioned me against taking too much of his people’s time. What he meant was that I was not allowed to interview them. Go figure how he expected me to complete the project.

This case shows that, when you don’t get the key stakeholders on your side, even if you succeed you fail. I went ahead and interviewed the people I had to, got the information, although with a lot more effort than budgeted. We finished the project, the company reaped the business benefits it was seeking, but the line manager was sorely peeved. Since he reported directly to the executive officer who had hired us, the opinion that mattered was that the project had been a failure. They never paid us for the extra work and we never got repeat business from the organization.