A common problem we used to have on many of our projects was with a certain regulatory body. They were very slow, and you never knew how long the project would be delayed before they even began their review. The frustrating thing wasn’t even so much when they came back with required changes or additional information, but when they didn’t! I mean, you’d wait an excruciatingly long time only to have them say “go ahead, no problem.”
I can only imagine that some people in the industry promised things they couldn’t deliver, because they weren’t as familiar with the regulators as we were.
If you’re one of those people that’s managing a project in an environment you’re not complete familiar with, unexpected things like that can happen and derail the project.
Major Reason for Project Failure
I’ve seen many survey results about project failure over the years, and without citing any one survey I’ll just mention the stakeholders are almost always cited as the number 1 or 2 reason for project failure, right after scope.
It’s all about Expectations
The important thing to note about stakeholders is that they have expectations. They are not carrying out the project, and they might not even know what happens on a daily basis. But they have an interest in it and often the ability to derail it.
Thus, stakeholder expectations are often a critical success factor.
Expectations that are Uncertain
Just to make things more difficult, their expectations are often intangible and contain large grey zones.
For example, a landowner near a new wind power installation might be highly sensitive to the sound and/or the shadows, but how much will they tolerate? They probably won’t even be able to give you a definitive answer as to what their expectations even are. There are options – Maybe a different turbine model can be used, or the sound can be muffled. But how much is enough? During the planning stage you cannot provide definitive answers to the stakeholder and you are not willing to commit to spending large sums of money to make sure you can satisfy them. This is a common scenario.
Perceptions over Reality
Often the perception of risk is more important than the actual risk of something occurring. For example, a person that lives near the new Keystone XL pipeline in Nebraska is probably worried about health effects from a pipeline spill. But the stakeholder is being influenced by social attitudes toward pipelines. In reality, the stakeholder’s mere perception of pipeline safety will influence the project, and it’s precisely this perception that can be fickle and subject to change with political or social values.
But just as the stakeholder’s perceptions can stop the project, they can also be influenced. The pipeline proponent could provide data on things like actual failure rates, affects, and scientific studies that could sway the individual stakeholder perception in the pipeline’s favor. Likewise, pipeline opponents could produce data which sway the stakeholder away from the project. Regardless of which side of the pipeline debate you are on, the point is that stakeholders can be influenced. Hopefully your project is less complex than Keystone XL.
- The stakeholder is heard and their concerns are listened to.
- The proponent is open and honest with their intentions and motivations.
- Regular communications such as project updates are supplied.
- Contact is made before major events take place.
Notice I didn’t say the stakeholder’s concerns are mitigated. Whether or not you can do what the stakeholder wants is a project specific issue and can involve budgets you don’t always have control of. The four things above should be done regardless of whether you have the budget to perform mitigating actions, but I would also add that spending a small amount of money to perform those actions usually goes a long way towards satisfying stakeholders.
Each stakeholder can be classified into one of the following groups:
- Unaware: Oblivous to the potential impacts of the project.
- Resistant: Aware of potential project impacts but in opposition to the project.
- Neutral: Aware of the project but neither supportive nor opposed.
- Supportive: Aware of the project and supportive of it.
- Leading: Aware of the project and actively engaged in its success.
Their category can change throughout the project, usually because of communication (or the lack thereof).
Stakeholders should be actively managed. If not, they will start to turn on the project and provide a tremendous headache (as well as additional costs or delay) to the project manager.
Stakeholders and Project Changes
Stakeholder issues very often boil down to the lack of communication when project changes occur. In fact, if you limited your communication to just the points of project changes, you’d probably do okay.
As you probably already know, projects almost never hit their original target without some sort of changes to the scope, budget, quality, or something else. These changes need to be communicated with the stakeholders. Whenever a change happens, you need to consult the list of stakeholders, decide where they are on the above awareness and supportiveness scale, and initiate the appropriate communications.
Communications Management Plan
To ensure strong commmunication with all stakeholders, you could create a communications management plan. Although you obviously need to communicate with the relevant stakeholders at anytime, most projects have standard communication requirements that are ideally put in writing during the planning stage. These might be monthly progress updates, investor circulars, interim completion reports, etc. The plan could contain the following information:
- Stakeholder communication requirements
- The information to be included in each communication
- Reason(s) for the communication
- Person or group(s) who will receive the communication
- Conflict resolution process
Trust can mend almost any potential conflict. The odds of finishing the project with completed goals are increased many fold if the project manager succeeds in building trust – in themselves, the organization they represent, and the project owner. This involves constant discussion with the applicable stakeholders, particularly on the listening side.
You’d be surprised how often project managers approach stakeholders with an “us vs. them” mentality. Attempting to ram something through, displaying power, or taking the attitude of “doing whatever it takes to get them on board” almost never results in successful outcomes, no matter how insignificant the stakeholder is to the project.
Early in my career there was point where I began to look at government regulatory agencies more as partners who wanted to be informed and worked with, as opposed to cost factors that should be pressured to allow the minimum possible requirements (like I had been taught). The result was not only prompt reviews and approvals, but requirements that were usually lower (as well as associated costs). Often reviews for smaller projects were waived entirely when they saw that I was in charge. My good relationships with regulators was immediately, and I think successfully, used to gain more work. Even today I use those relationships to get projects back on track within my company.