The Gold Standard Reference | Process Design and Readiness

Start with the change the work should produce for a named beneficiary. “Prepare learning packs” describes activity. “Each booked participant receives the correct usable pack before the session” describes an outcome that can guide design and review.

Name who benefits, what they need, when they need it and which conditions bound the promise. This prevents an internal task from becoming the goal. Printing quickly is valuable only insofar as it supports correct and timely learning materials.

Test the outcome from four positions: beneficiary, operator, reviewer and manager. The beneficiary asks whether the result is usable. The operator asks what must be done. The reviewer asks what can be verified. The manager asks whether the result can be sustained. A sound purpose survives all four questions.

Contents · Next chapter

Scope states what the process covers and where responsibility passes elsewhere. Include the starting event, ending event, people, locations, process version and important exclusions. An exclusion needs a reason and a route; it should not become a place where difficult work disappears.

For a workshop, the process might begin when a booking becomes confirmed and end when the session lead accepts the correct pack as ready. Content authorship may sit outside that process, while current-version control remains an input requirement.

Review the boundary when demand or technology changes. A process designed for scheduled sessions may not cover late additions. If the team accepts them anyway, the real scope has expanded even if the document has not.

Contents · Previous chapter · Next chapter

Acceptance criteria make the outcome testable. They should identify what must be true without prescribing unnecessary detail. Correct participant reference, current content version, complete required components and readiness before the session may be separate criteria.

Avoid words such as appropriate, timely and high quality unless the local meaning is defined. Two competent people should be able to examine the same case and understand the expected result.

Separate mandatory criteria from preferences. A preferred folder colour should not carry the same status as correct content. This keeps attention on the conditions that protect the beneficiary and supports proportionate response when a preference is missed.

Contents · Previous chapter · Next chapter

Map the sequence using real events: request received, information checked, work prepared, result verified, handoff accepted and outcome confirmed. Show decisions, queues, rework and information movement. A diagram that shows only ideal activity hides the places where failure accumulates.

Walk one normal, one difficult and one failed case through the map. The exceptions often reveal more about the process than the central line.

Contents · Previous chapter · Next chapter

A control should prevent, detect or limit a defined failure. Begin with the failure that matters, then place the control where it can change the outcome. A signature at the end adds little if the checker cannot distinguish the current template.

Prefer controls that make the correct state visible: one controlled source, clear identifiers, compatible inputs and an explicit acceptance step. Add verification where it can detect a material mismatch before the beneficiary is affected.

Record the control owner, method, evidence and response when it fails. Review the burden too. A control that requires continuous overtime may protect one outcome while weakening capacity and creating another failure.

Contents · Previous chapter · Next chapter

Processes depend on people, information, tools, time, space and upstream services. List the resources necessary for the promised outcome and the minimum usable condition for each.

Distinguish availability from readiness. A printer in the room is available; a printer with supplies, access and a usable current file is ready. A named substitute is available on paper; a substitute who has demonstrated the task and can access the system is ready.

Dependencies outside direct control still require management. Identify the supplier or upstream owner, expected input, acceptance check, communication route and fallback. Outsourcing an activity does not outsource the effect on the beneficiary.

Contents · Previous chapter · Next chapter

Readiness is a decision made before committing the process to delivery. It combines the criteria, competent people, resources, current information, capacity and controls needed for the stated scope.

Use a readiness record that supports judgement rather than ceremonial ticking. Each item should identify the evidence and the response if absent. The authorised person must be able to delay, narrow or redirect work when readiness is not established.

Readiness is time-bound. A morning decision may no longer apply after a system outage or demand surge. Define the changes that require reassessment.

Contents · Previous chapter · Next chapter

A process should state the conditions in which it is expected to work. Consider workload, input complexity, staff experience, timing, location and disruption. Do not infer resilience from a quiet pilot run by the designer.

Create routes for known variations. Late bookings, incomplete information and equipment failure need explicit decisions rather than improvisation disguised as normal work. The route may include refusal or rescheduling when the promise cannot be met safely.

Test the process at its boundaries. A controlled scenario can reveal whether staff can recognise and respond to a difficult condition. Record the conditions tested so the resulting claim stays within the evidence.

Contents · Previous chapter · Next chapter

An instruction should make the purpose, sequence, decision points and escalation route clear. It should identify the current version and the evidence created by the work. Screenshots and examples can help, but they need maintenance when the system changes.

Avoid documenting every gesture while leaving the important decision undefined. The operator needs to know what distinguishes an acceptable pack, what to do with a mismatch and who can resolve ambiguity.

Test the instruction with a competent person who did not write it. Observe where they require private explanation. That undocumented help identifies knowledge the process has not yet made dependable.

Contents · Previous chapter · Next chapter

A pilot tests the relationship between design, people, resources, controls and outcome. State the prediction, scope, conditions, observations and stop rules before beginning. Keep the beneficiary protected throughout the test.

Measure both intended results and balancing effects. A new version check may reduce incorrect pages while increasing preparation time. The team needs both observations to decide whether to adapt the method or capacity.

Treat assistance during the pilot as evidence. If the designer repeatedly rescues operators, the process has not demonstrated independent use. Record what support was required and revise the design before scaling.

Contents · Previous chapter · Next chapter

Release means the approved process becomes the current operating method for a defined scope. Confirm the owner, effective date, competent role holders, controlled documents, evidence route and initial review condition.

Withdraw superseded operational versions from ordinary use while preserving historical records. Communicate the change to people who perform, receive and review the work. Check understanding where the consequence warrants it.

A release can be phased. State which locations, cases or teams are included and what evidence permits expansion. A successful local pilot is not automatic authority for universal deployment.

Contents · Previous chapter · Next chapter

After release, compare actual outcomes with the promise. Examine exceptions, workload, missing evidence, difficult conditions and beneficiary experience. A process can be followed exactly and still be poorly designed.

Set redesign triggers: repeated failure, material change, dependency loss, unsustainable workload or evidence that the criteria no longer represent the intended outcome. Give the trigger an owner and decision route.

Do not patch indefinitely. Repeated workarounds may show that the main route no longer fits reality. At that point, return to purpose, scope and process design rather than adding another instruction at the edge.

Contents · Previous chapter · Next chapter

A fictional workshop has a documented packing checklist. The current template sits beside two older files, a substitute is scheduled without system access, and bookings exceed normal capacity by 40%. The manager argues that the checklist proves readiness.

Identify the process promise, readiness gaps and decisions required before release. Then draft a bounded readiness conclusion.

A worked response

The checklist describes part of controlled execution. It does not establish an identifiable current input, competent accessible staffing or adequate capacity. The team should reconcile the template source, provide qualified access or change the staffing plan, and decide whether the booking scope must narrow.

A defensible conclusion is: “Readiness is not established for the full scheduled scope. Release remains on hold until the current source, competent access and a sustainable capacity plan are confirmed. The owner may approve a smaller verified scope.” Each condition needs evidence and an authorised decision-maker.

Create a local readiness card with purpose, scope, criteria, inputs, people, capacity, controls, exceptions, decision owner and reassessment triggers. Test it against a normal day, a surge and a missing dependency.

Contents · Previous chapter · Continue through the reference program