Scope Management vs. Requirements Management

I find there’s a lot of confusion on the difference between scope and requirements. This is true in a class setting, but I also find it true in the workplace. Because of this confusion, important deliverables like a Scope Management Plan or Requirements Management Plan often get overlooked. After all, why would you bother going to the trouble to create documents when the distinctions between concepts are fuzzy? Isn’t it easier to just dive into requirements gathering and push right on with your project?

It doesn’t help that the PMBoK isn’t exactly the easiest read, ever. Neither does it help that if you look in the PMBoK, you’ll find THREE definitions for scope, in addition to a definition for requirements. It’s not surprising that there’s a lot of confusion.

Let’s start with those definitions.

Scope: The sum of the products, services and results to be provided as a project. See also project scope and product scope.

Product Scope: The features and functions that characterize a product, service or result.

Project Scope: The work performed to deliver a product, service or result with the specified features and functions.

Requirement: A condition or capability that is required to be present in a product, service or result to satisfy a contract or other formally imposed specification.

Wow, those are pretty fussy. For our purposes, let’s just worry about project scope and requirements. Project scope, in its super-simplest definition, is composed of ACTIONS. These are things that you will do to build the product or service you’re making. It’s work. Requirements, on the other hand, are features. They’re THINGS that you intend to build. So right away, when we look at project scope and requirements we can see that one is made of verbs and the other is made of nouns.

But I think we can get a bit better with our definitions.

I think the best way to look at requirements are to view them as “ideas made form”. Of course, this perspective opens a whole can of worms about the nature of ideas. It’s important we do that though, or we can’t really understand the underlying issues that call for the existence of a Requirements Management Plan.

We all have ideas. But what happens when you try to articulate one to someone so they can write it down? Often the words we use fail to give our idea justice. If you think of a tree, for example, you might in your head picture a lush evergreen standing in the middle of a snowy field. If you ask someone else to draw “a tree”, though, they’ll be just as likely to create a maple, or an oak or even a stout magnolia denuded of branches. Ideas are incredibly easy to misinterpret, even when we do our best to be super precise.

I demonstrated this concept in my class this week. I gave each of my students a different ambiguous image on a card. They got into pairs and, using only their words, had to describe the image clearly enough so their partner could draw it. On the left, you can see the images I provided. On the right are my students’ renditions. As you can see, some of my students’ descriptive and interpretive skills are pretty amazing! However, while many of these attempts were pretty close, nobody was able to create a perfect match.


If ideas are so challenging to communicate, then, doesn’t that put a project manager at a serious disadvantage where it comes to developing requirements? You bet it does. Now, the PM will have help – there will be subject matter experts and business analysts on the team to help make the requirements gathering process a lot easier. But even with the smartest, most language-savvy team, the process will still be very error-prone. As with any job that involves multiple people, mistakes can create additional problems, such as interpersonal disputes and conflict, which can cause even further delays.

Maybe, instead of worrying about the nitty-gritty of the requirements (since there will be people to take care of that anyway), the project manager could step in and think about the sorts of problems that could arise around requirements and deal with those!

Before we look at that, let’s talk real quick about project scope. I mentioned before that we could say this captures all the work that happens on a project, as measured in time and cost. That’s a nice tidy definition and all, but it’s a bit hard to articulate when you’re still in the beginning stages of a project. Unless you have a crystal ball, you don’t really know what all that work will look like.

Now, you could smack yourself repeatedly in the head with a lead pipe, hoping to awaken some latent precognitive abilities. But, just as with requirements, it might be a lot less painful to think about problems that might occur around your project scope first, and deal with them…once they’re out of the way, you can go into more detail.

Below are two documents that attempt to address all of the issues outlined above. These are the Scope Management Plan and the Requirements Management Plan.


“What steps will we need to take to prepare a really good project scope statement?”

“Who do we need to involve, and what steps should we take to prepare a robust Work Breakdown Structure?”

“How will we maintain and approve our Work Breakdown Structure?”

“What should formal acceptance look like for the finished things that we make?”

“How will we deal with change requests to the work we decide we need to do, once it gets underway?”


“How will our we plan, track and report our requirements-related work?”

“How will we prioritize our requirements? They can’t all be equally important!”

“How will we handle changes to our requirements, corrections to requirements we misinterpreted, or new requirements we missed during earlier stages of the project?”

“What measurements should we use to make sure we’re realizing our requirements correctly?”

“When we finish making something, how will we be able to tell that finished piece matches up with an existing requirement?”


You might notice that the above two documents have absolutely nothing to do with the actual scope or requirements that are found on a project. Instead, the Scope and Requirements Management Plans help give a project team a good, solid foundation on which to do their work. No project is ever conflict-free, but hopefully you can see how good planning can help make a lot of unnecessary problems just go away.

