Many people make their fatal (in project terms) mistake right here in who-ville. They think that the person who hatched the idea or that the person who cares the most about a particular project is the only who that matters. That is really wrong. As it turns out there are probably many people who need varying degrees of information concerning your project at various intervals. The key to the first W is to understand them all and their needs.
To meet this challenge we have a great tool. It is called a Communications Management Plan. You have to be careful to right-size this approach, but all projects above a certain size (cost or duration or both) should probably have a Communications Management Plan. The Communications Management Plan must contain the following:
- It must have an org chart depicting the various business units and how they relate to each other.
- It must describe the process to be used in conducting a stakeholder analysis.
- It must describe all of the roles within the project.
- It must describe the different communications channels and appropriate use for each.
- It must contain the stakeholder identification form
- It must contain the stakeholder analysis.
All of these things are important, but they all build and contribute to the Stakeholder Analysis. The S/H analysis identifies the organizational unit of each stakeholder. It also describes the role(s) of each stakeholder. It identifies how the stakeholder likes to receive communication and the frequency. The really big thing though is the Power/ Impact graph. You need to plot each stakeholder on this table to understand which stakeholders have the ability (power) to either positively or negatively impact your project. Once you do that, these are the people who you will want to keep as happy as possible. The people who either have very little power or very little interest or both are less labor-intensive.
If you don't take the time to do this then it is likely that you will try to please everyone all the time. Tough luck. That cannot be sustained over the long term. You have to know which of your stakeholders are the ones to be happy and spend your influence on them. Don't waste time or effort trying to influence people who are inconsenquential to the project.
Was that an almost short post?
In my experiece, the key W is "who is performing the work". I have never encountered a project that succeedes or failed based upon the existence of a formal communications plan, a great project plan, or any other inception-phase artifact.
ReplyDeleteIt is important to have a product owner who is responsible for prioritizing and balancing the needs of the various stakeholders; however, creating a formal communications plan places the focus upon the definition of boxes and boundaries, instead of challenging the team to self-organize and focus upon delivering the actual product.
Do you think Google, Amazon, and Ebay go about creating formal communications plan documents before initiating a project?
Before engaging a formal project I do. Think about it like this, I have the best developers in the world. You could pick your all star development team.
ReplyDeleteBut we haven't taken the time to identify or qualify the stakeholders. This is an important aspect, we only meet the needs of "Qualified" stakeholders. I define that as someone who stands to win or lose from the project. (Thank you Mel DeGuzman wherever you are.)
I have worked on projects in which a specific segment of my stakeholders only stood to lose on the project. Guess what they did, they created roadblocks and delayed at every stage. Their one goal was to derail the project. I don't know whether they knowingly did that, but with my 20/20 hindsight it is clear to see. They stood to gain nothing from a successful project and I tried to meet their needs just like everyone else. That fact alone sunk the project.
Another situation in which the Who aspect turned out to be really important was when we were building something, an application. I got a list of stakeholders from the person who hatched the idea. Guess what he did. He only chose people who were sympathetic to his idea. In many instances you would be able to get to the finish line in this project, but his side was a very significant minority. As such the utility of the application was severly limited as to make it not useful. Thus in this example, the work of construction is a commodity. It really didn't matter how good or bad the dev team was. We built products to the exact spec. The problem was that the people providing the spec were the wrong people.
If you are going to throw money at the project I believe it is worthwhile to invest a little bit of time to identify an qualify the stakeholders. From the PM perspective I need these people to be the right people if I am going to devote effort to meeting their requirements. I also need these people to recognize that they are indeed stakeholders to the project.
I really do bet that when Amazon engaged the Kindle project in a formal way they performed this work.