All late projects are the same (2011) [pdf]
systemsguild.com
All late projects are the same (2011) [pdf]
1–10 of 59 posts
Re: All late projects are the same (2011) [pdf]
#2While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.
Re: All late projects are the same (2011) [pdf]
#3They’re all late because customers are fools and salespeople are liars.
Customer: “how long will it take (and therefore cost)?”
Three vendors: “less than [the other 2 vendors].”
...iterate until “cheapest” solution is reached ... meanwhile the technical staff at the vendors are losing their minds at the sales team, telling them that what they’re specifying is impossible...
Customer, to vendor [cheapest]: “Here’s a contract. We look forward to this project being delivered on time and on budget!”
Re: All late projects are the same (2011) [pdf]
#4While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.
If you can't be flexible on the delivery date, you have to be flexible in feature scope.
That means building a simple verison first that still fulfills the purpose while not being perfect or polished. Then iteratively improve it to what you and the customer ideally want.
That way, if the deadline comes before you're done, you at least have a working version that fulfills the basic need and allows the kind of workflow that's necessary, even if it still has some rough edges or even gaps in rarely used areas.
Of course this approach requires you to write your contracts in a way that doesn't tie you down too strictly on how exactly things will be solved.
Re: All late projects are the same (2011) [pdf]
#5(2011)
Re: All late projects are the same (2011) [pdf]
#6While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.
Disagree. Upper and lower bounds can be realistically estimated. Whether the estimates meet the demands of the market is another question. I'm an engineer, not a CEO or sales person, but I'm a firm believer in selling first and building it later. Building it after it's been promised is one of the best ways to limit scope.
Re: All late projects are the same (2011) [pdf]
#7While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.
and no one is willing to say so.
On the reverse of course it makes sense to have estimates otherwise how should managers or product people decide what should be done next?
A big part of the issue is we don't have good knowledge how to estimate work. It's not a skill that is heavily invested in and is wrongly assumed as an inherent ability.
Re: All late projects are the same (2011) [pdf]
#8> [I]nstead of obsessing over “What’s the matter with those software folks who didn’t deliver on the schedule we gave them?” we need to ask instead “Why did we ever kick off a project with such marginal expected value?
Re: All late projects are the same (2011) [pdf]
#9While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.
and no one is willing to say so. Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number. On the reverse of course it makes sense to have estimates otherwi…
I have, on more than one occasion, said so, and the response was always bafflement or annoyance, and in either case and unwillingness to accept that answer. When I was younger, I would eventually give a guess, along with a "...but that's just a guess". Nowadays, I don't even give that, because the caveats get forgotten/ignored.
Re: All late projects are the same (2011) [pdf]
#10While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.
Disagree. Upper and lower bounds can be realistically estimated. Whether the estimates meet the demands of the market is another question. I'm an engineer, not a CEO or sales person, but I'm a firm believer in selling first and building it later. Building it after it's been promised is one of the best ways to limit scope.
I have seen "realistic estimates" be off by multiples. Also, "build it after it's been promised" is not making any sense to me, perhaps you can restate that somehow?