1. Introduction to Project Management
Managing Project Scope
Welcome to Introduction to Project Management: Managing Project Scope. This is Lecture c.
Lecture c
This material (Comp 19 Unit 5) was developed by Johns Hopkins University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated in 2016 by Johns Hopkins University under Award Number 90WT0005.
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit
Health IT Workforce Curriculum Version 4.0

2. Managing Project Scope Learning Objectives—Lecture c
Analyze scope to develop the project scope statement.
Elicit stakeholder requirements for the project.
Create a Work Breakdown Structure (WBS).
The Objectives for Managing Project Scope are to:
Analyze scope to develop the project scope statement.
Elicit stakeholder requirements for the project.
Create a Work Breakdown Structure (WBS).
 We will focus on the last two objectives in Lecture c.

3. Sample Outline of a Requirements Specification Document
Introduction
Background (include authorizing document, project charter)
Document Objective
Intended Audience
Assumptions and Constraints
Version Control (how changes will be made to this document)
Overview of the System
Summary System Description
Operational Concept (a user’s view of the intended system)
System Requirements
Functional Requirements (numbered and organized hierarchically in some way, e.g., by major function)
Non-functional Requirements (numbered and organized in some way, e.g., by characteristic, such as quality, reliability, system performance, et al.)
Interface Requirements (with other systems or entities)
Operational Scenarios (examples of end-to-end uses of the system by users, preferably illustrated with use case or other diagrams)
References
When defining scope and requirements at the start of a project, you want to make sure you have a requirements specification document that makes sense for your particular project. Here is a sample outline of a requirements specification document, showing the major elements that are very likely to appear. Make sure that your document makes sense for your project and your organization.
First, there’s an introduction section to capture very important elements and linkages to earlier documents such as the project charter. The introduction also includes the document objective, the intended audience for the document, and other information about how the document will be used.
Next is an overview of the system, followed by the heart of the document: the requirements themselves. You will want to organize and number the requirements in some logical way. Sometimes that’s done by the method shown here, breaking them down as functional, nonfunctional, and operational requirements. But there can certainly be other categories, such as performance and interface requirements. The inclusion of operational scenarios can help make the requirements real and demonstrate the way the systems and services are going to be used.
A final part of this specification document is a list of references.

4. How Much Requirements Specification Is Enough?
Effort spent on specifying requirements must provide proportional value and will vary depending on the project
Risk of inadequate documentation: fails to record important information about the system
Risk of excessive documentation: time-consuming and never referenced
When you’re expressing requirements specifications, a natural question is, “How much is enough?” Clearly defined requirements are a key driver for project success, but as you’re well aware, your project team is a scarce resource and their time recording requirements in a specification document needs to be balanced against other things that they can be doing. As a project manager, you have to determine what makes sense in terms of the project and the stakeholders that you have. There certainly is a risk of inadequate documentation. You’ll want to make sure you didn’t fail to identify and record all of the necessary information in your requirements specification document.
On the other hand, you’ll want to be on guard for excessive documentation. As a project manager, you have to exercise judgment here to make sure that you strike a balance between making sure you document enough, but not so much that it doesn’t provide proportionate value and is never referenced.
Look to your project lifecycle to help you determine the level of requirements specification you need. A linear project needs a higher level of explicitness at the beginning whereas an agile project needs less.

5. Requirements Management Plan
Documents your overall approach to requirements
How will you elicit requirements?
How will you represent requirements?
How will you process requests for requirements changes during the project?
What steps will you take to ensure that requirements are being satisfied by the system ?
The second document, the requirements management plan, has a very different objective. This is a place for you to document your overall approach to requirements, so it will address questions such as, how will you capture requirements and represent them? What is your process for handling requirements changes? How will you ensure that the requirements are being satisfied by the system? Remember that documents like this don’t have to be extensive and excessively wordy to be effective. The requirements management plan can simply be a place for you to capture all the questions related to requirements in one location to use to guide your project management.
Plan to visit the stakeholders multiple times using different requirement elicitation techniques because that will help the stakeholders be more concrete, and help you get more of the requirements that the stakeholders want for the system.

