The Business Analyst as Organisational GP

The Business Analyst as Organisational GP

Ask someone what a Business Analyst does and you may hear that they gather requirements, interview stakeholders, draw process models, analyse data, write business cases or help organisations introduce new systems.

All of those answers can be correct. But they describe the things a Business Analyst does, rather than explaining why the role exists.

Consider a General Practitioner. A GP may take a patient's blood pressure, listen to their heart, order a blood test, prescribe medication or refer them to a specialist. But none of those activities defines the purpose of the GP. They are techniques and interventions used in pursuit of something more important: understanding and improving the health of the patient.

Business Analysis can be understood in much the same way.

Seen this way, stakeholder analysis, process modelling, requirements engineering, investment appraisal and benefits realisation are not isolated techniques to be learned and applied mechanically. They are parts of a diagnostic and decision-making process.

The Business Analyst tries to understand the condition of the organisation, identify problems and opportunities, investigate their causes, consider possible interventions, help the organisation choose an appropriate course of action and, ultimately, establish whether the change actually made things better.

The Presenting Complaint

A consultation usually begins because something has happened.

A patient might complain of persistent headaches, tiredness or pain. An organisation has its equivalents. Customers may be leaving. Costs may be increasing. Orders may be taking too long to process. Staff may be overloaded. Errors may be rising. A competitor may have entered the market. New regulation may require a response. A promising opportunity may have appeared.

Sometimes, however, the patient arrives with more than a description of the symptoms. They arrive with their own diagnosis and preferred treatment.

A patient may tell the GP, "I've got a chest infection. I need antibiotics."

A stakeholder may tell the Business Analyst:

• "We need a new CRM system."
• "We need an app."
• "We need to automate this process."
• "We need another twelve people."
• "We need AI."

Any of those suggestions may eventually prove to be sensible. But at this point they are proposed treatments, not diagnoses.

This is one of the most important contributions a Business Analyst can make. Rather than immediately documenting somebody else's proposed solution, the analyst asks what problem the organisation is actually trying to solve, why it matters and what evidence suggests that change is needed.

Taking the Organisational History

A GP rarely considers a symptom in isolation. When did it begin? Has it happened before? What medication is the patient taking? Has anything changed recently? What is the patient's lifestyle? Is there relevant medical history?

The Business Analyst also needs context.

What does this part of the organisation actually do? Who are its customers or service users? What is it trying to achieve? How does the current process work? Who is involved? What systems and information does it depend upon? What has already been tried? What business rules apply? What regulatory, financial, technical or organisational constraints exist?

This is where many familiar Business Analysis techniques begin to earn their keep. The analyst might interview stakeholders, observe people at work, examine documents and data, facilitate workshops, model processes, map stakeholders or examine the wider business environment.

The technique is chosen because it helps answer a question. The objective is not to produce an impressive collection of diagrams.

Taking the Vital Signs

Medicine is not based entirely on what the patient says. The GP can take measurements.

Blood pressure, pulse, temperature, weight, oxygen saturation and laboratory results provide evidence about the patient's condition. No single measurement necessarily supplies a diagnosis, but each may contribute to a better understanding of what is happening.

Organisations have vital signs too.

Depending upon the problem being investigated, a Business Analyst might examine:

• revenue, costs and cash flow;
• profitability or cost per transaction;
• processing and waiting times;
• Value Time Percentage;
• capacity and utilisation;
• error, failure or rework rates;
• customer complaints or satisfaction;
• conversion and abandonment rates;
• staff turnover and absence;
• service-level performance;
• demand volumes and seasonal patterns;
• quality, safety or compliance indicators.

The relevant measures depend upon the organisation and the problem. A commercial business, hospital, charity, university and government department will not necessarily use the same measures of organisational health.

And, just as in medicine, a measurement must be interpreted.

A rising customer abandonment rate tells us that something may be wrong. It does not tell us why customers are leaving. Increased processing time may be a symptom of inadequate staffing, but it could equally result from a poorly designed process, duplicated work, bad data, inappropriate business rules or an IT system that makes a simple task unnecessarily difficult.

Diagnosis: Finding the Cause, Not Merely the Symptom

Suppose a customer service department reports that average handling time has increased dramatically. One obvious response would be to employ more staff.

But investigation might reveal that agents now have to copy customer information manually between two systems. Or perhaps a recent policy change introduced several unnecessary approval steps. Perhaps poor-quality data means staff spend several minutes correcting records before they can deal with the customer's actual request.

Each diagnosis suggests a different treatment.

This is where techniques such as root-cause analysis, the Five Whys, fishbone diagrams, process modelling, value analysis, observation, data analysis and business-rule analysis can help.

