PROJECT
Scope Management Plan
DRAFT
Revision History
NOTE: The revision history cycle begins after receiving requested changes or enhancements and
after the initial version of the Scope Management Plan is complete.
Date
Version
Description
XXX 9999
1.0
Initial creation of document for new
release.
PROJECT Scope Management Plan - DRAFT
ii
Author
June 2005
Table of Contents
1.
Introduction ..................................................................................................................... 1
1.1.
1.2.
1.3.
2.
Scope ......................................................................................................................................... 1
Definitions, Acronyms, and Abbreviations ................................................................................. 1
References ................................................................................................................................ 2
Scope Management ......................................................................................................... 2
2.1. Original Charter Information ...................................................................................................... 2
2.2. Enterprise Environmental Factors ............................................................................................. 2
2.3. Organizational Policies .............................................................................................................. 3
2.3.1. PROJECT Stakeholder Council .......................................................................................... 3
2.3.2. PROJECT CCB ................................................................................................................... 4
3.
Scope Definition Inputs .................................................................................................. 4
3.1.
3.2.
4.
HDR Content Analysis Prioritization .......................................................................................... 4
Data Standardization Domain Matrix ......................................................................................... 5
Scope Definition Tools.................................................................................................... 5
4.1.
4.2.
Iteration Scope Statement ......................................................................................................... 6
Generic Work Breakdown Structure .......................................................................................... 6
Appendix A ............................................................................................................................... 9
PROJECT Scope Management Plan - DRAFT
iii
June 2005
Scope Management Plan
1. Introduction
This document is a planning tool that describes how the PROJECT Project Team defines the scope of
each development iteration of the PROJECT project. It also documents how the scope statements for
each iteration are constructed and provides the generic Work Breakdown Structure (WBS) utilized
and refined by the project team per iteration to manage the deliverables associated with the current
iteration. The plan also details how the scope is controlled and managed throughout each iteration
through the delivery of identified work products.
This Scope Management Plan refers to and is to be utilized in conjunction with the following
documents and PROJECT project practices:
PROJECT 3.x Iteration Scope Statements (where x varies by iteration)
PROJECT Change / Configuration Management Plan
PROJECT Schedule Management Plan
PROJECT Stakeholder Council Charter
PROJECT CCB Charter
PROJECT Quality Management Plan
Identification of Stakeholder needs
Capturing of Stakeholder requirements
Prioritization of requirements
Managing change
1.1.
Scope
This plan provides definition and guidelines for the scope management of the PROJECT
project. The project’s scope statements for each iteration, as well as this management plan, will
reside in the project’s workbook area within the Groove workspace and be available to the
PROJECT project team.
1.2.
Definitions, Acronyms, and Abbreviations
HL7
Health Level 7 – Level 7 refers to the 7th layer of the Open
Communications seven layer architecture – the application
layer.
HL7 RIM
HL7 Reference Information Model
IT
Information Technology
MOU
Memorandum of Understanding
UML
Unified Modeling Language
VHA
Veterans Health Administration
PROJECT
PROJECT
PROJECT Scope Management Plan - DRAFT
1
June
1.3.
References
A Guide to the Project Management Body of Knowledge, Third Edition
Project Management Institute. 2004. PMI Global Operations Center, Four Campus Boulevard,
Newtown Square, PA 19073-3299
Requirements Management Plan Template from the IDL website
Kruchten, Philippe. 1999. The Rational Unified Process. Menlo Park, CA: Addison Wesley
Leffingwell, D. and Don Widrig. 2000. Managing Software Requirements. Menlo Park,
CA: Addison Wesley.
Change Management for PROJECT Version 1.3
2. Scope Management
Scope for the PROJECT project is managed across multiple, sequential iterations. Data
domains to be added to the enterprise level information model are parsed into time boxed work
periods to allow for maturation of processes and substantial, intermediate milestones to
demonstrate completion towards the overall project charter.
The following sections describe inputs to the scope definition for each of the PROJECT
projects iterations as well as the organizational processes which help control and manage
stakeholder expectations.
2.1.
Original Charter Information
The original charter for the PROJECT project consists of creating a segment wide information
model based on data elements from twelve, primarily, clinical domains with the intention of
later expanding to include all VHA data required for interoperability. The elements are to be
depicted in a Unified Modeling Language (UML) 2.0 standard modeling tool utilizing class
diagrams with accompanying textual descriptions. The style and arrangement of the data
elements within the class diagrams must be mappable to the Health Level 7 (HL7) Reference
Information Model (RIM) to enable information sharing with the broader healthcare
community.
The modeled information is to be transformed into implementable technical artifacts that
contribute towards the establishment of an enterprise wide semantics standard for message
structures and payloads as well as data repository semantics and structure and other
implementation artifacts such as XML Style Descriptions and java object libraries.
The project team is also responsible for setting up supporting management processes. These
processes include the identification of teams to manage and harmonize stakeholder requests,
analyzing the impact of changes as well as defining and measuring compliance and adoption of
the PROJECT artifacts.
2.2.
Enterprise Environmental Factors
The scope statements for each iteration of the PROJECT are influenced by the following
factors:
 Need for the availability of the information model per data domain
