Business analysts do a lot of different things, but their primary role in technology projects is in the elicitation, analysis and communication of requirements information. It’s becoming increasingly obvious to organisations that this function is of vital importance to the delivery of successful projects.
A recent white paper by IAG Consulting in the US compared the delivery of multi-million dollar technology projects amongst 100 large companies and discovered that projects with poor quality requirements cost over 60% more, and took almost 60% longer, than those with high quality requirements. It also found that sub-optimal requirements consumed 41.5% of the IT development cost of these projects. If you don’t understand what you need then you’re going to waste time and money. It’s that simple.
But there is another aspect of business analysis which gets much less attention in studies and surveys. A good business analysts, by the very nature of their role, needs to understand both the overarching business drivers (business requirements), the needs of the people who will utilise the software or system (user requirements) and the behaviour required of the system to satisfy these needs (functional requirements). As a result of rigorously examining these elements throughout the life of the project, the BA should always be the person who understands the project better than anyone else. They should understand the sponsor’s perspective, the customer’s perspective, the project manager’s perspective, the subject matter experts’ perspective, testers’ perspective… A great business analyst will strive to use this unique understanding to ensure that at all times, business value is prioritised.
Sometimes this will mean validating that the solution will meet the needs of the business as originally understood and communicated to the development team. But at other times, it will mean realising that the value proposition has changed in some way, potentially due to changes outside the project’s control, and that the project’s scope must expand or shift accordingly, or that there are scope elements that are no longer required. Perhaps it’s being aware of a critical business process that may be impacted by a change to the solution, or even realising that the original business case was flawed and must be revised. Sometimes, it might mean being the one to suggest that the project should be stopped, even when that means millions of dollars potentially down the drain.
Whilst a project manager’s focus should be delivering a project within budget, on time, and to scope, a great business analyst needs to look deeper than this. The project may have been delivered on time, and it may have been delivered within budget, but did it deliver true business value? Did it solve the problem it set out to? Did it result in increased revenue? Did it eliminate an inefficiency? Did it help service customers? These are just some of the important questions to ask.
Business analysts absolutely should be measured on their ability to develop easy to understand, complete and accurate requirements documentation. But the true measure of a business analyst is how effectively they can shepherd the delivery of value to an organisation. Requirements are an important element, and serve to underpin any work required to deliver the solution to the business, but business analysts should aspire to deliver more than this. They should aspire to be the sponsor’s representative on the project and always be mindful of whether business objectives are actually being met. Business analysts are in a better position to do this than anyone else, and that is the true value of business analysis.
