What business analysts do

01The problem

Ashgrove Chambers, a Lagos law firm with eight lawyers and 50 clients, has a request from its managing partner, Mrs Folake Adeyemi-Cole:

"We need a new practice-management system. Ours is a mess of spreadsheets. Find us one by the end of the quarter."

A junior analyst starts comparing software. An experienced business analyst asks a different question first: what problem is the system meant to solve? Spreadsheets aren't a problem in themselves. Somewhere there's a cost: money arriving late, lawyers wasting hours, clients complaining. Until you know which, you can't say whether a new system will fix it, or whether something cheaper would do.

That question is the heart of business analysis, and this course teaches you to answer it properly, using Ashgrove as the case throughout.

02The concept

What a business analyst does

A business analyst (BA) helps an organisation change for the better, by understanding how it works now, working out what needs to change and why, and specifying the change clearly enough that it can be built, bought or adopted. The BA sits between the people with the problem (the "business") and the people who'll deliver the solution (developers, suppliers, the operations team).

The roles overlap, especially in small companies, where one person may do all four. A BA who can query data is far more effective, which is why this track includes Excel, SQL and Power BI.

The business analysis cycle

1. Understand the problem: stakeholders, goals and the current situation, measured with data where possible.
2. Analyse the current state: how the work flows today and where it breaks.
3. Define the future state: what should be different.
4. Specify requirements: what the solution must do, in a form people can build and test.
5. Justify it: a business case comparing the options.
6. Support delivery: answer questions, test the solution and help people adopt it.

Problem, not solution

Requests usually arrive as solutions: "we need a system", "build a dashboard", "hire another clerk". Your first job is to work backwards to the problem with questions like "What would be different if we had it?", "What does it cost us not to have it?" and "How would we know it worked?".

A good problem statement says who's affected, what's happening, what it costs, and how you'll measure success, without naming a solution.

03Example

The managing partner's request, turned into a problem statement after a few conversations:

"Ashgrove's clients take an average of 45 days to pay their invoices, and ₦188m is currently overdue, much of it for more than six months. Partners spend hours each month chasing payments by phone, and nobody can see at a glance what's owed or by whom. We want to collect faster and know where we stand, measured by average days to pay and the value of overdue invoices."

Notice what's missing: the word "system". A new system might be the answer. So might automatic email reminders, a weekly overdue report, or clearer payment terms on the invoice. The problem statement leaves those options open, and gives you a way to measure whichever one is chosen.

04Walkthrough

1. Read the managing partner's request again and list the questions you'd ask her before doing anything else.
2. Download the legal dataset and open invoices.csv. Filter status to Overdue. That list is the problem in the problem statement.
3. Write Ashgrove's request as a problem statement in your own words (the task below).
4. Note who else you'd need to talk to: the people who issue invoices, chase them, pay them and use the reports.

05Practice

06Check your understanding