The analyst is looking beneath the visible problem. What is causing it? What evidence supports that conclusion? Are there several interacting causes? Would removing one bottleneck simply move the problem somewhere else?

Knowing When to Call a Specialist

Nobody expects a GP to be simultaneously a cardiologist, oncologist, radiologist, physiotherapist, pharmacist and surgeon.

Part of professional competence is recognising when specialist knowledge is required.

The same applies to Business Analysis.

A Business Analyst does not need to be the organisation's accountant, lawyer, Data Protection Officer, cybersecurity specialist, enterprise architect, UX specialist, tester or data scientist. But the analyst needs sufficient awareness to recognise when those perspectives matter and to involve the right people.

Consider a proposed customer analytics system. During investigation, the BA discovers that the organisation intends to combine customer records, browsing behaviour and information purchased from another company.

The BA does not have to personally provide definitive legal advice on data protection. But questions about personal data, purpose, lawful processing, transparency, retention and individual rights clearly need to be addressed. The appropriate privacy or legal expertise can then be brought into the analysis.

Similarly, a proposed AI system may raise questions about data quality, bias, explainability, human oversight, security, regulation or the consequences of an incorrect decision. Recognising those questions is part of understanding the proposed change, even though specialist answers may come from elsewhere.

Choosing the Treatment

Once a GP understands the condition, there may be several possible treatments.

Medication might be appropriate. But perhaps the more effective intervention is physiotherapy, weight reduction, a change in diet, more exercise, less alcohol, stopping smoking or simply monitoring the condition for a while.

Organisations also have more than one kind of treatment.

A problem might be addressed through:

• a change to a business process;
• training or development;
• different roles or responsibilities;
• a policy or business-rule change;
• better information;
• organisational restructuring;
• changes to suppliers or sourcing;
• an existing system used differently;
• a new technology solution;
• automation;
• artificial intelligence;
• a combination of several interventions;
• or, sometimes, doing nothing.

This is why Business Analysis should not automatically become requirements gathering for an IT system. Technology may be an excellent solution, but that conclusion should emerge from analysis rather than precede it.

Imagine an organisation whose sales staff complain that they cannot find accurate customer information. Management proposes purchasing a new CRM platform.

Investigation discovers that the existing system already contains the necessary facilities. The real problems are inconsistent data entry, inadequate training and different departments following incompatible procedures.

Buying another system might simply reproduce the same problems at considerable expense.

Will the Treatment Deliver Value?

Identifying a possible solution is not enough. The organisation must decide whether the proposed change is worthwhile.

That requires an understanding of value.

In a commercial organisation, value may include increased revenue, reduced operating costs, improved margins or competitive advantage. But value is not synonymous with profit.

A hospital might value reduced waiting times or improved patient outcomes. A local authority might value faster access to public services. A charity might value the number of people it can help. An internal HR department might value reduced staff turnover. A compliance initiative might reduce the organisation's exposure to regulatory action.

One of the BA's responsibilities is therefore to help make the expected value explicit. What improvement are we expecting? How large should it be? Who benefits? When should the benefit appear? How will we know whether it happened?

Financial analysis may form part of that decision. Cost-benefit analysis, payback, discounted cash flow, Net Present Value and Internal Rate of Return can help decision-makers understand the financial consequences of an investment.

But financial appraisal is evidence for a decision, not the decision itself. Strategic fit, risk, customer impact, regulatory obligations, operational resilience and less easily quantified benefits may also matter.

This is where Business Analysis contributes to the business case: not merely by supplying numbers, but by exposing the assumptions behind the proposed change and helping decision-makers understand the choices they are making.

Is the Treatment Safe and Appropriate?

A treatment can produce a desirable effect while creating unacceptable side effects.

Organisational change can do the same.

A highly automated process may reduce cost while making a service inaccessible to some customers. An AI system may increase productivity while producing systematically poorer outcomes for a particular group. A new analytics capability may generate valuable insight while creating serious data-protection concerns. A process change may improve speed while weakening an important control.

The question is therefore not simply:

Will this change deliver value?

It is also:

What else might happen if we do it?

The modern Business Analyst therefore needs awareness of subjects that may once have appeared peripheral to the role: privacy and GDPR, cybersecurity, accessibility, ethics, regulation, operational resilience, data quality, AI governance and the impact of automated decision-making.

Again, the BA does not have to become the specialist responsible for every one of these disciplines. The analyst's contribution is to ensure that important consequences are not ignored simply because they sit outside the immediate problem statement.

Writing the Treatment Plan: Requirements

Only after we have understood the problem and considered the appropriate intervention do requirements come fully into view.

This is an important distinction.

