Subscriber only lesson.

Sign up to this course to view this lesson.

View pricing

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 Planning.docx
202.8 KB Requirements Planning - Solution.docx
203.1 KB

Quick reference

Requirements Planning

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.

When to use

Requirements planning is done early in a project to verify the requirements and identify if there are additional requirements beyond what are found in the initiating documents.  If the project has high uncertainty in the requirement, then several “prototype” iterations should be accomplished and the requirement progressively elaborated as more information becomes available.  This may lead to requirements planning occurring well into project execution.  When a project is managed using a stage gate or phase methodology, requirements planning often occurs at the beginning of each phase.

Instructions

Requirements planning is a fundamental element of scope definition.  For small simple projects, the requirements are often clearly defined and easy to identify.  However, on a large project or on projects with vague or uncertain requirements, this can be the largest area of project risk and must be managed closely. 

SMART requirements

An acronym that is often used to assist in writing and reviewing requirements is SMART.  There are several sets of requirement definition principles that use the SMART acronym.  The one shown below is my preferred set.  If you are unable to meet the elements of requirements definition for all requirements, it indicates that you have a risk at that point in the project.  You will probably need to progressively elaborate that requirement.

  • Specific – clear, concise, complete.
  • Measurable – testable, unambiguous.
  • Actionable – within the project scope.
  • Realistic – achievable given resources and time.
  • Traceable – linked to stakeholder need or project goal.

Traceability matrix

On large complex projects the project activity is often managed through subprojects and with virtual teams.  It is important on those complex projects that the requirements are allocated correctly and that they are correctly verified at time of task completion.  The traceability matrix is a spreadsheet or database that manages the high-level requirements, its allocation to lower level requirements, and then its test or evaluation to ensure the requirement has been met.  There are many versions of the traceability matrix with slightly different column or field headings.  Use the matrix that is most commonly found in your organization or your industry.

Statement of Work (SOW)

When the project is being performed for a customer, the requirements are often captured in a Statement of Work (SOW).  A well-written SOW will include the technical/quality requirements, the schedule requirements, and the reporting requirements for the project.  The SOW is often an attachment to the contract and is considered contractually binding.  If working with an SOW from a customer, ensure you thoroughly understand each of the requirements prior to signing the contract.

Definitions

Requirement: “A condition or capability that is necesary to be present in a product, service, or result to satisfy a business need.” PMBOK® Guide

Requirements Traceability Matrix: “A grid that links product requirements from their origin to the deliverables that satisfy them.” PMBOK® Guide

Statement of Work: “A narrative description of products, services or results to be delivered by the project.” PMBOK® Guide

 

These definitions are taken from the Glossary of the Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Sixth Edition, Project Management Institute, Inc., 2017.

