Project Management Plan for Significant Event Notification
Page i
Project Management Plan
for
Significant Event Notification
Version 1.0 draft 1
Prepared by Team1
2/15/2011
Project Management Plan for Significant Event Notification
Page ii
Table of Contents
1. Overview .................................................................................................................................. 1
1.1. Background, Business Opportunity, and Customer Needs .............................................. 1
1.2. Objectives, and Success Criteria ...................................................................................... 1
1.2.1 Objectives ............................................................................................................ 1
1.2.2 Success Criteria .................................................................................................... 2
1.3. Project Deliverables ......................................................................................................... 2
1.4. Assumptions, Dependencies, and Constraints ................................................................. 3
1.4.1 Assumptions:........................................................................................................ 3
1.4.2 Constraints: .......................................................................................................... 3
1.5. References ........................................................................................................................ 3
1.6. Definitions and Acronyms ............................................................................................... 3
1.7. Evolution of the Plan ....................................................................................................... 4
2. Project Organization .............................................................................................................. 4
2.1. External Interfaces ........................................................................................................... 4
2.2. Internal Structure ............................................................................................................. 4
2.3. Roles and Responsibilities ............................................................................................... 4
3. Managerial Process Plans....................................................................................................... 5
3.1. Start-Up Plans .................................................................................................................. 5
3.1.1 Estimation Plan .................................................................................................... 5
3.1.2 Staffing Plan......................................................................................................... 5
3.1.3 Staff Training Plan ............................................................................................... 6
3.1.4 Resource Acquisition Plan ................................................................................... 6
3.1.5 Project Commitments........................................................................................... 6
3.2. Work Plan ........................................................................................................................ 6
3.2.1 Schedule Allocation ............................................................................................. 6
3.3. Control Plan ..................................................................................................................... 7
3.3.1 Data Control Plan ................................................................................................. 7
3.3.2 Requirements Control Plan .................................................................................. 7
3.3.3 Schedule Control Plan.......................................................................................... 7
3.3.4 Budget Control Plan ............................................................................................. 7
3.3.5 Metrics Collection Plan........................................................................................ 8
3.4. Risk Management Plan .................................................................................................... 8
3.5. Issue Resolution Plan ....................................................................................................... 9
3.6. Communication Plan...................................................................................................... 10
4. Technical Process Plans ........................................................................................................ 12
4.1. Process Model ................................................................................................................ 12
4.2. Methods, Tools, and Techniques ................................................................................... 12
4.3. Configuration Management Plan ................................................................................... 12
4.4. Quality Assurance Plan .................................................................................................. 13
4.5. Documentation Plan ....................................................................................................... 13
4.6. Process Improvement Plan ............................................................................................. 13
Project Management Plan for Significant Event Notification
Page 1
1. Overview
1.1. Background, Business Opportunity, and Customer Needs
WE Energies (“The Company”) requests a Significant Event Notification System that will
send notifications of events to interested individuals or groups of individuals. In order to
accommodate WE Energies policies, the Notification System (or SENS) must send the
notifications in a prompt manner, to ensure that all interested parties are notified. Currently,
an Outage system is in place, which includes a few categories of notifications. The
notifications are sent through different manual and automated methods, and, using these
various methods, interested individuals are then notified.
As the company moves forward with unified systems, we find it is in our best interest to
unify the communications, as this will help WE Energies improve efficiency with a more
automated system. In the current Outage System, team leaders manually maintain the list
of individuals and areas of responsibility. As roles change within the organization, the IT
department manually updates these lists in order to ensure that the appropriate individuals
receive the right notifications.
In the past, an attempt was made to create a central notification system to no avail. One
major issue with sending out numerous notifications is that it is a costly and timely process,
hindered by both technological boundaries as well as software boundaries. Another issue in
past attempts, the notifications flooded the system and a single notification took hours to
receive by an individual. Any attempt at another Significant Event System must address
these issues and any other related issues.
The current business process does not adequately determine which event notifications have
been sent and to whom. Likewise, it is difficult to determine which individuals receive
certain events over a period. This difficulty exists because the first iteration of design did
not include the applications current usage scope and vision. The business process and
requirements changed over time and there was no attempt to unify the process. Due to the
overall critical nature of these events, it is necessary to redesign the system with the current
business process in mind. This will allow us to streamline the interface and address those
concerns mentioned above.
1.2. Objectives, and Success Criteria
The purpose of this project is to provide WE Energies with a central point of notification in
the case of significant event taking place. This system will send out electronic messages to
concerned parties and subscribers to the system and the specific event type. These messages
can be in the form of SMS message, email or a page. Subscribers to this system will be able
to select the even class to subscribe to.
1.2.1 Objectives



