By Here's the next post from Jennifer Greene, coauthor of Head First PMP and Head First C#.
I once worked on a team that had a standing practice of padding all of the estimates their developers gave by 40%. They figured it just wasn't possible to know up front how long it would take to build a product, so the padding would account for any snags that might come up along the way. Some people think that's all there is to risk management; take your team's estimate, add a buffer to deal with risks, and you've got a date you can announce to everybody. Lots of people do just about that much planning before they make major decisions on how they'll market and and release their products. They drum up all kinds of anticipation for new versions based on early estimates with some padding and not much else. That idea, as it turns out, has led to a lot of programmers spending a lot of coffee-fueled nights at their desks.
The problem with doing planning like that is that everybody assumes the padding you've put in your schedule will account for any problems that might come up. So, when the programming team realizes that their design needs to change, they think "it's a good thing we've got all that padding to cover this." And when a client asks the sales team if the team could fit in just one more feature, everybody thinks "the buffer will cover it. Let's do it." Everybody in the project finds ways to eat up the buffer all at the same time and, the next thing you know, you're running late. That's why there are Time Management and Risk Management sections of the PMBOK that are core knowledge for the PMP exam. By learning about the tools and practices that have helped past project managers to keep their teams out of deadline trouble, the PMP-certified project manager is supposed to be equipped to help their teams plan for and manage uncertainty on their projects without killing themselves.
Andrew and I are big fans of an estimation technique called wideband delphi that focuses on getting your team to write down the assumptions they're making when they give their estimates. When you make an estimate, you obviously don't know exactly what's going to happen on your project. For the sake of the estimate then, you've got to make some assumptions about what's going to happen to figure out how long the work will take. The idea behind delphi is that if people who are qualified to do the work sit and discuss all of the assumptions that make up their estimates, they'll generally agree on how long the project will take and they'll come to a common understanding of how the work will get done. When you write down all of the assumptions you make in the beginning, you have a great head start for tracking risks to your project too. Whenever those assumptions turn out to be false, you know your estimate's got trouble. So planning how you deal with those assumptions is a great way to start thinking about mitigating risk.
But whether you use delphi or any other structured estimation technique (like planning poker) you'll find that that main goal is to get people to really think through the work that's going to be done and the decision points that will influence it. It's not enough to just add a nondescript buffer to a project and hope that your team will pull together to make the deadline when things inevitably go off track. The reason project managers focus so much on planning and estimating in the first place is to stop that kind of pain from making its way to the team at all. It's harder to really try to understand the work that's going to be done, to identify that risks that might derail your project and figure out ways to compensate for them than it is to just add a buffer into your project. It's always harder to do a thorough and good job of planning than it is to wing it. But adding a buffer without understanding the risks it's meant to compensate for often leads to a false sense of security that can sink your project and make life really tough for your team.
Share:
Leave a comment