Plan Scope Management Before You Start Collecting Requirements
Six weeks of workshops have produced four hundred requirement statements. They are genuine, they came from the right people, and the team now cannot do anything with them, because nobody agreed in advance how they would be prioritised, who was entitled to add one, what would make a requirement approved, or when the collecting would stop. The material is real and the machinery for turning it into a scope is missing.
Planning how scope will be managed is the work that supplies that machinery, and Section 2.2.2 of the PMBOK® Guide Eighth Edition places it ahead of the collecting for a practical reason: the rules change what you gather. A team that knows requirements will be prioritised against operational impact asks different questions in the workshop from a team that will sort them later by whoever shouts.
The questions the plan settles
Who may contribute a requirement. On a project with several user communities, this is the difference between a manageable set and an open inbox. It does not mean excluding people; it means knowing whose statements enter the process directly and whose are represented by somebody, and saying so before the first workshop rather than declining a request in month four.
How requirements will be prioritised, and by whom. Any scheme is better than none, and the important part is naming the person or group who applies it. Where prioritisation is an activity with no owner, it is done implicitly by the sequence in which things are built, which is a decision taken by a developer on a Tuesday.
What approved means. A requirement is approved when a named person has agreed it, in a recorded form, at a stated level of detail. Without that, the project has a document that some people consider a wish list and others consider a commitment, and the two groups discover their disagreement at acceptance.
How change will work afterwards. The route for a new requirement arriving in month seven is worth agreeing in month one, when nobody has a stake in the answer. Agreed late, the route is designed in the middle of an argument about a specific change, and it will carry the shape of that argument for the rest of the project.
What skipping it costs
No stopping rule. Requirements collection expands to fill whatever time it is given, because there is always one more stakeholder and always another edge case. The plan is where the stopping condition lives: enough detail for this stage, from these groups, by this date, with a route for what arrives later. Teams without one usually stop when the schedule pressure becomes unbearable, which is the worst available moment.
No decider. When two requirements conflict, somebody has to choose, and a project that has not named that person in advance will escalate the conflict to whoever is most senior in the room. That produces decisions made on authority alone, by people without the operational detail, and it produces them slowly.
No traceability. Deciding at the start how a requirement will be linked to the work that delivers it and the test that proves it is cheap. Reconstructing those links afterwards, across several hundred items, is a programme of work in its own right, and it is usually attempted at the point where somebody asks which requirements the first release actually satisfies.
Eleven hundred requirements and no scheme
A defence contractor was integrating a new sensor suite onto an existing platform. Requirements came from four directions: the customer's technical authority, the platform design authority, the operators through a user group, and the support organisation that would maintain it. Collection ran for five months and produced about eleven hundred statements, which was not unreasonable for the scale of the work.
What had not been agreed was how they would be handled. There was no priority scheme, so everything arrived at equal weight. There was no single approving authority, so the technical authority and the design authority each believed their agreement was sufficient. And there was no stated level of detail, so the set contained both a performance requirement covering the entire detection function and eleven statements about the labelling of a single connector.
The consequences took about a year to work through. The first integration build was specified against the set as it stood, which meant the connector labelling was implemented with the same seriousness as the detection performance. Two requirements were found to be mutually exclusive at the point of test, eight months after both had been agreed by different authorities, and resolving the conflict cost a redesign of a mounting and a slipped trials window.
The recovery was a scope management plan written after the fact, which is how most organisations acquire one. Four weeks of work established a priority scheme against operational capability, a single approval route with the technical authority holding the final word, a stated hierarchy of detail, and a change route with a threshold on it. The eleven hundred statements were re-sorted against it, which took a further six weeks and removed about two hundred as duplicates or as design detail that was never a requirement at all.
Every one of those decisions could have been taken in an afternoon before the first workshop. None of them needed to know anything about the sensor.
Keeping it proportionate
Size the plan to the project. For most work it is a page: who contributes, how priority is decided and by whom, what approval looks like, how change is handled, and how far the breakdown will go. A large regulated programme needs more, and a small internal project needs less, but the questions are the same and the value comes from answering them rather than from the length of the document.
Adaptive work has the same plan under a different name. The working agreement about who owns the backlog, who may add to it, how items are ordered and what makes one ready and done is precisely this material. The team writes it in a different form and reviews it more often, and a team that has never written it down is in the same position as the contractor above, at a smaller scale.
For a PMP® candidate, what helps is seeing that the rules for handling scope precede the scope itself, so a situation describing conflicting or unmanageable requirements is worth tracing back to what was agreed before collection started. A response that begins prioritising a chaotic set has taken on the symptom without establishing who is entitled to decide. Situations where the requirements are sound and the process around them was never agreed come up often in a structured PMP exam preparation course.
Even mid-collection, the plan is still worth writing today. Four answers, half a page, circulated to the people whose agreement matters: who contributes, who prioritises, what approval means, and what happens to anything that arrives late. It will be contested, which is the point, and contesting it now costs a morning.
Interested in going further?
The work that prevents a scope crisis is done before anybody has a scope to argue about, which is why it is so often skipped. Omega's PMP® Exam Preparation works through scope definition as a governed process with owners and thresholds.
Planning how scope will be defined, approved and changed is set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A102: The PMBOK 8 Scope Performance Domain: What It Really Covers
A103: Requirements vs Scope: Why the Difference Matters
A104: Acceptance Criteria: The Small Detail That Prevents Big Arguments
A105: Scope Baseline Explained
A106: Product Backlog vs Project Scope
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
