Chapter 05
Using the workflow library
Apply workflow packs, evidence, steps, and cost-model assumptions to a project conversation.
01
What this lesson is about
The workflow library is the public, browseable expression of the discipline this course is teaching. It groups workflows into packs by the construction problem they address: progress verification, claims evidence, safety monitoring, gate and logistics, stakeholder reporting, subcontractor performance, compliance, design verification. By the end of this lesson you should be able to walk a project team through the library, identify which packs apply, read a single workflow page critically, and translate the page into a recommendation for the next OAC meeting. The library is not a catalogue of features. It is a structured way of asking which closed loops the project actually needs, and which ones can wait until next quarter.
02
How packs and workflows are organised
A workflow pack is a thematic grouping. Inside it sit individual workflows, each with the same anatomy: trigger, evidence, activity, decision, action, closeout, owner role, frequency, current fulfilment role, replacement-or-supporting status, and whether a cost model exists. The structure is deliberately repetitive so that comparison across workflows is fast. A project director scanning the claims-evidence pack on a Tuesday afternoon should be able to read four workflows in twenty minutes and know which two apply to the contract she is on. That speed is the point. The library is not exhaustive; it is selective, and the selection is informed by what mature construction organisations have actually built rather than what is theoretically possible.
03
Reading a single workflow page critically
Start with the trigger and the conclusion. If those two do not match the construction reality on your project, the rest of the page is academic. Then read the evidence list and ask whether your project produces those records today, in what grade, and at what retention. Then read the steps and ask which role currently does each step on your project, even if informally. Then read the cost model assumptions, if any, and replace the defaults with project-specific numbers in your head. Finally read the replacement-or-supporting note, which tells you whether this workflow eliminates an existing job or supports it. The discipline is to leave the page with three notes: which evidence the project lacks, which step is currently informal and risks decay, and whether the workflow is a buy-or-build decision in your context. Twenty minutes of this reading prevents months of buying the wrong thing.
04
Translating the library into a project conversation
A project conversation that uses the library well looks like this. The project director picks two or three packs that match the contract and the phase. She walks the team through one workflow per pack on the screen, asking who currently owns the equivalent activity and where the evidence currently lives. She marks the workflows where the project already has informal practice and the ones that are entirely new. She picks one workflow per pack to formalise this quarter and one per pack to leave for next. She writes the closeout record location for the chosen workflows on the same page. The meeting ends with three or four named owners and a calendar. That is the library doing its job. The opposite of this is a vendor demo where the team admires the platform and leaves without choosing anything.
Practice
01. Pick two workflow packs that match your current project. For each, choose one workflow and write a single sentence on whether it would replace existing work or support it.
Look for: A strong response correctly identifies replacement workflows as easier to defend in ROI and supporting workflows as worth running for capacity rather than savings.
02. Read one workflow page in the claims-evidence pack and write three project-specific notes: missing evidence, informal step, buy-or-build decision.
Look for: A strong response leaves the page with concrete next actions rather than a generic agreement that the workflow looks useful.
Checkpoint
What makes a workflow suitable for an ROI calculation rather than a qualitative benefit?
Recommended reading