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