Voices on Project Management

by , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with - or even disagree with - leave a comment.

About this Blog


View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Cecilia Wong
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy

Recent Posts

How To Improve An Underperforming Team Member

Level 5 Leadership: Taking Your Project from Good to Great

Sprinting a Marathon

How Managers Can Grow Into Leaders

Managing The Last 100 Feet

Managing for Stakeholders — Not Stakeholder Management

The new Knowledge Area, stakeholder management, was cheerfully welcomed in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition.

We all agree on the importance of stakeholder management. It’s common sense. However, it is not common practice. Few project managers have a formal approach to stakeholder management. And many organizations lack guidelines to manage stakeholders.

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.


Figure 2: The virtuous cycle—as opposed to the “vicious cycle”—for managing stakeholders (Trentim, 2013)


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.

Posted by Mario Trentim on: November 25, 2014 09:53 PM | Permalink | Comments (1)

4 Signs to Pull Over and Stop a Project

Categories: Project Delivery

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:

  1. Accumulated issues with no path to resolution. It is common that during the course of a project, we capture and determine a path to resolution for issues. This path can sometimes involve an escalation to a higher level of leadership. However, if the project has incurred multiple issues where a path to resolution cannot be determined, it has reached a point where these issues will impair both current and upcoming project activities.  
  2. Unstaffed key or multiple roles. We're all challenged to find the right level and skill fit of resources for our project teams in a timely manner. For some specialized skills, it may take weeks to find the right kind of resource, which is why many project managers now build staffing lead time into their project plans. But when a project has either key or multiple roles unfilled, typically three to four weeks beyond their planned staffing date, it will start to cause a drag on the project. This drag occurs from tasks that are due to start with no resources available to do the work. 
  3. Lack of sponsorship. I have experienced unplanned exits of project sponsors for a variety of different reasons. I have also experienced project sponsors that are not willing to sponsor anything about a project. In both of these cases, you need to find a new project sponsor, fast. Without a sponsor, a project will not have the key decision-maker needed to guide its long-term course. While the typical remedy is just to keep working on the project, an unfilled sponsor role is setting your project up for a lack of attention and visibility within an organization -- and ultimate failure.
  4. Unclear or fluctuating success criteria. A project must have a clearly understood set of success criteria. However, changes in project sponsorship, business conditions and other internal/external factors can sometimes cause major changes in the success factors of a project. If any of the success criteria change, it is a good time to pause the project. Based on the new success criteria, work with the project leadership team to re-plan the activities, schedule, resources and budget for the project.
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? 
Posted by Kevin Korterud on: March 27, 2014 10:14 AM | Permalink | Comments (0)

Getting Out of Trouble

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:

  1. Seek out your sponsors. They should be the source to go to when trouble arises. Not only is it likely they will have encountered something similar in the past, but they can also provide additional budget funds, more resources or reinforcement for areas in conflict.
  2. Consult with your team. Bring everyone together, discuss the problems surrounding the project, and begin to discuss counteraction and next steps. Steer away from blame and trying to determine who is at fault. Beware especially of ganging up on the customer. Team members may want to take the position that it's the customer's problem, not the team's. But be clear that the point of getting together is to determine how to solve a problem project, not pass it off as someone else's fault. Instead, gear questions toward possible solutions and the support needed to achieve them. 
  3. Rely on backup and supporting information. Most likely, you will have monitored risks and issues all along and kept a good repository on your project. If so, you will be able to locate the exact information that helps address your problem. For example, you may be over budget because equipment purchases ate even beyond what your contingency allowed, and now a project sponsor or customer may be questioning the overrun. You should be able to pinpoint the authorization you received to make that purchase. 
  4. Enlist outside resources, if needed. Lessons learned or a fellow project manager could be consulted for knowledge transfer and experience. You could even call in an outside contractor for a specific need. 
  5. Remember that a halt is an option as well. Most times, this is seen as negative, and the project is considered a failure. But that is not necessarily the case. Sometimes, halting the project is the necessary solution, and it doesn't have to have horrific implications. If it isn't halted, the project could accumulate astronomical costs. The trouble could consume the project to the point where it would need to be shut down. A halt can also help you assess if the project is still meeting objectives (which could be the source of the problem). Stopping the project in its tracks could help you to determine if you need to redirect funds and/or resources. 

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?

Posted by Bernadine Douglas on: October 15, 2013 10:25 AM | Permalink | Comments (3)

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: 

  • The current schedule position of the project. Example: "We are two weeks late." 
  • The current budget position of the project. Example: "We are at planned budget." 
  • Progress toward the next key milestones. Example: "We are 50 percent complete with the process model." 
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? 
Posted by Kevin Korterud on: October 09, 2013 01:46 PM | Permalink | Comments (5)

Three Reasons to Dim Project Stoplights

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:
  1. Stoplights are not progressive. Project stoplights typically have only three indications of status. They can't show a range of progressive tolerance, trends or rates of change. For example, a yellow stoplight can be overly optimistic if the value for that stoplight is just shy of the range for red.
  2. Stoplight bands mean different things to different measurements. Stoplights break down into bands of tolerance ranges. For example, zero to 5 percent variance would be green, 5 to 10 percent variance would be yellow and above 10 percent would be red. The problem is, project measurement indicators might not follow a common range. For example, how realistic is it to measure customer satisfaction with the same band as test case validation? While test case validation might make sense at 7 percent, it would be discouraging if just 7 percent of your customers were happy with your project.
  3. Stoplights can be "gamed." A major vulnerability of project stoplights is that they can be manipulated by project managers and sponsors when either wants to defer an unfavorable status. Despite the actual value of the project measurement, the project manager or sponsor will leave the stoplight to a green (favorable) value. This "gaming" of project stoplights usually precedes the inevitable -- rapid acceleration of stoplights to a red (danger) value when hidden details are discovered. 
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.
Posted by Kevin Korterud on: April 17, 2013 02:01 PM | Permalink | Comments (4)

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts."

- Bertrand Russell