The Tragedy of Software Development
December 18, 2009Did you know that less than a third of all software projects are delivered successfully? By that, I mean on time, within budget and meeting the requirements of the users? It’s not a great statistic at all. As an industry we ought to be somewhat ashamed by this.
The really sad thing about it, however, is the extent to which the remaining two thirds – those projects which fail - might have been avoided. It’s pretty clear to see that a significant proportion of these failing projects fail for the same reasons, time after time:
- Inadequate Requirements;
- Poor Estimation;
- Low Stakeholder Engagement.
Of course, within each category the usual suspects crop up: lack of understanding of the context of a system, poor communication, scope creep, lack of organisation, corporate bureaucracy, and so on and so forth. All of these things are common to almost any software project, so an outsider would be forgiven for wondering just why we don’t learn from our mistakes and do something smart to help reduce their impact.
That smart thing, of course, is the process of Requirements Prototyping. Which is, as you will probably know by now if you follow this blog, the process of creating interactive models of designs and using them to solicit constructive feedback from business stakeholders, users and basically anyone who needs to have a say in the outcome of a project. Sure, there’s more to it than that, but in essence it is not overly complicated and the benefits in operating this way outweigh the additional costs – significantly, in the case of larger projects.
So, it’s a real tragedy that doing this smart thing is still so rare in modern software developments. Many companies might toy with the idea of building a prototyping in a half-hearted way, getting too bogged down in the stylistics without really using it as a powerful medium for evaluating designs, facilitating change and clarifying requirements. Like driving a sports car in a traffic jam, it’s a waste of the potential and a real shame. To get the real benefit – to get out of first gear, if you will – is to use a software prototype as a living, breathing specification and actively evaluate and refine it, involving all stakeholders.
If you do this, you will certainly increase your chances of finding yourself in that 1/3 of projects which are delivered successfully.
To pass up the opportunity would be a real tragedy indeed.
Hello,
i just finished reading this great article. I agree that using software prototype is required in all software projects. But how much time do we spent in software prototyping? Until all our questions are solved and all requirements are clear? is there a rule we can follow in order to make a realistic timeline? for example in a 6month software cycle, one month for sotware development is acceptable?
Well, there’s no hard and fast rule to be quite honest. It does vary depending on the nature of the project and what the end product is intended to be. The rule of thumb I subscribe to is that systems that will be heavily interactive will benefit more than those with less interaction, as refining a system’s interface design using direct feedback is one of the more established uses of prototyping.
You’re right to ask the question, though: “When to move forward” – and I think you’ve given me an idea for a future blog article, so thanks!