Prepare: Get Ready Before Go-Live

1. What this stage is for

By the time a change reaches Prepare, the problem is diagnosed and the future work is defined. Prepare gets the organization ready to do that work. It covers people, managers, partners, technology, governance, knowledge and project conditions: a long list, which is why this is the stage with the most advice in the Database and the one most often squeezed when a date is fixed. #52 · #9

The cost of skipping preparation shows up later and larger. Training delivered after a system goes live competes with the backlog the system created. Security settled after a pilot has to unpick data already shared. A partner who learns the information requirements at the first model delivery reworks everything. A plant shutdown that starts with incomplete work packs spends its first days waiting for permits. In each case the work had to be done anyway; it was just done at the most expensive moment. #52 · #31 · TAR-PLN-02

A useful finish line for Prepare: on the first day of the change, nobody has to stop and ask for something that could have been arranged in advance. People have access, managers know their role, partners know the rules, the fallback is rehearsed and the knowledge that matters is written down. The rest of this brief takes those in turn.

2. People and managers

Put training ahead of the technology rollout, not after it, and time each module close to when people will first use it. Training delivered months early is forgotten by go-live; training delivered after go-live is delivered to people who are already behind. The best window is usually the few weeks before first use, with short refreshers spread over the weeks after. #52 · LSC-TRF-03 · #3

Prepare the people who will do the work before you hire around them. Upskilling existing staff is usually faster and cheaper than recruiting, and they already carry the organization's context. Build role-based paths rather than one programme for everyone: a site engineer, a design coordinator and a finance analyst need different things from the same rollout. Diagnose what each person already knows, and run separate tracks for newcomers and experienced people, because heavy guidance that helps novices actively gets in the way of experts. #5 · #25 · LSC-CLT-02

The single most neglected preparation is for managers. Supervisor support and the climate of the team are among the strongest predictors of whether training is used on the job. Give managers a short, specific role: what their people have practised, what to give them to do next, what to watch for and how to coach the new way of working. Then give them time for it. A manager told to support adoption while carrying a full load will, reasonably, prioritize the load. #53 · LSC-TRF-04 · PRM-LRN-04

Choose champions carefully, and expect modest gains. Across 35 health-care studies, champions went with better adoption in some organizations, but effects on practice and outcomes were mixed or unmeasured; neither volunteering nor appointing several is a proven formula. Pick people colleagues already trust, write down what they do, teach them to explain the reasoning behind a workflow rather than the clicks, give them protected, non-billable time, and judge them on errors and rework, not sessions held. Leadership commitment needs to be visible too: people watch what senior staff actually use, not what they announce. #8 · LSC-MNT-05 · #7

Two practical preparations are easy to forget:

• Budget the hours. In professional firms, every training hour has a billable opportunity cost. Plan non-billable time as a managed overhead line rather than pushing training into lunch hours and evenings, and design around billable constraints rather than pretending they don't exist. LSC-ORG-02 · #23
• Remove access barriers first. Before making a new skill mandatory, make sure everyone can reach the training: the right language, devices that work on site, captions for noisy environments and accessible formats. #40 · #24 · IDE-MM-07

3. Partners and contracts

Few changes in construction, engineering or manufacturing stay inside one organization. Subconsultants, subcontractors, software vendors and clients all have to be ready too, and their readiness varies. Assess partner digital maturity before relying on it, and write what you need from them into their appointments: the information standard, the delivery formats, the review cycles and the security rules. Requirements that live only in a kick-off presentation are optional in practice. #6 · BM-REQ-04 · NIST-SUP-02

Then test the methods during mobilization, before production. On a BIM project, that means a trial exchange of models and data between every party, checked against the agreed rules, in the first weeks. On a manufacturing change, it means a first-article run with the supplier's real parts. On a software rollout, it means a test integration with each connected system. Each test finds the problems while they are cheap. BM-REQ-05 · #56 · KIN-CAP-04

A few contract preparations pay for themselves many times over:

• Named, expiring accounts for every subcontractor and vendor, never shared logins, and all vendor remote access to building and plant systems brokered and logged. NIST-SUP-01 · NIST-OTX-01
• A notice register set up before the first deadline, because most disputes start with missed notices and document errors. Use the early-warning machinery the standard form gives you. VCM-ADM-01 · VCM-FRM-05 · VCM-ADM-02
• Supplier tiers by the consequence of their failure, with an approved list that has criteria and gets re-evaluated, rather than a list of firms someone once used. VCM-SUP-01 · VCM-SUP-02
• Insurance wording checked at renewal, including cyber and war exclusions, because coverage is decided long before the claim. DQ-UP-09 · CYBER-14