Provide > 90% uptime with the new Significant Event Notification System
Unify the communication process of WE Energies through the Significant Event
Notification System.
Reduce WE Energies operating costs differences between the old and new system by at
least 15% within the first 12 months after the initial release.
Project Management Plan for Significant Event Notification





Page 2
Ensure a successful delivery of notifications to the proper subscribers
Allow administrators to select a means of notification for subscribers from the
allowable options the system provides.
Ensure accurate message are being delivered.
Streamline the process of notification to follow the company’s business process
Provide a single point of contact for notifications
1.2.2 Success Criteria
The following is a list of success criteria:
 Have 75% of the current employees using the current Outage System moved over
onto the new communication system within the first 12 months after the initial
release.
 In the new Significant Event System, achieve an overall increase or maintain the
current average number of events created in the current in the first 6 months.
 The system delivers messages without errors.
 The system delivers the correct message to the proper subscribers
 The project completes within budget and time
 The communication sub-system manages the additional load.
 The system is secure – see requirements
 The system provides an interface for management and administration
1.3. Project Deliverables
Deliverable
Recipients
Delivery Date
Scope and Vision
Statement
2/17/2011
Project Management
Plan (this document)
SRS – Requirements
Specifications
Software Design
Document
Updated SPMP
Software Testing
System Integration
Design
2/17/2011
Final SPMP
4/29/2011
3/2/2011
3/15/2011
Comments
Initial version
Project Management Plan for Significant Event Notification
Page 3
1.4. Assumptions, Dependencies, and Constraints
1.4.1 Assumptions:
1. Electric redesign will occur first and then the same principles will be rolled into gas.
2. All subscribers have completed the company's safety requirements
3. All subscribers have a copy of the of the company's standard operating policies and
procedures
4. Only internal employees can access this system
5. Security is based on windows authentication
6. Only authenticated users can access this system
7. This will be a web interface
8. Only team leaders and above can subscribe
9. All notifications will use corporate resources for transmission
10. Only the people who are directly related to the event need to be notified (i.e. the on-call
person)
11. All external subscribers must go thru the system administrator(s) to subscribe
12. Notifications options are: email, text message and/or paging
13. If you are part of a group or if your job role requires it, you will receive certain notifications
and cannot “opt-out”
14. The application will only on Internet Explorer v6.0 and above.
15. The application will be built using .Net framework v3.5 and above.
16. The system will use either Oracle v11 or MS SQL.
17. There will no implementation of this system
18. The customer will have access to the following tools: Microsoft Project
19. Planning Poker is a representation of what we are doing in the WideBand Delphi Process
20. At the end of the execution phase, we will not have a functional/verified system
21. After closeout, we will have a functional/verified and validated deployed system
22. The Work Breakdown Structure (WBS) is not all-inclusive for tasks, etc.
1.4.2 Constraints:
1. The team will not have direct access to the WE staff.
2. The project has a completion date that coincides with the end of the class.
1.5. References
Document
SOW
Scope and Vision
SRS
1.6. Definitions and Acronyms
Significant Event
Subscriber
User
Stake holder
Location
Project Management Plan for Significant Event Notification
Page 4
1.7. Evolution of the Plan
All scheduled and unscheduled changes to the PMP will be tracked through e-mail and
FreedCamp, our document and control system. All changes must go through each of the
group members and access to create/update the PMP is given to all members of the team.
We are all responsible for change management and we plan on giving a new version to the
document when appropriate and during save-times.
Dissemination of information relative to the project and including things such as status
reports, meeting minutes, PMP updates, etc will be distributed via e-mail at least once
weekly and the website will also serve as a focal point to keep the instructor, Dr. Isaacs,
updated on our progress with the project.
Our website can be found here:
http://csc602.byjillian.com. All of the files associated with our project with the version
numbers can be found on our FreedCamp website: http://freedcamp.com/CSC602/files.
Finally, the team will meet at least once weekly to discuss ongoing project work and the
rotation of the project team leader as the semester progresses.
2. Project Organization
The following structure will apply throughout the development of this project. A success project
is always managed by an individual and not a committee.
2.1. External Interfaces
The external interfaces for the project would be the stakeholders and DR. Isaacs
2.2. Internal Structure
<Describe the internal structure of the project organization, including interfaces between the
units of the software team. It might be helpful to include organization charts or matrix diagrams
to illustrate lines of authority, responsibility, and communication. Identify representatives of key
units, such as senior management, engineering support functions (configuration management,
quality assurance, verification and validation), and process improvement.>
2.3. Roles and Responsibilities
Role
Executives
Project Manager
Technical Lead
Responsible for
Sponsor and Approve the funding for this project
Provide the leadership and coordination for this project
Provide insight and information into technologies and current
standards
Software Lead
Provide support for this effort and provide insight into the
developers availability
Architect
Provide high level structure of the system
Requirements Analyst Collect requirements from the stakeholders
Project Management Plan for Significant Event Notification
Software Engineer
Systems Engineer
Test Engineer
Application Support
Subject Matter
Experts
Page 5
Develop the system
Provide support and technical information regarding the hardware
to be used
Collaborate with the team and the users to test the system
Provide support for the system once the system is in production
Provide insight into the how the system should work
3. Managerial Process Plans
<This section defines the various project management plans and activities for the project. >
3.1. Start-Up Plans
<This section specifies plans that will lay a solid foundation for a successful project. Depending
on the size and scope of the project, you may incorporate these plans directly in this section, or
each section may simply contain a reference or hyperlink to a separate document.>
3.1.1 Estimation Plan
<This section describes how project estimates will be prepared, including:




