A Date Is Not a Plan

Most projects have a date.

A go-live date. A completion date. A launch date.

Something that has probably already been shared with the board, the customer or the wider organisation.

Sometimes that date needs to be a fixed date.

There may be a contractual start date, a regulatory deadline, a shutdown window or a customer commitment that has to be met.

Other times, it is just the date somebody put in the plan months ago.

Those are two very different things.

But either way, the date on its own proves very little.

A date tells you when something needs, or is expected, to happen.

A plan should tell you whether you can actually get there.

That sounds obvious.

But it is one of the most common problems I see in project delivery.

When the date starts running the project

Once a date has been announced, it quickly becomes important.

People organise around it.

Customers expect it.

Senior management starts asking whether the project is still on track.

All perfectly reasonable.

The problem starts when the project team begins protecting the date without being clear whether it is actually achievable.

Testing gets squeezed.

Training gets shortened.

Known issues get accepted.

Readiness becomes something to tick off rather than something to prove.

And the closer the date gets, the harder it becomes for anyone to say:

“We’re not actually ready.”

That is usually where trouble starts.

If the date can move, then sometimes it should.

If the date cannot move, then the project needs to deal with that properly.

That may mean changing scope.

Adding resource.

Taking decisions earlier.

Changing the sequence of work.

Or accepting some very clear risks.

What does not work is assuming the date will be hit simply because it is important.

What is the evidence behind the date?

In one of the sample project assessments I developed, the go-live date was clear.

The problem was that several important parts of the project were still being drafted.

Process design was incomplete.

Migration and integration planning were immature.

Training and operational readiness were not yet demonstrated.

There was no detailed schedule, resource plan or readiness evidence showing that the date was achievable.

So there was definitely a date.

What there wasn't yet was enough evidence to support it.

At that point, it was still an intention rather than a controlled forecast.

That is an important difference.

You do not need a huge planning process

This does not need to become complicated.

You just need to ask some sensible questions.

What still needs to be done?

Who owns it?

What depends on what?

Have we got the right people available?

What still needs to be tested?

What needs to be true before we are ready to go live?

And one question that is often missed:

Can the date move?

If it can, then be prepared to move it if the evidence says that is the right thing to do.

If it cannot, then be clear about what else needs to change to give the project a realistic chance of hitting it.

That is the bit that matters.

Ask a better question

One of the least useful questions in project delivery is:

“Are we still going live on the 31st?”

It almost invites a yes.

A much better question is:

“What evidence tells us we can?”

That changes the conversation.

Now you are not just talking about whether the date is still written in the plan.

You are talking about whether the project is actually capable of achieving it.

That is a much better conversation to have.

No Fluff takeaway

A target date is useful.

A target date backed by evidence is a forecast.

And if the date is genuinely fixed, the evidence behind the plan becomes even more important.

The project needs to understand what has to happen, what could get in the way and what decisions need to be made early enough to keep delivery on track.

The problem is not having a date.

The problem is having more confidence in the date than you have evidence to support it.

Don’t just ask whether the project is still on time. Ask what tells you it will be.