4. Technology and governance

Clear security and data governance before piloting, not after. Once a pilot has shared data with a new platform, unwinding it is slow and sometimes impossible. Decide which data may go into which tool, keep a record of what any AI is trained on and how long data is kept, and settle privacy duties before launch rather than after a complaint. #31 · DG-01 · PRM-SEC-01 · AIG-11

Prepare the technology for learning as well as for production. Use a safe sandbox before AI or any new system touches production work, so people can make mistakes where mistakes are free. Error-management training, in which learners are encouraged to make and learn from errors in a safe setting, improves transfer to new situations. #44 · LSC-TRF-05 · #12

The security basics are unglamorous and decisive. Phishing-resistant multi-factor authentication on all remote and privileged access. No standing administrator rights. Networks segmented, with plant and building controls separated from office IT. Default credentials replaced before handover. Every new AI agent given its own scoped identity, with "don't touch production" enforced as a permission rather than written in a prompt. CYBER-04 · NIST-PRT-01 · CYBER-08 · NIST-OTX-02 · AGT-01 · AGT-02

Governance has to be operating, not just written. A policy binder is not a control. Build governance as repeatable processes with named owners, check that controls actually run rather than that policies exist, and put a version and a date on every framework you cite. ITG-GOV-02 · AIG-16 · NIST-GOV-04

5. Knowledge

Every change depends on knowledge that sits in a few people's heads: how the old system handled the odd cases, why a procedure has that extra step, which supplier always ships late. Capture tacit knowledge before experts leave, and before the change makes their knowledge harder to reach. Facility management alone expects a large share of its workforce to retire within a decade, and the same pattern runs through trades, plants and engineering offices. #18 · FAM-WRK-01

Capture in the flow of work rather than in a separate documentation project. Ask the experienced technician to record how they actually do the isolation while they're doing it. Have the senior estimator talk through a real bid. Pair veterans with newer staff, so judgment moves one way and digital fluency the other. Mentoring is a retention lever as well as a learning one. KIN-CAP-02 · FAM-WRK-02 · LSC-MNT-02

Don't rebuild what already exists. Convert useful internal material into training and job aids rather than buying generic content, because people learn faster from their own organization's templates and standards. Buy generic tool basics where they exist, and keep firm-specific workflow and standards training in-house. #17 · #16 · LSC-SFT-03

Then make the knowledge findable. Publish one current version at the point of use, with a version stamp on anything printed or offline. Point any enterprise AI only at governed sources and make it cite them. Check knowledge readiness at project mobilization: does the team know where the lessons from the last similar project live, and has anyone read them? SOP-DIG-01 · SOP-DIG-03 · KIN-TWN-01 · KIN-CAP-04

6. Plan for failure

The part of preparation people most dislike is planning for the change going wrong. It is also the part that most often decides whether a bad day becomes a bad month. Start with a pre-mortem: before committing to the plan, imagine it has failed badly and ask everyone to write down why. The often-quoted claim that pre-mortems make forecasts "30% more accurate" overstates the original study, which found people generated about 30% more reasons for failure. That is still the point: more reasons, surfaced while they can still be acted on. CS-03 · PM-22

Then build and rehearse the way back:

• Rehearse the manual fallback for critical tasks that a new system or AI will support. If the system stops, can people still do the work, and have they practised it recently? #46 · CYBER-11 · HO-13
• Keep recovery independent of the system that can fail. A recovery plan that needs the failed system's own console, network or vendor login is not a recovery plan. DQ-UP-08 · CYBER-09
• Test full restores, not just backup jobs. A backup nobody has restored is a hope. CYBER-10
• Write when to abandon the plan. Every standing plan rests on assumptions. Write down the conditions under which it no longer holds and who can switch, and rehearse the switch. DQ-RT-03 · HX-08
• Agree the error budget in advance. For software and digital services, decide before launch how much unreliability is acceptable and what happens when it's used up. SWD-SLO-02 · SWD-INC-02

Exercise the plans with the people who will run them. Tabletop exercises build shared understanding and confidence; technical drills test whether things actually work. Add unscripted events: a satisfying exercise is not the same as readiness, and real incidents rarely follow the script. Pre-brief people before stressful simulations, and give them a way out. CYBER-13 · GL-16 · CS-05 · CS-09

