Thursday Is Not Moving

Some deadlines are aspirations. The launch is “targeting end of Q3,” and if it lands in early Q4 there’s a conversation and everyone moves on.

Some deadlines are physical facts. The activation opens when the doors open. The media is booked and paid for. The sponsor has announced the date in a press release. The screens go live at the shopping centre on the Thursday because that’s when the site fee starts.

On a schedule the two look identical. To deliver, they’re almost nothing alike, and mixing them up is one of the more expensive mistakes in this business. So the first thing worth working out is which kind you’ve actually got.

What a fixed deadline actually changes

There are three levers on any project: what it does, how well it’s built, and when it’s ready. Nail one down and the others have to absorb everything.

When the date genuinely can’t move, scope has to be the thing that gives. There isn’t a third option. Projects that pretend otherwise end up letting quality slip instead, which is the same trade-off, just made badly and without anyone agreeing to it.

In practice that means planning a fixed-date project from the other end. Rather than “here’s everything, we’ll see how far we get,” it’s “here’s what exists on Thursday no matter what, and here’s what we’ll add if we’re ahead.” The list can be exactly the same. Working through it from that end is what makes the difference.

The conversation that belongs in week one

Ask a team building to a hard date what gets cut if they’re two weeks behind. If the answer is “we won’t be,” they haven’t made the decision yet, and they’ll end up making it under pressure.

The conversation worth having early is a plain sort: which parts of this are the reason it exists, and which parts are there because they were a good idea in the room?

Nobody enjoys this conversation in week one, because everything feels essential while there’s plenty of time. By the final week only one thing does, and by then nobody’s thinking clearly. A ranking made at 11pm on the Tuesday before tends to protect whatever’s closest to finished rather than whatever matters most. It’s much easier to agree in week one, when nobody’s panicking.

The other question that belongs in week one: what is actually fixed about Thursday? Occasionally the date is real and the scope of the date isn’t. The screens must run on Thursday, but the admin tool the client’s team uses to change the content can arrive the following week without anybody outside the building noticing. Finding that distinction early is often worth more than any amount of extra effort.

What gets protected first

When something has to give, a consistent order tends to hold up.

Whatever the public touches. What a customer or visitor experiences is what’s being paid for, and everything behind it has more room to move.

Whatever can’t be fixed afterwards. This is the one that gets missed. A microsite can be improved on Friday morning. A physical installation, a printed QR code, a mechanic baked into a broadcast asset, a piece of hardware in a shopping centre. Those get one attempt. Anything with a one-shot quality gets protected ahead of things that look more important but are amendable later.

Whatever fails ugliest. Some failures are invisible and some happen in front of a crowd with a camera on them. Effort concentrates on the second kind.

Whatever you can’t recover from. Data being captured incorrectly during a two-day activation isn’t fixable afterwards, because the people are gone. Reporting that’s ugly can be tidied up next week.

Cutting well and cutting badly

Cutting badly means keeping every feature and doing all of them to a lower standard. It’s the default, because it avoids the difficult conversation, and it produces something where everything is slightly wrong. Nobody remembers which corners were cut; they remember that it felt cheap.

Cutting well means removing whole things and doing what remains properly. Six features that work beat ten that nearly do. The version with six is generally the one that gets talked about.

Two techniques worth knowing. The first is graceful degradation: build the experience so that if a clever component isn’t ready or misbehaves on the day, what’s underneath it is still a perfectly good experience rather than an error. The second is the manual fallback. If the automated flow isn’t going to be reliable by Thursday, a person with a tablet doing the same job is a perfectly good plan. Plenty of well-received activations have run with a human standing in for a system that was cut two weeks out, and nobody in the public ever knew.

Rehearse it, then freeze it

The deliveries that go calmly tend to have two habits in common.

Rehearse in the real conditions. That means the screen you’ll actually use, on the venue’s network, at the brightness it’ll run at, with something like the number of people who’ll be using it, rather than a developer’s machine. Venue wifi is its own genre of problem and it is always worse than described. If it can be tested on site, test it on site, and do it far enough out that there’s time to respond.

Freeze before the day. Deployments stop at an agreed point, usually a clear day or two before. The instinct to keep improving right up to the deadline is understandable and it’s how good work gets broken at the last moment. A small imperfection you’ve tested is worth considerably more than an improvement you haven’t.

The date that isn’t real

One caution, because it costs money in the other direction.

Delivering to a fixed deadline takes discipline and involves trade-offs. Applying it to a deadline that’s actually flexible means paying the price of reduced scope, compressed testing and weekend work for no reason at all. If a date can move by a fortnight without commercial consequence, say so, and the same budget buys a better result.

So the honest question at the start of any tightly dated project isn’t “can you hit Thursday.” Nearly always, yes, with the right decisions made early enough. It’s “what does Thursday actually cost, and is it worth it?” Sometimes the answer is obviously yes, because the media spend dwarfs the build. Sometimes it turns out Thursday was a preference that had hardened into a fact somewhere along the way, and everyone is relieved to find out.

Simon Paul is a Business Solutions and Technology Specialist at Code Brewery who’s spent 25+ years turning business ideas into software that actually earns its keep. He’s delivered enough immovable dates to know the venue wifi is always worse than described. Reach out to Simon to talk through a project with a date attached.