The methods, tools, and techniques that will be used to estimate project size, effort,
cost, schedule, and critical computer resource requirements
The timing of the estimates
Who will participate in the estimation process
How the estimates will be documented, reviewed, and reported
You can include the actual estimates in this section or they can be stored elsewhere. For
each estimate made, document the estimation method used, the assumptions made, and the
confidence level for the estimate. Describe the rationale behind contingency buffers
incorporated into estimates. Specify the methods to be used periodically to re-estimate the
cost, time, and resources needed to complete the project. >
3.1.2 Staffing Plan
<Specify the number of staff needed by skill area or project role (see section 2.3), along
with required skill levels, and the duration for which each staff member is needed.
Describe the anticipated staffing profile (the mix of skills and effort levels needed at
various times in the project), when people will be added to the project or depart from it,
and how new team members will be brought up to speed. Specify the sources of the staff:
internal from your department, internal from another department within your organization,
hiring of a new employee, or hiring of contractors. Document the following information in
this section:




Available internal candidates, their skill sets, and dates of availability
Requirements for external candidates, including job classifications and descriptions
Selection of candidates and assignments to tasks
Availability and duration of assignment for all candidates>
Project Management Plan for Significant Event Notification
Page 6
3.1.3 Staff Training Plan
<This section specifies any training that will be needed to ensure the necessary skill levels
needed for the project. The types of training, number of people to be trained, and the
training methods should be specified. The Project Manager’s responsibilities include
identifying training requirements and working with local sources to provide training.>
3.1.4 Resource Acquisition Plan
<This section specifies the plan for acquiring the resources other than personnel needed to
successfully complete the project. Describe the resource acquisition process. Specify the
points in the project schedule when the various acquisition activities will be needed. List
any constraints, such as contention for shared resources (e.g., test facilities). Address any
known resource issues. Non-human resource categories are:



Development resources: the software and hardware tools required to execute the
project (number and size of computers, operating systems, databases, software tools
needed, network connectivity needed, CM and other support tools)
Test resources: the software and hardware tools required to test the software and
integrated products (number and size of computers, operating systems, software
products, tools for test case management and test automation, test equipment, and
network connectivity); details could appear in the Test Plan
Product resources: memory, disk, and other resources required by the final product.
At the end of development and engineering testing, this product will have its operating
environment resources identified so they can be included in the user documentation
that will be part of the product distribution.>
3.1.5 Project Commitments
<Record commitments that the project as a whole is making to external parties, as well as
major commitments that one individual or group within the project team is making to
another. This gives those involved a clear, shared understanding of their commitments and
allows project participants to track whether or not commitments are being fulfilled. A table
such as the one below is a convenient way to record these commitments. Describe how
project commitment changes will be communicated to the affected parties.>
Commitment
Made By
Made To
Due Date
3.2. Work Plan
3.2.1 Schedule Allocation
Activity
% Complete
User Analysis
0
Full Specification
0
Architectural
0
Design
Detailed Design
0
Database
0
Test Design
0
Status
S
S
S
S
S
S
Date Ending
2/1
2/27
3/18
4/08
4/28
SSSSS
SSSSSSSS
SSSSSSSS
SSSSSSSS
SSSSSSS
SSSSSSS
Comments
Project Management Plan for Significant Event Notification
Page 7
Planning / Progress Symbols
B
S
A
X
Work before Schedule Time
Scheduled Activity Time
Work after Scheduled Time
Scheduled But Not Worked
3.3. Control Plan
<This section describes how the project will control and report on the project status and
activities. Specify the frequency at which the various project status indicators are to be
monitored and specific events that could trigger a status evaluation.>
3.3.1 Data Control Plan
<Describe how the project will manage its data, including deliverable and non-deliverable
documents, project status metrics, reports, specifications, and so on. Address the following:






