Surely nothing is wrong…
In 1995, it reported that only 16.2% of software projects succeeded. In large companies, the number was only 8%. That is, these projects were on time and on budget.
The 2012 report is still fairly damning of the industry as a whole. It cites 12% success rate for waterfall projects and 42% success rates for agile projects. Firms like Headspring, with a 95% success rate, have embraced agile, of course, but there is still so much more to be desired by the track record of the industry. In 2012, 9% of agile projects still out-right fail, and 49% are “challenged”. i.e. they unacceptably ran over budget and/or over schedule
OK, so maybe there is something wrong.“If cars were like software”
- Over Promising Estimations
“you simply don’t KNOW whether something is possible yet without research into it”
“Managers and sales guys can be really annoying; understandably, they have to tell THEIR employers what’s up in the development process and where we are. But if you give in and avoid disappointing them now, you will only disappoint them more later.”
- Lack of good requirements
- Budget constraints
- Unreal expectations
- over-ambitious goals
- feature creep
- (most likely), under-investment
So what can I do about it?
Build awareness so everyone can work together to solve this problem early.
“I assume you know how to put together a jigsaw puzzle, for nearly any 3 year old can put together the most basic ones.
So let me ask you a question. If I went out and bought 5 jigsaw puzzles, each with say 2,500 interlocking pieces, how long would it take you to put together anyone of them?
Can you tell me within 25% of the actual time how long it will take you? After all, you DO know how to put together a puzzle, right? And it you can do that, can you tell me what day you’ll have all 5 of them finished?
I want to know! And can you have your reply ready for me by 3pm today?”
Deal with misconceptions. We are not building cars we are designing them.
What we need to do is get businesses to understand that when they undertake to have custom software built, what they are really asking for is not a construction project, but an R&D project.
Don’t ignore aspects of the business to give the illusion of agility.
Agile can improve things, but I have found that for most businesses, no matter how much you communicate that requirements need to be flexible, that you charge hourly for time spent, that adding things increases time and costs, at the end of the day they still expect to be billed exactly X dollars after X months for their exact scope, even if that scope exists entirely in their own minds.
We have a lot to improve upon in our industry (education in patterns, solid principles, db techniques, soft skills, requirements gathering)
Make sure not to build in bad practice
I used to work for a company, which was making about 3x more money from supporting crappy projects they have built for 1x at the first place. That’s what happens when none of the stakeholders is anything close to technically literate.