Project delays never happen overnight. They pile up one weekly meeting at a time

On a 12-month project, the most dangerous thing usually isn’t a big blow-up on one particular day. It’s the weekly meeting where someone says, week after week: “A bit of trouble this week, we’ll catch up next week.”

Catching up, catching up, and then a milestone has slipped past.

One of our projects nearly missed a milestone exactly this way. We saved it by switching weekly check-ins to daily ones. This post covers what the risk list should watch, which three milestones the schedule should watch, and the two things to do first when a delay is coming.

1. The project risk list: two kinds show up most

A risk list should cover every area, but in practice two kinds cause most of the trouble:

• Schedule risk: scope creep, so the work keeps growing; not enough people to keep up; a business owner who won’t engage, who doesn’t make the calls they should and doesn’t assign the people they should
• Cost risk: requirement changes, so finished work has to be redone; actual demands drifting from the blueprint, so what was signed and what is wanted now are no longer the same thing

Both kinds of risk often trace back to the same root: requirements. If requirements aren’t under control, the schedule slips and the cost goes up. That’s why the last few posts kept saying that criteria and requirements must be written down and signed at kickoff and in the blueprint phase.

2. Watch only three schedule milestones, and split the go-live tracker into six layers

A project usually runs in six stages: kickoff, blueprint design, system build, go-live preparation, go-live trial run, and acceptance. The trial run can also be split into two phases: the business process first, then automation.

On the schedule I watch only three milestones: blueprint design, functions built, trial go-live. All three are handovers: the blueprint gets signed, the functions are handed to testing, and go-live is handed to the floor. Once you pass one, it’s hard to go back, so you need to see before each milestone whether you’ll make it on time.

As go-live approaches, the work suddenly multiplies. We manage it with a go-live tracker, split into six layers:

• Data: the PFEP sheet, initial warehouse data, storage location mapping, a count of existing inventory
• Planning: when production orders cut over to the new system
• People: operating training for in-house warehouse staff and outside logistics staff
• Suppliers: teaching suppliers to prepare goods, print documents and ship in the system, and to label parts
• Systems: surrounding systems such as MES, SRM and QMS going live in step
• Hardware: network access, plus testing printers and handheld terminals together with the system

Every item has an owner and a date, with progress and status written down, and the weekly meeting walks through this tracker.

The tracker has to go with a communication rhythm. Ours looked like this:

• Daily: the project team meets once to collect the day’s implementation issues
• Weekly: the weekly meeting covers the week’s work summary, open issues, next week’s plan and resource coordination
• As needed: topic meetings that work one problem through to the end; phase reports that present results to leadership and the steering committee
• Weekly or monthly: an email update so people who don’t attend still know where things stand

How do you spot a delay early? Look at the tracker: if the same item’s status hasn’t moved for two weeks in a row, that’s the signal.

3. When the project is going to slip: warn in writing first, then change the rhythm

Once you see a delay coming, the first thing is a written warning: put it in writing and escalate it to the business side’s top manager so they know. This isn’t just reporting; it also puts the risk and the responsibility out in the open. A verbal heads-up, once something goes wrong, counts for nothing.

The second thing is to change the rhythm. This is how we recovered that time:

• Weekly check-ins became daily check-ins: problems surface the same day and get handled the same day, instead of piling up for a week
• Reporting progress together: everyone gathers and reports progress every day
• More resources: add people where people are short
• Leaders on site: leadership comes to the floor to keep watch

In the end, the milestone held.

---

When you warn about a delay, do you just mention it, or do you put it in writing?