Locked lesson.

Upgrade

About this lesson

Project requirements are often vague, incomplete or contradictory at the time of project initiation.  Normally, additional effort is required to collect and verify the true project requirements.

Exercise files

Download this lesson’s related exercise files.

Requirements Mgmt Exercise.docx
61.5 KB Requirements Mgmt Exercise Solution.docx
61.6 KB

Quick reference

Requirements Management

Project requirements management is a critical aspect of project management.  The requirements will drive the project planning, project control and ultimate project success. 

When to use

Requirements management is initiated during project initiation, and is normally finalize during project planning.  Traditional project normally attempt to “freeze” the scope requirements and limit any changes.  Agile/Scrum projects often have variable and varying scope requirements.  Because of this, the maintenance of requirements must be continuous throughout the life of the project.

Instructions

Traditional projects rely on the Project Charter and the Scope Statement to derive the project requirements. The high-level requirements of the Scope Statement are often decomposed into detailed requirements which are captured in the Work Breakdown Structure that defines all project scope. Traditional projects seek to identify all projects at the beginning of the project. The requirements are baselined. From that point on, a change to requirements will need to go through a formal change process. A change in requirements can trigger the need for a massive replanning with significant impacts on schedule and costs. 

 A fundamental difference between traditional projects and Agile/Scrum projects is that the scope in Agile/Scrum projects is intentionally varying. This means that requirements are added, deleted, and modified throughout the project. The requirements in an Agile/Scrum project are documented with Story Cards and organized through the use of the Product Backlog.  The Product Owner is responsible for consolidating the Product Backlog. The Agile/Scrum Product Backlog is regularly changing both the contents of the requirements and their priority.

A common problem with requirements management faced by both types of projects is the reconciliation of contradictory requirements. On a Traditional project, the project manager or project sponsor will normally lead this effort and attempt to reconcile all high-level requirements prior to the approval of the Charter. When a conflict arises at the detail level, the project manager must resolve the issue. On Agile/Scrum projects, the Product Owner must reconcile any differences or contradictions. This is a primary task for Product Owners and continues throughout the life of the project since the requirements are changing throughout the life of the project.

The scope boundaries for a Traditional project are established as part of the Charter and Scope Statement and then are embedded in the project plan. The project manager must guard against any changes to the scope boundaries either from external stakeholders or project team members. Since the scope boundaries for an Agile/Scrum project are flexible and often change, the final scope boundaries are not determined until the project is complete. At that time, whatever the project accomplished is considered to be the project scope. Although this may appear to be unmanaged scope, the Product Owner is actually managing it closely through the Product Backlog and the scope of each Sprint is managed through the Sprint Backlog.  

Hints & tips

  • Uncontrolled or unmanaged changes to requirements on Traditional projects is often referred to as Scope Creep. These changes create delays and overruns.
  • Although Traditional Projects seek to minimize requirements changes, they still may occur especially on long projects. Due to business conditions, technology, or organizational changes, the requirements may need to change for the project to achieve the business goal. When that is the case – change the requirements.
  • On large Agile/Scrum projects, requirements management is the most challenging aspect of the Product Owner role. The Product Owner will need to regularly review the project goal or vision and let this act as a guide when writing and including Story Cards in the Product Backlog.
  • Requirements reconciliation is the time when internal politics will impact the project. Different stakeholders will attempt to influence the Project Manager or Product Owner to ensure their requirements are added and prioritized to the top of the list.
  • In Agile/Scrum projects, the Product Owner should let the stakeholders with low priority requirements know that they may not get what they want from the project. A little foreshadowing can help to soften the blow if their Stories are not completed in the project.
  • When a stakeholder has a very aggressive requirement – to the point that it seems unrealistic, I will often create two story cards. The first one is the requirement being performed at a basic or standard level. The second is the requirement at the aggressive level. I make sure the standard level requirement is a high priority, but the aggressive level is lower. That way I can assure the stakeholder that the requirement will at least be met at the basic level and that we will strive to get the high level.
