At ProjectControls.online, we’ve automated the key schedule health indicators that we’ve used in our decades of industry experience. To supplement these indicators, we’ve included an industry-standard evaluation of schedule quality and health: the DCMA 14-Point Assessment. Our seasoned schedulers might be more than familiar with these guidelines, but here’s a brief overview or refresher.

Overview

While evaluating the schedule quality, during both planning and monitoring & controlling, it is important to make assessments from a qualitative and a quantitative perspective. A quantitative assessment of schedule quality is based on measurable criteria rooted in industry-defined scheduling best practices. The Defense Contract Management Agency (DCMA) developed a set of health checks and guidelines collectively known as the DCMA 14-Point Assessment. These are not hard and fast rules, but indicators of potential problem areas where a deeper schedule analysis may be necessary. While satisfying these guidelines doesn’t necessarily mean the schedule is feasible, not satisfying them almost certainly means it is not. Here, we will examine each of the 14 points and why they are critical for a healthy project schedule.

1. Logic

The logic check seeks to ensure that all incomplete activities have predecessors and successors. Just one missing link can have a significant impact on the project completion date; so, it is imperative that the network logic capture all activity dependencies. The DCMA threshold for this metric is that no greater than 5% of incomplete activities should be missing a predecessor and/or successor. However, it is not uncommon for organizations to self-impose a more rigorous policy that all incomplete activities have predecessors and successors, except for level-of-effort and summary tasks. At the very least, tasks without scope dependencies should be linked to the project start and/or project finish milestone. This indicates that the scheduler considered the dependencies and did not simply miss them.

2. Leads

A lead is a negative lag between two tasks in which a task starts some number of days before the finish date of its predecessor. Using leads disrupts the flow of the schedule and can have adverse effects on the project total float, impeding the ability to determine the true critical path. For this reason, the DCMA threshold is Zero. Rather than using leads, activities should be decomposed to a level of detail in which traditional Finish-to-Start relationships can be used.

3. Lags

Positive lags between tasks, where a task starts some number of days after the start or finish date of its predecessor, can also adversely affect analysis of the project critical path. Additionally, lags can be confusing if the reason for them isn’t immediately clear. DCMA is more lenient with this metric, setting the threshold at 5% of total task relationships. However, in many cases it is better to represent a lag with an explicitly named task. For instance, rather than adding a 5-day lag to account for shipping time to the customer, represent shipping time with a separate task.

4. Relationship Types

The preferred relationship between tasks is Finish-to-Start (FS). Ideally, all tasks in the schedule would be sequenced this way to have the clearest understanding of the critical path. Start-to-Start (SS) or Finish-to-Finish (FF) relationships may be used in cases where that is the true nature of the dependency. For example, it is reasonable that an audit may not begin until the activity being audited begins. Moreover, QA inspection may not finish until the process or product being inspected is finished. However, SS and FF relationships should not be used simply to schedule activities in parallel if they do not truly depend on each other. In such instances, it is better to give the two parallel activities the same FS predecessor(s). The fourth relationship type, Start-to-Finish (SF), can seriously impede the network logic of the schedule and should be used only in extremely rare cases. DCMA recommends that at least 90% of all activity relationships should be FS relationships.

5. Hard Constraints

Constraints in general should be used sparingly, allowing for task dates to result from dependencies and activity duration. When necessary, however, soft constraints (Start No Earlier Than and Finish No Earlier Than) are preferred because they allow the schedule to continue to be logic-driven. By contrast, hard constraints (Start No Later Than, Finish No Later Than, Must Start On, and Must Finish On) artificially prevent the schedule from shifting to the right. This has the potentially disastrous effect of obscuring the possibility of late performance before it is too late to take corrective action. The DCMA threshold for hard constraints is that no greater than 5% of incomplete activities in the schedule should use them. However, this is another area where an organization may choose to impose limits that are more restrictive. Ideally, there should be no hard constraints in the schedule. We suggest using deadlines to represent hard dates, allowing the schedule to forecast late delivery early while it is still possible to correct it.

6. High Float

DCMA defines high float as total float of 44 days (2 working months) or greater. Intuitively, one would assume that activities with high float would be a good thing, a form of schedule margin, so to speak. However, high float is more often the result of missing dependencies. It is rare that an activity can slip more than two months without impacting the project completion date. The threshold for this metric is set at 5% of incomplete activities.

7. Negative Float