6. Requirements Traceability Matrix
Tool to keep track of requirements and their satisfaction in the resulting system
Satisfying requirements is critical to project success
Links requirements in both directions:
Backward: What was the origin of this requirement?
Forward: What part of the design and system implements this requirement?
The third document is the requirements traceability matrix. As the name suggests, this is a tool for you to keep track of the requirements and how they are satisfied in the resulting system. Obviously, satisfying requirements is critical to project success. Here is a case where software tools can help. Some organizations will use off the shelf tools such as spreadsheet tools, but there are also dedicated tools for this that are often categorized under the heading of CASE (computer aided systems engineering) tools. These tools can be valuable for capturing all of these linkages and managing them over time.
The requirements traceability linkages can be both backward and forward. A backward linkage addresses such questions as, where did this requirement come from? What is the business need? What stakeholder wanted it? Is there some documentation that affirms that this really is a requirement? When was it made? In many cases the backward linkage may lead to the project charter or to your interviews with stakeholders, for example. A forward linkage addresses such questions as, where was this requirement satisfied in the design? More specifically, what part of the design? Can we associate part of this design with satisfying the requirement, or part of the systems or services, or processes that are established as part of the project? Are they really the ones that implement this requirement? Finally, what are the test scenarios that directly test whether this requirement is being satisfied or not? What are the names of the test scenarios that will test for this? Again, requirement satisfaction is a major determinant of the acceptability of any resulting systems or services from your project. It can be very important for you as a project manager to have this traceability matrix handy. You will have to balance whether traceability is at a level of detail that is effective and not excessively burdensome in your project.

7. Requirements Approach Should Fit Your Project
Example Project 1:
Setting: Internal project, so there is a high degree of knowledge about the operational environment, customers and users are internal
Requirements Approach: May be able to develop requirements document at high level, because internal environment means there is a context for all stakeholders
Caution: Because it is internal, don’t allow vagueness on requirements; still need to be clear on stakeholder expectations for the project, deliverables, and interfaces with existing systems
Example Project 2:
Setting: External customer, many and varied stakeholders, many alternative views about the intended functions of the health IT system, possible overlap with existing systems, using immature technology
Requirements Approach: High uncertainty suggests conducting facilitated sessions with various stakeholders to work toward consensus on what is needed in new system; draft preliminary requirements document to capture what has been agreed to; develop a requirements management plan with clear process on evaluating changes to requirements; create a project steering team of key stakeholders to get active involvement in shaping requirements during the project
Caution: Projects with unclear or unknowable requirements need a high level of attention from the project manager; there is a high risk of not meeting stakeholder expectations; use special techniques (like a project steering team) to mitigate risk
This slide shows a couple of examples to illustrate how the requirements approach should fit your project. The first example is an internal customer project, and the second one is an external customer project. In the first example, there’s a lot of knowledge about the operational environment. There’s a lot of knowledge about the users, and so the requirements approach may reflect that. For example, because there’s a lot of context for the internal environment for all the stakeholders, there might be less that needs to be specified explicitly. The caution in example 1 is that because it is internal, be alert to vagueness in your requirements. Even though there’s a defined context in terms of the internal organization, be sure to be clear about stakeholder expectations for the project, for deliverables, and for interfaces with existing systems.
The second example involves an external customer with many and varied stakeholders, so this will really influence your requirements approach. When there’s a lot of uncertainty like this, consider facilitated sessions with the stakeholders to work toward consensus on what is needed in the new systems. You may want to draft preliminary requirements documents and have them reviewed by stakeholders to make sure there is agreement about what the project needs to do, and what should be required for the project. The caution in example project 2 is that projects with unclear or un-knowable requirements need a lot of attention from you as a project manager. There can be a high risk of not meeting stakeholder expectations, so you may really want to use a project steering team to help assess suggested changes in requirements during the project. The examples here are simply meant to illustrate that your requirements approaches need to vary based on the nature of the projects that you encounter.

8. From Scope Statement to Work Breakdown Structure (WBS)
Scope statement: not sufficient detail to estimate required cost and schedule
Use scope statement to develop a WBS
Work Breakdown Structure (WBS):
A hierarchical structure showing the work to be done on the project
Hierarchy expressed as a diagram or indented text
We’ve discussed the scope statement that’s established and its link to requirements. We’ve talked about how to elicit requirements and how to capture them in a specification document. Now we want to develop the work breakdown structure or WBS. The WBS is a hierarchical structure that shows simply the work to be done on the project. As the project manager, you should have a clear way to describe and define the work, to organize the work hierarchically, and to put it in a graphical structure in a diagrammatic form. You’ll organize the work of the project and break it down into manageable tasks in the work breakdown structure.

