Stakeholder Management – Pay Now or Pay Later
A student in my TME3133 Managing Engineering and IT Projects asked a very good question a couple weeks ago: How far do you go with regard to stakeholder analysis and expectation setting – with all the potential stakeholders and impacts, it could go on forever… Very true. As with much of project planning, a ‘reasonable’ limit needs to be applied based on the size, complexity, and priority of the project.
The first step is to identify your stakeholders. The Project Management Body of Knowledge (PMBOK) defines stakeholders as “Persons and organizations such as customers, sponsors, performing organization and the public, that are actively involved in the project, or whose interests may be positively or negatively affected by execution or completion of the project. They may also exert influence over the project and its deliverables.”
Given this definition, the list of stakeholders for most projects can be quite long. However, the list can be prioritized by determining who has the most influence and who has the most to lose or gain (interest). Key stakeholders are those who have a great deal of interest and influence – these stakeholders need to be tightly managed. The level of influence and interest a stakeholder has in the project can vary with time throughout the project. For example, the HR department of the performing organization might be included on many stakeholder lists – but for most projects, they will have little influence and little to nothing to lose or gain. On the other hand, if your project is going to require the hiring of a large number of staff to complete the work, or if the result of the project may lead to a significant reduction is staff – then they will be a key stakeholder whose interest will peak when they are most impacted.
Influence is typically thought to mean those who can take action to help the project succeed or fail. In some cases though, a stakeholder can help the project fail simply by doing nothing at all.
I recently went to coffee with a project manager who was working on a project to develop and launch a new service to consumers in Atlantic Canada. I can’t go into details about this service, so let’s just say it’s an online shopping type of service. His sponsor, the primary stakeholder, was responsible for the consumer market segment. During the initial stakeholder analysis, it was determined that the sponsor’s peer responsible for the business market segment was a minor stakeholder because on a scale of 0-3 they rated:
- 2 for potential for gain
- 0 for potential loss
- 1 for influence
The sponsor reasoned that since it’s his budget, and it’s targeted to his customers, he is the only one who needs to sign-off on the project. The business stakeholder should just be happy that their customers will receive the benefit of a free service at no cost to the stakeholder. Although arguments and issues were raised, the business stakeholder was put on the “informed” list. As the project progressed however, it became apparent that they would need more and more support from this stakeholder. In fact, without this stakeholder on board as a partner the project could not succeed as consumers can’t shop if there is nothing to buy – and it’s the business customers that bring that to the table. It turned out that the business stakeholder wasn’t satisfied just being informed, even if they did have the opportunity to benefit at no cost of their own. The result? The service is developed and ready to launch, but has nothing to sell. In order for business to be brought on side now, the project will have to take a couple steps back and include this stakeholder on design decisions that may now be much more costly and time consuming than if they had be brought in early on.
This particular example may seem too obvious, but in fact this type of situation happens a lot more often than you might think. There are still a lot of organizations who practice product and service development in a vacuum. Little to no stakeholder analysis is done, those with the budgets make the (uninformed) decisions, and projects are delivered on time, on budget, and to specification – and are also failures. One of the top reasons for short changing stakeholder management is time – it takes more time if you have to involve more people or groups. This is usually true – however, it’s rare a project will be a success if they are not included. So it’s pay now or pay later.
Ever use a product or service and think to yourself “did they ever ask the end-user how this should work?” Have you ever been a part of a project that failed to identify an important stakeholder, or intentionally left them out in the cold? What was the result?
-Troy Kearns, PMP
TME 3313 Instructor