Business analysis practitioners have struggled for a while now to shed the image of just being note takers, scribes, and/or project managers in training. Unfortunately, many unwittingly hinder this cause by continuing to focus so much attention on dealing with project requirements.
Ask many a business analyst to describe what they do and invariably some version of “elicit and document requirements” comes back at you. These business analysts may not realize it, but they are conveying the idea that requirements are their final product.
Their final product, just as for everyone else on a project team, is a stakeholder whose needs have been met.
Requirements are a means to that end, just as development and testing are means to that end. You can have a certification-worthy requirements management process, but if the resulting solution doesn’t meet the business objective at all, or is an overly complicated way of meeting that business objective, the project still fails.
Here’s how I understand value management:
- Understand stakeholder needs
- Determine if the need is worth satisfying
- Determine the best solution to satisfy it
- Build a shared understanding of the solution
- Validate the need was satisfied
Sounds a lot like what business analysis should be, doesn’t it? In fact, business analysis is a type of value management that is appropriate in complicated contexts…such as those that you find in the Internal IT workings of many organizations. Other collections of skills that fit under the value management umbrella are product management and many aspects of project management. Requirements play a part in many of these steps, including a mechanism that aids in building a shared understanding of the solution.
Another equally good way of describing the ultimate outcome of business analysis comes from Chris Matts when he describes business analysis as a risk management tool:
Business Analysts perform an important risk management role for the business investor. They help the investor understand the implication of the investment before the investor commits to an expensive development phase.
As a business analyst, my view has been that the business analyst adds the most value by killing requirements that add no value. A good business analyst is one that helps the business build what they need. An excellent business analyst helps the business realize that they need to kill what they thought they want but do not actually need.
So what is the practical take away from these different perspectives? Calling it something different does not immediately drive change.
Change requires different actions. It requires practitioners to seek to truly understand the need they are trying to satisfy and work with their fellow teammates to determine if the need is worth satisfying. It requires practitioners to ask the difficult questions and have the difficult conversations when they find that a project does not meet the needs of stakeholders or the business. It requires an intentional search for a viable solution that satisfies stakeholder’s needs by adding the minimum amount of additional software or processes. It requires using requirements techniques in conjunction with other forms of communication, instead of the exclusion of all others, to build a shared understanding. Finally, it requires practitioners to frequently check whether they delivered the value they set out to deliver.
Good business analysis practitioners do some or most of these things already. Great business analysis practitioners do all of these things and are constantly asking the question “are we delivering what we should, when we should?”
In other words, utilize your business analysis skills with a value management mindset, and you will find that no one will confuse you with a note taker or scribe, but just about everyone will want you on their team.