We all know what we need when we start a new project – that’s why we start it! Or do we?
Just because we have identified a problem or an opportunity to improve a process or piece of software doesn’t mean that we see all the issues or all of the requirements. It may seem obvious, but we can easily jump to defining the problem or the solution before we’ve determined the stakeholders.
I have a confession: when I think of the word stakeholder I have an image in my head of a Buffy type character about to stick a pointy stick into someone! That’s a good image to have, because stakeholders who are ignored in a project can come back to bite you (if you’ll pardon the mixed metaphor)!
The forgotten Stakeholder
The most commonly forgotten stakeholder, and coincidentally the one with the longest memory is the end user. We know that there are business process experts, programmers, project managers and a whole host of experts, but no-one knows the ins, outs and quirks of your business systems like the end users!
In most business processes that have been around for more than a year or two there are tips and tricks, fixes and work arounds that never get beyond the end user – unless someone asks. These are often show stoppers when a new or improved process is considered. If there is a particular feature that is used daily, but unknown by the project experts then that is the one feature that the end users will complain about post implementation (pun definitely intended).
Search out the Stakeholders
The first order of business, therefore for any project is to search out all the stakeholders – not just the ones who have a perceived expertise in the production of the new or improved process, but the workers at the coal face, the end users who know the process because they use it daily. The problem with unknown stakeholders is just this: they are unknown. The only solution is to cast your net far and wide at the outset of any project. It’s much better to have someone say ‘no, I’m not involved with that’ than to have them complain about lack of input after the fact.
Redefine the problem if necessary
Once you have cast your net and identified all the genuine stakeholders you can then begin to remap the process. You will inevitably find that there are differences between the theoretical process and the actual. All these modifications to the originally defined process must be included in the process definition before moving on to consider the direction of the project.
If you conduct this pre-project discovery process fully you will find that your project will have a smoother ride to completion. You will also find that the stakeholders will have acquired a sense of ownership that not only makes them happier about the project, but, because of the sense of ownership will also have a vested interest in the project’s success. Being a stakeholder, therefore, is a two edged sword – it can work against the project manager if he has failed to cast his net wide enough, but for the savvy project manager who has included everyone all these stakeholders in the project will have a determination to see the project succeed.