7. By team: what preparation looks like

The six preparation areas apply everywhere, but each kind of team meets them differently. A few examples show where the effort usually goes. #63 · #13

Technology and IT teams

For a new platform, preparation is mostly invisible plumbing: identity, access, integrations, data rules and support. Give every account a named owner and the minimum rights it needs, connect the new system to the identity provider before anyone logs in, and agree how learning and usage data will be handled before collecting any. If the platform uses AI features, keep a register of what each one does and who checks it. Plan the help-desk load for the first month, which is usually far higher than anyone budgets. NIST-PRT-01 · IDE-DAT-01 · IDE-DAT-04 · #51

Project and construction teams

On a project, preparation is mobilization. Build learning and the new practices into the project plan from the first week, confirm the information requirements and execution plan with every party, test the exchange methods before production, and set up the notice register, the constraint log and the lookahead before the first deadline arrives. Set up short-interval planning with a dedicated facilitator, because pull planning that depends on volunteers rarely survives the first schedule crisis. #56 · BM-REQ-05 · VCM-ADM-01 · CM-LEAN-01 · CM-LEAN-04

Plants and operations

In a plant, preparation means operators who were involved in the design, procedures validated against the way the work is actually done, and the start-up planned from the start of the project rather than in its final weeks. Co-design new systems with operators and make them explain themselves; a screen operators don't trust becomes a screen they work around. Resource commissioning and start-up as their own team, early, and track long-lead materials on the critical path. DM-WRK-02 · PRM-MFG-03 · TAR-SU-01 · TAR-SU-03 · TAR-PLN-03

Safety and emergency teams

For safety, preparation is mostly about the plans for bad days: exercised with every agency that would respond, with communications that don't depend on public mobile networks, and with the decision to evacuate or shut down assigned in advance. Keep emergency plans current and exercised rather than filed, and design out hazards at the design stage where you can, because a hazard removed on drawings never needs a procedure on site. SEM-12 · SEM-10 · HX-03 · CM-SAF-03

Finance and business teams

In finance, preparation means knowing who owns each number, training everyone who will operate a control before they operate it, and keeping a backup for every critical role. When a new system arrives, the controls built into the old one need to be rebuilt and re-tested, not assumed. FIN-ORG-02 · FIN-TAL-02 · FIN-TAL-07 · FIN-TEC-04

Common mistakes

• Training too early. A course delivered three months before go-live is mostly forgotten by the day it's needed. LSC-TRF-03
• A plan without a rehearsal. The fallback that was written but never practised fails the first time it's needed. #46 · CS-05
• Champions without time. A name on a slide is not a support network. LSC-MNT-05
• Governance on paper. A policy that nobody operates gives false comfort. AIG-16 · ITG-GOV-02

8. The readiness check

Prepare ends with a readiness gate. Hold it against measurable criteria agreed in advance, and confirm readiness with a behavioural test wherever the stakes justify it: a pilot, a dress rehearsal, a parallel run or a commissioning test of every system before the public or the plant depends on it. Status reports say what people believe; tests show what is true. SEM-30 · DGN-RDY-03 · SEM-11

Start small where you can. Piloting on one live project before scaling, and starting with one bounded workflow with human review, consistently beats a big-bang launch. Pilots surface the integration problems, training gaps and workload effects that no plan predicts, while the cost of finding them is still low. #1 · #12 · OC-14

Read schedule pressure as a warning sign rather than a reason to skip the gate. Pressure to go live on a fixed date is when preparation gets cut, and on construction sites schedule pressure is itself a known safety signal. If the gate fails, the honest options are to fix and re-test, to narrow the scope, or to delay. Going live anyway is a decision, and it should be recorded as one, with its owner. CM-SAF-06 · DGN-BIAS-04 · OGV-GATE-01

For small organizations, the same discipline fits on one page: a list of the six areas, a name against each, a red, amber or green rating with one line of evidence, and a short rehearsal of the riskiest step before the real thing. That page, honestly filled in, is worth more than a thick plan nobody tests. ITG-GOV-05 · #1

The checklist. Train ahead of the rollout, close to first use. Give managers a coaching role and time. Pick volunteer champions with protected hours. Put requirements in partner contracts and test methods at mobilization. Clear security and data governance before the pilot. Open a sandbox. Capture what the experts know. Run a pre-mortem; rehearse the fallback and the restore. Pass a behavioural readiness test. Then go to Learn.