Project Management — Frequently Asked Questions
Practical answers on running delivery — why projects run late, estimating honestly, what to do when the date is imposed, managing stakeholders and the reporting habit that hides trouble.
Schedule#
Why do projects run late?#
Rarely one large event. Almost always an accumulation: work that was 90% done for three weeks, integration deferred, a decision that took nine days, an environment that was not ready, and a series of individually reasonable judgements that the team would catch up next sprint.
None of those is escalated on its own, because none of them feels significant. The gap becomes visible only when it is too large to absorb.
How do we estimate more accurately?#
Break work down until the pieces are small enough to be understood concretely — small items are wrong by less, and the error partly cancels rather than compounding.
Then track estimated against actual for a few months. Most teams discover a consistent multiplier, and applying it honestly beats any estimating technique. What ruins this is estimates being used to judge people: at that point they become negotiation and the information disappears.
The date was fixed before we were asked. What now?#
Say clearly, once, in writing, what is achievable by that date and what is not — then let the sponsor decide what to cut. That converts an impossible commitment into a scope decision, which is theirs to make.
What does not work is accepting silently and hoping. The date arrives regardless, and the conversation happens anyway, just later and with less room.
Should we add buffer?#
Yes, visibly, at the project level rather than hidden inside each task. Buffer hidden in tasks gets consumed by the work expanding to fill it; buffer held centrally and managed openly can be allocated where it is actually needed and reported honestly.
Reporting#
What is wrong with our status reports?#
If they have been green for months and the project is now late, the reporting was measuring optimism. Common causes: progress measured by effort spent rather than accepted work, "90% done" that never becomes 100%, and each layer of the chain softening bad news slightly on the way up.
Ask one question at every review: what would have to be true for us to miss the date, and how would we know?
How do we report bad news well?#
Early, with specifics, and with options. "We will miss by three weeks; here are three ways to respond and what each costs" is a professional contribution. "Amber" with no explanation invites the sponsor to assume the worst or, more often, to ignore it.
Bad news early is the single most valuable thing a project manager provides. It preserves the sponsor's ability to act.
How much reporting is enough?#
Enough that anyone can answer: are we on track, what is blocked, what changed, and what needs a decision. If the report takes a day to produce, it is consuming the capacity that should be spent removing blockers.
Scope and stakeholders#
How do we stop scope creep?#
One route in for requests, an assessment that includes what the change displaces, and a cumulative position reported at every review.
Creep is rarely formal requests. It arrives as small clarifications that expand behaviour, and as conversations between a stakeholder and a developer that nobody records. See change management.
A senior stakeholder keeps going directly to the team. How do we handle it?#
Do not fight it socially; make it structurally harmless. Ask the team to route anything that changes work into the request process, and give the stakeholder a fast, visible path so the process is not the slow option.
If small changes clear in a day, people use the process. If it takes three weeks, they will always go around it — and you will not be able to see it.
The sponsor is disengaged. What do we do?#
Treat it as a project risk with an owner, because it is one. Reduce the ask — decisions and escalations only, in fifteen minutes — and be explicit about the consequence: unmade decisions become delays, and the delay belongs to the project, not to them.
If it continues, it is worth asking whether this project still has organisational backing. That is uncomfortable and better established now than in month eight.
Method#
Waterfall or agile?#
Match the uncertainty. Work with well-understood requirements and heavy verification suits a plan-driven approach. Work where the requirement genuinely emerges suits iteration.
Most real projects are a hybrid, and that is fine when chosen deliberately. What fails is adopting the vocabulary of one while retaining the operating model of the other — see Agile.
Do we still need a project manager on an agile team?#
The coordination, dependency management, escalation and stakeholder work do not disappear; they are just distributed differently. On a single team with a strong product owner, a dedicated PM may be unnecessary. Across several teams with external dependencies, someone is doing that job whether or not it has a title.
What is the most useful thing a project manager does?#
Removes blockers and tells the truth early. Everything else — plans, reports, meetings — is instrumentation. A project manager whose team is never waiting on anything, and whose sponsor is never surprised, is doing the job regardless of what the plan looks like.
How do we close a project properly?#
Compare outcomes against the charter's success criteria, honestly. Record what shipped, what did not, and what is being handed over to whom. Run lessons learned with actions that edit a template or a process rather than exhort people.
Projects that close with congratulations and no assessment teach the organisation nothing about which projects to fund next.