Define: Say What "Done" Looks Like

1. What this stage is for

Diagnose ends with a clear account of the problem and its causes. Define answers the next question: what will the work look like when the problem is solved? That means the future workflow, the roles in it, who has the authority to make which decisions, what information each step needs and where it lives, and the conditions under which everyone will agree the change has succeeded. #63 · #62

Define is where most projects quietly lose. Research on project success keeps finding that the causes people cite most often are scope creep, overload and unclear goals, not technology or budget, and that relational factors such as shared understanding between sponsor and team outrank technical ones. Those are all failures of definition. When nobody wrote down what success looked like, every stakeholder carries their own version, and the project spends its life negotiating between them. PM-13 · PM-8 · PM-19

The stage has a simple test. By the end of it, could a new team member, a partner firm or an auditor read one short document and understand what is changing, who decides what, and how the result will be judged? If not, the definition isn't finished. In a small organization that document might be two pages. On a capital project it may be a set of contract schedules and an execution plan. The questions are the same. PM-12 · #14

2. Define the work, not the tool

The most common definition error is to describe the technology instead of the work. "Implement the new common data environment" is a purchase, not a definition. "Every model and drawing is shared, reviewed and published through one platform, with the reviewer's approval recorded before anything reaches site" is a workflow. The difference matters because adoption is a socio-technical change: roles, incentives, procedures, information and skills all move together, and a definition that only names the tool leaves all of them unplanned. #63 · ITG-CHG-01

Write the future workflow as a sequence of real tasks. For each step, say who does it, what they need, what they produce and who receives it. Pay special attention to the hand-offs between people, teams and tools, because that's where most information is lost. If the change spans several applications, define the workflow across them rather than one product at a time; people work in workflows, not in products. #20 · CM-DIG-01

Where AI is part of the change, define the human-AI hand-off before anyone is trained on the tool. Which steps does the AI draft, which does a person check, and which remain entirely human? Who owns each AI output? Before any of that, decide whether AI should do the task at all, and map where it is reliable and where it isn't, because capability is uneven even within one job. #35 · AIG-01 · PRM-BIZ-05 · PRM-EVD-07

Two cautions help keep definitions honest:

• Simplify before you digitize. If the current process has unnecessary steps, writing them into new software makes them permanent. Lean manufacturing teams learned this the hard way: simplify the value stream first, then let the principles set the software, not the software's defaults. DM-SUS-05 · DM-SUS-04
• Say exactly what you mean by the fashionable term. "Digital twin", "AI agent" and "platform" mean different things to different people. Write down which you mean: a static model, a model fed by live data, or one that writes decisions back. Then scope it to the decision it supports. DM-TWN-01 · DM-TWN-02 · CM-DIG-04

Match the size of the definition to the shape of the change. A small procedural change needs a short definition; a change that alters how several departments work together needs a fuller one, and possibly a named framework for handling complexity. Hybrid approaches, mixing planned and iterative work, are a legitimate end state rather than a compromise, as long as the definition says which parts are fixed and which will be learned as you go. PM-11 · PM-20 · PM-19

3. Decision rights

The second most important box on the canvas is decision rights. Write down who recommends, who decides and who must be consulted for every significant decision the change will create: approving a model for construction, releasing a hold point, stopping work, changing a procedure, accepting a system at handover, pausing an AI tool. Investigations of serious failures keep finding the same gap. At Grenfell Tower, the architect, contractor and cladding subcontractor each assumed someone else was responsible for fire safety. Nobody had written it down. DQ-UP-07 · ITG-GOV-01

Then line the contracts up with the decision rights. A responsibility chart that contradicts the contract will lose every argument. Make sure the contract says who can stop work, change the design and approve temporary works, and remember that delivery models change who can act: oversight gaps tend to follow the contract. Under each standard form, know who administers the contract and who is responsible for what. DQ-UP-10 · VCM-FRM-02 · CM-DEL-01

Two refinements make decision rights work under pressure. First, sort decisions by whether they can be undone. Reversible decisions can be delegated and made quickly; irreversible ones, such as pouring concrete, signing a lump sum, publishing a model or deleting data, deserve options, independent review and kill criteria. Second, pre-assign crisis decisions before the crisis: who can shut down a system during a cyber incident, who orders an evacuation, who pauses an AI tool today. Decisions that have to be negotiated in the moment are usually made late. DQ-UP-01 · CYBER-01 · AIG-14 · HX-03

