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.
SCOPE 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?”
REQUIREMENTS MANAGEMENT PLAN
“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!
