Far too many software development projects fail to meet deadlines and run over budget. You’ve possibly seen this first-hand. In fact, I’d be surprised if anyone working in this industry hadn’t personally experienced at least one development that ended up taking a lot longer and costing a lot more than originally intended.
Part of the problem is that designs and specifications are commonly put together in a short phase right at the beginning of a project. Some effort is put into trying to specify the requirements and translate them into a workable design in one swoop.
This is a noble but flawed thing to do. It almost always fails – and here’s why:
Projects can run for weeks, months or even years. However, such projects don’t exist in vacuums. They are part of a wider world of business, in which change is an ever-present reality.
By expecting to be able to specify a design up-front, and stick to it right through a development project, we set ourselves up for failure. Even supposing everything went well, and we missed nothing out from our requirements analysis, the fact is that the world will be a different place in the weeks, months or years it takes to translate those requirements and that design into an actual product or service.
What’s more, if we expect to get our requirements right and then build a single design to turn those requirements into something worthwhile, we’re placing all of our eggs in one very big and rather flimsy basket. We’re assuming that those requirements are correct, and that they won’t change. But, inevitably, the requirements will be written by someone who’d rather be out playing golf, and the very busy business stakeholder is really rather too busy to read that requirements specification. Probably a business analyst is trying to come up with a workable design without having any technical know-how, and in any case they’ve missed a huge chunk out because they didn’t really know how the new widget was going to fit into the existing system. So, they hide their misunderstanding in a veil of abstract and obtuse language, which is easy to misinterpret and difficult to follow.
To compound all of this, the rather unreliable requirements documentation is then revered as ‘correct’, and management will apply pressure for Real Work to begin. Which means cracking on with the build phase before anyone has engaged with the end-users to see if the proposed design is going to be up to the job. Which it probably won’t be.
Fast forward a few weeks or months, and the false assumptions, omissions, bad decisions and flaky designs have become so entangled in the actual fabric of what is being built, that disappointment and failure is a certainty. As the developers start to question the designs and requirements, it suddenly dawns on everyone that something is not right but nobody knows how to turn this baby around.
Effective requirements definition is not a one-shot deal. It must be treated as an ongoing process, which needs to be shaped by constant feedback from all the right people. Requirements prototyping, using software prototypes, feedback sessions and constant adjustment, is the answer to ensuring that requirements are up to the job.
By spending a bit more time at all stages, adjusting the design and the requirements to cope with new knowledge and user feedback, we can ensure that there is a much higher likelihood of delivering a quality system which actually does what it needs to do, rather than what was originally proscribed so many months previously. Expensive development effort is minimised because the design and requirements are clear and unambiguous.
At the end of the day, any additional cost of using requirements prototyping is more than offset by the significant savings by reducing wasted effort.
Try it – you might surprise yourself by how much better your project runs!