Types of data to be managed
Content and format description where pertinent (such as templates to be used)
Data requirements lists for suppliers
Privacy requirements
Security requirements and procedures
Mechanisms for data collection, retrieval, distribution, and archiving>
3.3.2 Requirements Control Plan
<Specify the mechanisms for measuring, reporting, and controlling changes to the product
requirements. Describe how to assess the impact of requirement changes on product scope
and quality, and on project schedule, budget, resources, and risk factors. If a separate
change control process is being followed, refer to that here. If changes in requirements
affect project schedule or other commitments, update this Project Management Plan, other
plans, estimates, and commitments to reflect the changes. Incorporate the tasks and effort
to perform the requirements control steps into the project’s work breakdown structure and
schedule.>
3.3.3 Schedule Control Plan
<Specify the control mechanisms used to measure the progress of the work completed at
milestones. Specify the methods and tools used to compare actual schedule performance to
planned performance and to implement corrective action when actual performance
deviates from planned or required performance. A project schedule in the form of a Gantt
chart should be created, preferably in a project tracking tool. Describe how contingency
buffers will be tapped and revised when actual performance falls behind estimates.
Describe how and when schedules will be modified and how agreement and commitment to
the revised schedules will be achieved.>
3.3.4 Budget Control Plan
<Specify the control mechanisms used to measure the cost of work completed, compare
actual to budgeted cost, and implement corrective actions when actual cost deviates
excessively from budgeted cost. Specify the intervals or points at which cost reporting is
needed and the methods and tools that will be used to manage the budget. For example,
Project Management Plan for Significant Event Notification
Page 8
you might say that the Department Manager is responsible for forecasting and controlling
budgets and expenses on an annual basis, and the Project Manager is responsible for
tracking actual hours and for reporting actual and estimated project hours by milestone to
the Department Manager.>
3.3.5 Metrics Collection Plan
<Specify the methods, tools, and techniques used to collect and retain project metrics. The
metrics to be collected, the collection frequency, and how the metrics will be validated,
analyzed, reported, stored, and used should all be addressed.>
3.4. Risk Management Plan
The initial Risk Assessment (following page) attempts to identify, characterize, prioritize
and document a mitigation approach relative to those risks which can be identified prior
to the start of the project.
The Risk Assessment will be continuously monitored and updated throughout the life of
the project, with monthly assessments included in the status report (see Communications
Plan) and open to amendment by the Project Manager.
Because mitigation approaches must be agreed upon by project leadership (based on the
assessed impact of the risk, the project’s ability to accept the risk, and the feasibility of
mitigating the risk), it is necessary to allocate time into each Steering Committee
meeting, dedicated to identifying new risks and discussing mitigation strategies.
The Project Manager will convey amendments and recommended contingencies to the
Steering Committee monthly, or more frequently, as conditions may warrant.
Risk
Estimated
Project Schedule
Risk Level
HML
H
Likelihood
of Event
Likely
Mitigation Strategy
Created comprehensive project
timeline with frequent baseline
reviews
Assigned Project Manager(s) to
assess global implications
Narrow
Knowledge
Level of Users
Available
documentation
clouds
establishment of
baseline
Project Scope
Creep
M
Likely
M
Likely
Balance of information to be
gathered
L
Unlikely
Project
Deliverables
unclear
L
Unlikely
Scope intially defined in
project plan, reviewed monthly
by three groups (Project
Manager and Steering
Committee) to prevent
undetected scope creep
Included in project plan,
subject to amendment
Project Management Plan for Significant Event Notification
Risk
Page 9
Risk Level
HML
L
Likelihood
of Event
Unlikely
Timeline
Estimates
Unrealistic
M
Somewhat
likely
Number of Team
Members
Unknowledgeabl
e of Business
Absence of
Commitment
Level/Attitude of
Management
Absence of
Commitment
Level/Attitude of
Users
Project Team
Availability
M
Likely
L
Unlikely
Frequently seek feedback to
ensure continued support
L
Unlikely
Frequently seek feedback to
ensure continued support
M
Somewhat
likely
Physical
Location of
Team prevents
effective
management
Change
Management
Procedures
undefined
Quality
Management
Procedures
unclear
M
Likely
Continuous review of project
momentum by all levels. Team
to identify any impacts caused
by unavailability. If necessary,
increase committmment by
participants to full time status
Use of Intrnet, comprehensive
Communications Plan
L
Unlikely
N/A
L
Unlikely
N/A
Cost Estimates
Unrealistic
Mitigation Strategy
Included in project plan,
subject to amendment as new
details regarding project scope
are revealed
Timeline reviewed monthly by
three groups (Project Manager
and Steering Committee) to
prevent undetected timeline
departures – school project
ends with class end date
Project Manager and consultant
to identify knowledge gaps and
provide training, as necessary
3.5. Issue Resolution Plan
The information contained within the Project Plan will likely change as the project
progresses. While change is both certain and required, it is important to note that
any changes to the Project Plan will impact at least one of three critical success
factors: Available Time, Available Resources (Financial, Personnel), or Project
Quality. The decision by which to make modifications to the Project Plan
Project Management Plan for Significant Event Notification
Page 10
(including project scope and resources) should be coordinated using the following
process:
As soon as a change which impacts project scope, schedule, staffing or spending is identified,
the Project Manager will document the issue.
The Project Manager will review the change and determine the associated impact to the
project and will forward the issue, along with a recommendation, to the Steering
Committee for review and decision.
Upon receipt, the Steering Committee should reach a consensus opinion on whether to
approve, reject or modify the request based upon the information contained within
the project website, the Project Manager’s recommendation and their own
judgment. Should the Steering Committee be unable to reach consensus on the
approval or denial of a change, the issue will be forwarded to the Project Sponsor,
with a written summation of the issue, for ultimate resolution.
If required under the decision matrix or due to a lack of consensus, the Project Sponsor shall
review the issue(s) and render a final decision on the approval or denial of a
change.
Following an approval or denial (by the Steering Committee or Project Sponsor), the Project
Manager will notify the original requestor of the action taken. There is no appeal
process.
3.6. Communication Plan
Disseminating knowledge about the project is essential to the project’s success. Project
participants desire knowledge of what the status of the project is and how they are
affected. Furthermore, they are anxious to participate. The more that people are educated
about the progress of the project and how it will help them in the future, the more they
are likely to participate and benefit.
This plan provides a framework for informing, involving, and obtaining buy-in from all
participants throughout the duration of the project.
Audience This communication plan is for the following audiences:





