When Delays Are More Than Delays

Posted by Rich Crowley in Change, planning, Project Management

One of things I’ve learned over many projects big and small is that delays in any aspect of a project can have some unanticipated consequences. One of the most common but unintuitive of these consequences is that sometimes a simply delay in one task, or task group, can actually result in changes to the definition of a task or task group that is dependent on the work that is delayed.

Why do I suggest this is unintuitive? Consider that project managers typically build plans by identifying as many tasks as are visible at a point in time, sequencing these according to dependencies, etc. If task group A must precede task group B, this translates into task group A needing to be complete, or close to it, before task group B can begin.

If task group A’s completion date gets delayed, the impact to task group B in theory is that its start date will likewise be delayed. However, it is important to first determine why task group A was delayed in order to understand the effect not only on the timing, but on the definition of, the downstream tasks groups.

For example, if task group A was a software development deliverable, and it is delayed, the cause of the delay may be that the nature of the deliverable is changing. Perhaps the deliverable needs to be a larger chunk of code, libraries or a more functionally complete unit. If this is the cause of the delay, then the downstream task group may need its definition to change as well.

Perhaps the downstream task group was defined as some test harnesses around smaller, less comprehensive units of code, libraries etc. If the upstream deliverable changes to be a more comprehensive deliverable, the need for, or value in, the original downstream deliverable may no longer exist. Instead, the downstream deliverable may also need to morph into some test artifact that more closely aligns with the revised upstream deliverable.

The challenge here for the PM is to ensure he/she understands the root cause of the delay in the upstream deliverable, analyse its impact on subsequent task groups and most importantly, be able to justify to project stakeholders why planned work, which has not yet started, continues to change before it starts. On the surface, this can appear as though the initial planned work wasn’t defined well enough. However, the above example illustrates that this is not always the case. Planned work will change based on the nature of the work that gets executed before it.