Project Management

Projects rarely fail on one big decision. They leak. An early estimate given as a single number turns into a promise. Scope grows one reasonable addition at a time, each solving a real problem the previous addition created. Risks everyone knew about never get written down, so nobody owns them. Status stays green until the week it turns red.

This practice covers running the work between approval and close: estimating when you know very little, planning in slices that each deliver something, holding the scope boundary, keeping risks visible, and closing in a way that makes the next estimate better. Release decisions have their own practice in Sprint & Release Management, and deciding what to build is in Product Management.

When to use this

• Use the estimating practice in the Definition state, when a sponsor wants a number and the requirements are still vague.
• Use the planning, scope and risk practices from Approved through In Progress.
• Use the closing practice when the project reaches Complete.
• The practices apply whether the team plans in phases or sprints. A team doing continuous flow still needs the estimate, the scope boundary and the risk list; it just revisits them on a calendar instead of at sprint boundaries.

Principles

An estimate is a range with a confidence level, not a date. A single number becomes a promise the moment it's spoken. A range with stated assumptions tells the sponsor how much is known and what would make the number move.

Every estimate has a revisit date. Early estimates are made in the fog on purpose. Committing to refine one within a few days, after a spike or a stakeholder review, is what makes it honest.

Fix the boundary before anyone simplifies. Decide what must stay true, such as which entities stay separate and which behaviors can't change, before the team chooses how to build. Implementation freedom starts inside that boundary; without one, a clean design can quietly redefine the problem.

Context is not scope. Background that explains a decision, constraints that limit the options, and ideas for later all help the team decide well. Only the work itself creates tasks.

An accepted limitation is a decision, not an unfinished feature request. When the product owner accepts "if it fails, retry," the team doesn't build a recovery subsystem to rescue them from that choice.

Each slice ships something useful. Plan work so the project can stop at any checkpoint with a net improvement. A plan whose value arrives only at the end is a bet, not a plan.

The practice

Estimate when you have almost nothing

1. Hold a 15-minute estimation interview. Ask what the primary outcome is and what done looks like; ask for three things that are definitely not included; ask who is available and for how many hours; ask which systems, vendors or technologies are involved; ask which date is driving the request and what is flexible.
2. Score three pillars from 1 to 5: Innovation (how novel the work is), Scope (how much is included) and People (who is doing it and how available they are). The scoring table is in Decision aids.
3. Size the work roughly in story points or a T-shirt size, convert it to person-days with the team's usual throughput, and multiply by the three pillar multipliers.
4. Turn that into three numbers at different confidence levels: P50, P70 and P90.
5. Quote the P70 with its range and assumptions: "P70: about 42 person-days, range 35 to 52, assuming one data source and partial availability." I quote P70 by default because P50 is a coin toss and P90 tends to get padded again by whoever hears it.
6. Name the biggest unknown and schedule a spike, a short time-boxed investigation, to retire it. Set the date when the estimate will be revisited, usually within three to five working days.

Plan in slices

1. Plan the first release in detail and keep the rest as a backlog ordered by outcome. Detail beyond the next release is usually rework later.
2. Cut the work into slices that each ship something independently useful: test coverage first, then a targeted refactor, then the redesign behind a feature flag. If the project stops after any slice, the business is still better off.
3. For any slice that rests on an assumption about the foundation, write an exit condition: "If the redesign requires changing the order schema, stop and re-plan." It turns a hidden risk into a decision point everyone can see.

Hold the scope boundary

1. Record the boundary before planning starts: what's in, at least three things that are out, what must stay true, and every accepted limitation.
2. Classify each new item that surfaces during the work as work, constraint, context, accepted limitation or adjacent idea. The table is in Decision aids. Only work creates tasks.
3. Write adjacent ideas down for the product owner instead of building them. A good idea and a feature that belongs in this release are two different decisions.
4. When a review finds a problem, fix the problem. Don't let each mitigation add a capability that needs its own mitigation. Risk shouldn't prescribe architecture.
5. Tell revisions from corrections. A changed requirement goes back to the product owner and may change the estimate. A task in the wrong order, a missing test fixture or a narrow verification step gets fixed in place, verified and left behind. Making people redo settled stages for small corrections teaches them to skip the process. I'd rather see a task in the wrong order fixed in place and verified than a full re-plan that nobody needed.

