How to map a construction project workflow
How to map a construction project workflow: follow a change from RFI to change order to progress payment, show who holds each step, and where time and money stall. Live change order example.
A construction project workflow is a handful of linked loops, not one line: questions become changes, changes become priced orders, and approved orders become payment. Map each loop on its own, then show where they hand off.
The short version
- Map the project as linked loops (RFI, change, payment, time), not as one line from design to handover.
- Use one swimlane per party so every cross-party handoff is visible and can be timed.
- Start the change loop with the question 'is this really a change?' before any pricing happens.
- Draw the query loop, the unpriced directive route and the rejection path, not just the approved route.
- Your contract decides notice periods and names; edit the template to match it rather than the reverse.
One project, several small processes
Ask someone on a construction project to draw the workflow and you usually get a single line from design to handover. That line hides the part that actually consumes project time: a set of small, repeating processes that run in parallel and feed one another. A question on site becomes a request for information. The answer changes the scope. The changed scope needs a price, an approval and an amendment. The approved amount then has to reach the next payment application. Each of these is a process in its own right, with its own owners, and each hands its output to the next.
Mapping the project well means mapping those loops separately and then showing the joins. In practice the useful sequence is RFI, then change order, then progress payment, with an extension of time claim running alongside whenever a change or delay affects the programme. Each one crosses the same parties (contractor, subcontractors, designer or engineer, owner or owner's representative), which makes swimlanes the natural format: one lane per party, so every crossing is visible as a handoff you can time and assign.
The example below is the change order process, the middle link of the chain. It starts with a decision most people skip (is this actually a change to the contract scope?), runs through notice, quotes and pricing, loops back when pricing is queried, and ends with three possible outcomes at approval. A note on honesty: contract forms differ, and the notice periods, names for documents and approval thresholds in your contract will not match any template exactly. Treat the chart as a structure to edit against your own contract, not as a statement of what any form requires.
From change event to closed change order
A construction change order from site event to closed log entry. Follow what each party holds at each step.
Is it a change at all?
A change event is spotted on site or in the design and the first decision is whether it falls outside the contract scope. If it does not, work proceeds under the existing contract and the position is recorded. Drawing this as a decision stops pricing effort being spent on things that were already included.
Notice, quotes and pricing
Written notice goes out within the period the contract sets, a request for proposal follows with revised drawings or an instruction, subcontractors quote the affected trades, and the contractor prices labour, materials, markup and time impact. Missing the notice step is a common way for a valid claim to weaken, so it is drawn as its own step with an owner.
Review and the query loop
The reviewer checks pricing against design intent and contract rates, then asks whether it is substantiated. A query sends the proposal back to pricing. This loop is where change orders spend most of their elapsed time, and it is invisible on a chart that only shows the approved route.
Approval with three outcomes
After a budget and funding check, the owner approves, rejects, or cannot agree a price. Approval leads to a signed change order. Disagreement on price routes through an unpriced change directive so work can proceed while cost and time are tracked daily, and then rejoins at signing. Rejection ends in withdrawal or dispute resolution.
Doing the work and getting paid
With the order signed the subcontract is amended, the changed work is performed with actual cost and time recorded, the approved amount is added to the schedule of values for payment, and the change is closed in the log with budget and forecast updated. This last handoff is where the change loop joins the progress payment loop.
How it works
List the loops before drawing anything
Write down the repeating processes on your project: requests for information, submittals, change orders, progress payments, inspections, punch list, time claims. Decide which ones you are mapping now. A project workflow is the set of these, so start with the one that hurts most rather than trying to draw all of them on one page.
Set up one lane per party
Create lanes for the contractor, subcontractors, designer or engineer, owner or owner's representative, and any authority that holds an approval. In QueryChart this is the swimlane assignment on each step. Put every step in the lane of the party that performs it, and the crossings between parties appear on their own.
Draw the trigger and the first decision
Name what starts the loop (a site event, a query, a payment date) and add the first decision. For a change, that is whether it is within scope. For an RFI, whether the answer needs design input. Early decisions decide which of the later steps ever run.
Add the loops and the unhappy paths
For every approval or check, draw what happens when it fails: query raised, comments issued, rejected, cannot agree. Give each branch a label. These return paths are where the time goes, and they are exactly what a happy-path chart leaves out.
Join the loops where outputs become inputs
Find the step where one process produces what another consumes: an RFI answer that triggers a change, an approved change order that enters the schedule of values, a delay that triggers a time claim. Reference the other chart by name in the step, and link the pages so a reader can follow the chain.
Check it against your contract and agree it
Compare notice periods, document names and approval thresholds with the actual contract and edit the chart to match. Then use comments to ask each party whether their lane is right, and keep the agreed version through version history so later changes to the process are visible.
Mistakes to avoid
One chart for everything
A single page covering RFIs, changes, payments and inspections becomes unreadable and is never kept up to date. Several short charts that reference one another are easier to review and own.
Drawing only the approved route
Change orders and submittals spend most of their time in query and resubmit loops. If the chart shows only the clean path it cannot explain why the process takes weeks.
Copying a template without reading the contract
Contract forms differ in notice periods, in who certifies and in what a directive is called. A template is a starting structure, and the contract is the authority.
Leaving the owner's side as a single box
'Owner approves' often hides a funding check, a design review and a signature by different people. Split it where different people hold the item, or the delay will stay invisible.
Map your own project workflow
Open the change order example as your own chart, rename the lanes to your parties, and edit the notice periods and approvals to match your contract.
Related guides
Frequently asked questions
What is the difference between an RFI and a change order?
A request for information is a question that asks for clarification of the documents. It may or may not change anything. A change order is a signed agreement to change the scope, price or time of the contract. Many change orders start as an RFI whose answer turns out to differ from what was priced, which is why the two processes are best drawn separately and linked. See /templates/rfi-request-for-information-process and /templates/construction-change-order-process.
Where does a progress payment fit into the workflow?
Approved change orders are added to the schedule of values, and the payment application then claims progress against that schedule. The payment process therefore consumes the output of the change process. The steps are laid out in /templates/construction-progress-payment-process, and the time impact of changes is handled in /templates/extension-of-time-claim-process.
Should I map every process on a construction project?
No. Start with the processes that cause the most delay or dispute, usually RFIs, submittals and changes. Others, such as /templates/construction-punch-list-process and /templates/construction-inspection-hold-point-process, can be added when the team needs them. A short review pattern shared by several of these is described in /guides/how-to-map-a-review-and-resubmit-loop.
Can this chart be used as a contract document?
No. A process map shows how work is meant to flow and who holds each step. It does not replace the contract, and it is not legal advice. Use the contract for rights, notice periods and remedies, and use the chart to make sure everyone on the project understands how those obligations are carried out in practice.