Login to download
  • 00:04 Hi, this is Ray Sheen.
  • 00:05 Let's talk about requirements management.
  • 00:07 As we begin planning a project, we must be certain that we have gathered
  • 00:11 the requirements the project is expected to meet.
  • 00:14 You are probably familiar with the definition of a project, that it is
  • 00:18 a temporary endeavor undertaken to create a unique product, service, or result.
  • 00:23 That product, service,
  • 00:24 or result is normally defined by a set of requirements that the project must manage.
  • 00:29 Traditional tools for managing requirements are the Scope Statement, or
  • 00:33 Work Breakdown Structure.
  • 00:35 These techniques create a fixed set of requirements or scope for the project.
  • 00:39 Completing all the items in the scope statement or in the work breakdown
  • 00:43 structure ensures that the requirements for the project have been met.
  • 00:47 The Agile/Scrum methodology uses a different approach.
  • 00:50 Agile/Scrum has a high level goal or vision, but
  • 00:53 it does not rely on a detailed specification or set of requirements.
  • 00:57 Rather, it relies on the product owner deciding periodically what should be in
  • 01:02 and what should be out of the project scope in order to achieve the vision
  • 01:06 within the project constraints.
  • 01:08 The desired requirements are documented on story cards, and the story cards include
  • 01:14 the demo criteria which helps to clarify exactly what the requirement means.
  • 01:18 A critical project management function is to maintain the requirements list.
  • 01:22 On a traditional project,
  • 01:24 the project manager will normally maintain a documented requirements list or
  • 01:28 scope statement, and any changes are considered out of scope for the project.
  • 01:32 On the Agile/Scrum project, the product owner maintains the product backlog
  • 01:37 of stories that includes all the requirements.
  • 01:39 The product owner decides how best to manage that list.
  • 01:42 If the product owner thinks it is in the best interest of the project to change or
  • 01:47 revise stories in the backlog in order to achieve the project goal,
  • 01:50 they can make the change.
  • 01:52 Now, incidentally, the use of story cards and
  • 01:54 demo criteria is just a format difference on how requirements are documented as
  • 01:59 compared to the traditional project.
  • 02:01 As much as we hope that the requirements in a project are easily agreed upon,
  • 02:06 often that is not the case.
  • 02:07 The project manager or product owner is often faced with the need to reconcile
  • 02:11 competing or incompatible requirements.
  • 02:14 This is one of the most difficult elements of project management.
  • 02:17 Inevitably, you end up with one or
  • 02:19 more stakeholders disappointed with an aspect of the project.
  • 02:23 To the greatest degree possible, try to find a hybrid requirement that meets
  • 02:27 the objectives of the incompatible requirements,
  • 02:30 even if it does not meet the exact nature of each requirement.
  • 02:33 If necessary,
  • 02:34 get help to facilitate a negotiation between the opposing stakeholders.
  • 02:39 In traditional projects,
  • 02:40 we try to bring these issues to the forefront when developing the charter.
  • 02:44 That is normally the best time to get stakeholders to compromise.
  • 02:47 They must in order to get the charter approved.
  • 02:50 On an Agile/Scrum project,
  • 02:52 the requirements are often evolving during the project,
  • 02:55 so they can't be agreed upon at the beginning because some are not yet known.
  • 02:58 In this case, the product owner must do the negotiation.
  • 03:02 A technique that I have found helpful is for the product owner to focus
  • 03:05 the stakeholder on the desired outcome, not the path to get there.
  • 03:09 This maintains flexibility for the project team to explore multiple ways to get to
  • 03:14 the outcomes required by the opposing stakeholders.
  • 03:17 The big difference between traditional and
  • 03:20 Agile/Scrum is the determination of the scope boundaries, which means
  • 03:25 deciding what stories will actually get done, which requirements will be met.
  • 03:30 Agile/Scrum projects keep the scope boundary fluid,
  • 03:32 requirements are being added or removed on a regular basis.
  • 03:35 In addition, the demo criteria, which is such a fundamental part of
  • 03:39 defining a requirement, is often changed in the middle of the project.
  • 03:43 What Agile has is a big wishlist that is constantly changing.
  • 03:49 The product owner decides which of those wishes are more important and
  • 03:52 prioritizes that list.
  • 03:54 But how many are actually done will be based upon the number of sprints and
  • 03:58 the number of scrum team members who participate on each sprint.
  • 04:01 Once that has been determined, the product owner can use the velocity
  • 04:05 measure to back into a probable set of stories from the product backlog list.
  • 04:10 Even then, the final list won't be set until the final sprint is completed.
  • 04:14 So, the scope boundaries for a sprint stay variable until the sprint completes.
  • 04:18 You could say that the sprint scope is determined at the sprint demonstration
  • 04:23 based upon the work that was actually done.
  • 04:25 And the full project scope is set after the last
  • 04:28 sprint in the Agile/Scrum project.
  • 04:30 If the business wants to project to accomplish more,
  • 04:34 they need to add more sprints.
  • 04:35 Contrast that with the traditional project which sets the requirements right
  • 04:40 up front.
  • 04:40 The project manager and
  • 04:42 team then build a plan that ensures those requirements are completed.
  • 04:46 Once that plan is base-lined, changing the requirements becomes difficult.
  • 04:51 That's because it forces a change into the plan that has been coordinated and
  • 04:55 integrated across the organization.
  • 04:57 Changes mean that everything must be renegotiated and re-coordinated,
  • 05:01 which wastes time and money.
  • 05:03 Requirements, all projects have them, and they must be managed.
  • 05:07 Different methodologies use different approaches, but in both cases,
  • 05:11 they are proactively managed on the project.

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course