Architecture Sprint
Ten business days to understand where the operating model is breaking and determine what, if anything, should be implemented.
We trace how work, decisions and information move across the functions involved, then write down the operating architecture that the operation actually needs. The result is a decision you can act on, with the reasoning visible.
What triggers a sprint
Not a planning cycle. A specific constraint that someone in the operation can already name.
- Experienced people spend their day carrying context between teams and systems.
- A decision changes and it takes weeks for the whole operation to act on it.
- Two functions report different numbers for the same thing, and both are right.
- Work gets stuck at handoffs that nobody owns.
- You are about to buy or build software and cannot state what problem it solves.
What happens in ten business days
Four blocks. Nothing is written up at the end that was not traced during the work.
- Days 1–2
Evidence intake
We read what the operation already produces instead of asking it to describe itself from memory.
- Days 3–5
Trace the real flow
Interviews with the people who actually carry the work across functions, following single units of work end to end.
- Days 6–8
Write the architecture
Lifecycle states and gates, decision rights, system-of-record boundaries, change propagation, handoffs and exceptions.
- Days 9–10
Decide
Prioritized roadmap, the exit we recommend, and an executive readout where the decision is made.
Who typically takes part
Six to ten people, a few hours each. We work around the operation, not instead of it.
- An executive sponsor who can change how the operation is run, not only what it buys
- The function leads on either side of the handoffs that are failing
- The people who are currently the integration layer, by name
- Whoever owns each system of record, including the ERP
- Finance or project controls, when the numbers disagree between functions
What evidence we examine
Documents and system state, not a questionnaire. We look at what the operation produced when nobody was watching.
- Lifecycle artifacts for real units of work: orders, projects, change notices, service jobs
- The chain of a decision that changed, and when each function started acting on it
- The same figure as reported by two different functions, and why they differ
- Where data is re-entered by hand between systems
- Exception paths: what people do when the normal flow does not apply
- The meetings and reports the operation currently relies on to stay aligned
What you get
Current-state operating architecture
How the operation runs today, including the parts that only exist in people's heads.
Lifecycle state and gate model
The states a unit of work moves through, and what must be true to leave each one.
Decision rights map
Who decides what, with which information, and who must be told.
System-of-record boundaries
Which system owns which fact, so two systems stop disagreeing about the same reality.
Change propagation map
What happens to the rest of the operation when a decision changes.
Handoff and exception architecture
Where work changes hands, and what happens when the normal path does not apply.
Management cadence and metrics
The meetings and numbers that keep the operating model honest.
Prioritized implementation roadmap
What to do first, what to defer, and what not to do.
Executive decision readout
A session where the decision gets made, not a document that gets filed.
Decisions that come out
- Who owns each lifecycle state, and what must be true to leave it
- Which system is the record for each fact, and which ones only read it
- How a change propagates, and what has to happen automatically
- Which handoffs need an explicit contract and which should disappear
- What to implement, in what order, and what not to implement
How a sprint can end
The output is not automatically a software proposal. Four honest exits:
- A
No build required
The existing systems and processes are sufficient. The problem is elsewhere, and we say so.
- B
Operating model changes
Governance, process or state ownership needs to change. No new software.
- C
Implementation required
There is a justified configuration, integration or control-layer implementation.
- D
Operations OS
The architecture requires a larger operational control layer.
Architecture before implementation. Operations OS.
What it is not
- Not a software demo.
- Not a licence sale with a discovery phase attached.
- Not a report that assumes the answer is technology.