12

Scope is divided into two categories:

  • Product scope, which is the features and functions that characterize a product, service, or result, and;

  • Project scope, which is all the work needed to deliver a product, service, or result as defined in product scope.

Requirements specifies the capabilities, features or attributes of the project’s deliverables. Stakeholder needs, wants and wishes are analyzed to derive the requirements. Requirements are prioritized to determine which requirements will be included and excluded from the project.

Could someone please help me understand the difference between requirements and scope?

Would it be correct to say that scope is more of a macro-level concept and that requirements is more of micro-level concept?

10

I respectfully disagree with @DavidEspina. I don't think his answer is fundamentally wrong, but it doesn't match my answer.

During project initiation (or in some contract work, prior to project initiation) you determine the scope of work. This is the box inside which all requirements must fit. The project sponsor and project management team must strongly own the scope of work. Scope change is generally a bad thing and should be avoided. Update Scope is a project level agreement between sponsoring stakeholders. Changes to scope generally mean changes to cost, resources, quality and many other assumptions about the project. Changes to scope will usually mean that at least one of the stakeholders will need to reconsider involvement in the project.

An example: a few years ago, the Smithsonian museum was taken to court because the scope of work of the contract was to maintain museum artifacts and executives were using the facility and staff to repair personal vehicles. The latter work is clearly out of scope.

Requirements are generally outlined during project initiation, and refined during project design. Requirements are generally more granular than scope. Requirements should be owned and maintained by the project team including technical staff. It is normal for requirements to change (although the change must be strongly controlled & approved by appropriate stakeholders). Update Requirements are defined within the scope of work, and usually involve much more technical coordination.

An example: If the scope of work is to maintain museum artifacts then the requirements might address things like:

  • All artifacts will be cleaned monthly using best professional standards
  • Environmentally sensitive artifacts will be stored in a safe environment and weekly environmental monitoring will provide assurance that the environment has the right temperature/humdity/etc.
  • Any artifact removed from display will be tracked in asset management in accordance with procedure X.

Let me add a counterexample to address Mr. Espina's question.

If you are the shop steward at the Smithsonian, you should have a copy of the scope of work. if a manager approaches you and says:

  • We've just acquired a new, historically significant C-130; I'd like you to bring it in and perform the initial cleaning and maintenance to permit us to put this on display.

Then the logical answer is, "Sounds interesting - we will need to take it through the change control board/artifact accessession committee to make sure that we have the right priority and authorization to spend hours and supplies."

If the manager comes to you and says

  • My boss's personal Cessna has some engine trouble; you have the tools here in the shop and you've done similar work on museum artifacts. Would you mind coming in on the weekend and performing the maintenance?

