The thankless job of a business analyst

It was 2012, and our office then was a hundred metres from where our corporate office is today. My friend Peter Menon met me one day. He had just exited his role as the head of information systems at Pest Control India Ltd, and was looking for consulting opportunities. He was frank with me: he did not understand modern software development at the bits-and-bytes level, but he had enormous business maturity, being a wise old veteran of many industries.

We had a new project coming up. I told him “Don’t get into project management, because it’s a more painful game, where your business knowledge may not be used as much. Why don’t you get into the functional side of the project? Become a leader from the functional and business side.” We talked, he liked the idea, and we shook hands. We got ourselves a fabulous business analyst in this tricky project.

The project was for one of India’s leading car leasing companies. They needed a software system to keep track of the insurance policies of their fleet of tens of thousands of cars. The average software developer in the IT industry does not have any idea of this world. But Peter, who had worn many hats in many businesses over his decades of stewardship of various roles, could just slip into this area.

He then asked me one question, and this essay is just that one question and its answer. The question remains valuable, 12 years later. He asked: “But Shuvam, what exactly do I do? What is my role?” I told him that he’ll be what we in the industry call a “business analyst”, and I was sure that he’ll be the world’s best business analyst.

What does a BA do?

I told Peter that a BA’s role has four pillars.

1 Capture specs

Everyone in the IT industry knows that the BA captures business specs for a new application. Most people describe the role of a BA in terms of fat documents which the BA is expected to prepare. The IT industry is burdened with fat documents which no one reads, like FSD (Functional Specifications Document), BRD (Business Requirements Document), and what not. We have a far simpler format for our specs capture exercise.

Together with conventional specs capture, the BA needs to work with a UX team to create wireframes which are first shown to the client, and then delivered to the dev team.

The BA gets the all-important client sign-off for the specs captured. This sign-off covers the mock screens, user journeys, user stories (we call them business operations in Remiges), and field-level details.

Peter asked me, how we will know that the specs capture has been done well? What are the yardsticks for a job well done? I said that the second pillar will demonstrate that.

2 Lead the tech team for functional specs

The BA must explain the business functionality, constraints and corner cases of the system to the software design and development team so well that the module leads will not need to get clarifications from the client. If any clarifications are required, the BA will get them.

Too often, the specs given by the client are incomplete or inconsistent. For instance, you are told that you have to enter a specific ID in a specific screen, but in some cases, that ID is not even defined till much later. A good BA will not only detect such inconsistencies in the specs, he will argue them out with the client and ensure that he presents gapless, flawless specs to the tech team. The mark of a good BA is the rarity of going back to the client for clarifications after the tech team studies the specs and throws up queries.

I told Peter very clearly — the BA is a human, and so are the tech leads who will design the application. Communication among humans needs conversation, not a document. I totally dismissed (and continue to dismiss) the prevalent belief in the software services industry that the BA’s job is to create a fat document. Documents must be created, but they will play a supporting role. The BA must be willing to do endless huddle sessions, endless scribbling on whiteboards, with the tech team, to win their trust, guide them, and give them comfort.

Peter was in his element here. He was absolutely awesome. The dev team, the tech leads, ate out of his hand. He would explain, in his gruff baritone, every argument they brought up. His word was law.

3 Verify functional correctness

This role comes up as the software is getting developed. The BA reviews the software for functional correctness. Testers are very valuable for testing whether the software accepts a floating point number where an integer is expected, or when a screen is rendered in a messed-up way, and so on. A BA knows the original specs to a greater depth. Only a BA will know whether a workflow implemented in a sequence of screens actually matches the client’s ask under all conditions.

Therefore a BA reviews all software at a user level, matches against his notes, and discusses doubts and discrepancies with the client if needed. He is the lead team member to point out functional discrepancies with the dev team and get them corrected. He escalates such discrepancies to the Project Manager and discusses impact of the remedial measures in terms of time and effort.

4 Lead the user acceptance process

The BA takes the lead to deliver the final system to the client.

Every project we have ever done gets into some arguments with the client at this stage. There will be disagreements about whether we needed a certain form B after form A or before. Whether a GST registration certificate was mandatory or optional for proprietorship firms. This is the stuff of user acceptance for any large custom business application.

Here, the BA is the lead member of the project team to engage in discussions (sometimes cool, sometimes heated) with the client to explain that the software which has been built matches what the client had specified, irrespective of whether the client today likes it or not. The BA may be assisted by the Project Manager, but this task is not in the Project Manager’s role. The dev team must be shielded from the client at this stage, because developers have a tendency to listen to the client and simply make changes to the system straightaway.

The challenges of the BA’s role

Peter and I discussed these four pillars at length, nodded a lot, and drank tea (his, without sugar).

It’s been a dozen years. I have seen how hard it is to do a BA’s job well. Here are the common challenges.

Don’t just listen. Question. Ask. Listening passively is the First Sin of a BA’s role. A BA is often told that his job is to “just capture specs from the client.” So he commits the sin of believing that he can sit and listen quietly while the client pours out the spec in a lucid and error-free stream of words and pictures. This never happens; we have never met a client who can do this. Sometimes senior officers of the client organisation start “discussing” the semantics of a business operation between themselves in the presence of our BA team, displaying remarkable confusion and ambiguity.

The BA therefore must take the lead; he must not sit passively while the client dumps a pile of detail on his bowed head. He must stand up, walk to the whiteboard, and then start asking the client crisp, penetrating questions to extract the relevant details from them with the least meandering. He must behave like a good medical diagnostician. He must ask questions to the client, not allow the client to pour confusion into the fact-finding session.

Look for inconsistencies. Our clients give us contracts, expecting us to identify the ambiguities and inconsistencies in their business operations. They look to us to clear up years of accumulated confusion in their processes. The BA is the arrowhead of our project team to cut through all this confusion and inconsistency to get clear spec. This requires a mindset not unlike a lawyer cross-examining a confused witness. We do it politely, that’s all.

Do not assume. Period. We work with enterprise clients — the largest and, sometimes, the most conservative financial institutions. They have been in business for decades, and their processes sometimes operate in ways which young engineers today would not consider “logical”. The BA must not assume anything with that but-of-course-isn’t-it-obvious brashness of youth. Fifty years of any business implies fifty years of time for archaic practices to accumulate in the system well past their use-by date. Fifty years of conflicting regulatory requirements to accumulate like layers in sedimentary rock, none of which may make sense in the 21st century. Fifty years of partial adaptation of painstaking manual processes to computerisation where an ab initio process design would have cut through the clutter. One of our clients will celebrate their 150th anniversary in a few days — they are a household name in the Asia Pacific capital markets. The BA does not have the luxury of assuming that processes and standards are “logical”.

In many ways, a talented BA’s mind is sharper than that of most developers.

I’ve been asked, “How do we expect a young BA to lead a fact-finding session with client officers who may be older than him?” I can only say that a good 30-year-old lawyer will grill his witnesses and tease facts out of them irrespective of their age. Only those who have this quality can be good BAs. It’s not about their age.