Proactive Business Analysis, Not Order Taking

Waitress taking an order

When discussing project vision, business requirements and software specifications with clients, a typical challenge is that the business analyst doesn’t act as a discussion partner but rather an order taker who has no opinions of his own.

Many business analysts simply sit there, tools spread out (laptop, notebook) and get ‘ready to listen.’ For business users taking time out of their busy day to help drive out requirements, this is a very frustrating and off-putting experience. It presents them with a blank canvas and no framework, no place to start. They are expected to intuit how to discover and communicate their requirements. The BAs might ask questions to guide the discussion and facilitate elicitation, but they – like doctors performing an initial exam, before ordering a battery of tests – refrain from expressing an opinion. This makes them no better than simple order takers, providing little value to the client or their own employer (IT or a services vendor).

There are many facets of the discipline of software business analysis that are not taught in “BA school,” and that can take years to discover on one’s own. I’ll try and outline some here that are pertinent to becoming a more ‘proactive,’ engaging BA.

Understanding Motivation and Managing Scope

I think it is important that business analysts operate under a clear framework of understanding the motivations of the different players at the table. By this, I don’t necessarily mean client-side participants only (although it would of course be reasonable to know the participants’ motivations during the session). I mean that BAs should be clear about what drives their own employer, and what drives the client’s. This goes to having an overall grasp of the business conditions under which a system is being specified and built. It also means that BAs are primary actors in scope management (I don’t believe managing scope should be left up to project managers alone).

For instance, IT will want to manage scope tightly and curb cost, as would an IT services vendor. Therefore, it is the BA’s job to assert this condition (politely, of course, but firmly) during the requirements workshop. It also means that nothing that’s not considered in scope should be promised without undergoing change management first. Similarly, it is in the client’s best interest to expand the scope of the project as much as possible (well, it actually isn’t in their best interest, but they think it is). Business analysts should continually have an overall awareness of these conditions and act accordingly.

Asserting Opinions

Business analysis should be a conversation. Nobody wants to face down a silent, immobile opponent. Nobody wants to embark on the ‘creative’ journey of dreaming up a new software system by themselves. I believe strongly that BAs need to bring in their own experiences into a requirements workshop. Even if the concept isn’t right, it still unblocks something and gets the group talking. I find that I often have strong opinions about how something should be done. I may not know anything about the client’s particular business problem, but I do know how good software is designed, and so I can easily bring that experience into the discussion. Similarly, I find that I can often draw on my experiences as a software user and online consumer for knowledge and opinions about a client’s particular design challenges. We all shop online, we all use web applications daily. What are the best practices? What do you know about that? Bring that to the table. Chances are, nobody else has any more specialized knowledge than you anyway…

Start With a Model

Always, always, always start the discussion with a ‘model’ of some kind. Clients become very frustrated with BAs who offer nothing to start with, or who simply talk about the process of requirements discovery, and then wait to be told something. You need to bring an approach to the table.

This can take any number of formats. It can be a hand-drawn three-box domain model on a white board. It could be a table of contents that reflects the client’s categories. It can be a breakdown of categories you want to discuss (business objectives and priorities, success factors… etc.). It could also be a draft document that you’ve already prepared ahead of time (why not? You already know half of what the client will want anyway if you’re like most BAs I know). It could be a collection of websites or application screen shots that you’ve prepared that you think are similar to what you’re supposed to specify. Start there. Firm it up. This is more than anyone else has, and if you play your cards right, it allows you to set the categories for the discussion right up front, allowing you to ensure that you can complete your work the way you need to.

Capture, Confirm, Iterate

You should be writing or recording throughout every part of the requirements session. This sounds elementary (and I think they actually do teach this in “BA school”) but you’d be surprised how hard it is to do this in the real world, particularly when you’re also right in the discussion, asserting your opinions and putting forward models. Your process should be goal-oriented. This means that you may need to bring a coworker to help make notes, or buy a $50 digital audio recorder and transcribe the notes after the session.

At every step of the way, business analysts should confirm that they have, in fact, properly understood what is being said. If it doesn’t make sense to you, ask. The client’s team will use its own language to discuss its business problems – and you’ll need to understand that language in order to truly ‘get it.’ Confirmation should also be done after the requirements workshop. In fact, I often encourage my customers to email me with further thoughts or points of discussion, and I ask that they look out for emails from me asking for clarification.

Finally, no requirements process can be completed without iterating the requirements with the entire team. It is literally impossible (or at least very, very risky) to hold a single requirements session and go away thinking, “I’ve got it all.” That pretty much never happens. BAs should be open to working transparently, and to sharing their work-in-progress documents with the client. It is also important to make the client review these works-in-progress. That’s not always an easy thing to do, but it’s very important.

Leave a comment