ManagementSubsection
Frameworks
The two bodies of project management practice you will meet in a tender document, a certification requirement or a client’s process manual. They are not competitors: one is a body of knowledge describing what to think about, the other is a method prescribing who decides what. Both pages describe what the current edition actually says, and the comparison between them is the argument most people have without it.
What is inside
Every page in this group, with what each one covers.
Where to start
Elsewhere in the section
- ManagementIT project management is the set of decisions that turn an intention into shipped software: what to build, how to cut it into work that can actually be finished, how the team runs itself week to week, and how the result reaches users. This section covers 21 topics in five groups — product management, decomposition, methodologies, the release process and the formal frameworks — and each page gives the trade-off behind the choice rather than a summary for a certification exam.
- MethodologiesHow a team decides what to build next, in what order, and how it knows when something is done. Nine methodologies, from the two most teams actually run to the four that exist because one team stopped being enough. Each page describes what the framework actually defines — every ceremony, every role, every artefact — rather than summarising it, and says plainly where it stops working.
- DecompositionTurning something too big to start into pieces small enough to finish — and keeping the reason for each piece attached to it on the way down. Four topics covering the two traditions that rarely meet: work breakdown from project management, and user stories from product. They answer different questions, and knowing which one you are in stops most arguments about how detailed a plan should be.
Found this useful?
Share it with someone who is working on the same problem.