4 ms·
"1. Nobody had the guts to kick off the project until the competition proved it doable and desirable; by then, the project was in catch-up mode and had to be fi
by rubidium 11y ago
"1. Nobody had the guts to kick off the project until the competition proved it doable and desirable; by then, the project was in catch-up mode and had to be finished lickety-split.
2.If the project were started long enough before its due date to finish on time, all involved would have had to face up to the fact from the beginning that it was going to cost a lot more than anyone was willing to pay."
In other words, projects are late because business justification is usually weak for software projects. When faced with "in order to ship this by 12monthsfromnow we need to hire 5 more software engineers today" management stalls.
- Etheryte 11y agoAdding more manpower doesn't mean faster completion.
- loup-vaillant 11y agoAt the beginning of a long project, it probably does. This is not like adding people to a late project. Now if your project isn't easily separable in several relatively independent parts, you are screwed.
- dahart 11y ago> In other words, projects are late because business justification is usually weak for software projects. While that's sometimes true, I read exactly the opposite. I read what he said as: 1- Software projects don't start until justification is strong, and 2- justification doesn't become strong until it's already too late. So, the problem isn't (necessarily) that justification is weak, it's that strong justification is itself a red flag, because it's already too late to start if you have a really good business case for it, you should have started before you had all the data to prove you needed to start. But, I don't think he's necessarily saying we should be able to somehow predict the future and start software projects before we know for sure we need them, he's just reflecting on patterns observed and providing more of a thought framework for dealing with these patterns.