Wednesday, May 1, 2013

Beam me up Scotty!

So, when trying to estimate a project, we've discussed starting with estimates from your front-line guys, and then holding them to those estimates.

Next, once you have all your estimates, roll them upward until you have a total, and then apply a safety factor. Just because we’re discussing adding safety factors is not to say that you should be “sandbagging” your estimates. You know, intentionally padding everything way beyond anything reasonable. Remember Scotty from the old Star Trek? When he finally appeared on the Star Trek: The Next Generation series he admitted that he always grossly inflated his estimates so that he could always be the hero for Captain Kirk.

Don’t get your hopes up too high, though. You are unlikely to have as much success with this technique as Scotty did. Sandbaggers become very visible and disliked, and they will usually have a fairly short lifespan in the real business world. But there’s nothing wrong with adding padding that represents what you have truly found to be needed in the past. Whether accounting for estimating errors, compensating for changing requirements along the way, or dealing with the occasional disaster, it’s easier to build it in early on than it is to try to readjust everything later.

How do you know how much extra to add? Experience! This is something you can grow more comfortable with as your career builds, but it will also have a component that is specific to each particular team that you lead. Each group, each company, each product, each set of processes, all create an environment that requires a varied amount of “fluff” in your estimates. You’ll learn how well each of your team members is capable of accurately estimating their own work. That, in itself, is another highly valuable characteristic to watch for. You’ll learn who needs bigger safety factors versus those who are pretty good at nailing it time after time. (You’ll also be able to start grooming the more accurate guys for additional responsibilities in the leadership realm.) Don’t let anyone tell you that you’re cheating by building in a safety factor. You’re being smart. It’s your experience leading you to a successful conclusion.

Ultimately, your goal should be to “overdeliver” on what people think you’ve actually signed up for. What’s wrong with coming in a little early on that deadline, or having a few more nuggets of gold in the product than they thought they’d have? We’re not talking about over-delivering by some massive amount – just by a little. Yes, sometimes the stars will align and everything will go close to perfectly, leaving much of your padding time untouched. But if you consistently deliver in half the time you predict, folks will think that you are trying to be “Scotty” and look like the hero. Even if that wasn’t your intention, you should use this as a sign that maybe you’re padding things up a bit too much. Something is probably different in this environment than in whatever one you were using as a model. Tweak your algorithm a bit.

“Isn’t it great, though, if I can constantly deliver much sooner than I’ve predicted?” No! There are many others who are using your estimates to build their own plans. They’re weaving together tasks they’ll have to do from a number of different projects, and if you keep coming in that early, you’re going to be making them miserable. They’ll be encountering high work peaks when they thought they had things smoothed out well. They will not be your friends.

“Yeah, but the sales folks will love me!” Nope. They might not mind a delivery that’s a little bit early. But if you are that early, they won’t have prepped potential customers for the arrival of your bouncing baby product. You’ll throw it over the wall to them and they’ll say, “Well that’s great… I have nobody ready to buy this right now.” They won’t be ready with the marketing brochures, advertising, and other sales support they’ll need to have available, and your support department won’t be staffed up yet to deal with the customers.

In short, you are not helping anyone by crazily inflating your estimates. Use a reasonable safety factor, then target to try to overdeliver by a bit. Consistency like that is what makes for a real hero.

1 comment:

  1. Software projects always pour it on at the end, as in long hours. That amount of extra time is flexible. So although you can apply some padding to yours estimates, even if your padding is not enough, the team can make up thr difference with overtime. What you want to avoid is requiring overtime right from the onset. The "death march" can only last so long.