Worked Initiative example: delayed building variations
Follow a full Discover, Frame, and Shape conversation between a Facilitator and a Domain Expert.
Worked Initiative example: delayed building variations
This made-up example shows how a Facilitator can take a request for a new app through Discover, Frame, and Shape, without assuming that software is the answer.
Open two browser tabs or profiles. Use one for the Facilitator cockpit and the other for the Domain Expert link. Send one question at a time. Submit the 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 request asks for an app, but an app is only one possible answer. First, find out what the real problem is.
Discover and Frame
1. Describe the problem
Select Problem statement and send:
What problem would a mobile app for approving variations solve?
Domain Expert answer:
Variation requests often wait for days before anyone deals with them. Site supervisors do not know who can approve them, and the office often gets requests without enough detail to price them. So either work stops while people wait, or work goes ahead before anyone agrees the cost.
2. Name the affected users
Select Affected users and send:
Who is affected when a variation is delayed or is missing information?
Domain Expert answer:
Site supervisors, estimators, construction managers, accounts staff, subcontractors, and the client. Supervisors and subcontractors feel the delay first. Accounts finds the cost problem later.
3. Make the pain concrete
Select Pain points and send:
What happens today, and how often does it cause problems?
Domain Expert answer:
Supervisors send variation details by email, text message, and photos. The details are often spread across several messages. We have about 15 active builds and usually get five to ten variation requests a week. About a third of them need someone to chase missing details. Some are still not resolved after five working days.
4. Define observable outcomes
Select Outcomes and send:
If the problem was solved, what would you see that is different?
Domain Expert answer:
Every variation would have one owner and a status that everyone can see. Complete requests would get to the right approver on the same working day. Supervisors would know if work should stop, continue, or wait for the client to approve.
5. Define success
Select Success criteria and send:
How would you know that the change worked?
Domain Expert answer:
At least 90 percent of complete variation requests get a decision within two working days. No variation work starts without a recorded approval, except under the written emergency rule. We can match approved variations to invoices without searching through emails.
6. Set non-goals
Select Non-goals and send:
What is not part of this Initiative?
Domain Expert answer:
We are not replacing the estimating, accounting, or scheduling systems, or the client contract process. We are not automating the decision about whether to accept a variation.
7. Record constraints
Select Constraints and send:
What limits must any change work within?
Domain Expert answer:
Supervisors mostly use phones, and phone reception on site is poor. We must keep the current accounting and estimating systems. We must keep the client's approval as evidence. We have little time for training, and we cannot bring in a complex process during the busy handover months.
8. Expose assumptions
Select Assumptions and send:
What are we assuming that we have not proved yet?
Domain Expert answer:
We assume that most delays happen because details are missing and because no one clearly owns the request. We also assume that supervisors will use a standard request process if it takes less than two minutes. We have not proved either of these.
9. Keep open questions visible
Select Open questions and send:
What do we still need to answer before we choose or design a change?
Domain Expert answer:
We need to confirm the approval limits, what evidence of client approval we need for legal reasons, whether we can connect to the estimating system through an API, and how often poor reception would stop a supervisor from sending a request straight away.
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 let badly priced work go ahead sooner. Supervisors might skip a process that is too slow. If we do nothing, the delays, invoice disputes, lost margin, 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 key details are missing, it is unclear who can approve them, and the supporting information is spread across different messages and systems. This can either stop work on site or lead to work being done before the cost and approval are properly recorded.
The problem statement must not say that the problem is a missing mobile app.
Shape a mixed response
Ask the Domain Expert:
What could we change to improve this? New software is only one option.
Add the interventions below. Each one has a description of the change and a rationale that says why it helps.
Process
Description: Use a standard checklist for every variation request. The checklist covers the scope, the reason, photos, the likely cost and time impact, the date a decision is needed, and who must approve it.
Rationale: Most of the chasing happens because requests arrive without enough detail to price or approve them.
People
Description: Give each active build a named variation coordinator. This person follows up incomplete requests and escalates delays.
Rationale: When one person owns each request, requests do not get stuck between the site and the office.
Policy
Description: Set approval limits. Do not let variation work start until the approval is recorded, unless the written emergency rule applies.
Rationale: Staff do not have a clear rule about who can approve work or when work can start.
Information
Description: Send a weekly report that shows how long each variation has been waiting, and if it is incomplete, waiting for a price, waiting for the client, approved, or rejected.
Rationale: Managers need to see the delays, and the causes that keep coming back, across all builds.
Technology
Description: Give everyone one shared variation register that works well on a phone. It records each request in the same format, with its status history, photos, evidence links, owner, and notifications.
Rationale: One shared record can replace the scattered emails and text messages. Build it only after the process and approval rules are clear.
Mark this intervention to continue to System Design.
Experiment
Description: Try the checklist, the coordinator role, the approval rules, and a simple shared register on two builds for four weeks.
Rationale: The trial tests the main assumptions before the business pays for a custom app.
No action
Record the option to keep using email and text messages, but do not select it. Note that it costs nothing to put in place, but the delays, missing evidence, unclear ownership, and lost margin will continue.
Check the Shape Gate and finalize
The Shape Gate should confirm that the technology intervention has a rationale and that you considered doing nothing. Only the technology intervention should continue to System Design. You can use https://www.modeller.website/playground as a safe example workspace link.
Finalize the Initiative. Check that the cockpit shows the archive period, and that the Facilitator link can open the archived record and reopen it.
What to observe
Write down any point where you ask yourself, "What do I do next?" Also check that:
- The Domain Expert sees a question only after the Facilitator sends it.
- Both views update without a page refresh.
- Accepted answers show under the selected structured fields.
- Gate labels and findings are easy to understand.
- You can still change earlier fields after Shape starts.
- The mix of interventions feels natural, not forced.
- Each description and rationale says something different.
- The System Design link carries enough context.
- Finalize, archive, reopen, and Copy link work as expected.
To test with a real case, replace the made-up facts with a real situation and record what the people involved actually say. This example is a guide only. It is not evidence from a real organization.