Effective Business Analysis Pt 1: Why and Who

There are many ways of classifying software quality. Some of the most obvious ways boil down to whether the software is fast, reliable, consistent, and relatively free of faults. Software that is slow, unreliable, or bug ridden is rightfully considered low quality. But there is a more fundamental aspect to quality: suitability. You could call this appropriateness, fitness-for-purpose, or functional value–regardless of what it is called, functional suitability is the fundamental measurement of quality. Building software which is truly fit for purpose requires good functional design, and business analysis is how you get there.

Coming up with a functional design is rarely a matter of asking what your stakeholders want, writing it down, and building what was asked for. Stakeholder requests are often influenced by old software, processes & habits, assumptions about what’s possible, or miscommunication between departments or user groups. It is the goal of business analysis to uncover what is truly needed and design a feasible and viable functional design.

Who

Traditionally, business analysis is done by team members with a job title of business analyst. This approach is common in IT departments and traditional consulting companies everywhere. The business analyst’s job includes helping define scope & requirements, acting as translator or communication conduit between stakeholders and developers, producing functional design documentation to hand-off to developers, and representing stakeholders’ interests in project team discussions.

In agile software development projects, there is rarely anyone called a business analyst. Instead every developer collaborates with stakeholders directly to decide on the functional design. In this case stakeholders may be end users or product owners, but the point is that the people for whom the software is being built collaborate directly with the people who are building the software. There is no intermediate designer. Most of the analysis activities performed on traditional projects still happen on agile projects, they are just done by developers instead of business analysts.

These are two different approaches to business analysis, but they are not the only two approaches. The divide between a completely traditional project and a completely agile one is a continuum. You could organize your project in many different ways. For example, perhaps only one or two developers on your project team with a specialization or interest in business analysis are tasked with analysis activities, and other developers work on more non-functional aspects of the system (e.g. performance tuning, framework integration, etc.). Perhaps one developer acts as an analyst mentor to other developers, helping them to conduct stakeholder meetings and reviewing functional documentation. Or perhaps (as I’ve seen recently on one of my own projects) a non-developer business analysis specialist helps the team on a part-time basis, doing analysis leg-work during development crunch periods, participating in meetings with stakeholders to help make sure enough ground gets covered, and writing required documentation, without removing the developers from the functional design process.

There is no one right approach. The approach that is best is the approach that makes sense given your project’s situation. The possibility of co-locating the developers with stakeholders, the degree of project politics, the disposition and availability of stakeholders, the disposition of developers, the degree of non-functional complexity, organizational methodology and documentation standards—all these things play a part in whether you have a person called a business analyst on your project, and what tasks that person will do.

That being said, consider pushing your team’s developers to take on more business analysis responsibilities. Try to become more agile. In my experience the highest functioning teams are those where everyone shares a sense of ownership for the whole end result. Leaving developers out of the functional design decision making process, even if you think it is for all the right reasons, will usually erode team effectiveness. You may tell yourself it is more efficient to have a business analysis expert come up with the designs, or it is inefficient to have a business analyst and a developer both meet with the stakeholders, or just coding is the best use of developers’ time. I say your project will make that time back and then some through the insight and foresight developers bring to bear. An agile project with developers performing business analysis will reduce redundant communication, both verbal and written. These projects result in less documentation of short-lived or volatile information, replacing it instead with collaboration time aimed at coming to a shared understanding. Other advantages are more resource redundancy, and design decisions made with access to the most up-to-date technology expertise available. And when the design inevitably has to change (this is software development, after all), developers who were equal contributors in the design process will greet new requirements with interest and attentiveness rather than disappointment or resentment.

Part 1 Summary

• Business analysis (or business system analysis) determines the functional design of software
• It is more than the translation of stakeholder requests to requirements and specifications
• Business analysis is a necessary activity to deliver quality
• Business analysis conducted by developers can lead to better results by reducing redundant communication, increasing collaboration, and fostering a holistic sense of ownership