![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
The Joy of Estimates
Apr. 25th, 2017 11:56 amEstimation is one of those scary things in software development. (Well, in lots of places, but this is the context I work in.) You don't want to make your estimate so low that you can't possibly complete the work in the allotted time, but if you make it too (realistically) high, you stand good chance of never getting to do the work at all.
And then there's the problem that lots of people believe that most of the time that goes into delivering a software project is actually spent writing the code. So when the estimate looks scarily high to them, the first thing they want to cut is the time spent on writing the code. It's not at all unusual to get a request to cut the development part of a project by fifty percent, at which point you sit down with the account team and walk through all the work that's included in that estimate, plus the fact the development costs (at least in my area) generally run 10-20% of the total project. Once you convince them that zeroing out the development budget doesn't get them to their goal, a more productive conversation can begin. (But don't let them talk to you about budgeted project hours without also discussing delivery dates, otherwise they're likely to slip a fast one in on you.)
Last week we had to deliver an estimate with very little lead time. It was just a minor feature update, but it was for a complex set of platforms with multiple options and looming cliffs of technical debt. Monday morning we get word that our estimate is too high. We need to cut it by 80-90% before we can even consider presenting it to the client. Our jaws dropped because that is insane. If they were serious about the numbers, then the clients expectations were majorly skewed and we should probably stop wasting our time. I spent all day gnawing fingernails over the expected battle we'd see in a late afternoon meeting.
As it turned out, the dev numbers were fine, although we dropped back to only supporting one platform as a slow roll out strategy. The real savings were whittled away from most of the other teams involved. It still wasn't anywhere close to a 90% cut, but it was large enough, and we helped the account team craft a story to sell the project with a preview of additional work to be done next year. Now it's out of my hands and not my problem until or unless I get a request for a variation on the initial estimate.
If you happen to be in the weeds with estimating software development, especially hybrid mobile development, I would strongly suggest never providing just a single number. It can still be high level, but you need to put together a line-item breakdown of the work you're estimating, preferably with a high/low range. Then, most importantly, you need to document all the assumptions and known factors that could impact the validity of the estimate. This includes areas of uncertainty which have caused you to provide a higher than usual estimate for a particular item. If you do enough similar projects, you can do a lot of copying line items and numbers from one estimate to the next, but it's alway worth your time.
And if they absolutely insist on a high level, ball park number and you can't negotiate enough time to put it in writing with a ten thousand foot line-item breakdown (yes, I try to do breakdowns at that level too), then add a generous fudge factor to your number before sharing it. And inform the recipient that there's a fudge factor inflating the number to account for uncertainties. (Personally, I wouldn't volunteer the magnitude of that fudge factor, partly because it's often based on prior experience with the team that's asking.) If the number makes them flinch, just remind them that it will decrease as uncertainties are resolved.
Happy estimating!
And then there's the problem that lots of people believe that most of the time that goes into delivering a software project is actually spent writing the code. So when the estimate looks scarily high to them, the first thing they want to cut is the time spent on writing the code. It's not at all unusual to get a request to cut the development part of a project by fifty percent, at which point you sit down with the account team and walk through all the work that's included in that estimate, plus the fact the development costs (at least in my area) generally run 10-20% of the total project. Once you convince them that zeroing out the development budget doesn't get them to their goal, a more productive conversation can begin. (But don't let them talk to you about budgeted project hours without also discussing delivery dates, otherwise they're likely to slip a fast one in on you.)
Last week we had to deliver an estimate with very little lead time. It was just a minor feature update, but it was for a complex set of platforms with multiple options and looming cliffs of technical debt. Monday morning we get word that our estimate is too high. We need to cut it by 80-90% before we can even consider presenting it to the client. Our jaws dropped because that is insane. If they were serious about the numbers, then the clients expectations were majorly skewed and we should probably stop wasting our time. I spent all day gnawing fingernails over the expected battle we'd see in a late afternoon meeting.
As it turned out, the dev numbers were fine, although we dropped back to only supporting one platform as a slow roll out strategy. The real savings were whittled away from most of the other teams involved. It still wasn't anywhere close to a 90% cut, but it was large enough, and we helped the account team craft a story to sell the project with a preview of additional work to be done next year. Now it's out of my hands and not my problem until or unless I get a request for a variation on the initial estimate.
If you happen to be in the weeds with estimating software development, especially hybrid mobile development, I would strongly suggest never providing just a single number. It can still be high level, but you need to put together a line-item breakdown of the work you're estimating, preferably with a high/low range. Then, most importantly, you need to document all the assumptions and known factors that could impact the validity of the estimate. This includes areas of uncertainty which have caused you to provide a higher than usual estimate for a particular item. If you do enough similar projects, you can do a lot of copying line items and numbers from one estimate to the next, but it's alway worth your time.
And if they absolutely insist on a high level, ball park number and you can't negotiate enough time to put it in writing with a ten thousand foot line-item breakdown (yes, I try to do breakdowns at that level too), then add a generous fudge factor to your number before sharing it. And inform the recipient that there's a fudge factor inflating the number to account for uncertainties. (Personally, I wouldn't volunteer the magnitude of that fudge factor, partly because it's often based on prior experience with the team that's asking.) If the number makes them flinch, just remind them that it will decrease as uncertainties are resolved.
Happy estimating!