Negative float occurs when the project schedule is forecasting a missed deadline, or when a hard constraint is holding a task further to the left than it would be otherwise. In either case, it indicates that some future critical date is likely to be missed and that the project team may need to either fast-track or crash the schedule to rein it back in. Ideally, DCMA recommends having no negative float in the schedule. However, if the negative float is accurate with regards to a critical or contractual date, the project manager may request an explanation and corrective action plan.

8. High Duration

Part of the planning process is decomposing work packages to a level where the activities are discrete enough to track and manage. DCMA considers any incomplete activity with a baseline duration of greater than 44 days to violate this metric. Activities with high durations make it difficult to objectively estimate resources and assess performance. In cases where an activity cannot be broken down further, the project manager should have an articulable method of performance assessment. The DCMA threshold for high duration is 5% of incomplete activities.

9. Invalid Dates

The invalid date check applies only during execution of the project. A task is said to have invalid dates if it has forecasted start/finish dates in the past or actual start/finish dates in the future, with respect to the project status date. The threshold for this metric is Zero. Tasks which have not yet started or completed must be pushed beyond the status date, and tasks which have started or completed early must be revised with the actual start/finish dates on which they occurred. This is one of the more critical metrics, as tasks that violate this lead to question the validity of the rest of the schedule.

10. Resources

Ideally, all project schedule activities should have resources assigned to them. In practice, not all organizations resource load their project schedules. Additionally, there are occasions where tasks with durations greater than zero represent time but have no work associated with them, such as procurement lead-time or customer review of deliverables. This is one of the more flexible metrics of the 14-point assessment. In the case of organizations that resource load their schedules, it is still a valid metric to ensure no activities were missed during the resource estimation process.

11. Missed Tasks [Comparison Analytic]

The missed tasks metric measures schedule performance against the prior plan (or baseline). It is the percentage of tasks which were planned to have finished as of the project status date, which have actual or forecast finish dates later than their baseline finish dates. It does not include tasks which are currently forecasting late if those tasks have baseline finish dates after the status date. In that way, it is purely retrospective. The DCMA threshold for missed tasks is 5%, though recovery becomes unlikely after a project falls too far behind.

12. Critical Path Test

The critical path test is a pass/fail metric intended to evaluate the integrity of the network logic in the schedule; specifically, it ensures that the schedule has a continuous link from project start to finish. This test is performed by identifying the critical path in the schedule and intentionally introducing some amount of schedule slip to the first task on the path. If a commensurate amount of schedule slip occurs on the project finish milestone, the schedule passes the test. A failed test indicates missed dependencies and requires deeper analysis of the network logic.

13. Critical Path Index

The Critical Path Length Index (CPLI) is a forward-looking measure of required schedule efficiency to complete a project. It is something of a schedule counterpart to the To-Completion Performance Index (TCPI). It is defined as the sum of the remaining project duration (number of working days on the current critical path) and total float, divided by the remaining project duration. Total float in this instance is the variance between the forecast and baseline finish date of the Project Finish milestone. A CPLI of 1.00 indicates that the project must execute exactly to plan for the remainder of the project. A CPLI above 1.00 indicates that there is remaining schedule margin; a CPLI below 1.00 indicates that the team must overachieve to meet the baseline finish date. DCMA considers a CPLI below 0.95 to indicate a potential issue requiring further investigation.

14. Baseline Execution Index [Comparison Analytic]

The final metric, Baseline Execution Index (BEI), is another indicator intended to measure performance against the baseline or prior project schedule plan. Put differently, it measures the throughput with which the project team is accomplishing tasks. It is calculated by dividing the total number of tasks completed by the total number of tasks of the prior schedule to have been completed as of the project status date. A BEI of 1.00 indicates the project team is executing on plan, with greater than 1.00 indicating ahead of schedule and below 1.00 indicating behind schedule. DCMA considers a BEI below 0.95 to be indicative of a potential issue requiring further investigation.

Conclusion

The DCMA 14-Point Assessment offers the project manager a great way to objectively evaluate schedule quality over the life of the project. While satisfying these guidelines doesn’t necessarily mean the schedule is feasible, not satisfying them almost certainly means it is not. It would be in the best interest of all project managers to routinely perform this assessment to maximize the likelihood of on-time project performance.  With ProjectControls.online, these schedule analytics are available instantly, allowing schedulers and project managers more time to resolve schedule issues than to discover them.  Our DCMA analytics work for both Microsoft Project and Primavera P6 schedule files uploaded to our CPM Schedule Services module.  If you have questions or would like to see a demo, feel free to contact us at admin@projectcontrols.online.