How the work is actually done
No listicles, no career-change motivation. Each note takes one piece of the job, shows a finished artifact and says what a reviewer would object to.
Three clusters
Every note belongs to one of three threads. Each starts from a pillar and goes deeper from there.
The Case File
The portfolio guide names the six documents a reviewer asks for and shows a slice of each. The notes in this cluster build those documents one at a time, on the same returns case, with the decisions behind them written down.
Requirements That Survive Review
The acceptance criteria piece opens with five checks and points at the twenty-five in the scorecard. These notes go deeper: what to check, how to trace it, how to settle a dispute between two people who are both right, and when a requirement is ready at all.
The Document That Gets Read
The BRD piece shows one fragment before and after eleven edits. These notes take the document's sections one at a time: the business need, the scope, the measure of success, and what happens to all of it when a change request lands.
Latest notes
How Long Will the Analysis Take? An Estimate You Can Defend
Three clocks on one published case: thirteen hours of work, seven to nine hours a plan could name in advance, and twenty-eight days of calendar.
Read →A Risk Register With Owners, Dates and a Trigger
A risk register derived from artifacts I already had: eight candidates pulled out of a published case, three thrown out for having no trigger, five rows kept.
Read →Definition of Ready for a Requirement, Not a Ceremony
A definition of ready for requirements: seven conditions a stranger can check from the requirement itself, run backwards over three versions of my own register.
Read →Five Whys Stops Working at Why Number Two
When five whys does not work, and what to do instead: one incident from a published returns case, three honest why chains, three different recommendations.
Read →The Eight Questions in a First Stakeholder Interview
First stakeholder interview questions, built backwards from the six things a case assembled from public sources could not settle, and what each answer changes.
Read →Conflicting Requirements Are an Unmade Decision
Conflicting requirements are an unmade business decision. The one-page card I write instead of mediating, filled in on a 40 EUR refund threshold.
Read →Writing a Use Case: The Main Flow Is the Easy Half
The main flow of a use case writes itself. A worked returns case where the exceptions take three times the space, with the source of each one named.
Read →The Traceability Matrix That Survives a Change Request
What a traceability matrix actually is, one change request walked through it row by row in a quarter of an hour, and the questions it still cannot answer.
Read →The Success Measure That Makes a Business Case Falsifiable
Five success measures in the wording documents use, put through one question: what result would mean this did not work. Plus the table the survivors go into.
Read →The Stakeholder Map That Survives Contact With the Project
A stakeholder map lists who can stop the work, what each one can stop, and where I know that from. A blank row to copy, three filled in from public sources.
Read →RACI for Requirements Sign-Off: Who Actually Approves
A sign-off matrix on a published returns case: one business rule walked through every role that can approve it, and what to write when nobody can be named.
Read →The Questions a Reviewer Asks About Your Work Sample
What reviewers look for in a BA work sample, in the order they look for it: seven questions across twenty minutes, and what stops the read at each one.
Read →Next in the queue: The Feasibility Memo That Recommends Not Building It · MoSCoW or WSJF: Prioritising When Everything Is a Must.
A letter when I have something worth sending
New notes go up on this page as they are written, and the Proof Pack comes when you join. No schedule, no sequence, no webinar funnel.
Subscribe