Double It And Move To The Next Unit Of Measure
Hey Dave, how long to add a location field to the reservation program?
That’s simple. probably an hour.
Okay then.
It took two days.
But, that’s fine. I expected it. Programmers are eternal optimists. Project managers are eternal pessimists. So, the formula to translate a programmer estimate into an actual schedule was to double the estimate and then move to the next unit of measure.
1 hour == 2 Days
2 Days == 4 Weeks
1 Week == 2 Months
3 Months == You aren’t going to get it this year. . .and next year is looking iffy
Why are the estimates so far off? I think it has to do with two competing desires, both of which lead to underestimating.
I joke that anything I don’t know how to do must be easy (I Learned Management from Dilbert’s Pointy-Haired Boss.) Developers think the same thing. When you ask a programmer to do something you are issuing a challenge. Especially when it’s something new or unique. (How To Talk To A Programmer. . .And Get Results.) And once they work out the logic of it, the implementation is often an afterthought. I’ve seen actual programmer design documents that say,
And then the miracle occurs.
They assume they will be able to figure it out eventually. Eventually is almost always longer than they expected.
The second thing that blows up schedules is that programmers want the product to ship. They really do. They don’t want to say,
If I try to add this feature it’s going to delay our ship date.
Partly they don’t want to say that because they know the PM will cut the feature. And it’s a good feature. It’s something that they WANT to code. I’ve seen developers work a feature “off the clock” because they decided that they would just put in some long weekends to make their dates.
During the months leading up to Windows 95’s release, the product suffered one delay after another. Bill Gates was asked in a company meeting if now that he’s no longer coding, does he ever get tempted to try to “help.”
Yes, I do. I’ve been tempted to take the entire code base home and write it over a weekend.
They can’t help it. All programmers do it.
So, what’s a Project Manager to do? Run with it. Seriously, encourage it every chance you get. Why? Because as I pointed out above, your programmers will put in extra time to try to add features to your product. They will spend late nights and weekends trying to make their date. You know they are going to miss there delivery dates, but they don’t. And when they miss their original date, but come in under your buffered date, you will get your feature and not blow your schedule.
The thing to be careful of is never, never let them know your buffer. If the programmer tells you it will take a day and you budget 2 weeks, you will get your feature. If you tell the programmer, you’ve budgeted two weeks, he will think,
What feature can I add that takes 2 weeks?
And guess how long that new feature is going to take him to code?
Rodney M Bliss is an author, columnist and IT Consultant. His blog updates every weekday at 7:00 AM Mountain Time. He lives in Pleasant Grove, UT with his lovely wife, thirteen children and one grandchild.
Follow him on
Twitter (@rodneymbliss)
Facebook (www.facebook.com/rbliss)
LinkedIn (www.LinkedIn.com/in/rbliss)
or email him at rbliss at msn dot com
