Pausing a System Project Over Peak Trading? Decide These First

"We'll pick it up in January."

If you work on a retail or wholesale systems (or maybe any systems) project, you'll hear that sentence a lot in the next few weeks. Peak is here. Black Friday and Cyber Monday have turned into a whole month. I'm seeing offers already from retailers saying "don't wait, this is the discount". Last year the Australian Retailers Association and Roy Morgan tipped the four days from Black Friday to Cyber Monday at a record $6.8 billion. Nobody wants any system changes landing anywhere near that. So typically, projects slow down or freeze until the new year.

That's sensible. What happens to the project during the freeze is the part that usually isn't.

The short answer

A change freeze stops changes to the system. It doesn't stop the project drifting.

Before you pause for peak, do four things: make sure every open decision has an owner and a date, you know who's really coming back to the project in January and with how much time, your steering committee hears where the project actually stands, and you write down where you left it. Those four steps take a few hours now and save weeks in January.

Why "we'll pick it up in January" goes wrong

On the surface, a freeze looks like a pause button. In practice, a few things keep moving.

Open decisions don't freeze. The design question nobody wanted to settle in October is still open in January, except now it's older, the people who understood it best have had six weeks off, and the build has carried on around it.

People get pulled away. Your best business people are exactly the ones peak needs most: in stores, in the warehouse, in customer service. Some of them won't come back to the project at the same level. Some will take leave in January (or February), which is fair enough after the peak they've just had.

Context leaks. The reasons behind half-made decisions live in people's heads, email threads and meeting chats. Vendor teams change over the break too, and I see the same thing every time: when the people change, context everyone thought was settled gets lost.

The new year asks a hard question. On the other side of peak, maybe we didn't quite hit the targets. This brings the question "what have we got for the money so far?" If the honest answer is "we paused with a lot of open questions", that's a harder conversation in January than in November.

Researchers who studied a clinical trial that had to be suspended and restarted described the same pattern from a different world. Constable and colleagues, writing in the journal Trials in 2020, split a suspension into three stages: "the decision to suspend, implementation of the suspension, and restarting". Their lessons are very familiar to anyone on a system project: keep a running record of what happened, keep people engaged with useful work during the pause, and make sure the people who matter most aren't "moved on to other projects". It's an experience report rather than a controlled study, but the insight is useful: the restart is planned before the pause, not after it.

So how might we approach this instead? Here are some suggestions (advice I'm giving to myself):

1. Give every open decision an owner and a date

Document every decision that's still open. The compromises, the design choices, the "we'll come back to that" items.

For each one, consider and document these three things: who owns this choice, when will it be made, and what's needed to make it? Also consider the contrarian angle. What would stop someone from making the decision? This angle helps make the potential blockers more obvious.

This does more than tidy the project. It helps the people carrying it. Psychologists Masicampo and Baumeister found in 2011 that unfinished goals keep intruding on people's thinking and get in the way of other work. Making a specific plan for the goal removed those effects. Their paper's title says it well: "Consider it done!"

On a project, an open decision with no plan nags at everyone who knows about it, right through the busiest season. An open decision with an owner and a date can be parked until required.

2. Be honest about capacity

Ask, person by person: who's working on the project in January, and which days can they really give it?

Include your subject matter experts, your testers, your project manager and the vendor team. If someone's going on leave (very likely), rolling off or moving back to their day job for a while, record it now. A January plan built on November's resourcing is the planning version of "we'll pick it up later".

If the numbers don't add up, that's not a problem to solve over Christmas when there's no one to ask. It's a decision for the steering committee, which brings us to the next step.

3. Tell the steer co where things really stand

Before the freeze, give your sponsor and steering committee the version of the project you'd give a trusted colleague over coffee. Not "on track, with some emerging concerns". What's done, what's half-done, what's still open, and what's worrying you.

That's not easy to say in November. But a steering committee that knows in November can make decisions before the break. One that finds out in February has fewer options.

4. Write down where you left it

Finally, write a one-page note: where we left it. What's finished. What's half-finished. What's been decided, and why. What's still open. What we were worried about. Who knows what.

Store it where everyone can find it in January. It's the cheapest insurance a project can buy, and it's the first thing I'd want to read on the first day back.

All being well

My Nana signed every birthday, Christmas and major life milestone card the same way. "Fondest love, Nana and Popa." Later, "Fondest love, Nana." It's one of those inside-the-family phrases that has meaning across the generations. So much so that at my second child's christening, an event Nana was too unwell to attend, one of my cousins asked of the card she had sent, "Was it fondest love?"

She had a signature sign-off too. Whenever she made plans to see you next, she'd sign off with, "All being well, I'll see you then."

"All being well" was like fondest love: part of Nana's base comms plan. As a child, I remember thinking that it was such a negative way to see the world. Overly catastrophic and theatrical was my thinking. "All being well?" What on earth did she think was going to happen?

With time and life experience, I've come to really appreciate the sentiment. Our best-laid plans can go completely off the rails, for reasons nobody controls. Life happens. I mean, have you watched the news? (No? Me neither.)

The other day I heard myself say it: "I'll see you at Christmas, all being well."

It's a good phrase to have in your head when you plan January. A plan that needs everyone back from peak at full strength has no room for the leave you might know about, let alone the life events you don't. So I try to always apply an 80% rule. Plan for 80% of the capacity you think you have, and keep the rest as room for things to go wrong.

Hospitals have a version of this. A [simulation study published in the BMJ found that the risk of having no bed for an emergency patient becomes "discernible when average bed occupancy rates exceed about 85%".

A ten-minute check before the freeze

Here's the short version as a checklist.

If you can tick all five, your project is pausing. If you can't, it might be drifting with the lights off.

Take the temperature before you stop

If you're not sure where your project sits, or somethings feeling a bit ''off' take The Project Undercurrent before you break. It's 12 statements and takes about five minutes. Your result shows which undercurrent could be running in your project and where to look first.

It's even more useful if you and the people who'll restart the project in January each take it, then compare answers. Where you see the project differently is exactly where to start.

And if several undercurrents show up at once, January is a natural point for a proper restart.

Some common questions

Should we pause our system project over peak trading?

Usually, yes. Most retail and wholesale businesses can't absorb a system change during Cyber and Christmas. The risk isn't the pause itself, it's pausing with decisions open, resourcing unclear or assumed and context in people's heads.

What should we do before a project change freeze?

Give every open decision item an owner and a date, confirm who's back in January and with how much time, tell the steering committee where the project really stands, and write a one-page note on where you left it.

Does a change freeze stop the project?

It stops changes to the system being deployed. It doesn't stop decisions ageing, people being pulled away or context being lost. Those keep moving unless you deal with them before the freeze.

How do we restart a project after Christmas?

Start from what's true now, not from the November plan. If you did the four steps above, the first week back is about reviewing the decision list and the January resourcing, not reconstructing what happened.

Not sure where your project sits?

Take The Project Undercurrent. It's about five minutes.

Until Sunday 22 November, I'm offering a complimentary 60-minute session to walk through your results with you, two sessions a week.

Book a results session.

If you'd rather talk it through first, book a 25-minute call with me.