Johannesburg, 05 Sep 2012
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.
A venerable statistic from the Standish Group says that only 16% of software projects are successful*; more recently, a study by project management consulting company, PM Solutions, concluded that 37% of IT projects are at risk**. 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'," says Robin Grace, principal consultant: Business Analysis at IndigoCube. "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' 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, says Grace, knowing where one is going and how to get there is vital. "A business analyst needs to have both a plan and a map," he explains.
Grace recently presented on "Why business analysts often lose their way" at the Business Analysis Summit of South Africa 2012 conference. IndigoCube was a Bronze sponsor. The conference's theme was "The professional business analyst as an enabler of effective business change", and planning, argues Grace, is essential to achieving this goal.
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", a phrase Grace uses, 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 sign-off. 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," says Grace. "That's the outcome of proper planning and it means the business analyst will deliver the accurate requirements that are essential for software that delivers business value."
* See http://www.projectsmart.co.uk/docs/chaos-report.pdf for the 1995 report
** Reported by ZDNet, available at http://www.zdnet.com/blog/projectfailures/cio-analysis-why-37-percent-of-projects-fail/12565
*** Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior by Tom Demarco, Peter Hruschka, Tim Lister and Suzanne Robertson
Share