PROJECT Scope Management Plan - DRAFT
2
June
o





This need is defined by the maturity and readiness of the Re-Engineering
project teams within HealtheVet
o The agreements and financial support from specific groups within the VHA
enterprise – as defined in current memoranda of understanding (MOUs)
Readiness of Re-Engineering project stakeholders to provide business requirements
and use cases
o As Re-Engineering project teams define their business requirements and use
cases, their priorities and project schedules influence the PROJECT model and
the associated teaming from the PROJECT project team that promotes adoption
of the PROJECT’s technical artifacts. A major information source in
determining the associated order of events is the HealtheVet Sequencing Plan:
http://.infoshare.va.gov/Sequencing%20Plan/default.aspx
Funding and size of the PROJECT project team
o Financial support of and available expertise within the PROJECT project team
also determines what can be accomplished within the development of each
iteration of the PROJECT. Typically, work is chunked into 4 month periods
which consist of activities including stakeholder requirements collection and
analysis, information modeling, mapping to HL7 standards in support of
internal and external interoperability, and technical artifact creation and
support
Approved change requests
o Requests for change that have been examined and approved by the PROJECT
Stakeholder Council as well as the PROJECT Change Control Board (CCB)
can influence the current iteration’s scope statement as well as future iteration
work. Please see additional information, below, in the Organizational Policies
section
Lessons Learned
o Lessons learned from previous project iterations as well as information
collected from stakeholders also influence the chunking of work across
PROJECT project iterations
Inter-agency and intra-agency standardization activities
o Agreements with external government and industry partners, as well as internal
VHA data standardization priorities will impact PROJECT priorities.
2.3.
Organizational Policies
Two chartered groups have been created to assist with managing change for the PROJECT
project as well as harmonizing potentially conflicting stakeholder requirements. These two
groups are the PROJECT Stakeholder Council and the PROJECT CCB.
2.3.1.
PROJECT Stakeholder Council
The PROJECT Stakeholder Council consists of representatives from each of the major
organizations contributing to and/or consuming the PROJECT. The main purpose of this
council is to prioritize and harmonize incoming requests for change to ensure that a request
from one stakeholder does not negatively impact other stakeholders’ business processes
within the VHA enterprise. Requested changes are also prioritized across the stakeholder
council representatives to influence proper sequencing of the approved changes as they are
folded into the PROJECT iterations.
PROJECT Scope Management Plan - DRAFT
3
June
2.3.2.
PROJECT CCB
The PROJECT CCB consists of senior management representatives and the project
sponsoring organizations. This group receives the approved change requests from the
PROJECT Stakeholder Council and works with the project manager to fold the requests
into the appropriate PROJECT iterations. The triple constraint: time, cost and scope; is the
primary concern of this group, so that planned iterations can absorb appropriate changes
and still meet baselined target dates.
Both the PROJECT Stakeholder Council and the PROJECT CCB work together with
PROJECT project management to ensure that stakeholder change requests are properly
harmonized and prioritized. The approved changes are folded into the PROJECT iterations
with proper management approval thereby ensuring proper direction for the project and
appropriate utilization of funds.
3. Scope Definition Inputs
Although the inputs to the PROJECT scope statements are not limited to the following items,
these documents have been key to defining and prioritizing domains modeled during several
PROJECT iterations.
3.1.
<<Repository>> Content Analysis Prioritization
The following table is provided and maintained by the HDR Content Team. The information
listed below is a snapshot of the content maintained at
http://.med.va.gov/hdr/HDR_Data_Content_Documents.html. While the PROJECT’s focus
extends beyond Repository, the size and importance of the Repository, along with the
prioritization of domains with Data Standardization, have helped shape the domains modeled in
recent PROJECT iterations.
HDR Content Domains
Target Completion Date
Primary
Content Team
Analyst
1st 12 HDR Domains
Remaining HDR Domains
19-Feb-04
19-Feb-04
14-May-04
19-Mar-04
14-May-04
1. Vitals
2. Pharmacy - Outpatient
- Inpatient
3. Allergies
4. Lab - Chem/Hem, Microbiology, Cytopath,
Electron Microscopy & Surgical Path
- Autopsy
- Blood Bank
5.
6.
7.
8.
31-Aug-04
HDR Hx: 5/31/05. HDR II: postponed
until VBECS is released (projected release
date of 2/28/06.)
14-May-04
14-May-04
30-Jun-04
30-Jun-04
Problems
TIU
Orders
Encounters - Outpatient
30-Jun-04
- Inpatient
PROJECT Scope Management Plan - DRAFT
4
June
HDR Content Domains
Target Completion Date
Primary
Content Team
Analyst
30-Jun-04
30-Jun-04
31-Jul-04
31-Aug-04
30-Nov-04
30-Nov-04
30-Nov-04
30-Nov-04
30-Nov-04
31-Jan-05
31-Mar-05
31-Mar-05
31-May-05
31-May-05
31-May-05
31-May-05
31-May-05
9. Health Factors
10. Radiology
11. Immunization
12. Demographics
13. Mental Health
14. Consultations
15. Patient Education
16. Surgery
17. Women’s Health
18. Home Based Primary Care
19. Compensation & Pension (C&P) Exam
20. Event Capture
21. Dental
22. Dietetics
23. Prosthetics
24. Registry Data
25. Resident Assessment Instrument/Minimum
Data Set (RAI/MDS)
26. Dental
27. Decision Support
28. Visual Impairment/Blind Rehab
31-May-05
31-May-05
Content analysis postponed until v5.0 is
released (8/31/05 or after)
Content analysis postponed until
management provides further direction.
Content analysis postponed until the new
NIIS system is released.
29. Clinical Procedures & Medicine
30. Nursing
3.2.
Data Standardization Domain Matrix
The attached spreadsheet identifies Data Standardization’s schedule in terms of domain
priorities and associated key milestone dates. This information, in conjunction with the table
above, has helped to determine the priority of domains to model in past and future PROJECT
iterations.
D:\Documents and
Settings\vhaiswgarnhg.VHAMASTER\My Documents\Health Informatics Architecture\VHIM\VHIM 3.2\Scope Management\DS_DomainMatrix
4. Scope Definition Tools
The PROJECT project’s scope definition activities include, but are not limited to, the utilization of
the following tools to communicate iterations scope to stakeholders and project team members:
PROJECT Scope Management Plan - DRAFT
5
June
4.1.
Iteration Scope Statement
Each iteration of the PROJECT project is planned and executed as a sub-project – complete
with a specific scope statement, schedule and deliverables. The scope statement, supplied in
Appendix A, is an example supplied from a past PROJECT iteration.
4.2.
Generic Work Breakdown Structure
While the specific scope for each PROJECT iteration may vary in terms of domains being
modeled, the following generic Work Breakdown Structure (WBS) is used to provide a
framework for scoping deliverables within an iteration. This WBS is modified as needed based
on the individual scope statement for the current iteration.
PROJECT Scope Management Plan - DRAFT
6
June
PROJECT Scope Management Plan - DRAFT
7
June
PROJECT Scope Management Plan - DRAFT
8
June
Appendix A
Example PROJECT Iteration Scope Statement
PROJECT (PROJECT) 3.1
Scope Statement
Key Stakeholders
XXX, XXX, XXX
Project Manager:
XXX
Overall Project Time
Frame:
From
:
9/9/99
To:
9/99/99
Project Goals and Objectives
 To continue to enhance the published PROJECT to include support for needs from OTHER
