Scope Statement

Quick reference

• 00:05 Hello again, I'm Ray Sheen.
• 00:06 I'd like to now talk about a Scope Statement.
• 00:09 Which is another of the techniques that can be used while doing project scope
• 00:12 planning.
• 00:13 The project management body of knowledge, the PMBOK Guide,
• 00:17 gives us this definition of a project scope statement.
• 00:21 The description of the project scope, major deliverables, assumptions and
• 00:24 constraints.
• 00:26 This may appear to be a little redundant with the project charter and
• 00:29 the project requirements.
• 00:30 It is.
• 00:31 Because of the redundancy, it's normally a very easy document to create.
• 00:36 And I find the best use for
• 00:37 this document is with large projects that have large teams in multiple locations.
• 00:43 Then I use the document as a communication tool used to maintain alignment.
• 00:48 The PMBOK Guide considers it to be a planning document.
• 00:50 So I've listed it here with planning.
• 00:52 However, it is often initially created during the project initiation phase and
• 00:57 then reviewed and updated during the project planning phase.
• 01:00 In fact, many times it's created before either a charter or a requirements list.
• 01:04 As I've indicated, it's used for
• 01:06 communication with all the stakeholders and the project team.
• 01:09 Often at the beginning of a project when the team is forming,
• 01:12 everyone has their own idea of what the project is trying to accomplish.
• 01:16 The scope statement sorts that out, and
• 01:18 ensures a common understanding of the project scope.
• 01:22 So let's look at elements of a good scope statement.
• 01:25 The scope statement will include some description of what the project is trying
• 01:28 to accomplish.
• 01:30 This is often referred to as the product description.
• 01:33 This can normally be taken right from the wording of the project charter.
• 01:37 Next are the deliverables.
• 01:38 Some of these are the product description already mentioned, but often
• 01:41 the project will have other deliverables associated with governance and
• 01:44 compliance of the project manager methodology that must be completed.
• 01:48 In addition, we'll have some acceptance criteria,
• 01:51 something referred to as the definition of done for the project.
• 01:55 Often these criteria come right out of any requirements planning documents.
• 01:59 A very important element of the scope statement that I've always included
• 02:02 is the project exclusions.
• 02:05 These are the topics or activities the project is not to include.
• 02:08 A great technique for clarifying this is the in frame out of frame technique
• 02:12 that we discussed with one of the other initiation lessons.
• 02:16 The scope statement will also includes some of description of the constraints for
• 02:20 the project.
• 02:20 The constraints are the internal or external restrictions on the project team
• 02:24 with regards to the types of activities that they are permitted on this project or
• 02:28 the manner in which the work must be done.
• 02:30 The assumptions are the elements of the project approach that the team could
• 02:33 consider to be true, and therefore take advantage of their impact.
• 02:37 An example might be, that the team assumes a new test facility will be operational
• 02:41 by the time they're ready to send test samples there for validation testing.
• 02:46 So now lets talk about how to create a scope statement.
• 02:48 Start with the project charter if one exists.
• 02:51 The charter was developed during project initiation and
• 02:54 was used to get the project approved.
• 02:56 Many of the scope statement elements will be there.
• 02:59 But the charter was written for the stakeholders.
• 03:01 It was so that they would know what they were approving.
• 03:04 The scope statement is written for
• 03:06 the project team to keep them aligned with project goals and objectives.
• 03:09 The charter provides much of what you need.
• 03:12 But I often find it's necessary to further expend on the information from the project
• 03:16 charter, providing clarity by progressively elaborating
• 03:19 some of the goals of objectives.
• 03:21 We discussed progressive elaboration already.
• 03:24 It is the continue unfolding of more detail on the project as the project
• 03:27 progresses.
• 03:28 One way is to clarify the requirements acceptance criteria.
• 03:32 This comes from requirements planning documents, and
• 03:34 it's often generated during the early stages of the project.
• 03:38 Also, meet with the stakeholders to insure that the assumptions and constraints
• 03:41 are accurate and there is clarity around what is and is not part of this project.
• 03:46 Many times the project charter was written months before a project starts, and
• 03:51 when it finally gets under way, some of the assumptions and
• 03:53 constraints may have changed.
• 03:56 I then like to coordinate the scope statement with the team and
• 03:59 subject matter experts, the SMEs.
• 04:02 They will think of things that I did not think of and
• 04:04 have some good questions that I can't answer.
• 04:07 I wanna get these identified so I can go back to the charter or
• 04:10 the stakeholders, and get an answer for as many of these as possible.
• 04:14 There'll undoubtedly be questions and concerns that can't be answered yet, or
• 04:18 some challenges in the project scope that are identified by the stakeholders and
• 04:21 the team members.
• 04:24 When updating the scope statement,
• 04:26 make sure you update your project risk register with these items, so that
• 04:29 they can then be actively manage by the project team as the project progresses.
• 04:34 The scope statement is used to clarify the project direction and
• 04:38 to maintain alignment.
• 04:40 On large projects with teams that are in multiple locations,
• 04:43 it's a necessary document to ensure that everyone is working together for
• 04:47 the success of the project.

Lesson notes are only available for subscribers.