Only Section 2: Scope of the PMP should be updated after Project Startup. The APHL Project Lead approves scope changes.

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.

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.)

Briefly describe prior / current experiences of Clients that identify the need for the project.

Describe the Problem or opportunity addressed, Justification, Customer’s needs, primary use cases.

Describe what the project is intended to achieve in business and technical terms. Use bulleted lists.

List the items that are out of bounds for this project.

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.

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. 

Include both product deliverables and those items needed to manage the project.

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).

Lists other systems or projects that might be impacted by this project – needed for coordination. (If none, delete this section.)

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.

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.

(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.

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.

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.

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.

This section describes the persons and roles supporting the project. This list includes internal and external project stakeholders to the project team. 

Defines who reports to whom (hierarchy of authority), how, how often, etc. – could be an organization chart for the project.

(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. 

(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.

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.

Defines the process whereby the project exit strategy will be described.  How to verify (prove) we are "done" is the goal.

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.

Below are suggested persons/groups and suggested communication. Update as needed.

All major high-level project communication, documentation, work files, and project reports must be stored where APHL and project staff can access them.

The below information is suggestive of information to include about project meetings.  This should be updated and tailored to the specific project.

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.