PROJECTS
 Maintain existing PROJECT models currently being utilized by project application teams
ensuring a usable, informational and semantic standard
 Demonstrate coverage of content relative to Standards Development Organizations
 Serve as the reference point information model for VHA containing the authoritative data
structure, relationships, and semantics
 Assist in driving VHA’s migration towards HL7 version 3 compliance. Project outputs will
consist of multiple models to achieve compatibility with existing applications, such as
xxxxxx. Please see Project Deliverables, below, for details
 Future PROJECT versions will become an administration level model to include cross-cutting
VHA requirements and reflect industry standards. Future versions will support all VHA
applications including xxx
High-Level Project Deliverables
The scoping of this effort will include the following simultaneous activities:
1. Maintenance of the current convergence model for xxx,xxx. Significant changes will be published as
PROJECT 2.2
2. Maintenance of PROJECT 3.0 as required and expansion of the number of modeled domains to
produce PROJECT 3.1
 PROJECT Convergence Model (PROJECT 2.1) was produced to satisfy the requirements of
XXX as well as converge the parallel modeling efforts between XXX AND XXX. This version of
the information model is compliant with COAS datatypes to ensure its usability for its current
project application team consumers.


PROJECT 3.1 will be produced to satisfy the needs of XXX,XXX as well as to continue the
move towards compliance with HL7 version 3.0 datatypes and messages.
Domains scheduled for inclusion:
(a) All PROJECT 3.0 domains
(b) Laboratory – General, Autopsy, Blood Bank, Chemistry/Hemotology and Microbiology
(c) Demographics
(d) Problem List
(e) Encounters
(f) Text Docs (TIU)
(g) Orders
PROJECT Scope Management Plan - DRAFT
9
June
3.
(h) Imaging
PROJECT Compliance and Governance process document
The following deliverables will be updated as required:
 PROJECT Datatypes Model Package
 PROJECT 3.0 Reference Information Model (RIM)
 PROJECT UML Profile


