How to meet project deadlines
Deadlines are not missed in the last week. Slippage usually builds up from the first weeks but becomes visible when it is too late to fix. These practices make slippage visible early and buy time to react.
1. Estimate with the people doing the work
An estimate a manager gives on behalf of the team is a wish, not an estimate. Ask the people who will do the work, and agree what “done” includes.
2. Count working days on a calendar
Holidays, moved weekends and leave eat weeks. Durations in working days on a production calendar show at once that “two weeks” in May is not the same as “two weeks” in March.
3. Link work instead of typing dates
Typed dates don’t move when the work before them moves. Dependencies recalculate the schedule — and show the real end date. See “How to make a Gantt chart”.
4. Know your critical path
The project end date can be set by one or more chains of work — the critical path. Watch them first and speed them up before anything else. See “The critical path in plain words”.
5. Keep buffers where they matter
A buffer spread across every task usually gets used up (“work expands to fill the time available”). It is safer to keep slack at the end of a chain or before a key milestone, and to see how much is left.
6. Set milestones every 2–4 weeks
A milestone checks that the project is on track. Without milestones you learn about slippage at the end. Milestones should be checkable results — “prototype shown to the customer”, not “development 50% done”.
7. Record a baseline and compare with it
Without a baseline you cannot say whether the project is late: dates just get “refined”. Compare the forecast with the approved plan every week. See “Baseline and forecast”.
8. Explain slips, don’t just record them
“The milestone moved 5 days” is a fact. “The milestone moved 5 days because of a late delivery, here are the responses” is management. For every slip it matters which work caused it.
9. Manage change explicitly
New requirements without revisiting dates can lead to missed deadlines. Every scope change should come with “what will this move” and a decision on who accepts the consequences.
10. Keep risks and issues next to the plan
A delay often starts with an unresolved issue or a risk that fired. If an issue has an owner and a due date, and a risk is linked to the work it affects, the problem shows before it moves the dates. See “The project risk register”.
A short weekly checklist
- What on the critical path is late?
- Which milestones in the next month are at risk?
- Which issues have waited past their due date?
- Which red-zone risks have changed?
- Which scope changes appeared, and are their consequences agreed?
Where to run it
In Etapero dates follow dependencies and the production calendar, the critical path and work with little float are highlighted, slippage against the baseline shows on rows and milestones, and risks and issues sit next to the work they affect.