On projects with several firms, decision rights need agreement across organizational boundaries. Align partners on digital goals, roles and success conditions at the start, and bring public agencies in early where they have a role, agreeing who commands when. #62 · SEM-13 · BM-REQ-01

4. Information

Every step of the future workflow consumes information and produces it. Define what each step needs, where it comes from, who owns it and what form it takes. In construction and asset management, this discipline has a formal shape: requirements cascade from the organization (what the business needs to know about its assets) to each project and then to each exchange between parties. Defining them in that order keeps a model full of what the owner will actually use, rather than whatever the authoring tool produced by default. BM-REQ-01 · FAM-SYS-01 · FAM-DAT-01

Specify information by need, not by a generic detail level. "Level of development 400" says little about what the facility manager needs for a pump; a level-of-information-need table that lists the properties, documents and geometry each object requires says a great deal. Set the project information standard and production methods before tender, so bidders price what you'll actually ask for. BM-REQ-07 · BM-REQ-06 · BM-USE-01

Outside construction, the same principles apply in different words:

• One authoritative source. Separate authoritative knowledge, such as current procedures and approved standards, from everything else. Keep one owned, current version for people and AI tools to read. KIN-GOV-02 · PRM-CTX-03 · SOP-DIG-01
• Govern data before the pilot. Decide classification, retention and who may use which data before anything is connected, not after an incident. No deletion rule, no launch. DG-01 · DG-04 · CYBER-28
• Name the data for the work. In plants, put the equipment hierarchy into data names so a reading means something without a lookup table. DM-IOT-04 · DM-ARC-01
• Personal data needs a purpose. If the change collects information about people, decide the lawful basis and what you'll tell them before collecting anything. GDPR-05 · GDPR-04 · #48

Finally, define how the documentation fits together. A clear hierarchy, with policies, procedures, work instructions and records each in their own lane, prevents the common failure where a project plan quietly overrides an enterprise procedure or a checklist contradicts the method statement it was meant to support. SOP-SYS-02 · SOP-SYS-05 · SOP-SYS-03

5. Success conditions

Define success and capture a baseline before launch. Projects that set success criteria and a measurement baseline before work starts are more likely to succeed, and those that don't can only ever report activity: courses delivered, licences issued, logins recorded. Write success conditions as measurable outcomes with an owner, not as intentions. "Improve coordination" isn't a condition; "design-attributable RFIs on the next two projects fall by a third from this year's baseline, owned by the design manager" is. #14 · PM-12 · OGV-BIZ-02

Set conditions at more than one level, because each level answers a different question and each moves on a different timescale. Plan the evaluation now, including where the data will come from, rather than bolting it on after launch. IDE-DES-07 · #10 · IDE-EV-01

Be honest about uncertainty in the numbers. Forecast cost and schedule from a reference class, meaning what similar projects actually cost and took, and then adjust for what's different about yours. Show the business case at the confidence it really has, as a range, and uplift early estimates for the optimism that early estimates reliably contain. A single confident number at the definition stage is usually the best case in disguise. CM-RSK-02 · PM-17 · OGV-BIZ-03 · OGV-BIZ-01

Expect a dip. Many changes make people slower before they make them faster, and industrial AI tends to follow a J-curve in which costs come first and gains later. Write the expected dip into the success conditions so that week six doesn't look like failure. #11 · DM-AIM-01

6. Gates, scope and stop rules

A definition needs a way to say no. Define each gate's deliverables and criteria in advance, before anyone sees the pitch, and make "recycle" and "stop" real options alongside "go". Gates that can only open aren't gates. Separate the people who decide from the people who advocate, and commission independent assurance at the points where mistakes become expensive. OGV-GATE-02 · OGV-GATE-01 · OGV-GATE-03

Agree stop rules when the project is approved: the cost, date or benefit conditions under which it comes back for a decision. Stop rules agreed in advance are far easier to honour than ones invented when the money is half spent, because sunk costs and personal commitment drive people to keep going. Generic warnings about escalation don't help; specific decision rules do. OGV-ESC-02 · PM-5 · OGV-ESC-01

