Project Management Methodology

Back to Project Mechanics

Most project failures I've been close enough to study had nothing to do with the code. They traced back to one of three causes, usually in combination. Nobody knew who made the final call, so decisions were made in the wrong rooms and nobody owned the result. The project started toward one destination and arrived somewhere else, because requirements moved without anyone deciding to move them. Or the team built what was specified and never found out whether it worked, because success was declared at delivery instead of at impact.

Those three failure modes are ownership ambiguity, scope drift and feedback failure. Project Mechanics is a framework built to prevent them. It gives every project the same life cycle, names who owns each decision, and supplies the practices on the other pages for the moments where projects usually go wrong. It works the same whether the work is planned in phases or delivered in sprints.

When to use this

Use it when setting up any project or program, before the first sprint is planned.
Use it to put every project in a portfolio on the same states, so leadership can compare them.
Use it to diagnose a troubled project: name the failure mode it's heading toward, then go to the practice that addresses it.
It isn't a replacement for Scrum, Kanban or a PMI-style plan. It sits underneath whichever one the team uses and supplies the states, the owners and the checkpoints that those methods assume.

Principles

Project management is part mechanics, part art. The mechanics are objective and teachable: states, gates, checkpoints, the release clock. The art is the communication with the people paying for the work, the people doing it and the people governing it. A team with good mechanics and no art follows the process into a failed project. A team with art and no mechanics depends on whoever happens to be in the room.

Name the failure mode, then act on it. Ownership ambiguity, scope drift and feedback failure each have different symptoms and different fixes. Once you can say which one a project is heading toward, you know where to intervene.

Every project has three constituencies. The business owner pays for the work and defines success. The team does the work and owns the accuracy of its technical judgment. Leadership sets priorities, allocates people and holds release authority. A decision that skips one of them comes back later as a conflict.

The same states for every project. When every project moves through the same life cycle, a portfolio becomes readable. Leadership can see what's waiting for approval, what's consuming people and what has stalled.

Handoffs are where Waterfall hides. A team can run two-week sprints and still pass work along as a chain of documents: requirements to developers, code to QA, a release to the business. Context leaks at each handoff, and misunderstandings surface late. Keep the people who understand the problem in a continuing conversation with the people solving it.

Maintain the process; don't keep rebuilding it. Overhauling how a team works every quarter burns the trust and habits that made the process worth having. Patch what's leaking, and change it deliberately when the evidence says the conditions have changed.

The practice

Move every project through the life cycle

Every project is in exactly one of seven states. The states don't change with the delivery method. What changes is what each state looks like and what evidence moves a project to the next one.

State	In iterative delivery	Evidence to move on	Who decides
1. Future	An idea on the roadmap or backlog. No team, no time tracked.	A sponsor agrees to fund a definition.	Sponsor
2. Definition	Discovery and refinement by a small team, with time tracked.	A proposal with a measurable outcome and a quick estimate with a confidence range.	Delivery lead
3. Proposed	A commitment decision. All work stops while it waits.	The sponsor approves before the proposal's expiration date.	Sponsor
4. Approved	Priority set, team formed, backlog ordered.	The kickoff is held and the release cadence is agreed.	Delivery lead
5. In Progress	Sprints, with each release run on the release clock.	The planned scope is released, or the business owner accepts the remaining scope as out.	Business owner
6. Complete	Delivered and closed, then the outcome is reviewed on a scheduled date.	The outcome review is held and its result recorded.	Business owner
7. Cancelled	Dropped at any state.	The reason is recorded, and people are reassigned.	Sponsor

A few rules make the states work:

Start tracking time when a project enters Definition, not when development starts. Definition work is real cost, and leaving it out makes every project look cheaper than it was.
Give every proposal an expiration date. A proposal that sits in Proposed for months is describing a world that has moved on; when it expires, it goes back to Definition or to Cancelled.
Stop all work while a project is Proposed. Work that continues without approval is how scope drift starts before the project officially exists.
Handle scope changes in progress through backlog reordering with the product owner, not quiet additions. Anything that displaces planned work is a decision someone owns.
Split Complete into its two halves. Close the project when it's delivered: final invoice, time code closed, team released. Then hold the outcome review on the date set at approval. Skipping the second half is feedback failure by design.
Cancel deliberately. A project that everyone has stopped working on but nobody has cancelled still holds people and attention.