Requirements are enormously important, but producing requirements is not the ultimate purpose of Business Analysis. They help translate an understood business need into something that can be designed, changed, delivered and evaluated.

Depending upon the initiative, the BA may work with business requirements, stakeholder requirements, functional and non-functional requirements, business rules, data requirements, user stories, acceptance criteria, process models or prototypes.

In an iterative environment these may evolve as stakeholders learn more and as an emerging solution provides new evidence. In other circumstances, formal specification and traceability may be essential.

The form varies. The underlying purpose does not.

Supporting the Treatment

Once an intervention has been chosen, the Business Analyst's involvement does not necessarily end.

Questions arise during design and development. Testing exposes ambiguities. Users react to prototypes. Assumptions prove incorrect. External conditions change. A proposed process may behave differently in practice from the way everyone expected it to behave on paper.

The BA can help maintain the connection between the original business problem, the change being delivered and the outcome the organisation is trying to achieve.

Business Need  →  Diagnosis  →  Change  →  Outcome  →  Value

That does not mean preventing change to the original requirements. New evidence may show that a requirement should change. The important thing is to understand why it is changing and what that means for the intended business outcome.

The Follow-Up Appointment: Benefits Realisation

Eventually the project delivers.

The new system goes live. The process changes. Staff are trained. The organisation announces successful implementation. The project may even have been completed on time and within budget.

Those are useful measures of project delivery.

But the organisational GP has another question:

Suppose the business case predicted that a new process would reduce average transaction time from 18 minutes to 10. Measure it.

If an investment was expected to save £400,000 each year, establish whether the saving occurred.

If automation was intended to reduce manual workload, find out whether it did. If customer complaints were expected to fall, examine the complaint data. If a new service was intended to increase customer retention, measure retention.

This is Benefits Realisation: returning to the expected outcomes and establishing whether the benefits used to justify the change have actually appeared.

Benefits Realisation may reveal that the intervention worked exactly as intended. But it may also show that adoption is poor, an assumption in the original business case was wrong, another bottleneck has appeared, an expected saving has not materialised or the change has created an unexpected consequence elsewhere.

That is not merely a project-management concern. It is valuable diagnostic information.

Preventive Medicine

There is one final part of the GP analogy that is particularly important.

Doctors do not exist only to respond when somebody becomes ill. Preventive medicine seeks to identify risks early and maintain health through screening, monitoring, vaccination and changes in behaviour or lifestyle.

Business Analysis should not exist only when an organisation has already decided that it needs a project.

Analysts can identify inefficient processes before they become serious problems. They can notice deteriorating performance measures, recognise emerging regulatory obligations, challenge business rules that have outlived their purpose, identify risks in existing ways of working and spot opportunities created by changes in technology, markets or customer behaviour.

Sometimes the most valuable piece of Business Analysis prevents the organisation from needing a large corrective project later.

What Makes a Good Organisational GP?

The range of work described here can appear daunting. No Business Analyst begins their career knowing every technique, industry, technology and regulatory environment they may eventually encounter.

A useful way to think about professional capability is through three dimensions: Knowledge, Skill and Attitude.

Knowledge

The analyst needs knowledge appropriate to the work: business principles, finance, technology, data, regulation, organisational structures and the relevant business domain. The precise mixture will vary between roles and will continue to develop throughout a career.

Skill

Knowledge must be turned into action. Investigation, interviewing, facilitation, modelling, quantitative analysis, requirements engineering, communication, problem solving, critical thinking and option evaluation are all skills that improve through practice.

Attitude

The third dimension is easier to underestimate.

A good analyst is curious. They listen. They are willing to challenge assumptions without becoming needlessly confrontational. They care about evidence. They recognise that different stakeholders may legitimately see the same problem differently. They have enough professional scepticism to ask whether an attractive answer is actually supported by the facts.

They also know the limits of their own expertise and are prepared to say, "I don't know. Let's find out."

The Business Analyst and Value

We can now return to the question with which we began.

What does a Business Analyst actually do?

There cannot be a single list of activities because organisations have different patients, different symptoms and different needs. One analyst may spend a morning examining process data and an afternoon facilitating a stakeholder workshop. Another may be developing a business case. Another may be investigating the implications of introducing AI. Another may be working with developers and testers to clarify requirements. Another may be running a Benefits Realisation workshop several months after a system went live.

What connects those activities is not the technique being used. It is the purpose behind it.

That is why Business Analysis can operate at strategic, operational, process and technology levels. It is why the BA may be interested in finance one day, data protection the next and process performance the day after. It is also why requirements, important though they are, represent only part of the profession.

The techniques change with the problem.

The purpose remains remarkably constant.