Prototypically Speaking – The Software and Requirements Prototyping Blog

Did 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.