The APHL Informatics Project Management Plan (PMP) identifies what the project will do, when, by whom and describes how major aspects of the project will be managed.
Only Section 2: Scope of the PMP should be updated after Project Startup. The APHL Project Lead approves scope changes.
Project Name | Policy Education |
APHL Project Lead | Brooke |
Project Manager | TBD |
Sponsor | Brooke |
Target Audience | Management, PHAs, PHLs, CSTE, ASTHO, other national partners |
Created By | Crystal and Brooke |
When Created | 2/2023 (Word) |
Document Date |
|
Document Status |
|
Template Version # and Date | (v. 1) |
Approved By and Date |
|
Sections with “*” are optional for small projects. PMs need to mark unused sections with “N/A due to <reason>.” An example reason might be “small project” or “not a factor.”
1 PROJECT OVERVIEW
Provide a brief description of the project and its associated product. Also, briefly state the business need for the project, its public health/business impact, and how the project goals align with the goals of APHL, CDC (if applicable), and other Public Health Agencies. It is strongly recommended that you include a technical diagram, if feasible. Suggestions would be a high-level conceptual data flow diagram, technical architecture, current/future state, or something similar.
1.1 Project Goals and Objectives
A brief summary of the end result of the project. (For Example: Facilitate labs sending ELR messages using HL7 format from labs to state PHAs and to the CDC.)
1.2 Background * (optional for small projects)
Briefly describe prior / current experiences of Clients that identify the need for the project.
1.3 Business Need
Describe the Problem or opportunity addressed, Justification, Customer’s needs, primary use cases.
2 SCOPE
2.1 Scope of Work
Describe what the project is intended to achieve in business and technical terms. Use bulleted lists.
The scope of work includes:
2.2 Out of Scope
List the items that are out of bounds for this project.
The scope of work does not include:
2.3 Critical Success Factors
Key business goals that must be achieved in order for the system to be a success for the Client or Organization. These factors help a team or organization decide what they should focus on and compare progress to the goals that are set.
2.4 High-Level Requirements (* optional for small projects)
Describe the functions that must be in place when the project is complete. The level of detail in this section will vary based on the complexity of the project and the persons involved in the development of the Project Management Plan.
2.5 Major Deliverables
Include both product deliverables and those items needed to manage the project.
Deliverable Name | Description & Value | Responsible Party | Target Due Date / Milestone |
|---|---|---|---|
2.5.1 Work Breakdown Structure
PMI defines a WBS as a "hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables." Identify all product and project deliverables. (Initial only – not maintained).
2.6 Approach (* optional for small projects)
Identifies the primary approach to the project. If using Agile, describe an initial breakdown of the sprints and releases, if applicable.
N/A: Small project, significant partner collaboration will be required to establish approach or tools required for success
2.7 Relationship to Other Systems / Projects
Lists other systems or projects that might be impacted by this project – needed for coordination. (If none, delete this section.)
3 ASSUMPTIONS, CONSTRAINTS, AND RISKS
3.1 Assumptions
A factor that, for planning purposes, will be taken to be true, real, or certain but is outside the project team's total control. These are recorded to gain agreement with the Client and to take swift action during the project if they do not hold true. These are potential risks! Include external assumptions such as a product’s availability, suitability and reliability, legislative changes, relative importance of scope vs. cost or time. Each assumption should spell out the consequence.
3.2 Constraints
A constraint is anything that might restrict, limit, or regulate the project (i.e., time, scope, cost, resource, or equipment) restrictions known in advance that will affect the project's performance. Generally, constraints are outside the control of the project team. List any constraints that must be taken into consideration before the startup of the project. Violating one of these in project planning usually causes a project to fail in some way.
3.3 Risks
(FUTURE) A risk is any uncertain factor that may occur during the project, which could negatively impact the project's Objectives (scope, cost, schedule, or quality). These are listed to identify mitigation approaches to be considered within the initial project workplan. Subsequent Risk changes would be tracked via a Project Risk Log.
(This is an initial list only; to be maintained in a Risk Log at <URL>)
Risk | Mitigation(s) |
|---|---|
4 SCHEDULE
4.1 Major External Dependencies
A task or deliverable performed by non-project staff that is required by certain times in the project workplan so as not to adversely affect the schedule and/or costs. These usually are critical to the success of the project.
4.2 Timeline / Gantt Chart / Schedule
Provide the high-level project schedule or a link or reference to the schedule. This schedule or summary Gantt chart would be a point-in-time schedule, and it would not be maintained in the PMP but maintained separately.
(This is an initial timeline only; to be maintained at <URL>)
4.3 Executive Milestones (* optional for small projects)
A significant, verifiable event in the life of a project. These indicate to management whether the project is on track or not. Milestones should be defined here; this document should include the current link to tracking milestones.
Executive Milestone | Estimated Completion Timeframe | Project Phase (Planning, Execution, Monitoring/Control, Closing |
|---|---|---|
5 PROJECT ORGANIZATION
5.1 Interested Parties, Roles, and Responsibilities
This section describes the persons and roles supporting the project. This list includes internal and external project stakeholders to the project team.
Name & Organization | Role | Primary Project Responsibilities |
|---|---|---|
5.2 Reporting Structure
Defines who reports to whom (hierarchy of authority), how, how often, etc. – could be an organization chart for the project.
(This is an initial reporting chart; to be maintained at <URL>)
6 QUALITY MANAGEMENT
6.1 Risk Management Approach
(FUTURE) A risk is any uncertain factor that may occur during the project, which could negatively impact the project's Objectives (scope, cost, schedule, or quality). It is recommended that a Risk Management Strategy be followed and a Risk Log be used for ongoing tracking and reporting. Below is sample wording.
The project team will follow the /wiki/spaces/PKMS/pages/1870823541 to plan for and address areas of uncertainties and develop contingency plans. The RMP documents our iterative Process for identifying, analyzing, response planning, monitoring, and reporting risks. The APHL TA project team will work with Client staff throughout the engagement to monitor and resolve these risks and any others that may arise during the engagement. Risks will be reported in all Status Reports to the Client. APHL TA project management staff will use a Risk Register or Log for ongoing tracking and reporting.
All risks will be analyzed for the probability of occurring and impact to project objectives of scope, cost, schedule, and quality. A grid will determine their red, yellow, and green priority. All risks will be tracked by a Project Risk Log.
6.2 Issue Management Approach (* optional for small projects)
(CURRENT) An Issue is something currently impacting a project’s Objectives (scope, cost, schedule, or quality). It is recommended that an Issue Management Strategy be prepared, and an Issue Log be used for ongoing tracking and reporting. Below is sample wording.
Issues will be categorized into four levels of importance (Urgent, High, Medium, and Low) based on their impact on the project goals, objectives, scope, schedule, and budget. The following guidelines will be used to prioritize the issue:
Importance Level | Description |
|---|---|
Urgent | The project cannot move forward until this issue is resolved. |
High | The project will not be able to move forward if this issue is not resolved by the due date |
Medium | The issue may prevent the project from moving forward in the near future |
Low | This issue is not preventing the project from moving forward |
Issues will be tracked in the Issue Log and are defined within the status categories listed below. The Project Manager, in consultation with project personnel, should update the issue status.
Status | Description |
|---|---|
Open | The initial Status assigned when a new issue has been identified and added to the log; typically, this Status is used when an owner has not been assigned, or the work has not yet started. |
In process | An owner has been assigned and has started working on the issue |
Resolved | A solution to the issue has been identified, and corrective action has been taken to resolve the issue |
Reopened | An issue was previously categorized as Resolved, Deferred, or Closed but has been identified again as a continuing issue. |
Deferred | The project manager, owner, and issue submitter have decided to postpone addressing the issue until later. |
Closed | The issue has been resolved and is no longer considered an issue |
Issues will be monitored weekly, and the project manager will update the issue log as needed. The Issue Log will be stored in a document repository located at <URL>.
6.3 Change Management Approach
It is recommended that a project-specific Change Management Plan be created and a Change Management Log be used for ongoing tracking and reporting. Below is sample wording.
During implementation, changes to a project usually occur. To accommodate the inevitable need for change, APHL TA project management will create a Change Management Plan (CMP) early in the engagement, which documents the process for submitting, tracking, analyzing (for impact to cost, schedule, staffing, risk), and approving (by the Client and APHL) each change.
Some large scope changes may require a re-scoping of the entire project. Some scope changes are small and can be incorporated within the existing effort.
Some key project documents (like Message Mapping Guides and associated artifacts) must be placed under Change Control once they have been published or are pilot-ready. Changes to related vocabulary or data elements must be carefully managed through a formalized change request process to minimize disruption to systems in production while enabling improvements or maintenance. This process will facilitate communication regarding requested changes to the standardized vocabulary or messaging rules among the stakeholders. This process will also provide a common practice for resolving requested changes and reported problems, resulting in accurate and up-to-date common MMGs.
APHL TA project management staff will use a Change Management log for ongoing tracking and reporting. The Change Management Plan will identify the following:
How change requests are communicated to the project team
Who can submit a Change Request (CR)
Tips for writing change requests so that their intent is communicated clearly and immediately to the project team
How change requests are processed
Definition of and how the Change Control Board (CCB) operates
Who the CCB members are that can approve a change request
6.4 Acceptance Criteria
Defines the process whereby the project exit strategy will be described. How to verify (prove) we are "done" is the goal.
7 COMMUNICATIONS MANAGEMENT
Communications management is an integrated approach to conveying clear, consistent, and timely information to stakeholders who can affect or may be affected by the objectives and outcome of the project. Also, define the approach that will be used to communicate with these stakeholders, including messages, messengers, vehicles, and timing.
7.1 Communications Matrix
Below are suggested persons/groups and suggested communication. Update as needed.
Name | Title | Contact | Communication | Vehicle |
|---|---|---|---|---|
<name> | Project Manager | <email address> | Status Reports And Internal Project Status Meeting | Email, Phone, Skype, Formal Written Communications |
<name> | Project Coordinator | <email address> | Status Reports, Progress Reports | Email, Phone, Skype, Formal Written Communications |
<name> | Project Coordinator | <email address> | Status Reports, Progress Reports | Email, Phone, Skype, Formal Written Communications |
7.2 Project Documentation (* optional for small projects)
All major high-level project communication, documentation, work files, and project reports must be stored where APHL and project staff can access them.
Documentation Type | Where Stored (include URL) |
|---|---|
7.3 Project Meetings (* optional for small projects)
The below information is suggestive of information to include about project meetings. This should be updated and tailored to the specific project.
Meeting minutes will be distributed within one business day following each meeting. Minutes will include a summary of the meeting, status updates, progress updates, and new action items. All meetings will have a set agenda to be distributed one business day before the meeting. The following chart describes the type of meetings for this project. Internal means just within the APHL organization and APHL TAs; external would be any other organization.
Meeting | Target Audience | Description & Purpose | Frequency | Owner | Distribution Vehicle | Internal / External |
|---|---|---|---|---|---|---|
<project> TA Team Biweekly Meeting | <project> Technical Assistance Internal Team | Brief Progress Report including <project> Project Updates, MMG development updates, pilot state implementation updates, deliverables updates | Biweekly | APHL | Phone/web conference | Internal |
<project> Core Team Meetings | <project> Core Team: Project Coordinator, Terminologist, Technical Architect | TA Pilot Jurisdiction Implementation status reports | Weekly | APHL | Phone/web conference | Internal |
Pilot State Checkpoint Meetings | Pilot State Implementers, TA Team | Update on MMG implementation progress, milestone progress | Weekly | APHL | Phone, Web conference, email | External |
8 APPLICATION DEPLOYMENT PLAN (* optional for small projects)
This section can be detailed or broad, formal or informal, describing the approach to deploying the product or service. For example, if the project involves deploying an application to state health partners, this section will discuss the strategy for rolling out the application to the end users, including conducting environmental assessments, developing memorandums of understanding, hardware/software installation, and data conversion.