Practical guidance for every phase of delivery — what to do, what to avoid, and the specific habit that makes each practice stick. No theory for theory's sake.
Most projects fail before the schedule exists, because nobody agreed what success looks like or who can say no.
If the objective cannot be stated as a measurable outcome with a date, the project has an activity list, not a goal. Force the sponsor to say what number moves and by when.
Do this: Draft: "Reduce order-to-cash cycle from 42 to 30 days by 31 March." Get the sponsor to sign it.
Avoid: Objectives like "improve efficiency" or "deliver the platform" — neither can be tested at closure.
Two sponsors means no sponsor. You need a single person who owns the business case, funds the work and breaks deadlocks within days rather than at the next steering committee.
Do this: Record the sponsor, the delegated approval limit and the escalation route in the charter.
Avoid: A committee as sponsor — decisions then queue behind the meeting calendar.
The person who can stop your project in week ten is usually identifiable in week one. Classify them and set an engagement cadence before you need something from them.
Do this: Build a stakeholder register with influence, interest, current stance and who owns the relationship.
Avoid: A distribution list masquerading as stakeholder analysis.
Exclusions prevent more scope creep than inclusions do. Anything a reasonable stakeholder might assume is included, and is not, belongs in the exclusions list.
Do this: Add a short "not included in this project" section to the charter and read it aloud at kickoff.
Avoid: Assuming silence at kickoff means agreement.
A plan is a model for making decisions, not a prediction. Detail it where the next 60 days are, and keep the rest coarse.
Build the work breakdown structure around nouns — the things being produced — then attach verbs. Activity-first plans miss whole deliverables such as training, data migration and hypercare.
Do this: Apply the 100% rule: the children of any WBS element must fully describe the parent, with nothing extra.
Avoid: Copying a task list from the last project without checking it against this project's deliverables.
Plan the imminent wave to task level and later waves to milestone level. Re-plan each wave as it approaches, when you finally have the information the estimate needed.
Do this: Keep tasks in the current wave at 8–80 hours so status is unambiguous.
Avoid: A 900-line schedule for an 18-month project baselined in week two.
A single-point estimate hides the risk. Three-point estimating (optimistic, most likely, pessimistic) makes the uncertainty visible and gives you a defensible contingency conversation.
Do this: Use (O + 4M + P) / 6 for the expected duration and log every assumption behind it.
Avoid: Padding individual tasks privately — the buffer disappears into Parkinson's law.
The critical path defines the shortest possible duration. Tasks with float can slip quietly; critical tasks cannot slip at all without moving the finish date.
Do this: Review the critical path weekly — it moves as actuals land — and staff it with your most reliable people.
Avoid: Treating the longest or most expensive workstream as the critical path by intuition.
Without a frozen baseline you cannot prove whether you are late; you only have a plan that keeps agreeing with reality. Change the baseline only through approved change control.
Do this: Save scope, schedule and cost baselines at approval, and report variance not just status.
Avoid: Silently re-baselining each month so the plan always looks green.
Delivery goes wrong quietly. Short feedback loops and binary completion rules surface problems while they are still cheap.
"Almost finished" is the most expensive status in project management. Every deliverable needs acceptance criteria agreed with the person who will accept it.
Do this: Use 0/50/100 or binary complete rules for progress rather than subjective percentages.
Avoid: Tasks that sit at 90% complete for three reporting cycles.
A 15-minute focused check on blockers beats a 60-minute round-robin narration of activity. Reserve detail for the risk and decision log, not the meeting.
Do this: Ask three questions: what changed, what is blocked, what decision do you need from me.
Avoid: Meetings where everyone reports and nobody decides.
Scope creep is rarely a big request; it is a series of small favours. Each change needs an impact assessment on scope, cost, schedule and risk before anyone says yes.
Do this: Log the request, size the impact, get the sponsor's written decision, then update the plan.
Avoid: Absorbing "tiny" additions to preserve goodwill.
When the schedule lives in three tools, the team follows the one that suits their argument. Nominate the authoritative artefact for scope, plan, risks and decisions.
Do this: Publish the location of each authoritative artefact in the communications plan.
Avoid: Reconciling spreadsheets emailed by workstream leads.
Risk management is a weekly habit. A register reviewed once at planning is documentation, not management.
"Resourcing" is not a risk. "Because the integration engineer is shared with Ops, API work may slip, delaying UAT by two weeks" can be owned, sized and mitigated.
Do this: Score probability and impact, name a single owner and set a review date for every risk.
Avoid: A register of one-word themes with no owners.
A RAID log keeps the four apart because they need different treatment: risks are mitigated, assumptions validated, issues resolved, dependencies negotiated.
Do this: Review the whole RAID log weekly and convert realised risks into issues explicitly.
Avoid: Letting an old assumption quietly become an unmanaged issue.
Contingency reserve covers identified risks and belongs to you; management reserve covers unknowns and belongs to the sponsor. Both should be explicit numbers.
Do this: Draw down contingency against named risks so consumption tells you something.
Avoid: Hidden buffers inside task estimates that no one can audit.
Defects found in UAT cost far more than defects prevented by peer review, definition of done and early integration. Plan the assurance activity, not just the testing.
Do this: Schedule review gates and entry/exit criteria per phase in the plan itself.
Avoid: A single test phase at the end as the only quality control.
You will spend the majority of your time communicating. Design it deliberately instead of defaulting to email volume.
Executives want decisions, exceptions and money; delivery teams want sequence and dependencies. The same status pack rarely serves both.
Do this: Write a one-page sponsor summary — status, decisions needed, top three risks — plus a detailed team view.
Avoid: Forwarding the 40-slide programme deck to everyone.
Escalation is a professional act when it arrives with analysis. Bring the problem, two viable options, your recommendation and the date the decision expires.
Do this: State the cost of delay explicitly so the decision competes properly for attention.
Avoid: Waiting until the slip is unrecoverable to protect a green status.
People sequence work better when they understand the constraint. Explain why a date matters and they will protect it themselves.
Do this: Restate the objective and the current critical path at each planning session.
Avoid: Issuing task lists without context and calling it delegation.
A decision that is not recorded will be relitigated. A short decision log with date, owner, rationale and alternatives considered saves weeks over a long project.
Do this: Publish decisions within 24 hours and reference them when the question returns.
Avoid: Relying on meeting memory or private chat threads.
Closure is where organisational learning is either captured or lost. It takes days and pays back for years.
Handing over the product is not the same as achieving the objective. Agree who tracks the benefit after closure and for how long.
Do this: Record the measurement owner, the metric and the review dates in the closure report.
Avoid: Closing on "all deliverables accepted" without checking the success measure.
The useful lessons are systemic — estimating bias, unclear ownership, late dependencies. Individuals only speak candidly when the session is about process.
Do this: Capture what to repeat, what to change, and one concrete owner per change action.
Avoid: A retrospective template filed with no action owners.
People and contracts drift into a long tail of unbilled support if you do not formally close them. Confirm handover to operations before the team disperses.
Do this: Complete contract closure, access removal and a signed operational handover checklist.
Avoid: An informal hypercare arrangement with no end date.
Each week: update actuals, re-check the critical path, review the top five risks, and confirm next week's owners. Most slippage is caught in this quarter of an hour.
If your sponsor summary does not fit on a page, you have not decided what matters. Status, decisions needed, top risks, money.
When a date looks impossible, list the conditions required for it to hold. The list becomes your assumption log and your negotiation script.
Give unknowns a fixed spike — two days, one deliverable, a decision at the end — instead of letting analysis expand until the deadline.
Confirm the date with the team that owes you the work, in their planning tool. A dependency you recorded alone is a wish.
Delivery quality falls when the PM only reacts. Block time to look two months ahead at risks nobody is raising yet.
Why it hurts: Status is reported to avoid difficult conversations, so the sponsor loses the chance to act while options are still cheap.
Instead: Report exceptions and trends, and make amber a normal, safe status to use.
Why it hurts: New people consume the time of the people who already know the work, so short-term throughput falls.
Instead: Fast-track independent work, reduce scope, or move the date with the sponsor.
Why it hurts: A populated Gantt or board can hide an unagreed scope and unowned risks.
Instead: Fix charter, WBS and RAID first; the tool then reflects a real plan.
Why it hurts: Zero slack turns every small variance into a queue and the queues compound.
Instead: Plan capacity at 70–80% for people carrying operational duties too.
Why it hurts: Feedback arrives after the money is spent, so rework is maximally expensive.
Instead: Sequence increments that can be reviewed, tested and accepted along the way.
Agree a measurable objective with a single accountable sponsor, decompose deliverables into a work breakdown structure, baseline scope, schedule and cost, review the critical path and RAID log weekly, control change through explicit decisions, and close with verified benefits and recorded lessons.
Focus on three habits: write acceptance criteria before work starts, run a weekly 15-minute plan-hygiene routine covering actuals, critical path and top risks, and escalate early with two options and a recommendation rather than a complaint.
Document exclusions in the charter, require every change to carry an impact assessment on scope, cost, schedule and risk, and record the sponsor's written decision before updating the baseline. Scope creep is usually a series of small unassessed favours rather than one large request.
Weekly for active delivery. Each risk should be written as cause, event and consequence, scored for probability and impact, and assigned to a single owner with a review date. Risks that materialise are converted to issues explicitly rather than left in the register.
Yes, with different artefacts. The objective, stakeholder analysis, definition of done, dependency management, risk cadence and lessons learned all still apply; the plan is expressed as a backlog and increments rather than a fixed baseline schedule.