A Task List Is Not a Plan: Why Projects Slip Without Warning

The question

The windows are two weeks late.

When do you move in?

Many project plans cannot answer that question.

Most people immediately start guessing. Some say two weeks. Some say longer. Some say it depends.

The interesting thing is that many project plans look perfectly reasonable until someone asks that question.

Why this matters

Projects rarely fail because people stop working. Projects fail because nobody understands the impact when something changes.

A task slips. A supplier is late. Testing overruns. A key decision is delayed.

The question is not whether things will change. The question is what happens when they do.

Task lists versus plans

Many project plans are really task lists. They tell us what needs doing. They do not tell us what happens when something slips.

The difference

The work has not changed. The durations have not changed. The resources have not changed.

The only difference is that the activities are connected together.

Now we can see which tasks depend on others. Now we can see what drives the finish date. Now we can predict the impact of a delay before it happens.

This is known as critical path analysis. Despite the impressive name, the principle is surprisingly simple. Some activities determine the finish date. Others have flexibility. The challenge is knowing which is which.

Producing realistic durations is another challenge. I look at twelve practical ways to estimate project work in a separate article.

A real-world example

Consider a CRM or ERP implementation.

Configuration → Data Migration → Testing → Training → Go Live

If testing finishes three weeks late, does go-live still happen on time?

The answer depends on the relationships between those activities. Without those relationships, you are guessing. With them, you are forecasting.

What I look for

One of the first questions I ask when reviewing a programme is: what is driving the finish date?

If nobody can answer, that is often where the real risk lies.

The issue is rarely the number of tasks. The issue is understanding how they fit together. Because a task list tells you what needs doing. A schedule tells you what happens when something changes.

And in complex programmes, that is usually the difference between predicting a delay and being surprised by one.

Conclusion

The windows are delayed by two weeks. When do you move in?

If your plan cannot answer that question, it may not be a schedule. It may simply be a list of tasks.

A task list tells you what needs doing. A schedule tells you what happens when something changes. Understanding the difference is often the difference between managing a delay and discovering one too late.

It is also one of the reasons organisations bring in an experienced interim manager when delivery needs independent scrutiny. The FAQ covers when a programme needs an interim rather than a consultancy.