Voices on Project Management

> Back to Voices Home

More posts in Project Delivery

4 Signs to Pull Over and Stop a Project

| | Comments (0)
Voices_Kevin_StopProject_TequilaMike.jpg
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? 

Getting Out of Trouble

| | Comments (3)
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?

Best Weekly Status Meeting Ever

| | Comments (5)
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? 

Three Reasons to Dim Project Stoplights

| | Comments (4)
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.

Boost Productivity by Renaming Tasks

| | Comments (3) | TrackBacks (0)
Do you assign yourself a task that's actually framed as an expected result? For example, creating or updating a report is a task, while producing a report is a result of that activity. Or, performing a troubleshooting session is a task; solving a problem is an expected result.

Language impacts how we work and what we accomplish. This reality is illustrated in project management through the use of the work breakdown structures, for example, where we break down the tasks and label them appropriately to be able to execute them. The work seems easier to accomplish that way.

To be productive, tasks need to be executable and controllable. Tasks framed as results are ambiguous because they do not specify an action that can be carried out -- instead, they imply that you will figure out the real action you can do and accomplish.

I find that I get a lot more done when I put a task on my calendar that I know I can control. For instance, I can control hosting a meeting, but I can't control the meeting's outcome. Therefore, the task, "Chair a solution review meeting" has more power than "Get the team to approve a solution." 

When our mind considers a task to be particularly important or ambiguous, it tends to look for an easier outlet or for ways to delay working on that task. It's only when we reword the action in terms that we can understand that we jump to execute the task. The key, I find, is in wording the task as something over which you have actual control.

Look at the work you planned for today or the next seven days. Reword your actions and tasks so that you can have complete control over them. Notice what happens to your productivity and report back.

Have you seen a productivity boost from renaming tasks? 

Are You a Project Driver or Enabler?

| | Comments (10) | TrackBacks (0)
Project managers are tasked with many simultaneous responsibilities. They manage and drive the delivery of a project while managing their team to deliver results according to the business expectations, on time and on budget. It's no small feat when this is accomplished seamlessly.

As a project manager, many times I find myself to be the driver, serving as the catalyst for movement and action.

A driver is someone who takes on the responsibility and accountability for the project deliverables. So, in addition to day-to-day team management, I drive the alignment of the team to the project plan, maintain quality standards with the delivered work and determine the project execution and communication methods.

Enablers act as complements to the driver. They go beyond the task of effectively driving the project activities and focus on the elements that empower the team by fostering a strong work ethic, high morale, satisfaction, and attaining personal and professional accomplishments. Enablers are very good at working with all the team members -- internal and external to the project and organization -- in such a way that allows everyone on the team to:

•    Align to the overall goal

•    Emotionally connect to why the project's overarching goal is important

•    See their own purpose on the team through their contribution and knowledge

•    Feel validated for their inputs and recognized for their efforts and outputs

Enablers add life and color to the project. They are known as the glue that keeps the team together. An enabler can exist within the project team, and he or she doesn't have to be the project manager.

The great value of project managers serving as enablers is that -- when combined with their authority, they are able to drive the project and enable their teams to deliver higher quality projects and longer lasting results. This value is reflected in the quality of the product or service, processes and process adoption rate, plus greater organizational awareness and integration.

Are you an enabler or a driver? Do you think it's most beneficial to have the project manager as the driver or the enabler? Why?

About This Blog

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.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll