The scorecard: 25 checks a business analysis artifact has to pass

Twenty-five checks across the six artifacts in the Proof Pack. Every one answerable yes or no by looking at the document.

Version 1.0 - 6 September 2026. Changes are logged at the bottom of this file, never edited silently.

Somebody has to say what good means, so here is my version, written down where you can argue with it. Twenty-five checks across the six artifacts in the Proof Pack. Each one can be answered yes or no by looking at the document. Nothing here asks whether the work is clear, professional or well structured, because those are opinions, and an opinion cannot be failed.

The examples in the "why this matters" lines come from the worked case in the pack: returns and refunds at a mid-size online retailer, REQ-014, BR-11, the 48 hour decision window. That case is an example I built from public sources to show the standard. It is not a client engagement, and the checks are not specific to retail.

Checks 01 to 05 are the five published on the site. They keep the numbers they were published with and sit in the artifact they belong to, so the numbering inside a section does not always run in order. Checks 06 to 25 are numbered in reading order.

Free to use on your own work, on your team's, or in a review you are running for somebody else.

How to use it

Run it twice. The two passes catch different things.

Pass one, alone. One artifact at a time, top to bottom, yes or no. Twenty minutes for all six once you know the list. There is no "partly": if you catch yourself building a case for a yes, write no and move on, because the case you are building is the answer.

Pass two, hand it over. Give a colleague the document and this file and ask them to be unkind. Not "does this look okay". The brief that works is "find the three checks I have fooled myself on". Do not walk them through the document first. If it needs your commentary to pass, it has already failed check 02, and you have just proved it in person.

How to answer. A check is a yes only when a stranger can confirm it from the document without asking you anything. "It is in my head", "the client knows" and "we agreed that in the workshop" are all no.

What the score means

Count the yes answers. Twenty-five available.

Score	What it means	What to do next
0-12	A set of headings, not a document. Most of it is still in your head.	Pick one artifact and finish that one properly. Patching all six at once produces six weak ones.
13-17	An internal draft. Useful to circulate, not to send.	Get the review done. Half of what is missing at this level only shows up when somebody else reads it.
18-21	Nearly. The thinking is there and the paperwork is not.	Fix the owners, dates and sources first. They cost minutes each and they carry most of the remaining nos.
22-25	Ready to show.	Send it. Expect questions about judgement, not about completeness.

Two rules on top of the number.

The published five are a gate. If any of 01 to 05 is a no, the pack is not ready to show, whatever the total says. Those are the checks a reviewer reaches first, usually inside the opening minute.

Where the nos sit matters more than how many there are. Four nos spread across four artifacts is a document with rough edges. Four nos inside the requirements register is a document that has not been thought through, and it will read that way.

1. Stakeholder map

One page naming everyone who can approve, block or quietly derail the change.

#	Check	Why this matters
04	Each stakeholder has a decision right, not just a job title	Titles tell you who attends the meeting; decision rights tell you who can stop the work, and you want that list before the steering committee rather than during it.
06	Every row names a person or a specific role, never "the business", "the users" or "IT"	A stakeholder you cannot put an email address against is a stakeholder nobody has spoken to.
07	Every row cites where its claim came from: a session and its date, a policy section, or a thread anyone can open	Without a source the map is a set of guesses in a grid, and the first person who disagrees with it wins by default.
08	Every row says what that person loses if the change goes through	People with something to lose are the ones who slow a project down, and the warehouse lead who receives the returned goods is rarely in the room where the refund window gets shortened.

2. As-is and to-be process

Two models of the same process: how it runs today, and how you propose it should run.

#	Check	Why this matters
03	The as-is model shows the exception path, not the happy one	An as-is with no failure branch makes your to-be look better than it is, and that is the objection a reviewer reaches in about forty seconds.
09	Every task in both models has one actor against it: a lane, a role or a named system	A task with nobody against it is work nobody has agreed to do, and it stays unassigned until somebody notices halfway through delivery.
10	Every claim about frequency or volume carries its source, or is marked as not measured	Turning "four of the first ten complaint threads ended there" into "40% of cases" is the cheapest way to lose a reader who checks things.
11	The to-be states what changed against the as-is, and what deliberately stayed the same	Without the delta a reviewer cannot tell a design decision from a redraw, so the whole model gets treated as unproven.
12	Every branch in the to-be where a case waits ends with a named owner and a time limit	A parked case with no owner and no clock is how a customer ends up chasing you, and it survives the redesign unless the model puts a name on it.

3. Requirements register and acceptance criteria

The numbered list of what the solution must do, written so it can be tested and traced.

