In such situations, tools such as stakeholder maps, stakeholder influence matrices and stakeholder registers rarely get used beyond the scoping phase, and the project team is forced to deal with stakeholders in a reactive manner without an established strategy. The purpose of this article is to set out several techniques that can be employed on complex projects either individually or collectively, and in any combination to effectively manage stakeholders.
Differentiate Between Motives and Expectations
This is easier said than done. What motivates stakeholders is not the same as what they expect from projects. Expectations are usually collected through face to face interviews or by filling in specific forms. The onus is upon stakeholders to be forthcoming about their expectations, whereas motives are concealed and they are rarely discussed. Unlike expectations, motives are the real drivers behind the way stakeholders think, act and behave. While expectations are just expressions of intent captured at the outset of the project, and usually remain static during the course of the project work - unless of course the stakeholder is changed or has a change of heart.
Project teams find it extremely difficult to distinguish between motives and expectations. This is because they are conditioned to think about, analyse intensely and track vigorously expectations. Subsequently, knowing about expectations of stakeholders is of limited usefulness when it comes to managing them. What is needed is a comprehensive picture about the motives of the stakeholders engaged with the project. Apart from asking a direct question and getting a direct answer there is no easy way to arrive at this information.
One way of ascertaining this information, is to study carefully what stakeholders say and do in their natural line function or work habitat. A high degree of convergence between word and deed will reveal the true motive. Conversely, a steep divergence between word and deed will indicate that stakeholder has a different motive. For instance, a stakeholder in numerous project meetings is verbally supportive of the project, but does not lift a single finger to aid the project. The same stakeholder in line management meetings is quite unsupportive of the project in both word and deed. By carefully observing the behaviour of the stakeholder in multiple situations one is able to arrive at a clear picture as to what motivates the stakeholder.
Obviously a detailed study cannot be carried out for each and every stakeholder to determine their motives. For such stakeholders speaking to people who know them well may provide a good basis to develop a picture about their motives. A similar approach can be used to evaluate the motives of external stakeholders such as third party vendors and consultants.
Once the project team possesses such intelligence it becomes easier to align expectations to stakeholder motives, predict stakeholder behaviour and establish mechanisms to ensure the right buttons are pressed for stakeholders to support the desired project outcomes.
Not All Stakeholders Are Equal
Treating all stakeholders equally is a recipe for project failure. On the ground reality necessitates that each stakeholder has to be treated differently depending on the circumstances. Some need to be cajoled, a few have to be reminded politely and others require executive intervention to get them engaged. Likewise, there will be times when the most powerful stakeholders have the full attention of the project team, while other stakeholders are completely ignored. Occasionally, there will be situations where a small minority of stakeholders are either publicly reprimanded or praised to ensure the success of the project.
Simply put there are no fixed styles for looking after stakeholders, and it is incumbent upon the project team to develop a repertoire of styles to deal with all manners of situations. With experience the project team will become more apt at picking the right style to manage stakeholders.
It is impossible to keep all stakeholders engaged, aligned and happy at the same time about the progress of any project. On complex projects the problem becomes much more acute and difficult decisions are either delayed or put permanently on hold. In such circumstances, the project team has to form alliances between different stakeholders to take critical decisions in the best interest of the project. For instance on transformation programmes, IT and Commercial maybe dead opposed against the outsourcing work stream shifting work offshore to a particular country. In contrast Finance, HR and Operations believe strongly in the benefits of offshoring to that particular country. Hence in this situation the project team may from a temporary alliance with Finance, HR, Operations and a few executives from the C-suite to select the country for the offshore work.
A feature of revolving alliances is that they are temporary in nature and usually take place when the interests of several stakeholders converge. Once the critical decision has been taken the alliance usually comes to an end. As the project progresses fresh alliances are formed from different stakeholders - often pitting former allies as adversaries in the new coalition. For instance, in the aforementioned programme example, stakeholders from IT, Operations and HR may form an alliance with the project team to stand against Commercial and Finance for launching a product prematurely.
Mastering this technique can prove invaluable at times, but its success depends on anticipating when the alliance is required, dividing the opposition and a single point agenda. The broader the agenda, greater is the failure rate for the alliance.
Picking the Right Fights
On complex projects there are always going to be occasions where the project team is tempted to engage in battles that it believes are necessary for the success of the project. There is nothing wrong with this attitude, however, the problem arises when the number of battles becomes too great to handle, and there is a risk of losing the war.
The project team should only pick battles that are critical to the success of the project, and are winnable. Any battle that falls outside this ambit is simply not worth the effort and may damage the reputation of the project team.
To avoid fighting unnecessary battles the project team should for each stakeholder define acceptable levels of behaviour. If the stakeholder remains within the boundary, even though the person carries out actions that undermine the project, the project team should overlook bad behaviour. Nonetheless, if the stakeholder violates the limits and it is deemed critical to the success of the project then the project should engage in the battle.
These are just some of the techniques that can be employed by project practitioners when managing stakeholders on very large complex projects.
Don't forget to leave your comments below.