Keep a risk list that moves

1. Start the list from the risk checklist in Decision aids during Definition.
2. Give each risk an owner, a likelihood, an impact and the next action. A risk with no owner is a worry.
3. Review the list at every sprint boundary or every week. Retire risks that a spike or a release has answered, and add the ones the team has started mentioning in stand-ups.
4. Turn the largest unknowns into spikes rather than contingency. A day spent learning usually costs less than the buffer it replaces.

Report status with evidence

Report the project's state, what changed since the last report, what the evidence shows, and each open risk with a confidence level. "On track" without evidence is a guess, and a team that reports guesses spends its credibility the first time one is wrong. Release-week status follows the release clock in Sprint & Release Management.

Close so the next project estimates better

1. Get final acceptance against the definition of done, including the acceptance scenarios agreed at the start.
2. Release people deliberately and close the time code.
3. Compare actual effort with the P50. Record which pillar was misjudged, and update the team's multipliers. Calibration is the only way the next estimate improves.
4. Capture lessons as changes to the practice (a checklist item, a multiplier or a checkpoint) rather than a document nobody reopens.
5. Confirm the outcome review date with the business owner. Closing the project doesn't close the question of whether it worked.

Decision aids

Pillar scoring

Score each pillar, then multiply the base estimate by all three multipliers. These starting values should be replaced with the team's own once a few projects have been calibrated.

Confidence levels

A worked example: 20 story points at 0.75 person-days each is a base of 15 person-days. Innovation 3 (×1.2), Scope 4 (×1.6) and People 3 (×1.2) multiply to about 2.3, giving a P50 of about 35 person-days, a P70 of about 42 and a P90 of about 52.

Is this new item scope?

Risk checklist

Walk through these during Definition and again when scope changes:

• Integrations: is there a new vendor, a new authentication scheme or a rate limit?
• Data: what do you know about its quality, volume, latency and privacy rules?
• Compliance: which approvals, audits or change windows apply?
• Performance: which service levels and load profiles does it have to meet?
• Environments: do test and production match, and is the infrastructure ready?
• People: is there key-person risk, onboarding time or limited availability?
• External: does the work depend on another team's backlog?

Who owns what

Signs it's going wrong

• An estimate gets repeated as a single date. The range and assumptions were dropped somewhere between the team and the sponsor.
• Estimates never get revisited. The project is running on numbers made before anyone knew much.
• Every review adds a capability. Each mitigation is breeding a new requirement, and the feature is growing without anyone deciding to grow it.
• "While we're in there" items keep entering sprints. Adjacent ideas are bypassing the product owner.
• People fix things quietly instead of going back through a stage. The process punishes small corrections, so it's being routed around.
• The risk list hasn't changed in weeks. Nobody is reviewing it, because no project's risks hold still that long.
• Actuals are never compared with estimates. The next estimate will be exactly as wrong as this one.

Related terms

Confidence Level, Spike, Exit Condition, Accepted Limitation, Definition of Done, Outcome, Business Owner, Product Owner, Delivery Lead, Release Clock, Program, Sponsor

Where this came from

• Building a Quick Estimation Template When You Have Almost Nothing to Go On: the three pillars, multipliers, confidence levels, the estimation interview and calibration.
• DevSpark Dogfooding: Escaping the Scope-Creep Spiral: context is not scope, accepted limitations, boundaries before simplification, and revisions versus corrections.
• Evolution over Revolution: A Pragmatic Approach: slices that each ship something, and exit conditions on risky work.
• QA Was Always My Last Battle Front: acceptance agreed at the start so closing has something to measure against.