Report status by state

Have every project report three things: its current state, the date it entered that state, and the next piece of evidence it needs to move on. Leadership can then compare projects on the same terms instead of translating each team's status format.
Ask about any project that has stayed in one state much longer than similar projects. I'd rather have that conversation early than discover a stalled project through a missed date.
Keep red-amber-green colors as a summary if the organization expects them, but never let them replace the state and the missing evidence. A color tells leadership something is wrong; the state tells them where.

Hold the kickoff

When a project reaches Approved, the delivery lead holds a kickoff with the business owner, the team and anyone with release authority. Cover these, in this order:

The outcome, how it will be measured, and the date of the outcome review.
What the business owner expects: the deliverables and the journey, meaning how they want to be involved along the way.
What the team expects from the business owner and from the delivery lead.
The project rules: the definition of done, the release cadence, and how scope changes are decided.
Who owns which decision, written down. This is the cheapest moment you'll ever have to prevent ownership ambiguity.
The resources available, and the constraints on them.
The mechanics: the release clock checkpoints, how status is reported, and where decisions are recorded.

Keep the work a conversation

Check how work actually moves, not how the process says it moves. If requirements reach developers only as documents, if QA first sees a change when it's finished, or if the business first sees the system at release, the team has rebuilt the handoff chain. Bring the business owner into refinement, plan acceptance evidence with QA before development starts, and show working software to the business before the release decision.

Decision aids

Diagnosing a troubled project

Use this when a project feels wrong and nobody can say why.

Failure mode	What you'll notice	First move	Practice
Ownership ambiguity	Decisions get reopened; escalations go nowhere; "we decided as a team"	Write down who owns each open decision, and get each owner to accept it	Leadership; Sprint & Release Management
Scope drift	Work appears that nobody remembers approving; the destination has quietly changed	Trace every backlog item to the outcome; question the ones that trace to nothing	Product Management
Feedback failure	Success declared at deployment; no baseline; no outcome review scheduled	Set the outcome measure and its baseline, and schedule the review	Product Management

Where to go next

If the problem is…	Go to
What to build, and whether it worked	Product Management
What ships in a release, and when	Sprint & Release Management
Running the project day to day	Project Management
Choosing among projects, or running several as one program	Portfolio & Program Management
The people side	Leadership, Conflict Management, Change Management

Who owns what

Constituency	Who it usually is	What it owns
Business owner	The client, or the internal owner who pays for the work	The outcome, the business risk, and what counts as success
Team	Developers, QA, analysts, the delivery lead	The work, and the accuracy of its technical judgment
Leadership	The sponsor, management, release authority	Priorities, people, funding decisions and release authority

In a traditional structure these are the client, the staff and management. The delivery lead is the project manager under another name: the person who runs the mechanics and makes sure the three constituencies hear each other.

Signs it's going wrong

Nobody can say who makes the final call on scope or release. That's ownership ambiguity, and it gets worse under pressure.
Projects sit in Proposed for months, or work continues while they wait. Proposals need expiration dates and a hard stop.
Every project reports status in its own terms. Leadership can't compare them, so the loudest project gets attention.
The project closes at deployment and nobody holds the outcome review. That's feedback failure, built into the plan.
Requirements, code and releases move between people as documents with no conversation. The handoff chain is back.
The process is overhauled every quarter. Nothing stays in place long enough to learn whether it worked.

Ownership Ambiguity, Scope Drift, Feedback Failure, Accountability, Authority, Business Owner, Product Owner, Delivery Lead, Outcome, Definition of Done, Project Charter, Release Clock, Portfolio, Program, Sponsor, Escalation

Where this came from

Accountability and Authority: Walking the Tightrope: ownership ambiguity, and keeping authority and accountability in the same hands.
From Features to Outcomes: Keeping Your Eye on the Prize: feedback failure, and why Complete needs an outcome review.
Isolated Development Agents: Reinventing Waterfall With AI: handoffs as the place Waterfall survives inside iterative teams.
The Beaver Builds a Pond: maintaining a process instead of rebuilding it.