Then control scope. Freeze it at a defined point and govern every late addition against criteria, and put work into a constrained window, such as a plant shutdown, only if it genuinely needs that window. Standardize the highest-consequence processes first rather than everything at once; a short list of procedures that are actually followed beats a long list that isn't. TAR-SCP-01 · TAR-SCP-02 · SOP-SYS-06 · SOP-DES-07

Keep governance proportionate. A thirty-person firm doesn't need a portfolio board; it needs one person who owns the decision and a written note of what was agreed. A large owner may need formal gates and independent review. Over-governing a small change is as wasteful as under-governing a large one. ITG-GOV-05 · OGV-ASR-02 · QMS-ARC-03

A worked example

Take a 300-person mechanical and electrical contractor whose diagnosis found that design-attributable RFIs had doubled in two years. The causes were mixed: a new subconsultant working to a different modelling standard, a coordination meeting that no decision-maker attended, and junior coordinators who had never been shown how to group clashes. Training was part of the answer, but only one part. DGN-FRM-02 · BM-COO-04

The definition that followed filled the canvas like this. Outcome: design-attributable RFIs back to the level of two years ago, about eleven a month, within three projects. Future workflow: each discipline checks its model against the agreed rules before sharing; federation runs weekly; clashes are reported as clusters with an owner and a date; decisions are made in the meeting, not after it. Decision rights: the design lead decides when a model is published; the information manager can refuse a delivery that fails the checks; the project director decides disputes between disciplines. Information: one modelling standard written into every appointment, including the subconsultant's, with a level-of-information-need table for the objects that matter most to the installers. BM-QA-02 · BM-COO-02 · BM-COO-03 · BM-REQ-07

Success conditions were set at three levels: coordinators running the clash process unaided by day 60; nine in ten deliveries passing the automated checks first time by month four; RFIs at target by the third project. Gates and stop rules: if deliveries were still failing checks at month three, the subconsultant's appointment would be reviewed rather than the training repeated. Nothing in the definition said "buy software" or "run a course", though both happened later. Because the work was defined first, each purchase had a job to do and a way to tell whether it had done it. BM-COO-05 · OGV-ESC-02 · #10

Common mistakes to look for when you review a definition like this:

• A goal with no baseline. "Fewer RFIs" can't be judged without last year's number. #14
• A role with no time. Naming a champion or an information manager who still carries a full billable load defines a vacancy, not a role. LSC-MNT-05 · BM-ROL-02
• A requirement nobody will resource or monitor. Don't write one; it teaches everyone that requirements are optional. SOP-GOV-12
• Titles instead of functions. "BIM manager" means different things in different firms; define the function the person performs. BM-ROL-01 · BM-ROL-03
• A statistic nobody can source. If the business case leans on a figure such as "70% of change fails", find its origin or drop it. CM-EVD-01 · DM-EVD-01

7. Handing it on

Define hands Prepare a short, specific document: the canvas in Figure 1, filled in. It should be readable in ten minutes and checkable by someone who wasn't in the room. Before you hand it on, test it against four questions:

• Does the outcome match the gap the diagnosis found, and does it carry the same baseline? DGN-FRM-01 · #14
• Is every significant decision assigned to exactly one decider, and does the contract agree? DQ-UP-07 · DQ-UP-10
• Can each success condition be measured with data you'll actually have, by a date, with an owner? OGV-BIZ-02 · IDE-EV-11
• Would the gate criteria and stop rules ever actually stop anything? OGV-GATE-01 · OGV-ESC-02

Explain the change in the terms of the people who will live with it. A definition written for the steering committee rarely persuades a site crew or a finance team. Anchor it to the mandates and standards people already recognize, and say what's in it for them in their own words; relevance in the learner's terms is one of the cheapest ways to win early commitment. #26 · #27 · KIN-GOV-01

The checklist. Fill all six boxes. Describe the work, not the tool. Define the human-AI hand-off. Give every decision one decider, and let anyone stop work. Line the contract up. Cascade information requirements from the organization down. Set success conditions at five levels, with a baseline and an owner. Forecast from a reference class, as a range. Define gates that can say no, and stop rules before you start. Then hand on to Prepare.