Comprehensive requirements and quality solutions go hand-in-hand. Without predefined requirements, a project can commonly cause frustration or become endangered.

This article discusses how to control and mitigate these potential pitfalls and instructs on alternative methods that could ensure you always have a well-documented set of requirements in place.

Recently, while working on a project – a project I was introduced to relatively late – I was asked by the client for some particular functionality. “Do we have any recorded specification for this exact requirement?” I asked.

No, was the reply. There weren’t any.

Instead, this particular requirement had been a verbal request and necessary specification hadn’t been captured beforehand. When opinions of the business end users vary from those of the client technical team, adhoc requests open up the client requirements to interpretation. This kind of fickleness has consequences; the risk the client requirements could be misinterpreted would jeopardise the time and budget of the project. But why do these pitfalls occur around business requirements? Because business end users are absent from the appropriate sign off/approval process between technical teams that explicitly states: “here’s the system, do you agree with this?”

My recommendation is a regular, formal, sign-off process. Business analysts capture the comments of business users, which are discussed between the solution provider and client’s technical team. The devised solution will then be handed back over to the business for review. Cue meetings/workshops to refine the requirements; to which end the solution can be finalised and approved.

The alternative is a phased approach. A drafted development – such as the user interface – is demonstrated to the end users in a cycle of every two weeks (for example) and they are therefore available to approve, constructively criticise and comment on the drafted solution. Involving end users means that the project is finalised to a point that meets their expectations. The approval process will always be adapted to the client; some clients know what they want and are systematic in their approach; others require guidance and to witness something practical first. We need to accommodate this diversity. Though, it is imperative that the requirements are fixed and defined by the time development on the project has started. The minute they begin to change the common goal becomes unsettled and therefore potentially unachievable.

By conducting this formalised process, providers and clients prevent a situation where a solution is delivered that doesn’t meet expectations. The threat of going over budget – built by the time spent on the ‘to and fro’ discussion to agree adhoc requirements – is also mitigated. With both the client and solution provider withholding an identical set of approved, fixed and comprehensive requirements, a solution can be built to great success.