The 14-point assessment from the U.S. Defense Contract Management Agency (DCMA) is an excellent reference for measuring the mechanical health of a schedule: logic, constraints, float, durations, resource use, baseline indices and more. If your programme passes the 14 metrics, you know it is well built.

What the metrics do not tell you is whether that schedule is useful, whether anyone understands it and uses it to make decisions, or whether it is honest, whether it reflects what will really happen on site or only what the contract wants to hear. That second layer is not measured by an automatic test; it depends on the process, communication and the planner's judgement.

In addition to applying the DCMA 14-point assessment, these are the recommendations that, in our experience, make the difference between a schedule that passes an audit and one that actually governs the project.

Document and communicate the plan, because having it is not enough

A schedule that is only understood by the person who built it is only half an asset. The first group of recommendations is about making it readable for the whole team.

Write a programme narrative. This is a descriptive document that explains which activities will be executed, with which resources and under which construction logic. The narrative forces the planner to justify their decisions and gives the rest of the team the reason behind the Gantt bars. On very large and complex projects, it is advisable to split it by work packages.

Define clear reports adapted to the recipient. A steering committee and a site supervisor do not need the same information. Reports must communicate progress, forecast and, when required, recovery plans, with content and level of detail adjusted to the audience. They must also be periodic: a sporadic report does not allow proper follow-up.

Take care of communication between project participants. Communication between project team members is essential. Relevant information must arrive clearly and simply; a correct data point that nobody understands in time is, in practical terms, a lost data point.

Visualise the schedule in different ways. The same programme reads very differently in a Gantt chart, an S-curve, a resource histogram or a zone-based view. Changing the viewpoint is not cosmetic: it is one of the most effective ways to detect logic errors and understand the project at a deeper level.

Keep the schedule alive and honest

The second group is about continuous technical rigour. A schedule is not a document that is submitted and archived; it is a model that must be kept synchronised with reality.

Keep the baseline present throughout the project. Without a baseline, there is no deviation, only new dates. The systematic comparison between what has actually been executed and the contractual plan is what turns the schedule into a control tool rather than a calendar that is rewritten every month.

Analyse float and subcritical paths regularly. The critical path is dynamic: a delay on a path with little float can make it critical overnight. Monitoring the total float of activities, not only those that are critical today, is what allows you to anticipate the problem before it explodes.

Study and optimise resource use. Resource levelling in Primavera and Project is a very powerful tool, but it must be applied with extreme care: if configured badly, it can delay priority tasks or alter the construction sequence without you noticing. Automate the calculation, but validate the result with site judgement.

Use the Earned Value Management method (EVM). It is one of the best ways to assess the real progress of a project in both cost and time, integrating both dimensions in the same framework (SPI, CPI). Earned value tells you not only how much you have completed, but how much what you have completed is worth.

Make honest forecasts, not cosmetic ones. Planning is not adjusting activities so that the schedule shows the project finishing on the contractual date. That is not a forecast; it is a wish in Gantt format. A real forecast considers past production rates, the team's learning curve and future resource availability. A schedule that always fits the finish date, whatever happens on site, is exactly the one you should not trust.

One plan, owned by the team

The third group is the most organisational, and the one that sinks the most projects when it is ignored.

Involve the team in planning. Bringing in other members, site supervisors, discipline leads and subcontractors, improves teamwork and exposes defects that are missed from the office. The expert who executes the task is often the first to see that a duration is unrealistic or that two scopes will interfere.

The Project Manager and the site manager should work side by side with the planning engineer. And above all: there must only be ONE project plan. As soon as two versions appear, the official one and the real one that someone keeps in Excel, planning stops being useful. This is probably the most important principle on the whole list.

Use specific project controls software. Tools such as Primavera P6 or MS Project are essential for managing logic, resources and baseline, even on projects that are not very large. Spreadsheets are excellent for communication, but they are not the right tool for planning: they do not manage relationships, calendars or a baseline against which to compare.

How we integrate this at PlanBuilt

If you look closely, almost all these recommendations share a common enemy: dispersion. Schedules living in one place, reports in another, the site manager's Excel file in a third, and none of the three versions saying the same thing.

At PlanBuilt we build our methodology around the non-negotiable principle behind these recommendations: one plan, one single source of truth from which everything else is derived automatically. From the schedule (P6 / MS Project), we deliver an online interactive dashboard that turns these best practices into something the team sees every day, not into a report generated once a month:

  • The as-built versus baseline comparison always visible, with the actual progress S-curve.
  • Continuous monitoring of float and subcritical paths, so that a change in the critical path does not catch you by surprise.
  • Earned value indicators (SPI/CPI) updated without manually reprocessing anything.
  • Reports and lookahead views filterable by discipline or contractor, adapted to each recipient from the same data.

All in a single shared access point, instead of a storm of versions by email.

The objective is for the planner to spend time on what the DCMA metrics cannot audit: judgement, honest forecasting and coordination, not formatting reports.