It's important to know the difference between 'scope' and 'requirements'

Scope and requirements are interrelated concepts. Projects in your portfolio should be creating and managing both. What is the difference between the two? Why do you need both? Why is a leading project management nonprofit organization addressing requirements management?

?When I spoke at my local Project?Management Institute (PMI?) chapter, I asked my audience a hypothetical question: if push came to shove and you could create and manage only scope, or only requirements, which one would you choose? My audience’s reaction was to be expected, with an appropriate amount of scoffing at the mere concept of managing a project without both. Understanding the distinctions between scope and requirements and the role of a business analyst can help you choose.

?Scope vs. requirements.

PMI??defines project scope as, “the work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.” (PMBOK??Guide – Sixth Edition (2017)). In my experience, project scope also describes the environment in which the project lives and breathes. All work in the project’s work breakdown structure should be aligned with project scope throughout the project, supported by a robust project scope change management process. A project sponsor defines the project’s scope, usually in collaboration with other major stakeholders.

Requirement management is the process by which stakeholders define the capabilities expected of the project’s result. Ideally, the requirement management process is continuous, where the capabilities are documented,?analyzed,?traced, ranked, prioritized?and managed throughout the life of a project. Requirements for each project in a portfolio should be assessed to ensure no duplication, conflicts, or gaps exist across the project portfolio. Requirements must also align with the project’s scope. A business analyst or product manager works with the business to define requirements.

The difference? Scope describes the project’s footprint. Requirements are those ‘specified features and functions’ of the result (also known as the project’s product). While I confess to being a project scope junkie, I would hypothetically choose requirements. My top priority is successfully delivering the result expected by my project portfolio’s sponsor.

?PMI? is talking about requirements!

What I find rather remarkable is that PMI? has blurred the lines between project management and solution delivery by publishing a practice guide on requirements management that is highlighted in PMI?’s PMBOK (Sixth Edition (2017)). In addition, the number of people certified in PMI?’s PMI Professional in Business Analysis (PMI-PBA)? has grown remarkably since the certification was introduced in 2014. ?

Why is an organization focused on moving the world’s project management skill set forward dabbling in a standard phase of the solution delivery process? Because they go hand in hand. After all, without a solution to deliver, there is no need for project management.

What is the difference between a stakeholder and a business analyst?

All stakeholders and business analysts are subject matter experts, but not all stakeholders are business analysts.

A stakeholder can explain a business process in an organized and detailed manner and knows the business inside and out. PMI? defines a?project stakeholder?as, "an individual, group, or organization, who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a?project." (PMBOK??Guide – Sixth Edition (2017)).

A business analyst understands how software and other applications support that business process. In addition, a business analyst is trained in and can apply the requirements management process (elicit, define, maintain, trace) to identify clear and unambiguous requirements. The requirement list (also known as a product backlog) is created and managed by the business analyst or product owner. Tracing requirements through design, build and testing occurs through collaboration with engineers, developers and testers.

?If push came to shove, would you choose scope or requirements??

Want to learn more about managing project scope, or why I knew I wanted to be a project manager in 8th grade? Need a 30-minute free consultation on whatever ails your project? Schedule time with me!

Jan Schiller, ex-PMP, PSM1, FLMI, is a partner with?Berkshire Consulting, LLC. She specializes in revealing the path from where an organization is to where they want to be. Jan delights clients by transforming strategy into results with project management in the financial services, investment, health, beverage, learning management, wholesale printing and life sciences industries. She has helped her clients with the adoption of project management best practices; streamlining business processes; complying with regulations; achieving competitive advantage, innovating effectively, getting things done despite turbulent times, creating a fantastic customer experience, migrating to an industry-standard platform, maximizing productivity, and wrangling projects. In addition to being quoted in PMNetwork Magazine, she's also discussed how to develop a PMO Project's scope statement on Phoenix Business RadioX and contributed to?PMWorld360's digital project management magazine.