Projects rarely drift away from their intended path overnight. In most cases, there are early warnings. Progress begins moving slightly away from the plan, resources do not arrive as expected, site conditions reveal something different from the design assumptions. Sometimes the same concern starts appearing in several discussions. Individually, these signals may not look serious. However, when they are ignored or treated as isolated events, they can gradually develop into bigger problems. They may develop into delays, rework, disputes, and sometimes decisions that cannot easily be reversed. That’s why hands-on projects experience is crucial in this phase.
The challenge is not simply finding problems. Every project generates comments, observations, questions, and unexpected situations. Some can safely be addressed later without affecting the overall outcome. Others require immediate attention because continuing the work may make the solution more difficult, expensive, or even impossible. The real project execution skill is therefore learning to recognize the difference between an ordinary concern and an early warning that should trigger action.
In the previous article, “Project Execution: How to Deepen Mutual Trust Without Losing Sight,” we discussed how staying close to the work, verifying progress, and maintaining open communication can strengthen trust between project partners. However, trust should not mean assuming that everything is going well. It should help people raise concerns early and examine reality together. This article continues that discussion from a practical perspective: what signs should we watch, what tools can help us detect them, and when should a concern become an officially recorded issue requiring action before the project begins to drift?
Maintenance Coupons
Maintenance Coupons
Read the S-Curve Before the Project Drifts
An S-curve is one of the most common project-control tools. It plots cumulative progress, cost, labor hours, resources, or other project quantities against time. The curve often begins slowly, rises more rapidly during the main execution phase, and gradually flattens as the project approaches completion.
Project teams commonly compare the baseline planned-progress curve with the earned-progress curve. In an Earned Value Management system, the planned and earned curves represent Planned Value (PV) and Earned Value (EV), while Actual Cost (AC) may be plotted separately to assess cost performance. You can find more details at PMI here: Applications and extensions of the earned value analysis method
The gap between planned and earned progress indicates whether the project is ahead of or behind the approved baseline at a particular status date. However, the size of the gap alone does not tell the whole story.
A project may report 45% planned progress and 42% earned progress. This is a 3-percentage-point shortfall, equivalent to approximately 6.7% below the planned progress at that date. Whether it is acceptable depends on the project’s tolerance limits, critical-path activities, and forecast completion date.
The more important question is whether the gap is stable, closing, or widening. A widening gap is an important early warning that project performance may be deteriorating and that corrective action or further schedule analysis may be required.
Project teams should also examine the slope of the actual curve. A flattening curve may indicate falling productivity, restricted work fronts, missing materials, unresolved engineering issues, or poor coordination.
Recovery plans also need careful examination.
A revised curve may promise that lost progress will be recovered later. However, that promise needs supporting evidence. Does the project have enough manpower, materials, work areas, and supervision to achieve the proposed recovery?
When the curve changes direction, the project team should investigate the reason before the deviation becomes difficult to recover.
Compare the Project Charts: Look for Warnings When the Numbers Do Not Agree
Project teams use several charts and trackers to monitor execution. These may include the S-curve, manpower histogram, procurement schedule, equipment-delivery tracker, and detailed construction programme.
Each report provides only part of the picture. Its real value becomes clearer when it is compared with the other project-control records.
For example, a manpower histogram may show planned and actual workforce levels over time. When the planned work front is available and adequately supported, additional productive manpower should generally contribute to increased physical progress.
What happens, however, when manpower rises while the earned physical-progress curve remains flat? This mismatch should be treated as an investigation signal.
Workers may be waiting for materials, approved drawings, access, inspections, or work permits. Different contractors may also be competing for the same work area. Additional personnel may then increase cost without increasing measurable output. Other explanations may include poor supervision, low productivity, rework, work-front constraints, or a delay between completed work and its formal progress measurement.
The same comparison applies to procurement. A progress report may show healthy current construction activity while the procurement tracker shows that critical equipment or materials are late. Current progress may therefore appear acceptable even though future work faces a predictable constraint.
The team should assess whether the delayed item affects a successor activity, critical-path work, commissioning, or the planned release of a work front.
Project teams should therefore avoid reviewing charts as separate reports. They should compare the trends and ask whether the numbers support one another.
When two project-control records tell different stories, the discrepancy should be investigated rather than explained away without evidence. Such mismatches can provide an early warning before the resulting deviation becomes visible in the overall schedule.
Site Reality: Warnings When the Design Meets the Real World
Drawings describe what the project intends to build. The site shows what can actually be built.
This difference creates some of the most important project warnings. A design may assume clear access for equipment installation. The actual site may have another structure in the way. A drawing may show sufficient space for cable bending. The installed equipment may leave much less room. These situations should not be treated as minor construction comments.
The team should first check the design assumption, the actual site condition, and the effect on subsequent work. A site observation can capture the physical difference. An RFI (Request for Information) can formally ask engineering to clarify the required solution.
The important point is timing. If the team can continue safely without affecting another activity, the issue may wait for a controlled decision. If continuing will cover the condition, lock equipment into place, or create rework, the warning requires immediate escalation.
This is where constructability becomes important. A technically correct design can still create serious execution problems if nobody checks how it will be installed, accessed, maintained, or connected to surrounding systems.
When an Interface Becomes a Project Warning
Interfaces create another common source of warnings.
One contractor may complete its scope exactly as specified. Another contractor may do the same. Yet, the two completed scopes may not connect properly. This can happen between civil and electrical works, equipment and cables, mechanical systems and controls, or different suppliers. he problem often remains invisible until installation reaches the interface.
For example, a cable route may appear correctly divided between contractors on separate documents. The problem becomes serious when both contractors assume the other owns part of the physical route. An interface register can identify these boundaries early. The team can assign an owner, required action, responsible discipline, and target date.
Do not rely only on verbal agreement. A warning discussed in a meeting but not recorded can disappear with the meeting.
The practical question is simple: f we continue this work today, can we still correct the situation later?
If the answer is uncertain, stop and clarify before proceeding.
Record the Warning: Not Every Comment Belongs in the Same Tool
Once a warning appears, the next question is where to record it. Project teams often use several records, and each serves a different purpose.
A site observation records something seen or identified at the work location. It provides evidence that a condition exists.
An RFI seeks formal clarification when the available design or specification does not provide a sufficient answer.
A punch list records incomplete or defective work that remains to be closed before an agreed milestone or handover. It should not become a storage place for unresolved design decisions.
An issue register tracks problems that require ownership, action, and follow-up. It should normally show the responsible person, due date, status, impact, and required decision.
An NCR (Non-Conformance Report) is appropriate when work or supplied material does not comply with an approved requirement.
Meeting minutes and project chat have another role. They help teams communicate quickly, but an important warning should not remain only in a chat conversation.
The formal project record should carry the decision. This distinction prevents a common failure: treating every comment as equal. A comment may need observation only. Another may need an RFI. A third may require an NCR or management decision. The classification should depend on impact, urgency, and reversibility.
If the team can correct the condition later without affecting safety, quality, cost, schedule, or another work package, controlled follow-up may be sufficient. If continuing the work can hide the condition, create rework, affect another interface, or remove future options, the warning has become a trigger.
That trigger deserves immediate action and formal ownership.
A Practical Test
Before closing the discussion, ask three questions:
What happens if we do nothing today?
What becomes harder or impossible if we continue?
Who has the authority to decide the next action?
These questions turn warnings into controlled project decisions instead of forgotten conversations.
In Short,
Project warnings rarely arrive with a label saying “major problem.”
They emerge through deviations, site observations, conflicting information, interface gaps, and repeated comments.
The project team’s responsibility is not to eliminate every deviation.
It is to recognize which warnings can wait and which ones require action before the project loses the ability to recover.