The correct answer is, "I'm sorry, that is outside the scope of my work." (Roughly, that's one of the things that happened in the court case)

To craft a somewhat strained analogy, the scope of work is like the constitution. A good constitution is broad principles, strongly endorsed and rarely changing. Requirements are more like laws; they are more flexible and can change as society changes or technology changes.

  • 2
    Could there be scope to maintain museum artifacts if there was not a requirement for artifacts to be maintained? If no one cared about those artifacts, then there can be no scope to maintain it, right? I also don't understand why change is bad. – David Espina Mar 26 '15 at 12:51
  • 1
    Excellent questions; I'll revise in the answer rather than in comments. – Mark C. Wallace Mar 26 '15 at 12:52
  • Given the PMP process "5.2 Collect Requirements" is an input to "5.3 Define Scope", I don't think this definition is in alignment with PMI's definitions. – AjahnCharles Jan 20 '18 at 17:45
8

Product Specifications vs. Project Scope

One assumes that you're not looking for dictionary definitions. We have Merriam-Webster and Wikipedia for that. For practical differences, I would suggest the following perspective:

  • Requirements
    Requirements are the things your project needs built, and specifications are the instructions for what the things you want to build should look like when they're done. For example, a widget is specified as weighing 16 tons and having 27 sides, each covered in priceless unicorn hide with a winged fairy trapped in amber affixed to the apex of the widget. Now that is a detailed specification!
  • Scope
    Scope defines the boundaries of a project. For example, you will be building a unicorn-hide widget for sale to the powerful mythical-monster lobby, and therefore building widgets out of beaver pelts is out of scope, as is building products that appeal to PETA.

Scope is what will fit within your project. Requirements and specifications are about what to build, and how to build them. There is certainly intersection and interaction between the two axes, but they are fundamentally different things.

3

To put it simply: Requirements is what the customer needs, scope is what will be done to fulfill them.

2

Requirements are what is wanted or needed. Scope is what will be done or performed. I would not put one over the other because they are both leveled. For example, you can have a set of requirements that dictate product scope, then a lower level set of requirements that will dictate scope features of that product scope, and then even a lower set of requirements that will dictate the activities scope to develop the scope features that will become the product scope.

Example: Requirement: I require movement from point A to B. Scope: Train, Car, or bike. If car, I require comfortable seating for four and ability to carry a bunch of stuff. Scope: SUV, truck with full cab, wagon. If SUV, I require....

This continues until you have a set of requirements that will dictate several projects with project scope of both deliverable and activities.

1

I humbly suggest that for all practical purposes, it doesn't matter. They are often used interchangeably but with little precision. Different people will use the terms differently. It is risky to assume a definitive meaning without validating with the person using the term - or at least validate with the 'context'.

  • Actually they are not interchangeable. It is important to use same jargon for people to understand each other correctly. – Aasimon Apr 1 '15 at 8:01
  • 1
    for practical matters, i agree, but they are different in the scope of the pmp/pmi – wag2639 Jun 21 '17 at 6:16
1

i think that the difference is quite simple:

  • requirements are list of things customer expects about the project
  • scope is a subset of requirements that will actually be implemented by the project

scope (defined by project scope statement) should contain list of 'in' requirements - which will be shipped, and list of 'out' requirements, which, although known, are excluded from the current project (because of conflicts, constraints, etc.)

  • Anyone have an example of a scope based on a legacy application which is being replaced by a newer version. I know what the scope of this project is but don't know how to communicate it. Should I bullet point a document or should I have a spreadsheet. – user1049286 Feb 16 '18 at 9:27
1

Requirements are the expectations which the product need to fulfill. Requirements are collected from the customer, stakeholders and Sponsor.

There can be some requirements which are industry standards and needs to be met by the product.

Scope is determined by condensing the requirements, whatever is on the scope needs to be done, in case any requests from the customer which are not in scope the Project Manager can turn down those requests or suggest a change in the scope, so scope is very important to determine clearly what needs to be done.

1

I read many answers above and it seems all of us are taking the same thing again and again with minor differences or I would say using the terms interchangeably.

When it comes to Scope and Requirement, it should always be Project Scope and Requirement as Product Scope has no comparison with it.

We cannot define the Scope until we define both Project scope and Product Scope.

  • Product Scope supersedes everything and this is defined in the beginning of the project
  • Requirements, based on the Product Scope you collect the project Requirement to understand the Product. This is largely Stakeholder Requirements
  • Project Scope here comes the Box of Requirements and box can take up according to the capacity and therefore its a subset of Project Requirements defined or outlines or requested by the stakeholders

https://www.mudassiriqbal.net/requirement-vs-scope/

You can find more details on the above links of my website

  • Thank you for pointing out. Please help in explaining how to define affiliation. It was never meant to be promotion but luckily I had the post on it and I cannot put all what is on post here. But i will be careful. – Mudassir Iqbal Feb 10 at 9:01
0

I think our answer must consider the chronology of a project, and how these concepts relate (in particular how they feed into one another).

By my understanding there are 3 important concepts that need to be developed in sequence: the mandate, the specific targets, and finally the work we will do to achieve them.

My take on Mark C Wallace's Smithsonian example:

  • Project Charter - High-level concept, mandate, mission statement, broad boundaries Example: Preserve, maintain, and display artifacts

  • Requirements - The specific targets to be fulfilled
    Example: Photosensitive materials must be protected; Environmental humidity must be maintained & monitored; Maintenance costs shall be minimised

  • Scope - The work we plan to do to fulfil the requirements.
    Example: Develop cleaning processes; Build workshop; Procure protective cases; Perform preventative maintenance

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.