The Programme Says the Work Can Start. Does the Site Have the Information to Build It?
A construction activity is not ready just because the programme date has arrived. Buildable work depends on current drawings, resolved RFIs, approved submittals, released materials, clear interfaces and a workfront free of hidden information constraints.
The short answer
A programme can say an activity is ready to start while the site still lacks the information needed to build it.
That gap is one of the quietest causes of construction delay. The labour is there. The subcontractor is mobilised. The material may even be on site. Yet the crew is waiting on a drawing detail, an unresolved RFI, an approval, an interface decision or a revision nobody has fully distributed.
The problem is not usually “design” in isolation. It is the break between design information and executable work.
Epicor provides the enterprise-grade ERP foundation for purchasing, finance, approvals and governance. Epicor Saturn adds the construction and engineering industry layer that keeps project information, site activity, resources, procurement and cost connected around the same job.
A programme date can create the illusion of readiness
Construction programmes are powerful because they turn a complex project into a sequence of dates and dependencies.
They can also create false confidence.
Once an activity appears in next week’s plan, teams start behaving as though the work is available. Labour is assigned. Plant is booked. Materials are chased. Subcontractors are told to prepare.
But the programme cannot always see whether the information needed for that activity is actually complete.
A drawing may have been issued but still contain unresolved interfaces. A submittal may be technically approved but not coordinated with the latest revision. An RFI may appear minor in a register while quietly blocking the only available workfront.
The date therefore answers one question: when does the project want the work to happen?
It does not answer the second: can the site build it without stopping?
That distinction is where workfront readiness begins.
“Issued” and “buildable” are not the same thing
Project teams often place great weight on document status.
Issued for construction. Approved. Reviewed. Closed.
These labels are necessary, but they can be misleading if the status is disconnected from site reality.
A drawing can be formally issued and still be difficult to build because a dimension conflicts with another trade, a support detail is missing, access is impossible or a related specification has changed.
The project therefore needs a practical test: can the responsible crew use this information to execute the work safely and correctly without needing another decision?
That question changes how design coordination is discussed.
Instead of asking only whether the drawing was issued, the team asks whether the information package is complete enough for the workfront.
That is why an issued drawing should be judged by buildability, not status alone.
RFIs should be ranked by what they stop
RFI registers can become deceptively tidy.
They show open date, owner, subject and response status. Teams often focus on the oldest item first because age is easy to measure.
But age does not equal impact.
A three-day-old RFI that blocks a concrete pour may be more urgent than a thirty-day-old query related to an area that will not be built for months.
The useful question is not “how long has this been open?”
It is “what happens if this remains open tomorrow?”
The answer may involve labour, procurement, inspection, subcontract scope, access or a critical workfront.
That impact should shape priority.
When the project links RFIs to the work they affect, design coordination becomes less about chasing documents and more about protecting production. An open RFI should therefore be understood through its site consequence.
Approval workflows become dangerous when they lose the site need date
Submittals are another area where administrative status can obscure operational reality.
A shop drawing may sit in review. A material sample may be waiting for approval. A technical submission may have been returned for comment.
The project team sees “pending”.
The site sees something else: procurement cannot release, fabrication cannot begin or the workfront cannot open.
That difference matters.
A submittal should not be important because it has been open for a certain number of days. It should be important because another decision or activity depends on it.
Once the site need date is visible, management can distinguish normal review from approval delay that threatens the programme.
This also improves conversations with designers and clients. Instead of simply asking for faster turnaround, the contractor can explain the consequence of the outstanding decision.
Submittal control becomes stronger when approval status is connected to the physical work waiting behind it.
Revision drift can create rework without anyone making a wrong decision
One of the most frustrating forms of rework occurs when everybody believes they followed the correct process.
The designer issues a revision. Document control distributes it. The subcontractor works from a drawing. The site later discovers that the drawing in use was superseded.
No one necessarily ignored a rule. The information simply moved through the project at different speeds.
Revision control becomes particularly difficult once work has started because one change can affect more than a drawing.
It can affect material already ordered, shop drawings in fabrication, method statements, inspections, temporary works and adjacent packages.
The project therefore needs to understand who and what is affected by the revision, not just whether the new file exists.
That is why drawing revision control has to reach the workfront, the subcontract package and the related material decisions before the site creates rework.
A full lookahead can still contain very little executable work
Two-week and three-week lookaheads are meant to bring the programme closer to site reality.
But they can become another layer of optimism.
Activities are copied from the master programme, dates are adjusted, and the report looks full. Yet several items may still depend on missing information, access, predecessor work or materials.
The project then discovers the constraint only when the crew is due to start.
A stronger lookahead distinguishes between planned work and ready work.
For each near-term activity, the team should understand what could prevent execution: drawing, approval, material, access, plant, permit, predecessor, subcontractor or interface.
The aim is not to create a huge checklist for every activity. It is to expose the small number of unresolved conditions that can invalidate the plan.
The lookahead becomes useful when it tells management what is truly constraint-free.
Field ingenuity is valuable — until the record stops matching the building
Construction teams solve problems every day.
A clash is discovered. An installation sequence does not work. A support needs to move. A site engineer proposes a better detail.
This practical problem-solving is often exactly what keeps a project moving.
The risk comes when the physical solution moves faster than the design record.
If the site installs a change before the approval trail, redline and design record catch up, the project can end up with three versions of reality:
- what the designer believes was approved;
- what the document system shows;
- what was actually built.
That gap matters during inspection, testing, handover, future maintenance and dispute resolution.
The answer is not to stop field initiative. It is to give that initiative a controlled path back into the project record.
Field changes should improve buildability without leaving the design record behind.
Workfront readiness is really an information-flow problem
Seen together, drawings, RFIs, submittals, revisions, lookaheads and field changes are not separate administrative processes.
They are different parts of one information flow.
The project is constantly converting design intent into physical work. Every break in that flow creates waiting, rework or uncertainty.
Senior management therefore needs a view that is closer to production than a design register and broader than the master programme.
Which workfronts are meant to open next?
What information do they depend on?
Which constraints remain unresolved?
What decision is required, by whom, and by when?
Those questions allow the project to manage the flow of information in the same way it manages material and labour.
The information may be intangible, but its absence has a very physical cost.
The best warning comes before the crew starts waiting
Once a crew is standing still, the constraint is obvious.
By then, the project has already lost time.
The real value of workfront-readiness control is to identify the problem a few days earlier, when the team still has choices.
An unresolved RFI can be escalated. A submittal can be prioritised. Another workfront can be opened. A material release can be resequenced. A subcontractor can redirect labour.
This is why short lookahead reviews are so important.
They create a place where programme, design, procurement and site conditions can be tested against one another before the work date arrives.
The meeting should not become a detailed status recital. It should focus on exceptions: what is supposed to start soon, and what could stop it?
That is a much more useful management question than asking whether every register is up to date.
The management consequence is bigger than a few lost hours. When information arrives late, the project often protects the immediate programme by making local compromises. A crew moves to a different area. Material is stored temporarily. Another trade is asked to work out of sequence. A subcontractor is told to “get on with what you can.”
Each decision can be reasonable in the moment. The cumulative effect is harder to see.
Out-of-sequence work can reduce productivity. Temporary storage can create double handling. Moving crews repeatedly can weaken learning and supervision. A late design decision can push one trade into another trade’s planned access window. The original information constraint disappears from the report, but the cost remains in the project.
This is why senior management should be careful with the phrase “no delay to the programme.” A team can protect the headline date while still paying heavily to work around missing information.
A mature workfront-readiness process makes those workarounds visible. If the same type of design or approval constraint repeatedly forces resequencing, that pattern deserves attention even when the master programme still appears healthy.
There is also a cultural effect. When site teams learn that drawings, approvals or answers are rarely ready when promised, they stop trusting the formal planning process. Supervisors create personal buffers. Subcontractors mobilise cautiously. Buyers add contingency to lead times. People protect themselves against the system.
That behaviour can be rational, but it makes the project slower and harder to coordinate.
Reliable information flow does the opposite. It allows teams to commit with more confidence because the workfront has been tested before labour and material arrive.
The real objective is therefore not a perfect register. It is operational trust: when the project says a workfront is ready, the people responsible for building it should believe that statement.
That is a demanding standard, but it is the standard that turns programme dates into productive work.
There is one final reason to manage this carefully: information delay and physical delay do not always appear at the same moment.
A drawing can be late on Monday, yet the site keeps moving because another task is available. The cost consequence may only appear a week later when the crew returns, the alternative work is exhausted and the original sequence has already been disturbed.
By then, the project may classify the problem as labour inefficiency, resequencing or subcontract delay rather than an information constraint.
This is why management should look for patterns, not isolated incidents. Repeated workarounds around missing information are a leading indicator that the project is consuming programme flexibility faster than the formal schedule shows.
Once that flexibility is gone, the next information problem becomes a visible delay.
The strongest projects therefore protect workfront readiness before the programme becomes fragile. They do not wait for the master schedule to show slippage before treating information flow as a management issue.
The result is a project that can distinguish between work that is merely scheduled and work that is genuinely ready to become productive.
That is the difference between planned work and trusted work.
Where Epicor Saturn fits in design-to-site control
Epicor is the enterprise-grade ERP foundation for purchasing, finance, approvals and core business governance. Epicor Saturn is ACC’s construction and engineering industry solution that extends that foundation across project planning, site activity, resources, procurement, cost and project control.
That relationship matters because workfront readiness sits between enterprise commitments and site execution. A material approval can affect purchasing. A drawing revision can affect a subcontract package. An unresolved RFI can change programme and cost.
Epicor Saturn provides the project-centric industry structure needed to keep these dependencies connected while Epicor supplies the enterprise-grade transactional backbone underneath them. Explore Epicor Saturn for construction and engineering.
Frequently asked questions
Is workfront readiness the same as lookahead planning?
No. Lookahead planning is one way to expose readiness, but workfront readiness also depends on design, approvals, materials, access, interfaces and site conditions.
Should every open RFI be treated as a programme risk?
No. Priority should reflect the work, procurement or decision the RFI is actually blocking.
Does an issued drawing mean the site can build?
Not necessarily. The project still needs to consider interfaces, completeness, current revision and buildability.
Why include field changes in design control?
Because the installed condition becomes part of the project record and should remain aligned with approved design information.