Never Be Responsible For Your Estimations Again
Filed Under Estimation, Software Process
Wild estimations are a common job hazard that every developer encounters. Developers are asked to give exact estimations based on few requirements, little to no domain experience, and in a very short time. Whatever number the developer spits out of their mouth becomes written project law. How fair is that? It gets worse than unquantified estimations…
The real problem is that you, the developer, now have effectively taken all responsibility for the project budget. By giving a single point estimation the project manager is no longer in control of the situation. All responsibility of the success and failure of that project is riding on your ability to wildly guess. In other words, you have made a managerial project scapegoat of yourself.
So what can the common developer do? The answer is simple – learn to push the decision making back onto the manager. By forcing management back into making the “important” decisions, you are giving management the authority to be responsible for the project again.
For example, let’s pretend you are a consultant working for $100/hr and get asked to do an estimation for a new custom solution.
Old Way – You throw out a complete guesstimate of $50,000 (500 hours). You are now a budget scapegoat.
New Way – You think it will be about 500 hours, but you present it with this wording:
Boy, this is really hard to say. I apologize for the range, but somewhere between 500 – 1250 hours. I can 100% guarantee that 1250 hours is plenty of time, but there is only a 10% chance that the project will come in on budget with a shoestring budget of 500 hours. How many hours would YOU like to dedicate to this project.
This tactic puts the act of estimating back into reality. An estimation range is much more forgiving than a single point estimation, and it gives multiple options for your manager to consider.
Your manager might have many business reasons for wanting to reduce your estimation. Putting a probability of success associated with each dollar amount makes them answer the tough questions they may have been dodging:
- Is the client most concerned about dollars or success?
- Is the business willing to take a 50% gamble on project failure to get this bid?
- If I gamble on a 10% success rate – what will happen to ME?!?!
The equation for this is very simple linear equation. If you feel your estimation ranges could use modification, I would recommend starting large and tightening using a model like the cone of uncertainty:
Being a responsible estimator is important, but being responsible for your estimates is not. You have to build the solution, you should not also have to manage the budget. Put your estimations in ranges with probabilities and let your manager manage the costs and risks of the project.
4 Responses to “Never Be Responsible For Your Estimations Again”
In a position I have since left, I was relied on to do estimates which I would be held to (yet being pressured to keep them low), and then they would go to the customer as a fixed-price quote.
Time was never allowed for things like testing – Nope, virtually as soon as the project had sputtered into life, it was deployed. It didn’t matter if I raised objections about the process or the way we overworked our developers, as my manager was too weak to be firm with clients (and unwilling to fire bad ones).
I am now the fifth person to resign from his 8 person team in 1 year. Basically, they’re screwed, since I’m taking a hell of a lot of domain knowledge with me (I was the “whatever it takes” guy, out of a team of apathetic 5:01 programmers).
Feels good to be gone 🙂
Unfortunately between having plumbers and handymen provide estimates to a home owner and software development today the definition of the word estimate turned into a synonym for the word “fixed bid” with devastating results.
Although I haven’t personally used Max’s concept of large ranges, I have been a fan of the phrase “this is the time it would take with my current understanding.” Then when new understanding is discovered I considered it a change order much like if the scope had changed otherwise. For the clients that haven’t been trained I could see a lot of value in Max’s proposal for never being responsible for your estimations again.
Side Note: I am telling some of you right now you really need to put the smack down on your managers for putting you in darn right crappy positions.
Yeah, I’ve had my ass handed to me before on this one too. I estimated out a project, padded it nicely, and handed it off to management. We were in a strict CMMI process driven shop, and they placed an “X” on a calendar based on initial signoff of the SOW. That was the release date, period.
In the months that followed, our doc phase went about 3 times longer than it should have, but the calendar release date never changed, then I went to Tech Ed for a week, got assigned to other clients, and arrived back in the office days before the release date on the calandar. We were not even close to releasable code. Management put us on a forced march, 20 hr shift the day before release, absurd.
Make a long story short, I gave the estimate, management couldn’t control the situation with the client to mention that we were running behind in the early stages, and I got my ass handed to me for a failure I was only marginally involved in, because I gave the initial estimate.
I no longer work for that management team or company, but it is now a firm practice of mine to estimate by phase, and avoid calandars at all cost. Using language like, “…based on the completion of X, it should take between X, and Y weeks to complete…”
People understand the reason for any ambiguity if you just expalin it to them. You can’t make sure that they like it, but you can make sure that they understand.
The only problem with even that answer, is that the project manager, lead, or client will end up picking some ridiculous date anyway and holding someone to it.
Of course even then a developer must fight on and repeat, time again and time again, that the estimate is an ESTIMATE and not a deliverable date.
I wonder how much companies waste in this type of idiotic behavior. I’m thinking a safe estimate of the “waste” would be in the 10%+ margin – AT MINIMUM.