Technology has become the indispensable foundation for any successful business, and yet the process for translating business requirements into effective software remains a weak point. One of the key reasons for failure is the requirements-gathering process—the work of the business analyst.

The seeds of failure are contained in the very term, ‘requirements-gathering. It makes it sound as though requirements are easily found and just need to be collected by the business analyst. In fact establishing what the business’s needs are is an extremely time-consuming and specialised activity—and if it is not performed correctly, the resulting software will unavoidably fall short. I prefer the term ‘elicitation’, which better conveys that this is an active process rather than simply a harvesting one!

By emphasising the scope and importance of the business analysis process, it will be easier to justify the time required to complete it properly. It’s a process that comprises multiple steps and, knowing where one is going and how to get there is vital. A business analyst needs to have both a plan and a map.

Before the plan is created, the business analyst has to understand the project, the people and the process. There is no standard process for establishing what a business requires. “Template zombies” simply don’t get the job done. The analyst must be clear about the type of project, what the existing documentation is, and establish objectives that are clear, measurable, have deadlines and genuinely deliver business value.

It’s also necessary to gain a clear idea of how many people are involved, and how complex the business and the solution itself are. Equally important, the analyst must identify the stakeholders within the business in order to be able to gain their input and, if necessary, their ultimate signoff. He or she must find out how best to communicate with each stakeholder group.

The final phase is the process itself. During this phase, the analyst must establish exactly what the deliverables are and the approach to be taken for each. Each deliverable will have several tasks associated with it, not just a single workshop or, more properly, “elicitation event”. The additional tasks include preparing for the event, documenting it and then confirming the results with all the relevant stakeholders.

In this way, the business analyst can build up a detailed understanding of the task ahead, and justify the time he or she will need to the project manager—and get the correct time assigned in the overall project plan.

For each and every task, the business analyst must understand the five Ws: why it is needed, what the task is, who needs to be involved, when it will be done and where—as well as how it will be done. That’s the outcome of proper planning and it means that the business analyst will deliver the accurate requirements that are essential for software that delivers business value.