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 Planning.docx.docx
62.1 KB Requirements Planning - Solution.docx.docx
62.5 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, primarily the Project Charter.  If the project has high uncertainty in the requirements,  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 project initiation and 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.  The sources of requirements are the Project Charter, meetings with stakeholders and subject matter experts, and the project management methodology.

SMART requirements

An acronym that is often used to assist in writing 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.

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 required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.” 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) – Fifth Edition, Project Management Institute, Inc., 2013.

 

Hints & tips

  • At the time of project origination, the requirements are often high level.  You may need to spend some time early in the project to gather more information and refine the requirements.
  • If you are unable to get clear requirements, you should plan on using the Agile project management approach and spend the first few Sprints refining requirements.
Login to download
  • 00:03 Hi, I'm Ray Sheen.
  • 00:05 Let's talk about another aspect of planning a project scope, and
  • 00:09 that is the identification of project requirements.
  • 00:12 The Project Management Body of Knowledge, the PMBOK Guide,
  • 00:16 defines project requirements as a condition or capability that is necessary
  • 00:21 to be present in the product service or result to satisfy a business need.
  • 00:26 This means that the requirements are what must be fulfilled for
  • 00:29 the project scope to be successfully completed.
  • 00:32 We normally start with the project charter to identify requirements.
  • 00:36 One of the challenges is to be certain that the requirements are written in
  • 00:40 such a way that the project team understands what they should be doing.
  • 00:44 There is an acronym that is often used to remind us of
  • 00:47 the characteristics of well-written requirements.
  • 00:51 The acronym is SMART.
  • 00:53 There are several different definitions of the SMART acronym,
  • 00:56 this is the one that I prefer for project requirements.
  • 00:59 The S stands for Specific.
  • 01:01 Requirements are to be clear, concise, and complete.
  • 01:04 The project team needs to know exactly what's required.
  • 01:07 The M stands for Measurable.
  • 01:09 The requirement states how success or performance is measured or tested.
  • 01:14 The project team knows when the requirement has been achieved,
  • 01:18 they can measure their success.
  • 01:20 The A is Actionable.
  • 01:21 The work to meet the requirement is within the scope of this project.
  • 01:25 The project team has the authority and
  • 01:27 capability to do what is needed to meet the requirement.
  • 01:30 The R is Realistic.
  • 01:32 Given the amount of time and money allowed to the project,
  • 01:35 it's possible to complete the requirement within those boundaries.
  • 01:40 And the T is Traceable.
  • 01:42 The requirements can be traced back to a specific stakeholder need or
  • 01:46 project objective.
  • 01:47 SMART requirements is one way to clearly define the success criteria for
  • 01:52 the project scope.
  • 01:53 Let's now talk about where and how to collect the requirements.
  • 01:57 The first and most obvious source of requirements is the goals and
  • 02:01 objectives for the project charter.
  • 02:03 A well-written charter will contain many of your requirements.
  • 02:08 Often, the requirements will be refined or
  • 02:10 elements of the SMART characteristics will come from the stakeholders.
  • 02:14 Stakeholders will provide use cases that describe how they intend to use
  • 02:19 the project results.
  • 02:20 Some stakeholders may have specific problems or
  • 02:23 issues that they want the project to resolve.
  • 02:25 These are often found in quality complaint documents.
  • 02:29 It's always a good idea to interview the key stakeholders to
  • 02:32 clarify the requirement with them.
  • 02:35 And in some cases, the stakeholder is not an individual but
  • 02:38 rather a category of individuals, such as customers.
  • 02:41 In this case, it's often necessary to set up a focus group to get the input
  • 02:45 needed to prepare a complete list of SMART requirements.
  • 02:49 Also, consider your project management methodology.
  • 02:52 It may have generic or typical requirements for different categories of
  • 02:56 projects, such as IT projects may have user acceptance testing, and
  • 03:00 facility projects may have print reviews.
  • 03:03 Finally, I've often found that when the project requirements are vague or
  • 03:07 high level, I can refine them with an iterative or adaptive life cycle.
  • 03:11 I use prototypes with the stakeholders in the early phases of the project.
  • 03:16 As the stakeholder sees the early prototype,
  • 03:18 they will then be able to clarify the requirements,
  • 03:20 which means they will provide a much more specific and measurable requirement.
  • 03:25 Many times, the specific project requirements will be identified and
  • 03:29 solidified in an early stage of the project.
  • 03:32 However, in some cases, the requirements are already fully specified and
  • 03:36 identified before we start the project.
  • 03:39 When this is the case, the project team is often provided with a document called
  • 03:44 a Statement of Work that contains the requirements.
  • 03:47 The Project Management Body of Knowledge, the PMBOK Guide,
  • 03:51 defines a Statement of Work as a narrative description of products, services, or
  • 03:56 results to be delivered by the project.
  • 03:58 In my experience,
  • 04:00 a Statement of Work is commonly used when doing projects for a customer.
  • 04:04 The customer will provide the Statement of Work as part of the contract.
  • 04:08 And if you are outsourcing project work, you will need to create one for
  • 04:12 your suppliers.
  • 04:13 The Statement of Work will contain all project requirements,
  • 04:16 including the specific deliverables, a schedule or milestones,
  • 04:20 and a description of the project reviews and
  • 04:22 oversight activities that the customer will be doing.
  • 04:25 When there's a large contract and Statement of Work, it will often reference
  • 04:29 detailed specifications or standards that further define the requirements.
  • 04:34 Regardless of whether your requirements are documented with a traceability matrix,
  • 04:39 a Statement of Work, or just a list of tasks, you need SMART requirements.
  • 04:44 Both the stakeholders and the project team will know and
  • 04:47 understand what is required to be done within 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