Project Sponsor
Steering Committee
Project Manager
User Group Participants
Subject Matter Experts
Communications Methodology The communications methodology utilizes three
directions for effective communication:
Project Management Plan for Significant Event Notification
Page 11
Top-Down It is absolutely crucial that all participants in this project sense the
executive support and guidance for this effort. The executive leadership of the
organization needs to speak with a unified, enthusiastic voice about the project
and what it holds for everyone involved. This will be 'hands-on' change
management, if it is to be successful. Not only will the executives need to speak
directly to all levels of the organization, they will also need to listen directly to all
levels of the organization, as well.
The transition from the project management practices of today to the practices
envisioned for tomorrow will be driven by a sure and convinced leadership
focused on a vision and guided by clearly defined, strategic, measurable goals.
Bottom-Up To ensure the buy-in and confidence of the personnel involved in
bringing the proposed changes to reality, it will be important to communicate the
way in which the solutions were created. If the perception in the organization is
that only the Steering Committee created the proposed changes, resistance is
likely to occur. However, if it is understood that all participants were consulted,
acceptance seems more promising.
Middle-Out Full support at all levels, where the changes will have to be
implemented, is important to sustainable improvement. At this level (as with all
levels), there must be an effort to find and communicate the specific benefits of
the changes. People need a personal stake in the success of the project
management practices.
Communications Outreach The following is a list of communication events that are
established for this project:
Monthly Status Reports The Project Manager shall provide monthly written
status reports to the Steering Committee. The reports shall include the following
information tracked against the Project Plan:
-
Summary of tasks completed in previous month
Summary of tasks scheduled for completion in the next month
Summary of issue status and resolutions
Monthly Steering Committee Meeting These status meetings are held at least
once per month and are coordinated by the Project Manager. Every member of the
Steering Committee participates in the meeting. The Project Manager sends the
status report to each member of the team prior to the meeting time so everyone
can review it in advance.
Bi-Monthly Project Team Status Meeting These status meetings are held every
other month. Every member of the Project Team will be invited to participate in
the meeting. Project Manager sends the status report to each member of the team
prior to the meeting so everyone can review it in advance.
Project Management Plan for Significant Event Notification
Page 12
Websites User Group Participants and Subject Matter Experts may be updated
monthly at the discretion of the Project Manager. Information will be posted to
the project’s website.
4. Technical Process Plans
<This section describes the technical approaches to be used on the project. Depending on the
size and scope of the project, these plans may be incorporated directly in this section, or each
section may simply contain a reference or hyperlink to an external plan. For example, nearly
every project should create separate Configuration Management and Quality Assurance Plans.>
4.1. Process Model
<Describe the product development life cycle that the project will use. Examples include
waterfall, iterative, and incremental (e.g., evolutionary, spiral, or agile). If an iterative or
incremental model is used, identify clear milestones and provide the planned iteration number
for each task in the work breakdown structure. The project’s Gantt chart should reflect the
model used. Identify checkpoints at which management reviews are needed.>
4.2. Methods, Tools, and Techniques
<This section describes the design and development methodologies, programming languages,
software and hardware tools, and operating environments to be used, as well as pertinent
technical and management standards and procedures. Describe the following:




