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, 6th Ed., 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.
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, tracked, 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 (6th Ed., 2017). In addition, the number of people certified in PMI’s Active 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 skillset 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 6th Ed., 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. Tracking requirements through design, build, and testing occurs through collaboration with engineers, developers, and testers.
Would you choose scope or requirements?