As our final article in this series on Project Management, we will investigate stakeholder management. While every project management topic covered in this series is crucial to project success, at the end of the day we want to positively impact as many stakeholders as possible, which means both executing the project and appropriately interacting with and managing stakeholders, their unique personalities, and their various expectations. In a recent project management coaching session with a friend who works in IT, he made the point bluntly by asking “Who are my stakeholders and how do I best make them happy?”
So what is stakeholder management? The Project Management Institute defines a stakeholder as “those who have a stake or an interest in a project or strategy undertaken by a company or an organization, they will be affected in some way by the project and so have an interest in influencing it.” Stakeholders can be either internal or external to the client’s organization. Internal stakeholders work within the client’s organization, and external stakeholders do not but still have an interest in the project. Stakeholder management involves the client reconciling “the differing stakeholder requirements and passing on clear direction to the project manager in order to gain a collective agreement and successfully complete the project.”
Four Stages of Stakeholder Management
As with all project management processes, stakeholder management can be approached systematically and broken down into four major stages:
1. Identifying the list of stakeholders to be considered and whether their interest is positive or negative (or neutral).
2. Clarifying the interest, involvement and the sphere of influence of each stakeholder/ stakeholder group in the project.
3. Agreeing on the process by which stakeholder engagement will take place.
4. Managing the ongoing relationship until the project is completed and adjusting as needed.
1. Stakeholder List
To manage stakeholders, we must first identify them. Often, we focus on the people who will benefit from the initiative and supporters of the project (financially and otherwise). Really, stakeholders include anyone with a defined interest in the project whether positive or negative.
In the case of my IT friend, stakeholders include customers, project sponsor, and the IT team that will design, build, and implement the project/product, in this case software.
In more detail, we then loosely identified stakeholder groups as people who:
When defining the stakeholder groups in detail, brainstorm the broadest list possible and then trim as needed; onboarding new stakeholders at later project stages can involve substantial work. Use of a Responsible Accountable Consulted Informed (RACI) or Responsible Accountable Supportive Consulted Informed (RASCI) matrix may be helpful in identifying roles and responsibilities during change management processes.
1. Interest, involvement, and Sphere of Influence
For each stakeholder group identified, my IT friend and I made a further list of the members of those groups, and we began highlight members who may have special requests or special interest in the project beyond that suggested by their organizational role.
Continuing with the grid, we assessed stakeholders that warranted individual attention and those that could grouped together. We then planned a series of meetings and calls to explore expectations, next steps, and the process for building the ongoing relationship with each individual or group. By paying attention to the sphere of influence, we discovered that several individual stakeholders had influence beyond the scope of their official role. We also added two stakeholders who did not initially seem to be impacted by the project:
· Head of Tax and Compliance – had expressed concerns to the CEO in the past about the security features of the existing software system and wanted to ensure the new system would address those concerns. This individual had a direct influence on the CEO and met regularly with the CEO to review the progress on the project.
· Front Desk Security Guard – had developed a friendship with the Head of Customer Experience who often invited this individual test new systems even prior to focus groups.
Remember to consider the sphere of influence and be ready for surprise stakeholders!
3. Agree on the Process by which Stakeholder Engagement will Take Place
In initial stakeholder engagement, establish the means and methods as to how future engagement will occur. After speaking with his stakeholders, my IT friend established the following menu of options:
· Weekly Lunch and Learns – agreed on Monthly
· Daily status emails
· Weekly status emails – signup offered so that those that do not wish to receive
· Monthly status roundup email
· Weekly status meetings
· Dashboard available in a shared location
· Weekly personal updates – phone or in person – reserved for project sponsor and senior management team (as a team)
· Vlog- video update combining PM on camera and a PPT of current concerns
· Open question time – an hour a day set aside when anyone can call and speak to the PM. First come first served
· Attendance at design meetings – as appropriate based on stage and product
· Attendance at prototype review meetings – as appropriate based on stage and product
· Weekly newsletter replaced with monthly status roundup
· Recorded team meetings shared online – no
· News wall – a wall of materials sharing details about the program progress, next key dates, key upcoming deliverables, Q&A wall
· Wiki page for the project
· FAQ on the project Wiki page
· Transparency of ALL project artifacts
· Bi-monthly project review and planning meeting for all interested parties
· Include updates from team leads – not all from the PM
· Surveys
Once the menu was established, we devised a communication plan that incorporated all these various forms of communication, and we assigned various team members roles for the appropriate dissemination of information. For example, one of his colleagues (with stellar penmanship) will update the “news wall” on Mondays, Wednesdays, and Fridays. As possible, switch up communication techniques to keep messages lively and interesting.
4. Managing the Ongoing Relationship Until Project Completion
PMI shares an interesting statistic: project managers spend more than 90% of their time communicating. My own research has shown that 80% of stakeholders and project participants (including project managers) expect PMs to provide context, purpose, and direction. When asked about PM importance, stakeholders and project participants largely agree that PMs provide a single point of contact and ensure constant and consistent communication. Interaction with stakeholders is critical to ensuring that project outcomes are predictable, consistent, and beneficial for the consumer. Benefit realization is essential to project, even more so than not exceeding project constraints, because sponsors may live with cost and time overruns if the ultimate return will be high enough. An on time, on budget project that does not deliver the expected return on investment is a failure.
Relationships with stakeholders are not static. Personnel and interest level may change or even be virtually nonexistent. For instance, a stakeholder once told me that his only interest was knowing when the project was done and being notified of completion at the end.
A common theme often heard from project managers is that communicating management is incredibly time-consuming. In my experience, the time spent discovering how individual stakeholders process information is a good investment that can often reduce the number of communication touchpoints required. When designed a stakeholder and communication management plan, consider:
· Detail vs. Summary
· Visual vs. Auditory vs. Kinesthetic
· Heart vs. Mind
· Feeling vs. Thinking
· Personal vs. Impersonal
And finally, the check-in. Establishing regular check-ins to ensure the communication plan is effecting will help keep stakeholders engaged and the project on track. Communication is necessary as a PM, but it can be organized smartly and efficiently.
