The Secret In How To Be The Best Business Analyst (Without Blowing Your Own Trumpet)

Some time back I had a crisis with my personal accounts. You see, I’d gotten so busy that I neglected my sacred routine of monthly tabulating my income and expenditure — which I let go for months. At one point a money issue came up and I didn’t have the data in my accounts to figure out how to handle it.

I was stuck. I started to panic and kicked myself for not keeping discipline.

Similarly in business analysis, discipline is critical even in the face of busy-ness and time pressures. You need unbreakable discipline in managing requirements so you never have to get stuck. To bring this out, we will cover the following three points in this article:

1. Why requirements are so important
2. What happens when requirements are mismanaged
3. What tools you can use to manage requirements from the get-go

Why are requirements so important?

As a Business Analyst, you are responsible for bridging the gap between customer teams and solution teams, and you need to communicate with the business using various techniques to understand and elicit their problems. Through this engagement, you identify their needs — which we call requirements. Without this process, customers’ needs and problems will be vague, unstructured and therefore incomplete.

Although there are different types of requirements (that’s a whole separate topic), the concept is that it captures something that has to be turned into some kind of solution. Without requirements, there is no basis for a project, and no way of identifying whether a solution put in place actually solves a customer’s problem.

Your responsibility as a business analyst is to make sure you clearly document all these requirements.

What happens when requirements are mismanaged?

Through requirements gathering, you will be speaking with many business stakeholders to identify their needs. It’s not that only one person has all the needs. This makes engaging with them complicated (which we repeatedly see in our Business Analysis training programmes). Not only this, but over time you will find that needs change, the understanding of the problem changes and so requirements can evolve.

This means that you’ll be having a discussion one day and have a clear understanding of requirements, but a week later, after more exploration, you and the stakeholders will develop a different understanding. So requirements can expand, and they can come in and out of scope.

And to make things more tricky, as the project phases progress, more clarity on requirements is surfaced. So as you’re documenting all this, it requires careful management of the requirements you’re writing down. If the dynamics of this fluid process aren’t managed, stakeholders will become confused, solutions won’t be fit for purpose and you’ll likely be in the firing line for costly project delays.

What tools can I use to manage requirements from the get-go?

There are 3 simple tools I regularly use to make sure requirements are never mismanaged:

1. RACI matrix — understanding who is responsible for contributing to and signing off requirements means you will never have confusion about who your ‘go-to people’ are. The last thing you need is a ‘meddling’ stakeholder who muddies the waters of requirements. A RACI can help stop this
2. Documentation — this might sound obvious, but everything needs documenting in a solid way, and then communicated clearly to your ‘go-to people’. As part of this, you use documentation tools to help make sure that all changes are completely visible and traceable
3. Decision Log — as decisions change over the course of communicating, having a record of these which is shared with the ‘go-to people’ is critical to make sure everyone knows when and how the direction of a requirement has changed

But why spend time documenting so much if everyone on the project is regularly speaking?

This is a typical objection, particularly in the Agile world where it emphasises less documentation and more collaboration. It is true that project stakeholders regularly speak and so know more or less what’s needed — but to manage evolution and change of requirements you cannot get away with documenting.

After all, the requirements act as a kind of contract between business and technology and without a contract there’s huge room for misunderstanding.

Using a requirements catalogue is a great way to manage requirements

By cataloguing requirements you create a repository which allows you to manage the requirements as though it were a big set of data. With that, you can version, filter, sort, slice and dice — and do all sorts of weird and wonderful things that help you not only manage change but also create interesting ways to help stakeholders interact with the information.

The biggest mistakes in version control that caused me massive confusion

On one project, I ran a large workshop to review a draft of the functional requirements with my client team and software vendor. Following this, the vendor sent through an updated version — without any trace of what they’d changed. As my team all wondered where to begin, I simply pushed it back over to the vendor to ask for a revision with changes tracked. Oddly enough, this is a common mistake — so make sure to highlight all changes on any documents you revise and send out.

Summary

• Requirements are the bedrock of a project that drives the appropriateness of a solution
• You as the business analyst are responsible for managing the elicitation and evolution of requirements
• Without proper management, even a well-planned project will descend into chaos resulting from confused stakeholders, miscommunication and solution ‘car crash’
• 3 useful tools to keep requirements in check are a RACI matrix, documentation tools and a decision log
• Even if everyone communicates well on a project, you still need to make sure requirements are well documented
• You can set up a requirements repository that will help manage and communicate requirements
• Whatever changes you make to requirements along the project journey must always be well communicated and traceable
• With this amount of control over requirements, you will be considered ‘one of the best business analysts’ — as not many do this part of the job well
• Without all this in place, you may find at some point in the project that you’ll have to undergo the pain of backtracking all discussions, decisions, and changes to understand exactly what the true requirements are

So did I recover my personal accounts?

After sitting down, cancelling all my engagements and painstakingly backtracking on every transaction, I eventually caught up (days later) and then found the money issue was simply related to a lack of clarity on my own accounts.

I felt relieved, light and free of anxiety — and resolved that I’d never let that sacred routine go out of whack again. It was actually transformative.

Learn more about the Business Analysis career

Read the in-depth “Life As A Business Analyst” report where you can read more about how to get started, the career stages, and the rewards.

About The Author

James Compton is a Business Analyst Consultant and Trainer with over 20 years of experience. He is on a mission to help early to mid-career professionals to become top class business analysts and get paid well for solving meaningful problems. He is also the Director of Professional Development at the International Institute of Business Analysis (IIBA).

You can follow James on LinkedIn, as well as subscribe to the newsletter to receive more articles like this.