05Where the project manager's work went
PMBOK's ten knowledge areas traced to their place in Scrum, and what happens when nobody picks them up.
If Scrum redistributed project management, we should be able to trace each piece of it. PMBOK's knowledge areas provide the list. For each one, the questions are where it lives in Scrum, and what happens when nobody picks it up.
| Knowledge area | Where it lives in Scrum | Typical drift when it is dropped |
|---|---|---|
| Scope | Product Owner, Product Backlog, Product Goal | The backlog becomes a ticket queue with no goal; scope is whatever was asked for last |
| Schedule | Timeboxes, cadence, release forecasting | Sprints become two-week deadlines; nobody can say when the product will be usable |
| Quality | Definition of Done | "Done" means "coded"; testing and debt are pushed to later sprints |
| Risk | Short loops, a usable increment every sprint, backlog ordering | Increments are not truly usable, so risk is deferred exactly as in a waterfall project |
| Stakeholders | Product Owner, Sprint Review | The review becomes a demo to the team; real stakeholders stop attending |
| Communications | Transparency through artifacts and events | Events turn into status meetings for management |
| Resources | Self-managing, cross-functional team | Tasks are assigned from outside; specialists hand work to each other |
| Integration | Shared between Product Owner and Scrum Master, implicitly | Nobody owns the whole; the product loses coherence sprint after sprint |
| Cost | Largely outside Scrum | Ignored, or handled by a shadow project manager |
| Procurement | Outside Scrum | Contracts and suppliers are managed elsewhere, out of sync with the backlog |
Table 2 · PMBOK's ten knowledge areas, redistributed. The third column is the catalogue of symptoms examined in Part II.
Three observations follow from this table.
The redistribution is real. Most knowledge areas have a clear home in Scrum. A team that takes its Product Goal, its Definition of Done and its Sprint Review seriously covers scope, quality and stakeholders at least as well as a traditional project.
Integration is the weakest point. In PMBOK, one person is accountable for keeping the whole coherent. In Scrum, that accountability is spread between the Product Owner, who owns value, and the Scrum Master, who owns the effectiveness of the team. The Scrum Guide does not name an owner for the coherence of the technical whole. That gap is where architecture, dependencies and long-term trade-offs fall through.
Some areas are not covered at all. Cost and procurement sit largely outside Scrum, and so do multi-team dependencies and regulatory deliverables. Scrum is deliberately minimal and expects organisations to complete it. When they don't, a project manager reappears under another title, often a Scrum Master who in practice runs the project. The team then pretends the role does not exist, and both Scrum and project management are done badly.
The rest of this essay follows the third column of Table 2. Part II examines how each orphaned accountability decays, and why the decays reinforce one another.
Section takeaways
- Each PMBOK knowledge area has a destination in Scrum, except cost and procurement, which sit largely outside it.
- Integration is the most fragile: no single accountability owns the coherence of the technical whole.
- Where Scrum is silent and the organisation does not complete it, a shadow project manager appears.