Let me tell you a story about my two friends. One is named Casey, the other is named K.C. Casey is obsessed with managing project scope, while K.C. is always harping on project requirements. Neither of them can agree on which is more important because, when described in a conversation, these two aspects sound virtually the same. According to Geoff Crane of The Papercut Project Manager, there are ways to distinguish scope management from requirements management; for they are indeed, separate entities.
To Have or To Do?
Crane describes the difference between scope and requirements as the difference between things and actions, or nouns and verbs.
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.
He goes further, saying that requirements are best understood as “ideas made form.” This makes perfect sense when you consider the example of my friends Casey and K.C. Without putting their names into written form, they are indistinguishable from one another. Every project manager faces this problem when trying to communicate about requirements. That’s why there are such people as business analysts and subject matter experts. Perhaps, argues Crane, the PM is the one who can tackle the kind of problems that arise around, and as a result of, project requirements.
Now, let’s take a closer look at the definition of scope. Describing it as action of the work of a project measured in time and cost is very fuzzy, and not at all helpful for planning and management. But perhaps, if we take a cue from our revised approach to requirements management, we could first tackle the problems surrounding project scope, such as “How will we maintain and approve our Work Breakdown Structure?” and “What steps [must be taken]to prepare a really good project scope statement?” Once we can make the distinction between requirements and scope, it is then only a matter of putting ideas on paper, even if it only pertains to defining what our scope and requirements are.
Read Geoff’s blog at: http://edge.papercutpm.com/scope-management-vs-requirements-management/