The new Knowledge Area, stakeholder management, was cheerfully welcomed in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition.
Figure 1: Lack of stakeholder management leads to poor results. (Trentim, 2013)
Most of us rely on soft skills, communication and leadership to manage stakeholders. But while they’re helpful, interpersonal skills are far from being the sole way to implement stakeholder management. As a matter of fact, there are hard skills in stakeholder management — tools, techniques and methods that should be diligently applied to enhance stakeholder management and improve project success rates.
For example, there are at least 10 different tools for stakeholder identification. Often, project managers rely only on brainstorming to write a stakeholder registry, conforming to the methodology imposed by a project management office (PMO). That’s why I believe we need a paradigm shift.
A project manager’s goal is to add value. Value depends on stakeholder expectations and perception. Consequently, the project manager’s goal is to engage and involve stakeholders in value creation. This is what we call managing for stakeholders.
On the contrary, the term stakeholder management assumes we can manage expectations. This is wrong. We cannot manage people, to paraphrase U.S. author and businessman Stephen Covey. We lead people. We persuade and influence stakeholders.
In 2013, the Project Management Institute published my book, Managing Stakeholders as Clients. It presents a framework with a paradigm shift from traditional stakeholder management by first setting the premise that we can’t manage stakeholders or their expectations — we can only lead, influence and persuade people. To my surprise, I was the recipient of PMI Educational Foundation’s 2014 Kerzner Award* at PMI® Global Congress 2014—North Americafor my results in managing projects and programs. But in particular, the award recognized my creation of this stakeholder management framework and the results of its application.
The main difference between stakeholder management and managing for stakeholders is this: Stakeholder management’s goal is to manage stakeholders’ expectations, enhancing support and reducing negative impacts — a reactive measure. It’s almost as if project managers develop stakeholder management plans to protect themselves from external interference.
Managing for stakeholders means involving and engaging stakeholders in value creation, boosting their support and having them take ownership in a proactive way. Managing for stakeholders embraces change as a learning process.
While stakeholder management is instrumental, employing processes for conformity, managing for stakeholders is results-oriented. In summary, stakeholder management is an attempt to manage stakeholders’ expectations toward the project. On the other hand, managing for stakeholders is clearly oriented to manage the project and its results for the stakeholders, on behalf of their changing needs and expectations.
Now that it’s clear we should start approaching stakeholder management from a different perspective, in my next post I’ll share more tips and details from Managing Stakeholders as Clients. Don’t miss it!
How do you manage for stakeholders?
*The PMI Educational Foundationadministers the prestigious Kerzner Award. The Kerzner Award is sponsored by International Institute for Learning, Inc. (IIL)to recognize a project manager who most emulates the professional dedication and excellence of Dr. Harold Kerzner, PhD, MS, MBA.
Photo: Courtesy of tequilamike
Have you ever seen the award-winning movie Rush? In it, Austrian Niki Lauda, Formula One World Champion racing driver, lectured fellow competitor from England, James Hunt, on risk management. Mr. Lauda states that he manages to a risk factor of 20 percent; any conditions that produced risk over this factor could lead to a deadly accident. At the last race of the season, Mr. Lauda pulls over in a rainstorm as he feels there is too much risk. While this action hands the top prize to Mr. Hunt, Mr. Lauda is unrepentant in his action to pull off the road. He goes on to win more racing world championships than Mr. Hunt.
Projects are like racecars -- both are complicated and exist in environments where there are many moving parts. That's why, as with a race, knowing when to put the brakes on a project will be best in the long-run. Here are four warning signs that you need to pull over:
We are typically judged by the amount of progress we make as well as the outcomes from our projects. But we should also be judged on our ability to cease projects when the level of risk is too high. Although it might seem like a sign of weakness, stopping and re-directing a project incurring too much risk can reduce the potential overall cost and preserve its value proposition.
Under what conditions have you had to stop a project due to too much risk?
Project trouble can hit from a blind spot, even though you tried as much as possible to prepare for issues. You did a risk analysis when you took the project on, and even tried to be ready to mitigate unknown issues.
As I advised in my previous post, do an assessment to determine the problem. Figure out what needs to be fixed, or if the situation is even fixable. If the project seems to have reached a point of no return, here are some tips on how to pull it out of trouble:
Finally, keep in mind that not all trouble devours all. Before panicking, calmly look to areas that will guide you to a solution. You may even find your project is more sound than it seems.
How do you confront trouble on your project?
Best Weekly Status Meeting Ever
Categories: Project Delivery
Many project team members prepare for weekly status meetings with a sense of dread and resignation. These meetings often subject people to long motivational speeches, an overly detailed review of project tasks and even the unpleasant prospect of speaking about their specific progress in front of project leadership. Sometimes these meetings last hours, causing team members to rush to complete project activities. No wonder they make excuses to miss these meetings!
How can you, as project manager, structure a weekly status meeting so team members are engaged, informed and willing to contribute to the project's next steps? Here are some tips:
1. Start with the answer. The worst question to ask is, "What did you do this week?" It invariably generates unnecessary, time-consuming dialogue from team members. Plus, you should already know what everyone on the team did during the week. Avoid this time-waster by starting with a "project answer," such as:
Starting the meeting with a project answer produces confidence in team members and allows them to focus on remedies for schedule, budget and progress variances.
2. Structure discussion around risks and issues. After presenting the project answer, lead a group discussion on risks and issues. You should have a list of the current risks and issues along with their assigned "owners." Make clear before the meeting that risk and issue owners should come prepared to share the status of their item. In addition, they should have a path to resolution. If they do not, this is a clear signal for you to escalate the risk or issue to the leadership team.
3. Clarify and confirm upcoming milestones. As the last agenda item on the status meeting, you should highlight the upcoming two to three weeks of milestones and the path to completion for them. In addition, share your expectations on the progress toward these milestones by the next status meeting. This agenda item also serves as an excellent opportunity for team members to identify new risks or issues that may impair the team's progress.
4. Schedule the status meeting the second workday of each week. Project managers have varying opinions on the best day to conduct status meetings. Some prefer the first workday, thinking it will provide a head start on the workweek. Others prefer the end of the workweek, believing this maximizes the project manager's visibility to recent project activities. Personally, I find that holding the meeting on the second workday is the most beneficial. It allows time during the first workday to gather information for the meeting. In addition, the project team then has three full days to act on the milestone guidance from the last portion of the meeting.
These tips have worked well for me in leading effective status meetings. What's your number one tip for conducting successful status meetings?
Hardly a project status report goes published without at least one stoplight indicator. As the name suggests, stoplight indicators show the status of key project progress measurements: green (good to go), yellow (use caution) and red (stop or danger ahead).
In recent projects, I have noticed recurring instances of "stoplight overkill." Project status reports now include all manner of stoplights, such as how the last status meeting turned out or the happiness level of every single customer group. In fact, I have even seen a stoplight indicator that, through a complex calculation, was intended to show the aggregate status of 40 stoplights. The colors on that report made my head spin.
Beyond avoiding a headache, here are three major reasons why project managers should limit stoplights:
I favor more progressive and consistent modes of status presentation that indicate position, direction and pace.
For example, use a remaining budget marker to show the position of budget against a broader range of tolerances. For deliverables, you can show a scatter plot of projected and actual completion dates to reveal pace and true progress. Highlighting customer satisfaction on a timeline is a good way of showing the impact of a project on a sponsor's business.
What do you consider the limitations and dangers of project stoplights? What alternate methods have you used on project status presentations? Share your thoughts below along with your Twitter handle, and Voices on Project Management will publish the best response as a blog post.