Most programmes do not fail on technology. They fail because nobody
established what the organisation was for, what actually happens today, or who had to
agree. This is the process I run, the 24 techniques I run it with, and the
28 diagram templates I draw the results in.
Engagements start wherever the gap is — you do not have to buy the whole
sequence. But each stage assumes the one before it was done by somebody.
01
Frame the strategy
Before anyone writes a requirement, agree what the organisation is for.
You end up with A stated direction, and the external forces that could move under it.
PESTLE
Francis Aguilar's ETPS, 1967
The problem
We are committing to a direction without knowing what could move under us.
What you get
The external forces that would actually change the decision, each marked known, inferred or speculative — not a list of everything happening in the world.
Porter's Five Forces
Michael Porter, 1979
The problem
Nobody can say who captures the margin in this market, or whether we could.
What you get
A structural read on the market, and a straight answer on whether it is worth entering with the capability you have.
MOST
No single originator
The problem
The team is busy, and nobody can explain how the work serves the mission.
What you get
The specific breaks between mission, objectives, strategy and tactics — and what the largest one is costing you.
SWOT
Stanford Research Institute, 1960s
The problem
Strategy conversations turn into a list of complaints.
What you get
Capability and conditions in one frame, converted into strength-opportunity pairs. The pairs are the strategy; the grid on its own is wallpaper.
02
Understand the situation
Find out what actually happens, not what the process document claims.
You end up with An evidenced as-is, with the real gaps named.
Interviewing
No single originator
The problem
The people who know how it works have never been asked properly.
What you get
A record of what each role actually does, with the completed documents that prove it rather than the blank forms that describe it.
Workshops
No single originator
The problem
The decision has been circulating by email for six weeks.
What you get
Decisions made in the room by the people with authority to make them, and the disagreements resolved on the day instead of resurfacing at delivery.
Document analysis
No single originator
The problem
The process document and the live system disagree, and nobody has reconciled them.
What you get
What data is really captured, who fills each field, and every process step the paperwork implies but no one described.
Fishbone analysis
Kaoru Ishikawa, 1960s
The problem
The same failure keeps happening and everyone already knows the cause.
What you get
Causes separated from symptoms, each marked evidenced or assumed, with the cheapest test that would settle the biggest assumption.
03
Read the people
Most stuck programmes are stuck on worldview, not on technology.
You end up with A stakeholder map, and the conflicts that would otherwise surface late.
CATWOE
Peter Checkland, Lancaster University, 1981
The problem
Two senior people are arguing about a solution and agreeing on nothing.
What you get
The worldviews underneath the argument and the precise point where they diverge — which is the thing that has to be resolved, not the stated dispute.
Power/interest grid
No single originator
The problem
More stakeholders than there are hours, and all of them want a meeting.
What you get
Who to manage, consult, inform and watch — including the quiet high-power ones who become very interested the moment they hear about the change.
Force-field analysis
Kurt Lewin, 1951
The problem
The change is technically ready and politically stuck.
What you get
Driving and restraining forces scored, and the single restraint that unblocks the most if it is removed. Removing a blocker beats adding a push.
Cynefin
Dave Snowden, 1999
The problem
A best-practice answer keeps being applied to a problem that has no best practice.
What you get
What kind of problem this actually is, and whether your current approach matches it. Running complicated-domain methods on a complex problem is the usual failure.
04
Model what happens
Draw it. Ambiguity survives prose and dies in a diagram.
You end up with Process and system models precise enough to build from and to argue with.
Business process modelling
No single originator
The problem
We are about to automate a process nobody has drawn end to end.
What you get
Swimlane models showing every hand-off, wait and rework loop — with the unknowns listed as questions to ask, not smoothed into plausible guesses.
Business activity modelling
Peter Checkland, Soft Systems Methodology
The problem
The current state is such a mess it is stopping anyone imagining a better one.
What you get
What the business must do, independent of how it does it today, and the gap between that and the present.
Use case modelling
Ivar Jacobson, 1987
The problem
We cannot agree what is in scope with people who will not read a specification.
What you get
An agreed system boundary expressed as goals users achieve, not screens they see — legible to people who will never open the spec.
Gap analysis
No single originator
The problem
We know roughly where we are and where we want to be, but not what stands between.
What you get
Gaps across people, process, technology and information — sized, sequenced by dependency, and including what has to be retired. That last part is where cost hides.
05
Choose between options
Make the trade-off explicit and priced, before the decision hardens.
You end up with An options appraisal with a recommendation and a revisit trigger.
Cost-benefit analysis
No single originator
The problem
The business case claims benefits nobody can substantiate.
What you get
Benefits split into cash-releasing, quantifiable and intangible, with the forgotten costs added back: transition, training, run, and decommission.
Investment appraisal
No single originator
The problem
Two options look alike until you notice the money lands in different years.
What you get
Payback, NPV and IRR with the workings shown, plus the one assumption whose movement flips the ranking.
Feasibility assessment
No single originator
The problem
We are building a business case for something that was never going to work.
What you get
Business, technical and financial feasibility assessed separately, ending in one recommendation: proceed, proceed with a named probe, or drop it now.
Decision trees
No single originator
The problem
The outcome depends on things we do not control, and nobody has priced waiting.
What you get
Expected values rolled back, the probability the answer hinges on, and what it would be worth paying to resolve the uncertainty before committing.
06
Specify and land it
A requirement nobody can test, and a benefit nobody owns, both evaporate.
You end up with Testable requirements, a scope that holds, and an owner for every benefit.
MoSCoW prioritisation
Dai Clegg, 1994; DSDM
The problem
The date is fixed and the scope is not, so quality is what quietly gets cut.
What you get
A prioritisation that survives pressure: musts challenged down to those with no workaround, contingency protected, and every exclusion given a reason.
User stories and acceptance criteria
Kent Beck, 1997; Mike Cohn
The problem
Requirements arrive with no statement of what done means.
What you get
Independently deliverable stories, each with given/when/then criteria covering the happy path, the boundary and the failure.
Impact analysis
No single originator
The problem
Someone has described it as just a small change.
What you get
Everything it touches — process, roles, systems, interfaces, data, reporting, regulation, third parties — with confidence stated on each.
Benefits realisation
John Ward and Elizabeth Daniel
The problem
The project delivered. Nobody can show the benefits arrived.
What you get
Every claimed benefit with a measure, a baseline, a named owner and a review date — plus what happens if it has not landed by then.
—
The artefacts
Every stage above ends in something drawn. These are the
28 diagrams I draw them in — one visual language across a whole
engagement, rather than whatever the last deck happened to use.
Format Plain SVG, light and dark, no
dependencies. They render the same in a document, a deck, or a repository.
Architecture
C4 · component
Inside one container: the components, their responsibilities, and the call path.
Architecture
C4 · container
Deployable units inside the system boundary, and the data they own.
Architecture
C4 · system context
The system as one box, and every person and external system that touches it.
Architecture
Deployment topology
Network zones, what runs in each, and where the trust boundaries fall.
Architecture
Integration hub
A mediation layer between point-of-service systems and national infrastructure.
Architecture
Layered architecture
Horizontal bands with a strict downward dependency rule.
Process & flow
Data pipeline
Ingest to serving layer, with the observability tap drawn in.
Process & flow
Decision flow
A branching path with the condition named on every edge.
Process & flow
Linear process
Five sequential stages with the owner and exit condition of each.
Process & flow
Patient journey
Care stages above the line, system touchpoints below it.
Process & flow
Request lifecycle
One request end to end, with the latency budget written on each hop.
Process & flow
Swimlane process
Who does what, in order, when the work crosses three teams.
Roadmap & time
Milestone timeline
A dated spine with milestones alternating above and below.
Roadmap & time
Now / next / later
The honest roadmap: dated only where you can actually commit.
Roadmap & time
Phased rollout
Four phases, each with its scope, its exit criterion, and its rollback.
Roadmap & time
Quarterly roadmap
Three workstreams across four quarters, with dependencies shown as bars, not promises.
Decision & comparison
Build vs buy
Two columns, both steelmanned, with the deciding axis named at the bottom.
Decision & comparison
Option matrix
Options as columns, criteria as rows, scored before anyone argues.
Decision & comparison
Two-by-two
Plot the options on the two axes that actually decide it.
Decision & comparison
Weighted criteria
Weights set before scoring, so the answer is not reverse-engineered.
Metrics & data
Conversion funnel
Stage-by-stage drop-off with the leak called out.
Metrics & data
KPI row
Four numbers that matter, each with its movement and its source.
Metrics & data
Maturity ladder
Five levels, with today marked and the next rung named.
Metrics & data
Trend with callout
One series, one annotation, one conclusion.
Governance & risk
Control map
Controls grouped by objective, with the evidence that proves each one works.
Governance & risk
RACI matrix
Decision rights made explicit, one accountable name per row.
Governance & risk
Risk heat map
Likelihood against impact, with each risk owned by a named person.
Governance & risk
Trust boundaries
Where data crosses a trust boundary, and what is enforced at each crossing.
No templates in that category yet.
If any of that describes where you are
I work as a CTO, enterprise architect and digital health consultant —
usually where the architecture, the regulation and the organisational politics all have to
be solved at once.
These are standard techniques, not mine. Each is attributed to whoever originated it.
The skill is not knowing they exist — it is picking the right one, and knowing what it
will not tell you.
Cadle, J., Paul, D. and Turner, P. (2014) Business Analysis Techniques: 99
Essential Tools for Success, 2nd edn. Swindon: BCS Learning & Development.
Paul, D., Cadle, J. and Yeates, D. (eds) (2014) Business Analysis, 3rd edn.
Swindon: BCS.