The job: need first, then the change, then the value

A business analyst (BA) helps an organisation change in a way that is worth it. The most widely used description of the work is the BABOK Guide, published by IIBA. It describes business analysis as enabling change in an organisation by defining needs and recommending solutions that deliver value to stakeholders. This course follows its structure, version 3 from 2015.

In practice the job has three parts that repeat all through a project:

1. Understand the need. What problem or opportunity is there, for whom, how big, and how do we know?
2. Define the change. What must be true of a solution, what will people do differently, and what are the rules, data and edge cases? This becomes the requirements the team builds and tests against.
3. Make sure it delivers value. Did the change solve the problem? If not, why not?

The first part is the hardest, because most work arrives as a solution in disguise. In your first week two requests land. The head of partner sales: "Build a phone-order screen for the reps so they can type orders in faster." A finance analyst: "Force the shops to use the app. Switch off phone orders." These are opposite solutions, and neither says what the pain is.

Use the move from Problems before solutions: split each request into a goal, a pain and a proposed fix. The sales head's goal is happy shops and reps; the pain is time spent writing and re-keying orders; the fix is a screen. Finance's goal is lower cost; the pain is corrections after delivery; the fix is a rule. The shared need underneath is "partner orders that are quick to place and arrive right". Keep both fixes on the list as options, and pick none until the need is measured.

Six core concepts to check any change

BABOK's core concept model (BACCM) names six ideas that every piece of analysis touches. They are useful because they are connected: change one, and you have to check the other five. Here they are on your project.

• Need: a problem or opportunity. About 1,500 partner orders a week still come by phone to about 40 sales reps, and about 1 phone order in 12 (about 125 a week) is corrected after delivery, at about $9 each.
• Change: the move from today to a better state. Partner orders move from the phone into the Partner app, and the reps' daily work changes with them.
• Solution: a specific way to meet the need. It is not chosen yet. Candidates so far: a phone-order screen for reps, switching the phone line off, or changes to the app itself.
• Stakeholder: anyone with a relationship to the need, the change or the solution. Ravi and about 1,800 partner shops, the 40 reps, the head of partner sales (the project's sponsor), finance credit control, the four DCs and about 120 drivers, Lagoon Digital and Imran.
• Value: what the change is worth to a stakeholder. For Mangrove, moving to 75% app share is worth about $40,000 a year in cost to serve (Unit economics worked it out). For Ravi it might be fewer wrong deliveries. For a rep it might be time back, or a loss if their bonus counts the orders they enter.
• Context: the circumstances around the change. Shops buy on credit with limits set by finance, orders before 6 pm are delivered next day, mobile data is patchy in places, and Lagoon works under a contract.

Use the six as a checklist for every candidate solution. Take "switch off phone orders". Need: it removes phone corrections. Value: good for finance, unknown for Ravi. Context: what about a shop with patchy data, or an order over its credit limit? Stakeholders: will some shops buy from another wholesaler instead? Two minutes with the model turns a confident request into four questions.

Six knowledge areas: what you will actually do

BABOK groups the BA's tasks into six knowledge areas. Don't memorise them as a list. Read them as six kinds of work you will do on this project, often in the same week.

BABOK says plainly that the knowledge areas are not phases and are not a method to follow in order. On an agile project you touch all six inside one sprint, at small scale. In one week you might confirm interview notes (elicitation), write examples for the credit story (requirements analysis), update a trace link after Imran reorders the backlog (life cycle management) and check pilot numbers (solution evaluation).

The guide also lists 50 techniques the tasks use (interviews, process modelling, decision tables and many more) and five perspectives on how the work changes by setting: Agile, Business Intelligence, Information Technology, Business Architecture and Business Process Management. Your project mixes Agile (Lagoon builds in sprints) with Business Process Management (the real change is how orders flow through reps, finance and the DCs).

Who does what, and how a BA works in an agile team

On a real team the roles overlap, so agree them early. What a product manager actually does covers the product manager and project manager in depth. Here is how the BA fits in.

The BA's special value is staying neutral about the solution while being precise about the need. Imran decides the order; you make sure each item is understood and earns its place.

How the work flows depends on the project. In a plan-driven project, the BA writes a full requirements document up front, it is signed off, and changes go through formal change control. That fits work where the rules are known and change is expensive, such as a regulatory report. In an agile project the requirements grow with the product. Lagoon builds in two-week sprints, so you work one or two sprints ahead, with just enough detail just in time. A story for next sprint needs examples and edge cases. A story three months away needs one line and a link to its objective.

Three habits make this work.

• Backlog refinement. The Scrum Guide describes it as an ongoing activity. You bring the next stories with their purpose, rules and examples; the team asks questions and sizes them.
• Three amigos. Before a story is built, you (the business view), a Lagoon developer (how could we build it?) and a Lagoon tester (what could happen?) talk it through and agree examples. The Agile Alliance glossary warns against keeping it to exactly three people when someone else knows the answer, such as a finance analyst for the credit story.
• Sprint review with real users. At the end of each sprint, Ravi or a rep tries the new piece. Their reactions go into the backlog before the next refinement.

Your project is a hybrid, like most vendor projects. Lagoon's contract (see Working with vendors) fixes the budget and main scope up front, so objectives and business requirements are agreed early; the detail stays just in time.

Measure the problem, then set objectives

Before you define any solution, measure the need. Ask Tomás for one week of partner orders by channel and count corrections. The query is in the Practice section. Here is what it shows:

channel   orders   corrected   corrected_pct
app        2,500        25          1.0
phone      1,500       125          8.3
total      4,000       150

App share today: 2,500 / 4,000 = 62.5%, about 62%

Then write a problem statement in the form from pm-02: a specific user, an obstacle, a measurable cost and evidence, with no solution words.

Partner-shop owners need to reorder stock quickly and receive exactly what
they ordered, but about 1,500 orders a week still go by phone to about 40
sales reps, who write them down and enter them later. About 1 phone order
in 12 (about 125 a week) is corrected after delivery, at about $9 each, and
a phone order costs about $1.75 to serve against $0.20 in the app.
We know because of one week of order data (Tomas) and the pm-27 cost study.

Next, turn the problem into measurable objectives. Each has a metric, a baseline, a target, a date and a named source for the number:

• O1, app share: partner orders placed in the Partner app, from about 62% to 75% of all partner orders. That is about 500 fewer phone orders a week (1,500 down to about 1,000).
• O2, corrections: phone-order corrections after delivery, from about 125 to under 60 a week, while app orders stay at about 1 correction in 100.

Writing the numbers down teaches you something. If O1 succeeds and nothing else changes, about 1,000 phone orders a week at 1 in 12 still gives about 83 corrections. O2 can't be met by moving orders alone. The remaining phone orders must go wrong far less often: under 60 in 1,000 is under 6%, or better than about 1 in 17. So the project must find out why phone orders go wrong, which is what elicitation in ba-02 is for. The second half of O2 is a guard: it stops the team "winning" by moving errors from the phone into the app.

Agree the date with the sponsor and write it into each objective. Without a date and a source, nobody can check the objective at the end, in Solution Evaluation.