4.
5.
Both Information Models will be represented as Rational Rose model files (Class Diagrams) with
definitions for concepts, their attributes and their associations
Models include Domain Packages and Templates intended to describe the payload of
messages/interfaces for services
PROJECT Project Workbook
Enhancements, as required, to the:
5.1. PROJECT Change Control Process
5.2. PROJECT Team Member Handbook
Critical Success Factors
1.
2.
3.
4.
5.
Key stakeholder buy in and support of versions 2.2 and 3.1
Senior management support
Active participation in established PROJECT workgroups including the PROJECT Stakeholder
Council and the PROJECT CCB
Continued integration with Data Standardization, Common Services and the project application teams
including HDR II and the Re-engineering teams.
On-time delivery of scheduled work products
Affected Products, Services, Operations, Organizations
 Sofware Development Projects:
 XXX
 XXX
 XXX
 Data Standardization and Terminology: Domain Action Teams, SDOs
 XXX
 XXX
 Standards Development Organizations
 XXX
Key Stakeholder Approval
The identified stakeholders have noted the contents and the particulars of this Scope Statement and
approve the same.
Xxx Xxx
Date
Xxx Xxx
Date
Xxx Xxx
Date
PROJECT Scope Management Plan - DRAFT
10
June
Project Leadership Approval
The project leadership has noted the contents and the particulars of the project’s Scope Statement and
approves the same.
XXx Xxx
PROJECT Scope Management Plan - DRAFT
Date
11
June