Worked Initiative example: delayed building variations
Follow a complete Discover, Frame, and Shape conversation with a Facilitator and Domain Expert.
Worked Initiative example: delayed building variations
This realistic, fictional scenario shows how a Facilitator can take a requested application through Discover, Frame, and Shape without assuming that software is the answer.
Use two browser tabs or profiles. Keep the Facilitator cockpit open in one and the Domain Expert link open in the other. Send one question at a time, submit the given answer as the Domain Expert, then accept it as the Facilitator.
People and original request
- Facilitator: Priya Morgan
- Domain Expert: Daniel Reed, Residential Construction Manager
- Original change request: "Build a mobile app so site supervisors can approve client variations faster."
The requested app is a proposed answer. The session must first discover the underlying problem.
Discover and Frame
1. Describe the problem
Select Problem statement and send:
What problem would a mobile variation approval app solve?
Domain Expert answer:
Variation requests often sit unresolved for several days. Site supervisors do not know who can approve them, and office staff frequently receive requests without enough information to price them. Work either stops while people wait, or continues before the cost is agreed.
2. Name the affected users
Select Affected users and send:
Who is affected when a variation is delayed or incomplete?
Domain Expert answer:
Site supervisors, estimators, construction managers, accounts staff, subcontractors, and the client are affected. Supervisors and subcontractors feel the delay first. Accounts discovers the financial problem later.
3. Make the pain concrete
Select Pain points and send:
What happens today, and how often does it cause a problem?
Domain Expert answer:
Supervisors send variation details through email, text messages, and photographs. Important information is often split across several messages. We have about 15 active builds and usually five to ten variation requests each week. About a third require somebody to chase missing information. Some remain unresolved for more than five working days.
4. Define observable outcomes
Select Outcomes and send:
What would be observably different if the problem were solved?
Domain Expert answer:
Every variation would have one visible owner and status. Complete requests would reach the correct approver on the same working day. Supervisors could see whether work should stop, continue, or wait for client approval.
5. Define success
Select Success criteria and send:
How would you decide whether the change was successful?
Domain Expert answer:
At least 90 percent of complete variation requests should reach a decision within two working days. No variation work should begin without recorded authority, except under the documented emergency rule. The business should be able to reconcile approved variations against invoices without searching through emails.
6. Set non-goals
Select Non-goals and send:
What is explicitly outside the scope of this Initiative?
Domain Expert answer:
We are not replacing the estimating system, accounting system, construction scheduling system, or client contract process. We are not automating the commercial decision about whether a variation should be accepted.
7. Record constraints
Select Constraints and send:
What constraints must any intervention respect?
Domain Expert answer:
Supervisors mainly use phones on sites with unreliable reception. The existing accounting and estimating systems must remain. Client approval must be retained as evidence. We have limited capacity for training and cannot introduce a complex process during peak handover months.
8. Expose assumptions
Select Assumptions and send:
What are we assuming but have not yet proved?
Domain Expert answer:
We assume delays are mainly caused by missing information and unclear ownership. We also assume supervisors will use a standard request process if it takes less than two minutes. We have not proved either assumption.
9. Keep open questions visible
Select Open questions and send:
What still needs an answer before selecting or designing a change?
Domain Expert answer:
We need to confirm approval limits, the legal evidence required for client approval, whether the estimating system has an integration API, and how often poor site reception would prevent immediate submission.
10. Record risks
Select Risks and send:
What could go wrong if we change this process, or if we do nothing?
Domain Expert answer:
A faster process could allow poorly priced work to proceed more quickly. Supervisors might bypass a process that is too slow. If we do nothing, delays, disputed invoices, margin loss, and unapproved work will continue.
Check the Discovery Gate
Evaluate the Discovery Gate. The accepted answers should support all twelve checks. If a check remains flagged, inspect the structured fields before you override it. A useful final problem statement is:
Variation requests are delayed because required information is incomplete, approval ownership is unclear, and evidence is distributed across several communication channels. This stops site work or allows work to proceed before cost and authority are recorded.
The problem statement must not say that the problem is a missing mobile app.
Shape a mixed response
Ask the Domain Expert:
What changes could improve this situation without assuming that new software is the only answer?
Add the following interventions.
Process
Description: Introduce a standard variation intake checklist containing scope, reason, photographs, estimated effect, required decision date, and responsible approver.
Rationale: Most rework starts because requests arrive without enough information to price or approve them.
People
Description: Give each active build a named variation coordinator who owns incomplete requests and escalations.
Rationale: A clear owner prevents requests from waiting between the site and office teams.
Policy
Description: Define approval limits and prohibit variation work from starting without recorded authority, except through a documented emergency exception.
Rationale: Staff do not have a consistent rule for who can authorize work or when work can proceed.
Information
Description: Produce a weekly variation-ageing report showing incomplete, awaiting-price, awaiting-client, approved, and rejected requests.
Rationale: Managers need to see delays and recurring causes across all active builds.
Technology
Description: Provide a mobile-friendly shared variation register with structured submission, status history, photographs, evidence links, ownership, and notifications.
Rationale: A shared record can replace fragmented email and text-message trails after the process and authority rules are clear.
Mark this intervention as continuing to System Design.
Experiment
Description: Trial the checklist, coordinator role, approval policy, and a simple shared register on two builds for four weeks.
Rationale: The trial tests the key assumptions before the business commits to a bespoke application.
No action
Consider, but do not select, continuing to use email and text messages. Record that this has no implementation cost but leaves the delay, evidence, ownership, and margin problems unchanged.
Check the Shape Gate and finalize
The Shape Gate should confirm that the technology intervention has a rationale
and that no action was considered. Only the technology intervention should
continue to System Design. You can use
https://www.modeller.website/playground as a harmless example workspace link.
Finalize the Initiative. Confirm that the cockpit shows its archive period and that the Facilitator link can return to the archived record and reopen it.
What to observe
Write down any point where you ask, "What should I do next?" Also check whether:
- Questions appear to the Domain Expert only after the Facilitator sends them.
- Both views update without a manual refresh.
- Accepted answers appear under the selected structured fields.
- Gate labels and findings are understandable.
- Earlier fields can be revised after Shape starts.
- Mixed interventions feel natural rather than forced.
- Intervention descriptions and rationales feel distinct.
- The System Design link carries enough context.
- Finalization, archive, reopen, and Copy link controls behave as expected.
For a live validation, replace the fictional facts with a real situation and record what the people involved actually say. This example is a guide, not evidence from a real organization.