The hardware, OS, and network environments for development, test, and operation
Software tools including those for requirements management, design modeling, source code
and document version control, compiler or IDE, build automation, and so on
Development methodologies, including requirements development practices, design
methodologies and notations, programming languages, coding standards, documentation
standards, and system integration procedure
Quality assurance practices, including methods of technical peer review, unit testing,
debugging tools, defect tracking, integration and system testing, and test automation. The
details of these approaches will appear in a separate QA Plan or Test Plan.>
4.3. Configuration Management Plan
<This section could contain the configuration management plan for this project. For any but
very small projects, this section should refer to a separate document. The CM plan should
describe the activities and methods used for configuration identification, control, status
accounting, auditing, and release management. The configuration management plan should
address the initial baselining of work products, logging and analysis of change requests, change
control board procedures, tracking of changes in progress, and procedures for notifying
concerned parties when baselines are established and changed. Estimate the percentage of
project effort or the number of hours planned for configuration management activities.
Incorporate CM tasks into the project schedule and budget. List the personnel responsible for
establishing the baselines, maintaining the configuration management system, and conducting
CM reviews and audits.>
Project Management Plan for Significant Event Notification
Page 13
4.4. Quality Assurance Plan
<This section could contain the quality assurance plan for this project. For any but very small
projects, this section should refer to a separate document. The QA plan should describe the
activities and methods used to build a high-quality product by the sensible application of an
appropriate process. The plan should indicate the relationships among the quality assurance,
testing (or verification and validation), peer review, audit, and configuration management
activities. Identify the quality-related tasks to be performed, who is responsible for each, and the
target date for completion. Estimate the percentage of project effort or the number of hours
planned for quality assurance activities. Incorporate QA tasks into the project schedule and
budget. List the personnel responsible for performing identified QA tasks.>
4.5. Documentation Plan
<Describe the plans for creating system documentation deliverables, including installation and
maintenance guides, user guides, reference manuals, on-line help systems, release notes, and so
forth. List the documents to be created. For each type of documentation, describe: any pertinent
template, standard, or conventions to be followed; who will prepare it; who will review it; target
dates for initial delivery and baselining; and information about recipients, distribution, or
storage. A table like the one shown below is a convenient way to record this information.>
Document
Template or
Standard
Created
By
Reviewed By
Target Date
Distribution
4.6. Process Improvement Plan
<This section describes plans for assessing the project and its processes, determining areas for
process improvement, and implementing improvement plans without seriously disrupting an
ongoing project. Each project should address at least one process improvement activity, selected
from the following list:



New procedure or a new example of how to implement an existing procedure or process
Improved procedure or template based on lessons learned
New tool or improved use of a current tool
List the specific new process approaches to be tried and the anticipated impacts on the project.
As the project progresses, track how the new approaches are being used, how they are affecting
the project, and whether they had to be modified. Capture lessons learned from these
experiences during the project retrospective (see section 3.6).>
Project Management Plan for Significant Event Notification
Page 14
Revision History
Name
Raed Sadi
Date
2/14/2011
Reason for Changes
initial draft
Version
1.0 draft 1