#	Check	Why this matters
01	Every requirement traces to a named business rule	A requirement with no rule behind it is the first thing cut when the date gets tight, and nobody can say what breaks when it goes.
02	Acceptance criteria are testable without asking the author	If the tester has to walk over and ask what you meant, the criterion is a note to yourself filed in a document other people work from.
05	Open questions are listed with an owner and a date	A question with nobody's name on it quietly becomes an assumption, and assumptions surface during build, at the worst price you will pay all year.
13	Every criterion containing a duration names the event that starts the clock	"Within 48 hours" went through refinement without a single comment and came back at the sprint review with two people disagreeing about whether it was done.
14	Every requirement carries an id, a version and the date it last changed	Without those, a reviewer's comment lands on a paragraph instead of a line, and neither of you can tell which draft you are arguing about.

4. Business rule with rationale

One rule, stated precisely, with the reason behind it and the person who owns it.

#	Check	Why this matters
15	The rule states its condition and its outcome in one sentence	A rule that needs a paragraph of context before anyone can apply it gets applied differently by every person who reads it.
16	The rule names the person or role who set it, and the date it was set	A rule with a name on it can be renegotiated; an anonymous rule can only be worked around, which is what happens quietly and permanently.
17	The reasoning is written down, and anything you inferred rather than found is labelled as an inference	The 40 EUR figure is the least interesting part of BR-11, and the argument behind it is the thing that stops somebody changing it in a corridor six months later.
18	The rule names the event that would make it wrong and should trigger a review	Thresholds outlive the conditions that produced them, and a threshold nobody can explain survives the next redesign because changing it feels riskier than keeping it.

5. Review log

A short record of what a reviewer objected to, what you changed, and what you did not.

#	Check	Why this matters
19	Every entry names who raised the objection, what changed as a result, and the date	An objection recorded with no consequence next to it shows that you heard it, not that you did anything with it.
20	At least one entry records an objection you did not accept, with the reason you held your ground	A log where the author agreed with everything was either a very short review or a very polite one, and neither is evidence that you can think while being argued with.
21	Every objection is either closed or carries an open action with an owner and a due date	An objection parked in the "we discussed it" state comes back later, usually from somebody more senior and in front of more people.

6. One-page summary for a decision maker

One page, written last, read first, addressed to the person who has to say yes or no.

#	Check	Why this matters
22	The first line states the decision being asked for, who has to make it, and the date it is needed by	A page that opens with "this document describes the current process" asks for nothing, so nothing happens, and you get invited to another meeting instead.
23	Each option shows its cost, its risk and its effect on the problem named in the document	Options without those are a menu with no prices, and the choice defaults to whoever speaks last in the room.
24	One option is marked as your recommendation and carries your name	A studiously neutral summary hands the judgement back to the person who asked you for it, and the judgement was the part they wanted.
25	The page says what happens if nothing is decided	Doing nothing is always on the table, and when you leave it undescribed it tends to win by accident.

Score sheet

Copy this, or tick in the margin of the printout.

Artifact	Checks	Yes
Stakeholder map	04, 06, 07, 08	___ / 4
As-is and to-be process	03, 09, 10, 11, 12	___ / 5
Requirements register and acceptance criteria	01, 02, 05, 13, 14	___ / 5
Business rule with rationale	15, 16, 17, 18	___ / 4
Review log	19, 20, 21	___ / 3
One-page summary	22, 23, 24, 25	___ / 4
Total		___ / 25

Published five all yes? ☐ yes ☐ no. A no here caps the pack at "not ready to show", whatever the total says.

Date scored: __ Scored by: ____

What this scorecard does not check

A checklist catches the things that can be seen on a page. Most of what separates a good analyst from a tidy one cannot be, so here is the honest list of what a perfect 25 does not prove.

Whether you asked the right questions. The register can be immaculate and describe a process nobody needed changed. No check here can tell you that you spent three weeks on the wrong end of the business.

Whether the answers you were given are true. Check 16 asks whether the rule has an owner and a date. It cannot tell you the owner was right, or that the person in the workshop was describing what actually happens rather than what is supposed to.

Whether the model matches reality. Only somebody who does the job every day can confirm that, and they will do it in about ten minutes if you show them the model instead of describing it.

Political timing. When to raise an objection, when to let it go until the room is smaller, whose name to leave off a slide. Every one of those is judgement, and judgement is the thing a scorecard is worst at.

Whether the change is worth making. Value, priority, sequencing, opportunity cost. Six perfect artifacts about a process that should have been left alone are six perfect artifacts.

Whether the solution is buildable. Cost, feasibility, what it does to the systems around it. That conversation happens with people who are not you.

Whether anyone enjoys reading it. Rhythm, tone, the sentence that makes a director keep going to the second paragraph. Compression is a craft and this list does not measure it.

Whether you can defend it out loud. Five minutes of questions from somebody unimpressed will tell you more than all twenty-five checks together. Ask for the five minutes.

A document that scores 25 and answers the wrong question is a well-built answer to the wrong question. The scorecard cannot see the question. You can.

Version history

1.0 - 6 September 2026. First public version. Later versions get a dated line here, with what changed and why. Nothing gets edited out silently.

The six templates these checks apply to · The worked case · The Proof Pack · All field notes