I’ve got a speaking engagement in a month or so where I’m going to talk about “How to Reduce Risk in IT Projects.” In thinking about what I want to say in that presentation, it occurred to me that “risk” is an interesting word. We define the word as the uncertainty of bad things happening, and one of our goals in project management is to minimize that uncertainty and prevent the bad things. But what about the uncertainty of good things happening? What do we call that? Serendipity? Good luck? Good fortune? Happenstance? And why is it that we focus on preventing the bad things but we don’t try to make good things more certain?
Look at it another way. We usually consider a project to be successful if it achieves the planned result with the expected quality and if it finishes on time and within budget. Realistically, this success is pretty rare; according to the Standish Group, only 34% of U.S. IT projects in 2002 were completed on time and within budget, and $55 billion was wasted due to canceled projects or cost overruns, out of $255 billion spent on U.S. IT projects. Yet it seems to me that we ought to be striving for more: projects which exceed expectations, provide superior quality, finish early, and come in under budget.
Do I expect this to happen very often? No, but I think we’re making a mistake in not taking the right steps toward this extraordinary result. I believe that many of our projects are late because once we create a project plan, we never try to do better than the plan. We try to bring the project in on time, but never early. If a task is completed early, then we figure we have some breathing room and we don’t start the next task right away. In many cases, we can’t start the next task right away because no one assumed that we would be able to finish the first task early, and so things aren’t ready for us to start the next task. If we adopt this attitude for all tasks which finish early, then the best possible outcome is a project that’s on time, and the project will be late if the least little thing goes wrong.
Similarly, our projects run over budget because we try to bring them in on budget but not below budget. If we’re under budget in one part of the project, then we tend to spend the money on other lower priority items that probably aren’t required. Again, the best we can hope for in any budget category is to be on budget, and therefore most projects run over budget.
Swing through the Ball
In case you’re getting the wrong impression, I’m not advocating “sandbagging” your project estimates, ensuring a favorable outcome by deliberately adding more time or money to your project plan than you think you’ll need. But if your people have the attitude that they can take as much time to finish the project as was planned, then there is no incentive to beat the time. It’s kind of like the idea in golf (as well as baseball and tennis) of “swinging through the ball.” You don’t just hit the ball and then stop your swing on impact. Instead, you keep swinging even after you’ve made contact with the ball, and this gives you more power to make the ball go farther and more control to make it go where you want it to go. In projects, you shouldn’t just create a project plan and consider it the best that you can do. You should treat the project plan as a reference point and then try to do better than the plan. “Swing through” the project plan by trying to beat it.
How to Make This Work
Let’s take a look at the way we should schedule our tasks for a project. For each task, most people estimate the most likely effort and duration, and then they provide some reserve time or “slack time” after each task to allow for possible uncertainty. Suppose instead we estimate the lowest reasonable1 effort and duration, and we define the project tasks accordingly. Then we should provide a “slack task2″ after each major task to pad it out to the most likely effort and duration, and we should remove these slack tasks from the schedule as their corresponding tasks are completed. Are we kidding ourselves by doing this? No, we’re just giving a message to our employees that they should try to achieve the lowest reasonable effort and duration for each task, even though the overall plan is based on the most likely effort and duration. Mediocrity shouldn’t be a goal; it’s what you get when you don’t achieve your goals.
Ok, how about the slack time that we typically add to a task above and beyond the most likely effort and duration? Take it out of the plan, and instead of scheduling the slack time at the task level, you should include an aggregated slack time at the end of the overall project. If you include slack time at the task level, then people will assume it’s for their use as breathing room and they’ll take advantage of it, often to the detriment of the project schedule. If you include it at the end of the overall project, then it can be used as a buffer for task overruns on the project’s critical path where it’s needed the most.
Let’s look at another aspect of good project management, the risk mitigation plan. A good risk mitigation plan has a list of risks, a contingency plan for each risk, a well-defined trigger event that will cause the contingency plan to be invoked, a “risk owner” who is responsible for tracking the trigger event, and a list of steps we’re going to take to make each risk less likely. But again all of the risks are negative events, so the contingency plans are designed to get the project back on schedule—not to bring the project in early or under budget. Have you ever seen a project plan that includes a “serendipity encouragement plan” or a “good luck plan”? The terms seem absurd because the idea is so uncommon that we don’t have a good name for such a plan, but the idea is to list the positive events that might happen and what we’re going to do in the project to make them more likely. For example, user training might go faster if the system is easier to use, so list the things we will do to ensure that it’s easier to use. Or costs might be lower if we can reuse some existing servers, so list the things we’ll do to make that reuse more likely.
We have naively assumed that the opposite of “risk” is “no risk,” but that’s not the case. The opposite of “risk” (negative uncertainty) is “good luck” (positive uncertainty), and we ought to be taking steps to make good luck more likely. As Seneca said, “Luck is what happens when preparation meets opportunity.” If you anticipate possible areas where “good luck” things can happen, prepare for them, make them more likely, and create your opportunities, then your projects will always be much better than just mediocre.
1. Notice that this is the lowest reasonable effort and duration, and not the lowest possible effort and duration. The estimate should be challenging but not so challenging that employees give up when trying to achieve the estimate.
2. A “slack task” is a dummy task that acts as a placeholder in a project schedule. It’s like slack time, except slack time has a duration but no effort, while a slack task has both duration and effort. The duration in this case should be the difference between the lowest reasonable duration and the most likely duration for the task corresponding to the slack task. Similarly, the effort should be the difference between the lowest reasonable effort and the most likely effort for the task corresponding to the slack task. The effort should be assigned to the same resource(s) used for the task corresponding to the slack task.
Related Posts and Articles
- How to Stop a Runaway Project
- Are You Wasting Your Resources on “Honey Projects”?
- Preparing for your own Hurricane Katrina (on risk and contingency planning)
- On Time at the Wrong Restaurant (about doing the right projects)
- How to Get People to Change — the Human Side of IT Projects
- How to Reduce Risk in IT Projects (downloadable white paper)