From promise to plan.

That "how" is your strategy. And the schedule is just the strategy, written out in dates.

Type the activities before you've settled the strategy, and you build a beautiful schedule for the wrong plan. So let's do it in the right order.

The execution trap

You know the temptation. New project, so you open the software and start listing tasks. It feels productive.

It's the same trap we met in Week 4 — just one level up. Back then it was tool before strategy. Here it's activities before approach.

A detailed schedule built on an undecided strategy doesn't reduce your risk. It just automates your failure, faster.

Strategy, tactics, logistics

A real plan has three layers, and they stack in a strict order.

Strategy is the "what" — the game plan. Do we build the two wings in parallel, or finish one and hand it over early? Do we precast off-site, or pour in place?

Tactics are the "how" — the day-to-day steps that deliver the strategy.

Logistics is the "what do we need, and when" — the crews, cranes, materials and access that feed the tactics.

Here's why the order matters. Logistics sits at the base. Run out of rebar, or lose the crane for a week, and the day's tactics stop — and the strategy fails with them. You decide from the top, but the whole plan stands on the bottom.

The multiplier effect

This is the reason strategy deserves so much care.

A choice made at the start moves the project far more than any tweak you'll make later.

Imagine a tunnel. Drive it from one end, and you get one heading, one rate of progress. Decide — on day one — to drive it from both ends at once, and you've roughly halved the duration before a single metre is excavated.

No amount of daily task-juggling six months in will ever buy you that. The big levers are all pulled at the start. Strategic decisions compound; daily adjustments don't.

The feasibility trap

There's a difference between your project strategy and your technical strategy.

The project strategy is the goal and the delivery model — build in parallel, hand over in phases. The technical strategy is the specific method you'll use to get there — a particular precast system, a climbing formwork, a new ground-improvement technique.

And there's one rule you break at your peril: never pair a tight deadline with an unproven method.

If the method is new to you, prove it first — a trial pour, a mock-up, a test panel — while there's still time to change course. A trial that proves a method won't work isn't a failure. It just saved you from discovering that on the critical path.

Choosing between strategies

Usually there's more than one sensible way to build the job. So how do you choose — without it turning into the loudest voice in the room winning?

You run the options through a funnel.

First, generate freely. List every sensible approach, no judging yet. Then switch modes and judge hard.

Filter each option against four things: performance, cost, time and scope. Anything that fails a hard limit — safety, permits, the deadline — is out.

Rank what survives with a simple priority matrix: compare the options head to head, two at a time, and let the team vote. Not the most senior person — the team. It turns opinion into evidence, kills the politics, and leaves an audit trail you can defend later.

Finally, stress-test the front-runner with a quick SWOT — and for every weakness or threat you list, write the action that answers it. A risk you've named but not answered is just a worry.

Risk is not the same as threat

Speaking of risk — one distinction saves a lot of confusion.

A risk is a passive event. It has no intent. Rain, bad ground, a late delivery — probability, not malice.

A threat is an active actor, working against you on purpose. A claim-hungry subcontractor. A neighbour objecting to every permit.

You manage them differently. You can't negotiate with the weather, and you can't pour concrete over a lawsuit. Plan for both — but don't reach for the same tool for each.

For the risks themselves, you have four moves:

Reach for avoid first. Changing the plan so the risk simply can't happen — re-sequencing around the flood season — is almost always cheaper than fighting the risk once it's here.

When the cure is worse than the disease

Every strategy has side effects. The trick is spotting them before you commit.

Say you're behind, so you accelerate — more crews, longer shifts, work stacked on top of work. Speed goes up. But so does the error rate. Inspections start failing. Rework floods back in. And now you're further behind than when you started.

Here's the test: if a strategy's side effects are worse than the problem it solves, drop it. The cure must not be worse than the disease. A slower plan you can actually hold beats a fast one that collapses.

The human equation

One last thing — and it's the one the software can't do for you.

You can build the best schedule on the project. If the team and the stakeholders don't back it, it's worthless. A baseline nobody believes in is just a wall chart waiting to be ignored.

So when someone resists — a client rep, a functional manager — don't try to win with more data. That only hardens them. Ask instead:

"What would you need to see to support this plan?"

It stops the endless back-and-forth, shifts the burden onto them, and turns a fight into a checklist. Most resistance isn't about the schedule. It's about not being asked.

The charter tells you where to arrive. The strategy is how you'll get there. And the schedule — the thing we finally start building next week — is only ever as good as the thinking behind it.

Practical insight

The next time a charter lands on your desk, don't open the scheduling software.

Open a blank page and answer four questions first:

What's the smartest way to build this — in parallel, in phases, precast or in-situ? Is any method here unproven, and can I prove it before I commit? Which risks are events, and which are people? And who has to believe in this plan for it to survive?

Answer those, and the schedule almost writes itself. Skip them, and you'll be rescheduling all year.

Key takeaways

✔ A charter is a promise — what, when, how much. It isn't a schedule.
✔ The schedule is your strategy written out in dates — so settle the strategy first.
✔ Strategy, tactics and logistics stack in order; a collapse at the base fails everything above it.
✔ Strategic choices made at the start have far more leverage than any later tweak.
✔ Never pair a tight deadline with an unproven method — prove it first.
✔ Choose between options with a filter and a team vote, not the loudest voice.
✔ A risk is an event; a threat is an actor — and avoiding a risk beats fighting it.
✔ If a strategy's side effects are worse than the problem, drop it. The best schedule is worthless if nobody backs it.

What's coming next

In Week 5, we chose the method that fits the work. This week, we turned the charter into a validated strategy — the thinking the schedule will express.

Now we build it. Next week begins the real work: the step-by-step process of turning that strategy into a complete, working schedule — activity by activity, from a blank model to a plan you can run the project on.

The thinking is done. Time to build.