Writing

Building
in public.

A working Business Analyst project, posted in 32 parts. From kickoff to launch, with the rough edges left in.

Start here

The roadmap: what I'll be building over the next 32 posts

A fictional mid-sized Canadian P&C insurer is drowning in claims intake. They want to bring AI into the workflow. I'm the BA. This is the full arc, end to end, before any of the work begins. Read this first.

Read the roadmap

Stage 01 Domain understanding 2 posts

Where I'd actually start as the BA on this project

Most people think a BA starts by gathering requirements. They don't. They start by understanding the world they're walking into.

The first questions I'd ask, and who I'd ask them to

The question list comes last. Who you sit across from comes first, and how you read them once you're there.

Stage 02 The business case 5 posts

What a business case actually is, and what most people get wrong about it

A business case is a permission document, not a project plan. Most reads like a feature description, which is why most don't get approved.

The problem statement, and why the first draft is always wrong

My first draft was so weak a director would have skipped to lunch. Three rewrites later, it landed.

Business objectives, and the mistake almost every junior BA makes

I almost wrote my objectives like features instead of outcomes. The difference is what gets a project approved or killed.

Designing success metrics, and the standard deviation moment that humbled me

A senior BA once said: show me the metrics and I'll tell you if the project will work. Here's what I designed, and what I almost got wrong.

Measuring what can't be measured: experience, cognitive load, and three biases that ruin your data

How do you measure whether agents feel less overwhelmed? Most teams send a survey. That's the wrong answer.

Stage 03 Scope, assumptions, stakeholders 5 posts

Scope thinking: the three mental moves that actually generate a scope list

Most BA training says "define scope" but never teaches how to think about it. Here are the three moves I use.

The out-of-scope list, and the single sentence that protects the project from politics

The most important sentence in the scope section isn't about the AI. It's about the people the AI works alongside.

Assumptions and constraints: the section where junior BAs lie to themselves

Every BA project rides on hidden assumptions. The senior move is to name them out loud, even when they make you look uncertain.

The stakeholder map, and why the call centre agent matters more than the CEO

Most stakeholder lists put the C-suite at the top and the actual users at the bottom. That ranking is backwards.

The executive summary, and why I wrote it last

Every template tells you the exec summary comes first. Mine was the last thing I wrote.

Stage 04 Process maps & requirements 6 posts

Current state process mapping, and why BAs draw the broken process first

You can't design the fix until you can see exactly what's breaking, where it's breaking, and why.

Future state process mapping, and the trap of drawing it too clean

The future state map almost lies by being too neat. Real workflows always have exception paths.

BRD vs FRD: what they actually are, why people confuse them, and which one you need

These two documents get mixed up constantly. Here's how to keep them separate.

User stories: the format every BA learns, and most BAs use wrong

The template is simple. Using it well is hard. Here's where most user stories fall apart.

Acceptance criteria: the discipline that separates a junior BA from a senior one

If you can't write clear acceptance criteria, your user stories will always come back broken.

Edge cases: the work nobody trains you to do

Every edge case you don't think about now becomes a defect later. Here's how to surface them.

Stage 05 Build the prototype 4 posts

Why a BA should build the working prototype, not just spec it

Most BAs hand off the spec and wait for the developer. Building it yourself changes what you understand.

The actual workflow: n8n connected to Vertex AI, with screenshots and JSON

The build itself. Every connection, every prompt, every decision.

What surprised me when I tested it with real-looking inputs

Every AI workflow does something unexpected on day one. Here's what mine did.

Prompt design for severity classification: what worked, what didn't

Five rewrites of the same prompt to get consistent output. The lessons that survived.

Stage 06 Testing & governance 4 posts

UAT for AI systems: where the social desirability problem shows up again

User Acceptance Testing for AI is harder than UAT for normal software. Here's why.

Designing the test cases: covering normal, edge, and adversarial inputs

If you only test the happy path, you'll launch a system that fails on contact with reality.

The defect log, and how to structure one without overengineering

Defect logs collapse under their own weight when they're too detailed. Here's the structure that survives.

The AI evaluation framework: Hawthorne, drift, parallel runs, in context

All the concepts I touched on earlier, now wired into a real evaluation plan.

Stage 07 Operationalizing 3 posts

Post-launch monitoring: dashboards, ownership, weekly vs monthly

If nobody owns the dashboard, the metrics die. Here's how to structure ongoing oversight.

Change management for the agents: the political post

An AI project that fails on technology can be fixed. One that fails on people usually can't.

Jira and Confluence setup: the boring but important infrastructure post

Nobody talks about this part. Every real BA does it on day one.

Stage 08 Closing the loop 2 posts

What I learned doing this in public

The honest retrospective. What worked, what didn't, what I'd do differently.

What's next, and an open invitation to anyone hiring

The series ends. The work continues. Here's where I'm going.

Let's work together

Following along?

If you've done this kind of work, or you're a BA staring down an AI project with no playbook, I'd love to compare notes.

Book a free call Follow on LinkedIn