9.0 Project Management FAQ: Common Questions

9.0 Project Management FAQ: Common Questions
Chapter 9 Part of Project Management Essentials

Project Management FAQ

Almost every project question turns out to be one of about a dozen questions in different clothes. This page answers the ones that come up most, briefly, and points at the chapter that covers each properly.

New to this? Nothing here assumes you’ve read the rest. If you want the guide in order, start at Project Management Essentials; if a word is unfamiliar, the glossary has it in plain English.

In short

  • Most questions here have the same underlying answer: decide it earlier and write it down.
  • If you only fix one thing, name a sponsor who can decide between scope and date.
  • If you only measure one thing, count deliverables accepted rather than tasks closed.
  • Two more FAQ pages follow: one for people starting out, one of practical habits.
Six common project questions and which chapter answers each I have just been made project manager, what first — answered in 2.1 Project Initiation. How do I stop the scope growing — 3.1 Scope, then 6.2 Change. Everything is 90 percent done and we are still late — 6.1 Monitoring Deliverables. My team will not keep the tool up to date — 5.5 Task Management Tools. Should we be doing Agile — 5.4 Agile vs Waterfall. How do I tell them the date is going to slip — 6.3 Reporting Progress. THE QUESTION BEHIND THE QUESTION WHERE IT IS ACTUALLY ANSWERED “I’ve just been made project manager — what first?” 2.1 Project Initiation “How do I stop the scope growing?” 3.1 Scope, then 6.2 Change “Everything is 90% done and we’re still late.” 6.1 Monitoring Deliverables “My team won’t keep the tool up to date.” 5.5 Task Management Tools “Should we be doing Agile?” 5.4 Agile vs Waterfall “How do I tell them the date is going to slip?” 6.3 Reporting Progress Most project questions are really one of about a dozen questions wearing different clothes. Finding which one you are asking is usually most of the work — the answers are already written down.
If your question isn’t in the left column, it is probably a version of one that is. The answers below are the short forms; each links to the chapter with the working detail.

How do I stop the scope growing?

Put a cost on every request, out loud, at the moment it arrives. “That’s about two days — do we move the date or drop something?” This converts a favour, which is hard to refuse, into a decision, which belongs to the sponsor rather than to you.

The prevention is earlier: write down what the project is not doing, specifically the things a reasonable person might assume are included. More in 3.1 Scope and 6.2 Change Management.

Everything is “90% done” and we’re still late. What now?

Stop counting percentages and count things that are finished and accepted by somebody other than the person who built them. The 90% state is not dishonesty — percent complete is an estimate of remaining effort, and remaining effort is exactly what nobody can judge while stuck.

Then look at where items are piling up. It’s usually review or testing rather than building, which means adding another builder makes it worse. See 6.1 Monitoring Deliverables.

How much planning is enough?

Stop when more detail would not change any decision you are about to make. Concretely: plan the next few weeks in tasks, and the rest in rough blocks, refining as it approaches.

The two failures are symmetrical. Too little and you trade a week of thinking for a month of rework; too much and you produce a detailed twelve-month plan for work nobody has done before, then spend the project raising change requests against it. See 2.2 The Planning Phase.

My estimates are always wrong. How do I fix that?

Three things, in order of return. Break work into pieces small enough that the person estimating has done something similar before — anything over about two weeks is a guess. Estimate a range rather than a number, and say which end you would bet on. And record what things actually took, because measured history beats judgement within about two projects.

Also check you’re estimating in available hours rather than calendar days: a person at 50% availability does not finish a ten-day task in twenty. See 3.2 Creating a Schedule and 3.3 Resource Allocation.

My team won’t keep the tool up to date.

Almost always one of three causes, and none of them is laziness. Updating is slow — if changing a status takes four clicks it will happen weekly rather than when it changes. Updating changes nothing — if flagging something blocked produces no help, the behaviour extinguishes. Or there are two sources of truth, so the tool is optional and loses to the spreadsheet.

The fastest fix is the second one: unblock something the same day it gets flagged, visibly. See 5.5 Task Management Tools.

Should we be doing Agile?

Ask instead: can you deliver in usable slices, and is somebody available every week or two to react to what you build? If both are yes, iterating will find your mistakes far earlier. If half the thing is worth nothing, or the person who can react appears at milestones only, iteration mostly buys overhead.

Most real projects are hybrid — a fixed frame with iterative work inside it — and that’s a legitimate answer rather than indecision. See 5.4 Agile vs Waterfall.

How do I tell people the date is going to slip?

Early, first, and with options. Early because a slip a sponsor learns about a week late is two problems. First because hearing it from someone else turns a schedule problem into a trust problem. With options because “we’re going to be late” needs a five-day email thread, while “we can move two weeks, cut the reporting module, or add a contractor — here’s the cost of each, and my recommendation” takes five minutes.

Lead with it rather than burying it in paragraph four. See 6.3 Reporting Progress.

Nobody will give me a decision. What do I do?

Usually one of two problems. Either there is no named decider — in which case ask directly who chooses between date and scope, and treat a vague answer as a serious finding. Or the decision is being avoided because it is unpleasant, in which case make the cost of not deciding explicit and dated: “if I don’t have an answer by Friday, I’ll proceed on option two and the date moves by a week.”

Both are covered in 2.1 Initiation and 4.2 Stakeholder Management.

Do I need a certification to be a project manager?

No. Certifications help in some job markets and in organisations that use them as a filter, and they give you a shared vocabulary. They do not make anyone better at the parts that actually decide outcomes, which are noticing problems early and getting decisions made. See 10.2 Certifications.

How much of this applies if I’m not a project manager?

Most of it, and the highest-value parts are available to anyone doing the work. Flagging a blocker early with a specific consequence, naming the stakeholder nobody has mentioned, and asking “who else needs to know?” are all things that change project outcomes and require no authority whatsoever.

What this chapter covers

9.1

Questions from Beginners

The questions people ask in their first weeks running a project — including the ones they’re slightly embarrassed to ask.

9.2

Practical Advice

Small habits with disproportionate returns, and the things that reliably go wrong in real projects.

Terms used on this page

Scope creep
Work added after scope was agreed without a matching change to time or budget. Arrives as small reasonable requests, never as a demand. More →
Sponsor
The person who funds the project and decides trade-offs the team cannot. The answer to several questions on this page. More →
Percent complete
A self-reported estimate of how much of a task remains. Systematically optimistic near the end, which is where the 90% problem comes from. More →
Availability
The share of a person’s week genuinely free for project work. Plans built on 100% are always late. More →
Blocker
Anything preventing work continuing that the person doing it cannot resolve alone. Flagging one early is the highest-value act available to anyone on a project. More →
Hybrid approach
Running some parts of a project sequentially and others iteratively, deliberately. The usual real-world answer to “should we do Agile?” More →

Related reading

Project Management Glossary

Every term in this guide, defined in plain English with why it matters.

8.1 Traits of Successful Projects

The two-hour week-one checklist that prevents most of the questions above.

1.0 What Is Project Management?

The starting point, if you landed here first and want the whole thing in order.


Published on: 2025-07-30 Last updated on: 2026-07-27

Questions & answers

Have a question about this topic? Ask below — no sign-up needed. The team reviews and answers questions here.

No questions yet — be the first to ask.

Ask a question

We’ll send a one-time email to confirm your address. Questions appear after a quick review.