I Need a Better Estimate
I’m not sure how many times I’ve been tasked with estimating the time it will take to complete a software development project. I’ve already accepted the fact that most of the time I’m asked to do it with unclear requirements, poorly described features, no definition of done, and minimal time to create it. The foundation for this estimate is already shaky but I document my assumptions, quickly describe some scope, and put together my best faith estimate. Far too often, someone, usually a non-technical person such as a project manager, sends the estimate back to me and says, “I need a better estimate.” What?
After seven years in the software industry, I’ve learned to translate “I need a better estimate” to “I need it done faster as your estimate will take too long and I’ve already promised the customer a delivery date even though I didn’t have enough knowledge to do so and now I’m stuck delivering it sooner than your estimate because I’m not going to be the bad guy and tell the customer it’s going to take longer than I said because I screwed up so you need to figure out how to get it done faster.” Whoa. Deep breath.
For the sake of this post, let’s ignore the unclear requirements, poorly described features, and no definition of done, and assume everything is crystal clear. Here is a simple, non-software related example: Bob tasks me with creating an estimate for Rob to drive from Philadelphia to a bank in Pittsburgh.
Tasked with creating an estimate, I take my personal knowledge of having previously driven from Philly to Pittsburgh, I check Google Maps, and I ask if anyone else had any expense with this trip. I then come up with a five hour estimate and add half an hour for contingency. In no time, Bob would be emailing me. “Five hours! I need a better estimate! I promised the customer Rob could get there in three!” So how is it my problem? Oh yeah, I’m the developer. So now I’m tasked not with creating a better estimate, but figuring out how to get it done faster. I always handle it the same way; I put the work back on the Bob.
There are only a few ways to affect a project schedule: time, scope, resources, and quality. Let’s take them one by one.
Time
Time is very simple. Bob can always go back to the customer and ask for more time.
Scope
Many times the requirements are relayed without really understanding the problem. By figuring out why Rob needs to get to the bank in Pittsburgh maybe we can find a solution that will take less time. Maybe there is a bank in Harrisburg that will meet the same needs as the one in Pittsburgh? Heck, maybe there is one right in Philadelphia? Maybe Rob doesn’t need to go to Pittsburgh at all and this can be handled over the phone or on the Internet? Maybe someone already in Pittsburgh can go in his place? Again, I put it back on the Bob to go find out the actual problem.
Resources
If Rob is using a broken-down car that only goes 40 miles an hours and dies every 30 minutes then maybe a faster car would make a difference. My estimate assumed he is driving a car that can consistently do the speed limit and has average reliability, so giving him Ferrari isn’t going to make much difference. The Ferrari would allow him to go faster but we’ll assume Rob is going to drive at a reasonable speed. Two cars aren’t going to help much either. Maybe we have access to helicopter or airplane? Can we get a police escort? Again, Bob needs to go find out what additional resources we have access to and then I’ll revise the estimate.
Quality
Rob could run a few lights, drive down the shoulder, cut off other drives, take curves at dangerous speeds, and other crazy things to shave off time. Cutting corners is only going to make things worse. Rob might get pulled over, arrested, or injured. In any case, quality should never be compromised. I’ve been on development teams where quality was sacrificed to meet customer demands. It eats away at your soul. If you are ever part of a team where sacrificing quality is truly an option, quit immediately. You are not only sacrificing quality but you are also sacrificing your personal integrity.
In summary
In some cases you may need to actually improve on the estimate. Maybe your estimate for the drive from Philadelphia to Pittsburgh considered the scenic route though San Francisco. This isn’t the case most of the time. Improving the estimate is all about getting more information, agreeing on assumptions, better defining the requirements, and recognizing resource availably and constraints.