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?
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.
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?