Introduction to Project Management

1. 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 IU24OC000013. 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 http://creativecommons.org/licenses/by-nc-sa/4.0/.

2. Managing Project ScopeLearning Objectives—Lecture c • Analyze scope to develop the project scope statement. • Elicit stakeholder requirements for the project. • Create a Work Breakdown Structure (WBS).

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

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

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 ?

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?

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

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

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

10. Work Breakdown Structure (WBS)

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 !

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)

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

14. Managing Project ScopeSummary—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

15. Managing Project ScopeReferences—Lecture c References 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. 2010. Available from: http://hitechanswers.net/ 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. Images Slide 10. Work Breakdown Structure of Aircraft System. Image extracted from Systems Engineering Fundamentals. Defense Acquisition University Press, 2001. Available from: http://en.wikipedia.org/wiki/File:Work_Breakdown_Structure_of_Aircraft_System.jpg

16. Introduction to Project ManagementManaging Project ScopeLecture 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 IU24OC000013. This material was updated in 2016 by Johns Hopkins University under Award Number 90WT0005.