Starting out as project managers, we begin to recognize the signals that point to project risks. Initially, these signals come in the form of status reports, work plans and delivery metrics. As we gain experience, we learn to sense additional risk signals that come from observation and dialog. And those signals originate from project managers themselves.
These signals sometimes go unheeded because the ability to act on them can typically be constrained. For example, there is fear of making project customers unhappy if you raise objections, unrealistic expectations and a false belief that these types of messages will somehow motivate the project team.
In my experience, here are some of the signals that have pointed to a project headed down the wrong path:
1. "We'll start the project at the kickoff meeting."
Many times, important project mobilization activities tend to be ignored in the haste to begin a project with a large group meeting. This fixation on the kickoff meeting causes key mobilization tasks to fall behind. Early action on staffing plans, on-boarding processes and communication mechanisms before the kickoff meeting are more important than making sure the chocolate chip cookies arrive in time.
2. "This project WILL finish on time and budget."
This signal typically appears at the first sign of progress or cost slippage. As opposed to dealing with the root cause of the slippage, many times project managers will shrink scope to meet time and budget. Reducing scope has the effect of reducing the overall value proposition for the project. Address this tendency by allocating sufficient time early in the project to identify business success criteria independent of schedule and costs.
3. "The CEO is the sponsor for this project or program."
Name-dropping typically emerges when there is a conflict over resources needed by multiple projects. Project managers hope that by presenting the CEO or other executive as a sponsor, it will create commitment to the project. However, CEO's and other executives usually do not have the luxury of time to serve as a sponsor on a project. Leverage stakeholder management activities such as a level of funding approval list to confirm the primary sponsors for the project.
4. "We are four weeks behind schedule, but we'll make it up in the next phase."
Unless there is a large change of scope, one of the more the unfortunate laws of physics for projects is that any schedule slippage is likely to carry over to the next phase. The best approach is to be transparent about the schedule delay. By making the slippage transparent, you enable leadership team attention and corrective actions.
5. "I feel green."
A green status indicator in a project report typically means that no issues are present. However, a green status indicator does not always tell the complete story.
For example, despite deliverable dates that were slipping on one project, the project manager continued to declare a green status indicator. In an executive steering committee meeting, the leadership team challenged the project report. The project manager said, "I know the deliverable dates are slipping but I'm still feeling green." To promote project team and leadership confidence, employ objective project metrics such as planned vs. actual deliverable dates or earned value analysis to show the true status of the project.
While tools, approaches and processes help manage delivery risk, recognize these signals and take the right steps to act on them.
What have you found to be good examples of signals that point to risks on projects?
The next time your boss asks you for a number, a deadline date or another fixed value, remember anything you say will be wrong. The reason is 'the flaw of averages.'
Discussed in a book of the same name by Sam L. Savage, the flaw of averages basically explains why everything is behind schedule, beyond budget and below projection.
For example, you're developing two software modules. Both are expected to take between eight and 12 weeks to complete. When both modules are finished, your organization can start a new process, which requires four additional staff.
Your boss asks you for a completion date so the additional people can be brought 'on-board' and the new profitable line of business started. You say, "Eight to 12 weeks," and your boss replies, "Give me a date!" You estimate that a safe date would be 10 weeks, the average of eight and 12 weeks.
Everyone is happy. But should they be? Let's look at the flaw of the average:
Based on your projected date, your boss works out his profit forecast for the next quarter based on an estimated profit of US$1,000 per week. You take the first seven weeks developing the application, and the new team uses the application for the remaining five weeks.
This sounds sensible, but the estimate of US$5,000 profit is the best that can be achieved. If you finish early, there is no upside. The new people will not be available.
If you finish late, however, sales will be lost. The cost of the unproductive new staff will be an added expense until both modules are working. On average, the profits achieved are likely to be significantly less than US$5,000.
Plus, you're more likely to be late than early. The probability of finishing each of the modules in 10 weeks or less is 50 percent. It's like tossing a coin - there is always a 50 percent chance of it landing on 'heads.'
Since two modules need to be finished in 10 weeks or less, think of the options when you toss two coins:
Tails + Tails
Tails + Heads
Heads + Tails
Heads + Heads
There is only a one in four chance of you achieving the 'average.' That 25 percent probability means there is a 75 percent probability of being late. Therefore, on average, you can expect to be late.
All you did was assess a reasonable number based on your expected average time to complete each module. The problem is not your estimate, but the way it is being used. This is the flaw of average.
The next time you are asked for a 'number,' use your skills in managing upward to build flexibility into the conversation.
For example, offer your boss a safe date with an option for improvement. "We will definitely be finished in 12 weeks, and there is a possibility of finishing sooner." Point out the cost risks of being early and late. Keep the boss updated as you work through the project.
Or, do some serious analysis. Offer your boss a range of dates with different levels of probability. You need tools for this, but you want a target date with an 80 percent probability of achieving.
Effective stakeholder management needs more than simply complying with a request -- however reasonable it may appear on the surface.
In coaching several agile teams and sifting through long lists of metrics, I've observed a core set of metrics that can help distinguish successful teams from teams headed for schedule slips:
Many teams have multiple team members who split time between projects. In most cases, it is better to have fewer people full time on a project than more people part time. For example, instead of having eight people working part time, try having four people work full time.
Why? We lose 20 percent efficiency each time we multitask, according to Mike Cohn's book Succeeding with Agile. Count the average percent of time each person is allocated to the project. Averages less than 80 percent should be looked at to see if the team is being pulled in too many directions.
This is the ratio of work planned compared to potential capacity. In theory, people could allocate up to 54 task hours per two-week iteration, but the team only plans an average of 30 hours. Then there is a problem with planning.
Fill your plan until you have 70 to 80 percent of the team's time accounted for. Eighty hours for a two-week sprint is not ideal because other important work is not represented by tasks (such as mandatory training, email, unexpected maintenance work).
In addition, have the team own its total task hours and let them "pull" work when they are ready. Assigning work to individuals may create silos and is based on imprecise estimates.
Compare the number of task hours left at the end of the iteration to the total planned. There should usually not be any hours left, but if the team meets this goal every time, it may not be planning aggressively enough. It's healthy for teams to have a small number of hours, say 5 percent, left over on a small number of their iterations (10 percent or less).
This shows how much unplanned work was added during the iteration.
In my experience, it is okay to add up to 15 percent because planning is based on approximate estimates and technical execution of the project may reveal new subtasks. But if more than 15 percent has been added, it's a sign the team is either not planning enough or they never say no to new requirements. Either way, they lack the ability to plan with enough diligence or to pause new work until future sprints.
What do you think? Have you used these metrics? What metrics do you use to help spot trouble?
A project that's broken down into milestones and tasks doesn't seem that difficult -- in fact, it seems more manageable to execute. But the tasks can be numerous, and they all compete for your time -- something there is almost never enough of.
I use a technique where I take one task and separate it from any others that should be worked on that day. The task comes from the project plan and my calendar, so I've already assigned a duration and specific date and time to work on it.
To actually execute the specific task, I separate it in my mind from anything else I need to do and focus on it completely. In other words, I zoom in.
If disruptions are present, try focusing on your task with these tips:
1. Clear your mind of everything except what you're working on.
2. Establish what your optimal environment is. Are you most productive when it's quiet? When there are people around? At your desk?
3. Visualize the end result or completion of the task.
4. Convert or break down the task into actionable items that you or someone else on the team can handle. Converting written tasks into actionable items pushes those items to completion much faster.
5. Identify people who can help you get the task done or resources you need to get it done.
6. Jump straight into the task until completion.
What tactics do you use to "zoom in" on your tasks?
Scheduling time to execute your work is one thing. But project managers should also schedule time for scheduling.
Setting aside a block of time each week lets you review your project plan, timelines and pre-requisites. It also lets you gauge whether you're still on track with deliverables and if you must make any necessary tweaks to your plan. I review all of the planned activities at least a week out and make sure everything is aligned to execute those activities.
I recommend creating a two-month view of the project, no matter what the size. With that in place, it's a matter of confirming that you're still on target.
At the end of each day, schedule an additional 15 to 20 minutes to look at the next day's schedule. I make sure all the meetings and activities that my team is managing are well-planned, scheduled and confirmed.
It may seem tedious but spending time on scheduling will help ensure you stay on top of your plan and know that it's on track.
Do you schedule time for your planning? Is it worth it?