A final note, I don’t see the PMBoK as being the be-all and end-all of project management approaches. But I have to give the PMI a lot of credit. The two documents I’ve described above aren’t meant to waste time. These are genuine, roll-up-your-sleeves problem-preventers that can save you and your team a lot of trouble.

What do you think? Do you regularly prepare Scope and Requirements Management Plans on your projects? Do you think they’re time-wasters and you’d rather skip to the good stuff? Shout out your opinion in the comments below!

Enhanced by Zemanta
I’m a professor of project management at the college where I work. My students continually amaze me with their insights, passion and all-around awesomeness. I figure they deserve access to more answers than I can give them by myself. This site is for them.
  • John J. Philip

    Hey Geoff, great article! They’re absolutely not time wasters. The real waste happens if you don’t create those plans 🙂

    Would be great if you can expand these ideas in a different post and perhaps include some sample scope vs. requirement plans to clearly see the differences.

  • Hey, great idea! If there’s demand, I might put together some templates and give them away right here! 🙂

  • CaitlinSmall

    Once it is laid out before me in simple terms as you have done, it seems silly that I was confused before. I can also see now, why it is necessary to develop these plans; so that when the project “begins”, there will be boundaries and guidelines for the actual project plans.Thanks Geoff!

  • The PMI throws a lot of stuff at you so it’s easy to get confused. It’s not silly at all! But you got it. That’s the point of all this stuff – it’s to help get you organized and answer important questions. And you’re most welcome, Caitlin! 🙂

  • Alexey Goryansky

    Doesn’t scope management include requirements management?

  • Hey, Alexey! Yes, the scope management knowledge area of the PMBoK does include requirements management. The documents above are one step below that (inside the overall scope management knowledge area). At this level, requirements management and scope management get separated out and each treated with their own artifact. Does that help clarify?

  • Alexey Goryansky

    Hi, Crane! Thank you for the answer and no, it doesn’t clarify the root cause. It just state the known fact again. To my mind Requirements MP should be included into Scope MP. But yes, I’m taking into account that in terms of PMBoK these are different plans )

  • Hey, Alexey. I’m not quite sure how to answer your question. It may be that you’re confusing “scope management” as a knowledge area (large and broad across the entire project lifecycle) and the “scope management plan” which is a one-off document created early on that addresses how you will manage scope on your project. Both the scope management plan and the requirements management plan definitely fall together within “scope management” the knowledge area.

    Note, though, that planning how you will address requirements is not the same thing as planning how you will address scope. Scope covers the breadth of all work the be done across the entire project, and requirements are specific to the thing or things that your project creates. It’s important to think through both. However, as long as you address both, you can do that within one document or two – it doesn’t really matter.

  • Alexey Goryansky

    Requirements to be implemented is a part of the scope, right? And Yes, scope includes much more then requirements only. And Yes, not all requirements issued are approved to be included in the scope. But if requirements are included into the scope, why Requirements Management Plan is not included in Scope Management Plan then? That is confusing me ) And I still hear no reasonable explanation ))

  • It sounds to me like you have most of the pieces. You said in your last comment you recognize that requirements and scope are not the same thing (one is bigger than the other). Take another look in the pink shaded areas in the article above. If you can recognize that these are two separate sets of questions then you will see why scope and requirements are treated separately. One set of questions pertains specifically to all project scope. One set of questions pertains to requirements only. The reason for separation is to keep everyone clear and focused. If you jumble everything together it’s likely people will become confused.

    You *could* create a scope management plan that addresses all the scope management questions and then the requirements management questions, but you’d have to *clearly* separate them within the document.

  • Alexey Goryansky

    OK, Geoff, Let’s things going their own ways )Thanks for a discussion!

  • PM-by-PM

    Hi Geoff, I have rarerly prepare a SMP or a RMP. Usually the organizational procuedures and guidelines are taken at the project approach. IF required some taloring can be done.

    Praveen Malik

  • david

    Please do!

  • Ashley Wolf

    Yes yes, please do so!

Real Time Analytics


My name is Geoff. I write about project management pretty regularly. From time to time, I also make tools and templates to give away.

You can keep on top of these freebies in one of two FREE ways:


Subscribe to my RSS feed. Every time I publish an article, it will magically appear in your reader.


Join my community. A couple times a month, you'll get a digest of my latest articles. You ALSO get my FREE ebook, Nine Destructive Behaviours.

Either way, you'll never miss a post! How cool is that? (Psst...if you'd rather just hide me, click the tab again. No one has to know.)