9. Features of a WBS Level 1 is the entire project Tasks: units of work
Work Packages: lowest level of task, not further decomposed, used for estimating time and cost
Supporting document: WBS Dictionary, showing description of the task, responsible entities for its completion
The top level of the work breakdown structure, Level 1, represents the entire project and all the work that needs to be done on the project. Level 1 is broken down into smaller levels, and those levels are in turn broken down into smaller and smaller units. These work units that can be broken down are called tasks. As you continue to break down the work units, you end up with the lowest level, called work packages, which are not broken down any further. It is these work packages at the lowest level that we use as the basis for estimating time and costs.
There’s a lot of detail associated with all these tasks and work packages, so you’ll want to create a supporting WBS dictionary, which will have more detailed information about all the tasks. For example, it will include who’s responsible for the completion of the tasks.
Remember that every work package is a task, but not every task is a work package. A task can be at different levels of detail, while a work package is characterized as being a task at the lowest level of detail. There is also terminology that defines any task that is broken down into lower-level tasks as a task group, to indicate that it has been broken down into constituent tasks. It’s important for you as a project manager to make sure these terms are being used in a consistent way as you define the work of the project.

10. Work Breakdown Structure (WBS)
This graphic illustration shows an example work breakdown structure. In this diagram, level 1 is the entire project, level 2 consists of task groups, and level 3 consists entirely of work packages. It’s typical for a work breakdown structure to have some tasks broken down into more detail than others, but in general you want to be sensitive to how much detail there is and how many levels you have.
Work packages are usually represented as one-person tasks, meaning that they reflect the time one person would take to complete that task. If you split a task between two people, it may still be only one work package because one person may do half of the task and the other person the other half.
An example of a work breakdown structure for a typical IT development job might show that the first level breakdown has a large task related to establishing system requirements. Often there may be another large task that would represent design, another related to procurement of products and services, another related to implementation or system integration and testing, and perhaps another one related to quality assurance—a very important activity on any project. These are simply examples of typical first-level breakdowns you might find on health IT projects.
Health IT Workforce Curriculum Version 4.0

11. Guidelines for Building a WBS
Start with the scope statement:
Work top-down
Decompose the work into component parts
Ensure that the WBS covers all aspects of the scope statement and the deliverables
Involve key people on project team, e.g.,
Use sticky notes—real or virtual—with task names
Arrange notes to get desired work structure
Don’t confuse WBS with scheduling tasks over time—it is not chronological !
Here are a few guidelines for building your WBS. One way to start is with the scope statement. Take the requirements from the scope statement and decompose them into component parts. By doing so, you have some assurance that you’re covering all the elements that are defined in the scope statement. The deliverables that are discussed in the scope statement will be addressed in your WBS.
This can also be an excellent way to start engaging the people on your project team. You might get them to assist you in rearranging sticky notes—either real or virtual—with task names on them, to start building the WBS structure. With this method you can get their buy-in while confidently finding the best way to organize the work.
Keep in mind that this work breakdown structure is not to be confused with an actual schedule of tasks over time; it’s not meant to be chronological. The WBS is simply a way to take the total amount of work, starting with the scope statement, and decompose it into chunks that show the hierarchal relationships without showing the activities over time.
This is an important place to use the experts that you have available to you. You may not know the process in your organization for procuring hardware for your project, but there must be someone who does. You may not know the clinical process for ordering laboratory specimens, but your clinical experts will. Be sure to use them and get all of those steps down so that your work breakdown structure is correct and well-defined.

12. How to Ensure the WBS Is Complete
Keep decomposing when –
You can still define tasks that have deliverables
It is practical to monitor task status and progress toward completion
New tasks still enable estimation of time and cost
Stop decomposing when –
Any further decomposition will result in tasks without deliverables
You reach smallest estimated time unit based on the magnitude of the project, e.g., one month, one week
No longer practical to manage more levels of the WBS (e.g., 5-6 levels is usually maximum)
You reach a task associated with a separate contractor or provider organization (then refer to the WBS from that provider)
We’ve talked about the work breakdown structure as being the decomposition of your work into smaller and smaller tasks, but when do you stop decomposing? You’ll want to keep decomposing when you can still define tasks that have deliverables, and when it’s practical for you to think about actually monitoring these smaller tasks for status and progress towards completion. Remember that work package tasks are used to estimate time and cost. Stop decomposing when you get to a point where any further decomposition is going to result in tasks without any deliverables.
You might stop decomposing when you get to the point at which you are able to estimate the time for a task, at a level that makes sense for your project. There can be tremendous variety here based on the size and scope of your project, but you may, for example, decide to decompose to the point at which each task takes between one staff week and one staff month to complete. This may be the appropriate level of granularity for you to track. You will also have to deal with the practicality of just how many levels exist in the WBS. Experience in project management shows that often around five to six levels is the maximum you want to work with in a WBS. Finally, another reason to stop decomposing is that you reach a point at which tasks are associated with partner organizations, for example contractors, consultants, other providers, vendors, and so on. You can simply have a single designation for all the work being provided by that provider. That provider organization will have its own work breakdown structure to show how that work is further decomposed. Keep these guidelines in mind so you have a sense for the right levels of decomposition when you’re building a WBS.