Login to download
  • 00:04 Hi, I'm Ray Sheen.
  • 00:06 Let's talk about another aspect of planning a project scope, and
  • 00:09 that is the identification of project requirements.
  • 00:13 The project management body of knowledge.
  • 00:16 The PMBOK Guide, defines project requirements as a condition or
  • 00:21 capability that is necessary to be present in the product, service or
  • 00:25 result to satisfy a business need.
  • 00:28 That means that the requirements are what must be fulfilled for
  • 00:31 the project scope to be successfully completed.
  • 00:34 Identifying requirements can be a challenge.
  • 00:37 One of the challenges is to be certain that the requirements are written in such
  • 00:40 a way that project team can understand what they should be doing.
  • 00:44 There's an acronym that is often used to remind us of the characteristics
  • 00:48 of a well-written requirement statement.
  • 00:50 This acronym is SMART.
  • 00:52 Now, there are several different definitions of the SMART acronym, and
  • 00:55 this is the one that I prefer for project requirements.
  • 00:59 The S stands for specific, requirements should be clear, concise and
  • 01:02 complete the project team knows exactly what is required.
  • 01:06 The M stands for measurable requirement states
  • 01:09 how successful the performance is measured or tested.
  • 01:12 The project team knows when the requirement has been achieved,
  • 01:15 there is no ambiguity about the status.
  • 01:18 The A is for actionable,
  • 01:20 the work to meet the requirement is within the scope of this project.
  • 01:23 The project team has the authority and
  • 01:25 capability to do what is needed to meet this requirement.
  • 01:29 The R is realistic.
  • 01:31 Given the amount of time and money allocated to the project,
  • 01:34 it's possible to complete the requirements within those boundaries.
  • 01:38 And the T is traceable.
  • 01:39 The requirement to be traced back to a specific stakeholder need or
  • 01:42 project objective.
  • 01:44 Smart requirements is one way to clearly define the success criteria for
  • 01:48 the project scope.
  • 01:50 Lets now talk about when and how to collect these requirements.
  • 01:54 The first and most obvious source of requirements
  • 01:57 is the goals of objectives from the project charter.
  • 02:00 A well written charter will contain many of your requirements.
  • 02:03 Often the requirements will be define or
  • 02:05 elements of the SMART characteristics will come from stakeholders.
  • 02:09 Stakeholders will provide used cases that describe how the intent to
  • 02:13 use the project results.
  • 02:15 Some stakeholders may ask specific problems or
  • 02:17 issues that they want the project to resolve.
  • 02:20 These are often found in quality complied documents.
  • 02:23 It's always a good idea to interview the key stakeholders to clarify
  • 02:26 the requirements with them.
  • 02:28 And in some cases the stakeholder is not an individual, but
  • 02:32 rather a category of individuals such as customers.
  • 02:35 In this case it's often necessary to set up a focus group
  • 02:38 to get input needed to prepare complete list of smart requirements.
  • 02:44 We can also obtain requirements by looking at what other organizations have done
  • 02:48 when doing similar projects.
  • 02:50 Benchmarking, either internally within your organization or externally against
  • 02:54 other organizations will reveal success criteria for a project.
  • 02:58 Finally, I've often found that when project requirements are vague or
  • 03:01 high-level.
  • 03:03 I can refine them with an iterative or adaptive lifecycle.
  • 03:06 I use prototypes with stakeholders in the early phases of the project.
  • 03:10 As the stakeholder sees the early prototype.
  • 03:13 They will then be able to clarify what is really required and
  • 03:16 provide a much more specific and measurable requirement.
  • 03:20 An excellent technique for managing the planning and
  • 03:22 execution of project requirements is a traceability matrix.
  • 03:26 The project management body of knowledge the PMBOK Guide defines a requirements
  • 03:31 traceability matrix as a grid that links product requirements from their origin
  • 03:35 to the deliverables that satisfy them.
  • 03:39 This is an example of the traceability matrix.
  • 03:42 Your organization may use a different format or
  • 03:44 have a slightly different columns and fields.
  • 03:46 But this structure will likely be the same.
  • 03:49 It's starts on the left side with the business or stakeholder need.
  • 03:52 This is then deployed into specific solution requirements.
  • 03:55 Those solution requirements are then deployed into specific test requirements.
  • 03:59 With the test plan that describes how the project will measure the solution.
  • 04:04 Finally, the specific deliverable is listed, with a column for
  • 04:07 the current status of the requirements, and comments.
  • 04:10 This gives us a specific, measurable, actionable, realistic, and
  • 04:14 traceable path to meet the stakeholder need.
  • 04:18 In addition to using this document for planning project scope, it can also be
  • 04:22 used for tracking and documenting the completion of project scope.
  • 04:26 Many times, the specific project requirements must be identified and
  • 04:30 solidified in an early stage in project work.
  • 04:33 However in some cases, the requirements are already fully and
  • 04:37 specifically identified.
  • 04:39 When that is the case, the project team is often provided with a document called
  • 04:42 a statement of work that contains all the requirements.
  • 04:47 The project management body of knowledge the PMBOK guide,
  • 04:49 defines the statement of work as, a narrative description of products,
  • 04:54 services or results to be delivered by the project.
  • 04:58 In my experience the statement of work is commonly used when doing project work for
  • 05:02 a customer.
  • 05:04 The customer will provide a statement of work as part of the contract.
  • 05:07 And if you are outsourcing project work, you are the customer, so
  • 05:10 you'll need to provide a statement of work for or your supplier.
  • 05:14 The statement of work will contain all project requirements including
  • 05:17 the specific deliverables a schedule of milestones and a description of project
  • 05:22 reviews and oversight activities that the customer will be doing.
  • 05:26 When it's a large contract and a large statement of work, it will often reference
  • 05:30 detailed specification or standards that further define the requirements.
  • 05:34 Now, regardless of whether your requirements are documented with
  • 05:39 a traceability matrix, a statement of work or just a list of tasks,
  • 05:43 you need smart requirements.
  • 05:45 Both the stakeholders and the project team will know and
  • 05:48 understand what is required to be done within the project.

Lesson notes are only available for subscribers.

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

Gift this course