Why we suck at estimating software projects
-
I'm pretty good with my estimations and have worked with people who are also pretty good at it. The biggest problem is bosses/management don't want to hear the actual estimate. Long before Agile and Scrum, Novell adopted the mantra that all projects take two weeks. I was in one meeting where everyone on our team was asked how long it would take to finish--mind you it was just our team--and everyone said "two weeks". I said "five months." I got laid off six weeks later. The project took exactly five months to finish (and still didn't ship for another six months after that.)
-
Kent Sharkey wrote:
Because wethey (managers, marketing, sells...) suck at defining projects
FTFY
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Kent Sharkey wrote:
Because we suck at defining projects
Engineering is usually quite good at estimating the time required for a project. The problem is that Sales always wants it earlier so they can show it at the next expo, and they have the ear of Management. Given that most companies are profit-driven, the company that delivers first is likely to get the most sales, and that Management is rarely held liable for any failures, there is no real solution to the problem.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Kent Sharkey wrote:
Because we suck at defining projects
Engineering is usually quite good at estimating the time required for a project. The problem is that Sales always wants it earlier so they can show it at the next expo, and they have the ear of Management. Given that most companies are profit-driven, the company that delivers first is likely to get the most sales, and that Management is rarely held liable for any failures, there is no real solution to the problem.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Daniel Pfeffer wrote:
The problem is that Sales always wants it earlier so they can show it at the next expo
Not only Sales - the customers, too! In my student days, one large project was implemented using an IBM prototyping system with APL as the prototyping language! It was really great (if you could handle APL...). The guy who introduced the system to us told about one 'problem': Customers testing out the prototype often would say: "That's exactly what we need; we'll take it. You'll receive our payment shortly. Thanks and goodbye!". So the developers must make sure to always leave some essential functionality out, and make that very clear to the customer, to stop him from running off with the prototype. Quite often, the customer had a hard time understanding why it would take another six months to implement the system - they had seen in running perfectly in front of their eyes, why would it take so long? Not only salesmen but customers crave for news at every expo. I worked in a company where the sales people held back some new developments for expos/releases: As developers, we were eager to display all we had achieved, but the sales people said "No! We have enough news for this time, we'll hold the rest back, in case we don't get around to developing any eye catchers in the next round". We developers were told not to reveal any of the already-implemented functionality (it was not yet linked in the product sold) to customers; that should be a new big headline a few later. You don't gobble all the vitamin pills in the bottle in one go :-)
Religious freedom is the freedom to say that two plus two make five.
-
I'm pretty good with my estimations and have worked with people who are also pretty good at it. The biggest problem is bosses/management don't want to hear the actual estimate. Long before Agile and Scrum, Novell adopted the mantra that all projects take two weeks. I was in one meeting where everyone on our team was asked how long it would take to finish--mind you it was just our team--and everyone said "two weeks". I said "five months." I got laid off six weeks later. The project took exactly five months to finish (and still didn't ship for another six months after that.)
Joe Woodbury wrote:
The biggest problem is bosses/management don't want to hear the actual estimate.
100% this!
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger:
-
I'm pretty good with my estimations and have worked with people who are also pretty good at it. The biggest problem is bosses/management don't want to hear the actual estimate. Long before Agile and Scrum, Novell adopted the mantra that all projects take two weeks. I was in one meeting where everyone on our team was asked how long it would take to finish--mind you it was just our team--and everyone said "two weeks". I said "five months." I got laid off six weeks later. The project took exactly five months to finish (and still didn't ship for another six months after that.)
amen. This is one of the nuggets that came forth from the original Extreme Programming book. If you aren't doing the work, you don't change the estimate. It's amazing how everyone continues to lie about this. "I'm sorry, I did NOT miss my estimate, I missed yours" was a common theme in so places I worked. The worst part is that by not accepting the estimates, the company sabotages their own efforts and developers never learn to estimate properly.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.