13. Hints on WBS Development
What to do with very large projects:
If you reach levels 4-5 and there is still much more to decompose, have appropriate project team members go off and build their own WBS to decompose the lower levels
How the WBS is affected by project life cycle:
For linear and iterative life cycles, you will typically be able to develop a WBS at the start
For adaptive and agile life cycles, you will want to have certain work packages be considered as planning packages—still assign budget to them, but defer any detail of their task structure
Here are some further hints on developing a work breakdown structure. When you have very large projects, it is a good idea to delegate some of your project team members to go off and flesh out some of the details. This could be a practical way for you to provide some leadership opportunities for those members.
The work breakdown structure is affected by the project lifecycle. When you know a lot about the requirements and there’s a lot of stability, it’s reasonable for you to develop a stable WBS at the start. On the other hand, when there’s less known about a project or when you’re following an adaptive model, you may want to have certain work packages considered to be planning packages, meaning that you’ll assign a chunk of resources to them in the budget, but you’re deferring any detail of their task structure until later on when more is known. This is a placeholder in your WBS until you can go back and flesh out these tasks later on. You’ll want to be sensitive not to waste effort by trying to decompose work that is not well understood at the beginning of the project.

14. Managing Project Scope Summary—Lecture c
Your effective management of project scope is critical to project success
Several tools will support the scope management process:
Requirements Document
Requirements Management Plan
Requirements Traceability Matrix
Scope Statement
Eliciting requirements from stakeholders
Is an important first step in defining scope
Provides an opportunity to build constructive relationships with stakeholders to engage them in the project and demonstrate your commitment to meeting their needs
The scope statement is the starting point for building a Work Breakdown Structure (WBS) that maps out the work of the project
This concludes Lecture c of Managing Project Scope. In summary, we have emphasized the importance of scope. It’s one of the nine knowledge areas in the project management body of knowledge and it is critical to project success. We’ve discussed examples of how “scope creep” is very injurious to projects and is a major reason why projects are not successful.
As a project manager, you have tools and techniques to help you with the scope management process, such as the requirements document, requirements management plan, requirements traceability matrix. These are all very useful documents for developing the all-important scope statement. We’ve discussed ways of eliciting requirements from stakeholders, which is an important first step in defining scope and in building relationships with stakeholders and engaging them with the project. We also discussed the importance of taking advantage of organizational assets in coming up with your best representation of requirements. The scope statement is a starting point for defining the work of the project in the form of the work breakdown structure, which will map out all the work on the project into an effective, graphical, hierarchical structure.

15. Managing Project Scope References—Lecture c
Fowler M. (2003) UML distilled: a brief guide to the standard object modeling language, 3rd ed. Boston: Addison-Wesley.
Highsmith JA. (2009) Agile project management: creating innovative products. 2nd ed.; Boston: Addison-Wesley.
HITECH Answers Available from:
Houston S, Bove LA. (2010) Project Management for Healthcare Informatics. New York: Springer Science + Business Media, LLC.
Kerzner H. (2009) Project Management: a Systems Approach to Planning, Scheduling, and Controlling. 10th ed. Hoboken, NJ.:Wiley.  
Stackpole C. (2009). A Project Manager’s Book of Forms: A Companion to the PMBOK Guide. Hoboken, N.J.:Wiley;
Whitten N. Neal (2007).Whitten's Let's Talk! More No-nonsense Advice for Project Success. Vienna, VA.:Management Concepts Inc.
No audio.
Images
Slide 10. Work Breakdown Structure of Aircraft System. Image extracted from Systems Engineering Fundamentals. Defense Acquisition University Press, Available from:

16. Introduction to Project Management Managing Project Scope Lecture c
This material (Comp 19 Unit 5) was developed by Johns Hopkins University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated in 2016 by Johns Hopkins University under Award Number 90WT0005.
No audio.
Health IT Workforce Curriculum Version 4.0