<Consultant logo> <Client logo>

<Client Org. Name>

<Project Name> Project

Governance Plan

Distribution:
Prepared By:
Status: <Draft; Final>
Initial Release Date:
Latest Revision Date:

Contents of this document are proprietary and may not be distributed without the prior
written consent of <Consultant> and <Client>.

1
Document Approval Page
Project Sponsor ________________________________________Date _________
Name, Title
Client Org. Name

Project Owner _________________________________________Date _________

Name, Title
Client Org. Name

Project Owner _________________________________________Date _________

Name, Title
Client Org. Name

Project Owner _________________________________________Date _________

Name, Title
Client Org. Name

Project Manager _______________________________________Date _________

Name, Title
Client Org. Name

2
Revision History
<CONSULT
Date Reason <CLIENT>
ANT>

3
Table of Contents
Page

1. Introduction 6
1.1. Purpose 6
1.2. Scope 6
1.3. Objectives 6
1.4. Participants 6
1.4.1. Charlotte-Mecklenburg School District (<CLIENT>) 7
1.4.2. Superintendent of Schools 7
1.4.3. Curriculum & Instruction 7
1.4.4. Accountability 7
1.4.5. Technology Services 7
1.4.6. Educational Foundations (Funding Entities) 7
1.4.7. Other Stakeholders 8
1.4.8. <Consultant> 8
1.4.9. <CLIENT> MP Project 8
1.5. Relationships between the Organizations 8
1.5.1. Principles for Inter-Organizational Communication 8
1.5.2. <Consultant>-<CLIENT> Functional Roles 9
2. Project Governance 12
2.1. The Agile-Scrum Delivery Process 12
2.1.1. Agile Principles 12
2.1.2. What is Scrum? 12
2.2. Sprint Planning 13
2.3. Sprint Execution Monitoring 14
2.4. Sprint Reviews 14
2.5. Project Deliverables Approvals and Overall Project Approval 15
2.6. Scope Change Management 15
2.6.1. Definitions 16
2.6.2. Change Management Process 16
2.6.3. Personnel Authorized to Submit Changes 17
2.6.4. Change Request Preparation 18
2.6.5. <CLIENT> Personnel Authorized to Approve Changes 18
2.6.6. Review Period for Change Requests 18
2.6.7. Change Request Approval 19
2.6.8. Change Request Rejection or Deferral 19
2.6.9. Change Request Tracking, Reporting an Maintenance 19
2.7. Risk Management 19
2.7.1. Definitions 20
2.7.2. Risk Management Process 20
2.7.3. Risk Identification 21
2.7.4. Risk Assessment 21
2.7.5. Risk Quantification 22
2.7.6. Risk Response Planning 22
2.7.7. Risk Monitoring and Control 22
2.8. Issue Management 22
2.8.1. Issue Management Process 23
2.8.2. Issue Escalation Process 26
2.9. Communication Management 28

4
 2.9.1. Guiding Principles 29
2.9.2. Communication Strategy 29
2.9.3. Communication Management Process 30
2.9.4. Communication Vehicles 31
2.9.5. Project Communication Matrix 32

Appendix A. Change Request Form 38

5
1. Introduction
1.1. Purpose

This document describes the Governance Plan for the <Client Name> <Project Name> Project.
The purpose of the Governance Plan is to describe the specific roles and responsibilities of the
project and its stakeholders, focusing primarily on authority level and decision-making structure.
While some high-level roles and responsibilities are discussed in the Professional Services
Agreement and Statement of Work, the Governance Plan contains the detailed list.

1.2. Scope

This Governance Plan identifies the key governance roles and responsibilities and issue
escalation paths for the project. In addition to documenting the stakeholders involved in
managing the project, the plan covers who -- by role -- is:
 responsible for approving project documents,
 establishing contracts in support of the project,
 approving project deliverables,
 making decisions on project scope changes and resolving issues, and
 making the final decision to accept the system and its associated products from
<Consultant>.
This document is meant to clarify and expand upon responsibilities established in the
Professional Services Agreement and Statement of Work between <Consultant> and <Client>.

1.3. Objectives

<Consultant’s> reputation and standing within the marketplace for <project type> rests on the
manner in which <Consultant> supports and contributes to the <Client’s> requirement to provide
a fully capable <Solution Type> to the <Client User> communities. Ensuring that <Client> is
able to <provide the desired results> to the <Client User> community is paramount to
<Consultant>> achieving customer satisfaction and maintaining its standing with <Client> and
the marketplace. Hence, the <Consultant>objectives for the project are to:
 Achieve the earliest possible delivery of the <Project Name> solution components in an
incremental manner.
 Maximize the capabilities delivered within the <Project Name> solution.
 Ensure <Client> and <Consultant> project–related technical activities are coordinated to
avoid additional costs, or scope erosion or schedule delays.
 Build <Client User> community confidence in the quality and integrity of the <Project
Name> solution.

1.4. Participants

There are various organizations that are considered stakeholders of the project. Not all of the
stakeholders will participate in governance decisions and activities, but they will be affected by
the decisions and activities. A brief description of their organizational roles and responsibilities is
provided herein.

6
 1.4.1. <Client>

1.4.2. <Project Sponsor>

The <Project Sponsor’s title>, as Project Sponsor, has overall authority for the project. The
Project Sponsor provides vision and strategic direction for the project, provides policy
leadership, assists in removing barriers and supports change management initiatives, and
provides support to the Project Steering Committee (comprised of the designated Project
Owners) as needed. (A high level organization chart for <Client> is presented below as Figure
1.)

1.4.3. <Project Owner & Steering Committee Member 1>

The <Project Owner & Steering Committee Member 1’s title>, as a Project Owner, has joint
operational authority for the project. The Project Owner ensures conformance to the strategic
direction for the project, provides operational leadership, assists in removing barriers and
supports change management initiatives, and is a key participant in the Project Steering
Committee.
The <Client User> Community constitutes the primary and majority group of user stakeholders
for the <solution components> that will be enabled by the implementation of this project’s
solution. They are actively engaged in defining the detailed requirements for data, metrics and
their representation at the user interface.

1.4.4. <Project Owner & Steering Committee Member 2>

The <Project Owner & Steering Committee Member 2’s title>, as a Project Owner, has joint
operational authority for the project. The Project Owner ensures conformance to the strategic
direction for the project, provides operational leadership, assists in removing barriers and
supports change management initiatives, and is a key participant in the Project Steering
Committee.

1.4.5. <Project Owner & Steering Committee Member 3>

The <Project Owner & Steering Committee Member 3’s title>, as a Project Owner, has joint
operational authority for the project. The Project Owner ensures conformance to the strategic
direction for the project, provides operational leadership, assists in removing barriers and
supports change management initiatives, and is a key participant in the Project Steering
Committee.
The <Project Owner & Steering Committee Member 3’s title> is responsible for establishing and
enforcing <Client> policies and standards regarding the implementation and use of IT,
monitoring the <Client Name> <Project Name> Project, and assisting in the final decision of any
issue resolution, if necessary.
Members of <Client> Technology Services are assigned to the project as technical contributors,
and will become accountable for the support of the <project solution> once it is implemented
and accepted by <Client>.

1.4.6. <Other key Stakeholders>

Advocates, advisory groups, state organizations, federal organizational groups, parents, and
researchers are considered stakeholders in the outcome of the project.

7
 1.4.7. <Consulting Organization>

The <Consulting Organization> is responsible for the definition, design, development,

implementation, and (where necessary) support of data warehouse and business intelligence
applications for educational communities, such as <Client>. The <Consulting Organization>
structure is presented in Figure 2 below.

1.4.8. <CLIENT> MP Project

The organization of the <Client Name> <Project Name> Project is depicted in Figure 3 below.

1.5. Relationships between the Organizations

1.5.1. Principles for Inter-Organizational Communication

The following principles are to be applied to inter-organizational communication:

 Formal contract communication is to be conducted through the nominated formal
contract communication channel.
 Routine communication is encouraged at all levels as appropriate.
 Staff-line management arrangements are to be respected.
 <Client> and <Consultant> managers and leads are to be cognisant of all significant
interchanges between their respective organisations.
 A written record of significant meetings/discussions is to be kept and distributed to all
participants.
 Action items from meetings/discussions are to be recorded in a consolidated record and
managed to closure.
 Significant issues/conclusions/outcomes are to be formally confirmed between
<Consultant> and <CLIENT> as appropriate.
 Information is to be shared to the maximum possible extent.
The following principles are to be applied to <Consultant> communications with <CLIENT> and
its IT and end user <Client User> community
 Communication on matters relating to the MP Central Hub and Data Warehouse project
will normally be achieved through the <Consultant> Education Practice leadership
and/or the onsite <Consultant> project manager.
 Technical level discussions on <project solution> design issues are to be confined to
<CLIENT> Technology Services subject matter expert (SME) attendees at formal
technical reviews that are sanctioned by <CLIENT>.
 <Consultant> contact with the <CLIENT> user <Client User> community on MP Central
Hub and Data Warehouse and Performance Portals and Reports matters will not
proceed without prior <CLIENT> MP Project Manager knowledge and consent.
The following principles are to be applied to <Consultant> communications with the <Client
User> Community and its Representative:
 No communication on contractual matters is to occur with the <Client User> Community
and its representative(s).
 Technical discussions with the <Client User> Community representative(s) are to be
confined to matters of solution requirements definition or clarification. Legitimate contact
between the <Client User> Community representative(s) and <Consultant> staff would
generally cover <project solution> technical matters and requirements and related
quality system surveillance activities, particularly as relates to end user portals and
reporting.

8
  Contact between <Consultant> staff and the <Client User> Community representative(s)
is to be coordinated through the <CLIENT> MP Project Manager and/or the
<Consultant> Project Manager or his designee (the Business Analyst).
 The <CLIENT> MP Project Manager is to be kept appraised of all significant contact
between <Consultant> staff and the end users of the <CLIENT> <Client User>
Community.

1.5.2. <Consultant>-<CLIENT> Functional Roles

<Consultant>-<CLIENT> communications must be effectively conducted at all functional

management levels, and must take cognisance of all aspects of business and technical
management for both parties. The levels at which communication and interaction occur, and
their respective roles are summarised in Table 1 below:
Functional Level Role
Executive Arbitration/resolution of referred contract issues and disputes
Alignment of corporate and project objectives
Strategic corporate direction and leadership
Engender mutual commitment

Practice/Program Strategic leadership and direction

Communication of strategic guidance
Multiple project coordination and synchronization
Management and administration of scope definition and change
Relationship/expectation management
Resolution/elevation of referred contract issues and disputes

Contract Mgmt Contract administration and management, including change management

Performance management
Open reporting on achievement and progress
Resolution/clarification/elevation of contract issues and disputes

Project Mgmt Effective communication of problems, issues and risks

Proactive management of risks
Cooperative management of project issues and external interfaces/dependencies
Trusted (honest) reporting of progress – good and bad
Project team leadership
Understanding of each parties limitations, constraints and capabilities

Team Leads Cooperative interaction to resolve technical issues

Unreserved innovation to address risks and issues
Collaboration with other data warehouse / business intelligence and source data
systems providers to ensure satisfaction of dependencies
Table 1. Functional Levels and Roles

9
Figure 1. <CLIENT> Organization Chart

Figure 2. <Consultant> Organization Chart

10
Figure 3. <Project Name> Project Organization Chart

11
1 Project Governance
The following section describes the specific roles, responsibilities and processes for governing
the project.

1.6. The Agile-Scrum Delivery Process

Agile development using the Scrum methodology is the natural evolution of software processes
to support today’s accelerated, rapidly-changing business environment. Through a simplified
approach to system development, Agile incorporates a set of management and engineering best
practices for accelerating and improving the delivery process.

1.6.1. Agile Principles

The key principles of Agile development are based on a series of straightforward, proven steps.
The core principle that underlies the whole Agile process is “do the simplest thing that will work.”
And by working from this core principle, the development team can consistently identify better
ways to develop software and help others benefit from new information. These core principles
and concepts are defined in a guiding document for Agile development called the Agile
Manifesto.
Three of the principles that support the Agile Manifesto stand out as keys to Agile/Scrum’s
success:
- The user community and developers must work together daily throughout the project.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity - the art of maximizing the amount of work not done - is essential.
Through Agile development, we have come to value individuals and interactions over processes
and tools, working software over comprehensive documentation, customer collaboration over
contract negotiation and responding to change over following a plan.

1.6.2. What is Scrum?

Scrum as an open project management framework with an uncomplicated set of rules. The rules
enable an average team to organize themselves into a high performance team that greatly
exceeds the performance of traditional teams. The rules of Scrum allow continual inspection,
adaptation and self-organization and enable innovation to emerge. Within this environment,
teams produce valuable products earlier for the customers, enjoy high team spirit and satisfying
work, generate high productivity and customer satisfaction, and achieve the operational and
financial goals for the project.
Scrum enables teams to select their own work, and then decide, through close communication
and mutual agreement within the team, on how best to accomplish the work. This removes the
pressure of outside management from teams, significantly improving the quality of work
environment and life for developers while increasing employee retention.
So, in Agile/Scrum projects:
 Organizations break large initiatives down into smaller projects or releases.
 High-level, feature-driven plans evolve over time, replacing speculative, task-based
details.
 Continuous, “Just In Time” planning methods are substituted for detailed, upfront plans.

12
  The business sets the priorities. Teams self-organize to determine the best way to
deliver the highest priority features.
 Cross-functional teams break projects down into short, frequent iterations that
incorporate all aspects of development – e.g., planning, analysis, design, development,
testing, and integration.
 Features are worked on collaboratively and delivered in the order of business value.
 All stakeholders (executives, managers, customers, developers, testers, etc.) are
involved throughout the delivery cycle to ensure ongoing alignment with evolving market
needs.
 Working, tested system components serve as the primary measure of progress.
 Visibility into project status and progress is based on the undeniable truth of working
software.
And the Scrum Master plays a key role by:
 Representing management to the project, as the Scrum PM (Project Manager), filled by
a PM or Team Leader.
 Being responsible for enacting Agile and Scrum values and practices (as described
above).
 Ensuring that the process is followed - regular Scrums, Sprint Reviews, and Sprint
Planning and Sprint Retrospective meetings.
 Ensuring that the team is fully functional and productive.
 Being responsible for removing barriers (impediments) in coordination with the Product
owner and stakeholders.
 Enabling close cooperation across all roles and functions.
 Refereeing conflicts.
 Shielding the team from external interference.
The Scrum Master (SM) leads the Scrum process, and is the person who tries to optimize the
productivity of the whole team (including software development and business management).
The SM helps balance the tension that is typically generated between the two sides. The SM
exerts minimal external authority and is not identified by the team as a “taskmaster project
manager.” The SM’s key role is removing (or assuring removal of) the biggest impediments for
the team.
In most projects, development is slowed down by many issues identified as impediments during
daily meetings or planning and review meetings. With Scrum, these impediments are prioritized
and systematically removed, further increasing productivity and quality.

1.7. Sprint Planning

This meeting is to decide what the Team will be doing in the coming Sprint. This is where Scrum
identifies the equivalent of a detailed project plan. The attendees are comprised of the core
team (including the Product Owner and the Scrum Master). Additional parties may be invited if
they are useful to the Team. The roles and responsibilities are outlined in Table 4 below.
Participants
Product
Owner/ <Consultant> Project Client
Activity
Sponsor/ PM Team Stakeholders
Client
Revise Product Backlog R A C I
Elaborate on requirements - functional A I R C

13
 requirements
Add ‘design’ work needed for next Sprint into
I I R I
this Sprint
Create Sprint Backlog C C R I
Note: R=responsible, A=approves, C=consulted, I=informed
Table 4. Sprint Planning RACI Chart
The Product Owner (with others as needed) must prepare the Product Backlog (PB) before
every Sprint Planning Meeting. If the Product Owner fails, the Scrum Master must do this. (This
means that the Scrum cycles continue, and an increment will be produced. And all parties can
inspect this increment. Typically, the observation will be made that things would be better if the
Product Owner had prepared the Product Backlog.) We usually learn during the Sprint, so this
<Client User> needs to be reflected in the Product Backlog. New use cases are added, old use
cases are revised or deleted, priorities change, estimates change. This is Product Backlog
refactoring.
It is strongly recommended that before coming to the Sprint Planning Meeting, each PB item
have two estimates -- an estimate that reflects "why we want to do this item" and an estimate of
relative effort (e.g., an estimate in “Story Points” or some other relative weighting). The
prioritization of PB items is usually based on three things: business value, risk and effort (in
other words, cost-benefit).
The Product Owner describes the Product Backlog items the Product Owner wants the Team to
do in the next Sprint, and the Team determines whether they can commit to completing all or
many of those items. The Team can propose and explain why other priorities might be better,
but ultimately the Product Owner determines the priorities. On the other hand, the Team
determines how many PB items it can commit to. In this way, the power is balanced.
The Team then starts to take the PB items and break them down into tasks. Some teams want
to "know everything" before they identify the tasks, and this desire, while good in limited doses,
must be controlled. The Product Owner must be available to the rest of the Team to answer
questions about the Product Backlog. It is also useful that the Product Owner confirm for himself
that the tasks reflect the work needed to complete the PB items agreed to.
The output from the team analysis and planning is the Sprint Backlog. This includes a list of all
the tasks that will be done in the Sprint. Each task has an effort estimate and ideally only one
person assigned to it.

1.8. Sprint Execution Monitoring

The output from the team analysis and planning -- the Sprint Backlog – is formatted into a Sprint
Work Plan to use for tracking and reporting purposes. It includes a list of all the tasks that will
be done in the Sprint, along with the effort estimate and the person(s) assigned to it. The Work
Plan will be updated by the team members on a regular basis, to reflect work progress and
isolate any areas of concern.
Each <CLIENT> <Project Name> Project Sprint is planned to be two (2) months long. Each
week during the Sprint, Scrum meetings are to be held twice-weekly (Monday, Thursday) to:
identify what was completed in the previous work-week, what is planned to be completed (or
has been completed) during the current work-week, and what impediments exist to the timely
completion of any segment of work. The project’s management team is charged with facilitating
the resolution of any impediments.

14
 1.9. Sprint Reviews

The Sprint Review is held at the end of a Sprint for the Team to present to the Product Owner
and Stakeholders the functionality that was done (“potentially shippable product”). And if there is
a choice between less done or more done, a PB item should always be more done. It is always
necessary that the Product Owner and the Stakeholders completely understand the meaning of
"done". Functionality that is not done may not be presented or demonstrated. (If promised
functionality was not completed, the Team must make this clear to the PO.) The demonstration
of working software is the measure of progress and the basis for inspecting and adapting.
Functionality will be demonstrated from a team member workstation or another workstation. An
environment that is as close to the Production environment as possible will be used. Usually this
is the final Quality Assurance (QA) environment.
The required attendees are comprised of the core team (including the Product Owner and the
Scrum Master). Interested Stakeholders and other parties (e.g., users, customers, etc.) may
come. During the Sprint Review, the Team must discuss progress and how other factors are
affecting their work. So, discussion is an integral part of the Sprint Review.
The Sprint Review starts with one or more Team members discussing the Sprint Goal, which PB
items were promised, and which PB items were completed. And any key PB item, the PO had
some questions about it, so we did not complete it."). Any Team member (including the Product
Owner) may mention key things learned during the Sprint (e.g., new risks, new technical issues,
key <Client User>s about the functionality, new blocks, etc.) The majority of the time is spent
giving a demo of the software and discussing the <Client User>s. So, the Team members
present the demo and answer questions from the Product Owner and other stakeholders about
the functionality. Someone takes notes regarding desired changes to the system(s). The
stakeholders are free to discuss the working software, e.g., compliments, comments,
observations, criticisms, etc.

1.10. Project Deliverables Approvals and Overall Project Approval

The <Client <Project Name> Project is comprised of two basic types of deliverables: document
deliverables, and application / solution deliverables (code, database tables, etc.). A separate,
previously approved document governs the review and approval of document deliverables –
<CLIENT> <Project Name> Project Document Deliverables Management Plan
(https://<Consultant>-usa.securespsite.com/<Client>/mp/Shared%20Documents/<CLIENT>
%20MP%20Project_Document%20Deliverables%20Management%20Plan_Final_2009-08-
28.doc).
Key document deliverables that govern the evaluation and approval of the application / solution
deliverables are the Requirements Documents – in this case for the <CLIENT> <Project Name>
Project, the Requirements Documents for each of the Performance Portals and the associated
Performance Reports. The approved versions of these documents form the basis for the
preparation and execution of User Acceptance Tests (UATs) related to these portals and reports,
and their ultimate acceptance. The successful conclusion of each set of User Acceptance Tests
that are subsequently approved by the <CLIENT> <Project Name> Project Owners will
constitute the acceptance of that component of the overall <CLIENT> <Project Name> project
solution.
The acceptance of the portals and reports largely validates the underlying application code and
database tables upon which these portals and reports are generate. Additionally, though, other
approved document deliverables related to the application infrastructure, including design
documents, standards and guidelines, are used during code development and testing to verify
the adequacy of the infrastructure.

15
 1.11. Scope Change Management

Change management is the process of controlling scope changes to the project to ensure that
only authorized changes are applied. It involves receiving requests for change, analyzing them
for impact and feasibility, approving them before implementation, and tracking them through
completion.
The scope change Management process is a crucial mechanism that can affect the success or
failure of the project. This process is the primary vehicle for containing scope and ensuring that
<Consultant> and <CLIENT> management has the opportunity to make timely trade-offs
between the three key program variables of cost, time and scope. Inadequate change control
can lead to unexpected cost and time overruns. It is imperative that potential changes are
identified early, documented carefully, and approved prior to implementation.

1.11.1. Definitions

 Authorizing Agent – Any individual or group with authority to approve or reject Program
changes to requirements, scope, deliverables or schedules.
 Requester – Anyone who requests, a change, or requests information regarding the
status of a change. The requester may be a user, developer, operator, manager, or any
other Program stakeholder.
 Baseline – A point-in-time collection of agreed to deliverables identified within the
Project Statement of Work. The baseline is used as a measure, to manage change to
the project’s scope Plan by the <Client> and the <Consultant>. It can be modified only
through formal change control procedures.
 Change of Plan (COP) – Documentation of activities not originally considered within the
scope to be delivered or tasks to be performed as defined by the project’s Statement of
Work. A COP is any change to the baseline schedule, budget or scope.
 Change Package – A single change request or batch of related Change Requests
presented as a unit for analysis and disposition.
 Change Request – The mechanism for describing a requested change and for
capturing information about its solution and disposition. It may be in hardcopy or
electronic form.
 Change Log – The repository of information with the status of Change Requests.

1.11.2. Change Management Process

In order to effectively manage change, a change management process will be established to

identify, record, assess, and approve project changes, as depicted in Figure 4 below.
<Consultant> and <CLIENT> will follow this process to classify, prioritize, approve, or reject out-
of-scope changes to the project baseline.
Change Requests will be clearly defined, including cost and schedule implications to allow
<Consultant> and <CLIENT> management to make informed decisions about potential project
changes. <Consultant> will always need prior authorization and approval of expenditures by
<CLIENT> management before starting work on out-of-scope, non-baseline changes.

16
Figure 4. Scope Change Management Process

1.11.3. Personnel Authorized to Submit Changes

The <Consultant> and <CLIENT> MP Project Sub-Team Leads (ETL, SharePoint/Portals,

Reports, and Data Modeling) can submit Change Requests. Any MP Project Sub-Team
member who proposes a change should present it to their Lead for submission.
<Consultant> and <CLIENT> management who are key stakeholders in the project (such as the
Project Owners, the <CLIENT> MP Project Manager or System Workstream Lead) may also
submit Change Requests.

17
 1.11.4. Change Request Preparation

When a need for a change is identified, the originator (<Consultant> or <CLIENT>) completes a
Change Request form and submits it to the <Consultant> <Project Name> Project Manager.
See Appendix A for a sample Change Request form. The <Consultant> <Project Name> Project
Manager estimates the analysis time and cost and records it on the Change Request.
If the changes are minor (impact to the schedule does not impact the critical path), changes will
be tracked in a log and submitted as a group once the next significant change requires
approval.
The <Consultant> <Project Name> Project Manager will engage a SME who will conduct a
detailed impact analysis of the submitted change. The SME and one or more of the team
members will be assigned to analyze the approved change and define schedule and cost
impacts within 3 working days.
 The <CLIENT> <Project Name> Project Manager approves the analysis effort.
 The <Consultant> <Project Name> Project Manager reviews the change with the SMEs
and project architect(s), as appropriate.
 One or more team members are assigned to analyze the client-approved change (the
estimated time and cost should not be exceeded).
 The <Consultant> <Project Name> Project Manager updates the project schedule with
the resulting task(s) (including cost) from the impact analysis.
 The SME team member updates the Change Request with the resolution and provides
an estimate for designing and implementing the change.
 The <Consultant> <Project Name> Project Manager updates the change management
log.
 All costs are considered for the change, including documentation, management
overhead, system performance and schedule impact.
 The detailed impact assessment, including estimated effort and cost, is documented and
communicated to <CLIENT>, requesting approval to implement the change.
If multiple Change Requests affect the same components of the project or Sprint deliverable, then they
will be compiled into a change package and analyzed as a group.
The <Consultant> <Project Name> Project Manager reviews the Change Request with the
<CLIENT> <Project Name> Project Manager to determine whether the change is a candidate
for implementation. The <CLIENT> MP Project Manager will review the proposed change with
the <CLIENT> <Project Name> Project Owners. If the Project Owners agree that the change is
warranted and that either the funds are available and assigned or an existing comparable scope
item is to be replaced, one or all of the Project Owners will approve the Change Request and
will direct the <CLIENT> <Project Name> Project Manager to authorize the <Consultant>
<Project Name> Project Manager to proceed. No further analysis or implementation will be
performed without client approval and funding, as required.

1.11.5. <CLIENT> Personnel Authorized to Approve Changes

The <CLIENT> MP Project Owners are the representatives identified to <Consultant> to

formally approve changes.

1.11.6. Review Period for Change Requests

The <CLIENT> change review period to approve proposed changes is 5 business days,
(beginning on the submission date). The date shown on the Change Request always reflects
the date that the change is submitted to the <CLIENT> <Project Name> Project Manager. At
18
the completion of the review period the Change Request will either, be approved, rejected or
deferred based on its business and technical value.
Upon completion of the <CLIENT> <Project Name> Project Owners review, the Change
Request should be signed, dated, and returned to the <Consultant> <Project Name> Project
Manager. Approval delays will result in schedule slippage.
Exceptions to this review timeframe may be negotiated between the <Consultant> <Project
Name> Project Manager and the <CLIENT> <Project Name> Project Manager. This negotiation
should occur prior to the end of the 5 business day period. Large Change Requests may not
realistically be reviewed in a 5 business day period and the <Consultant> <Project Name>
Project Manager and the <CLIENT> <Project Name> Project Manager will negotiate an
appropriate review period.

1.11.7. Change Request Approval

When the Change Request is approved by the <CLIENT> <Project Name> Project Owners, it
should be signed, dated and returned to the <Consultant> <Project Name> Project Manager. A
Change Request can be approved with conditions. This can be a list of items that the
<CLIENT> wants <Consultant> to address before approval is granted. Additional client-
requested work or changes might be considered out of the scope of the project and could
require additional funding by <CLIENT>.

1.11.8. Change Request Rejection or Deferral

When a Change Request is rejected, the <CLIENT> <Project Name> Project Owners will sign
and date the “Rejected By” section of the Change Request. The <CLIENT> <Project Name>
Project Owners will provide an explanation for the rejection.

1.11.9. Change Request Tracking, Reporting an Maintenance

The status of all Change Requests are tracked and reported on a regular basis to <CLIENT>
and <Consultant> management, to ensure that changes are being implemented according to
schedule.
The Change Log summarizes and tracks the status of changes. A Change Log will be
maintained from which the status of individual Change Requests can be obtained and trends
can be analyzed. This Change Log will track each individual request from initiation through
rejection or installation, and will also provide simple metrics that can give insight into the nature
and status of requests and changes.
The <Consultant> <Project Name> Project Manager maintains all change of scope
documentation, as part of the change management process, into the project’s SharePoint
database. An Open Change Log report will be printed weekly (more frequently if required) and
reviewed with the <Consultant> <Project Name> Project Manager and other appropriate
individuals based on the nature of the changes. <Consultant> will formally track and report the
status and impact of all identified changes. Significant changes will be identified in the Issues
section of the weekly status report to <CLIENT>.
All Change Requests, both approved and rejected, will be maintained for the life of the project in
the project’s SharePoint database. Change Request Reports will be tracked by the Sprint
phase in which they are completed.

19
 1.12. Risk Management

Controlling risk is fundamental to project success. It is a project management “best practice”

developed to avoid and minimize risk and assure quality. The methodology for risk
management is based on early identification of issues, coupled with risk assessment, analysis
and mitigation. Identifying, assessing and quantifying risks enables proactive action which can
serve to minimize the impact of adverse risks and maximize the impact of opportunities.
It is essential to understand that risk assessment is subjective and that different people will
perceive risks differently. Risk assessments should record all views with the majority view being
accepted as the guide.
In the <CLIENT> <Project Name> Project, risks can be identified by any identified stakeholder
or project team member and will be tracked and managed by the project’s management team.

1.12.1. Definitions

 Risk – Any potential events that can adversely impact the Program technical, cost, or
schedule performance.
 Probability of Occurrence – The probability that the unwanted event that defines the
risk will occur. Probability of occurrence will be expressed as high, medium, or low.
 Impact or Loss – The consequences to the project if the risk occurs. Impact will be
expressed as a high, medium, or low risk.
 Risk Exposure – An assessment of the overall threat to the project of the risk, based on
the probability of the risk item occurring, and the severity of the impact, if it should occur.
Risk exposure will be calculated in the same terms as impact, in order to allow
comparison of risk mitigation alternatives.
 Risk Mitigation – A plan, or course of action, to be implemented prior to risk occurrence
that either eliminates or reduces the probability of the risk occurring or reduces the
impact if the risk should occur.
 Mitigated Risk Exposure – The revised assessment of risk exposure, with the risk
mitigation plan in place. The goal of risk mitigation is to make this rating as low as
possible.
 Risk Mitigation Status – The current status of the risk mitigation activity.
 Risk Contingency Plan – A plan developed for implementation if the risk event actually
occurs.

1.12.2. Risk Management Process

The Risk Management process is an iterative process that is initiated at the start of the project
and continues throughout the project life cycle. Not all project risks can be identified, both
because of unknowns and because all planned events include some risk. The Risk
Management process is intended to qualify and quantify risks so that the most significant risks
are managed.
Risks can and should be identified by any <CLIENT> or <Consultant> project team member or
stakeholder. They should be submitted to the Project Manager to manage and track. The
Project Manager performs an initial review of the risk and allocates it to the appropriate SMEs
for further definition and assessment. In some cases, the item requires additional information
from the originator, or may be rejected for a number of reasons.

20
Once identified, risks are recorded and categorized by the originator on a Risk Inventory and
Assessment Worksheet. The Worksheet is completed by the Project Manager and by the
Management Team as the risk is assessed. The risk status will change during its life from active
to pending or closed. The risks will then be analyzed, reviewed, and reported as part of the
status reporting process. Risks are analyzed qualitatively, assessing them for their probability of
occurrence and likely impact on the project domains such as cost, time and performance.

1.12.3. Risk Identification

Risk identification entails determining which risks are most likely to affect the project and then
documenting the characteristics of each. Each risk should be stated as an event that may occur
and that if it occurs would have a negative impact on the project. Documenting risks effectively
requires describing each risk clearly and categorizing the risk by impact and probability of
occurrence. Risk statements include:
 The future event or situation that poses the risk.
 The consequences of that event or situation.
 The source of risk.
During Project Execution, each project team member should be encouraged to identify risks as
they occur and report these to the Project Manager using the Risk Identification and
Assessment form.
Risk Assessment
Risk Source:

Risk Probability: Cost Schedule Quality

Identify probability for each area of
impact identified using risk
probability matrix
Risk Impact Rating: Cost Schedule Quality
Identify impact rating for each area
of impact identified using risk impact
matrix

Table 2. Risk Identification & Assessment form

Risk sources include:
 Internal – things that the project team can control or influence
such as staff assignments
 Project – things that require project level control
 External – things beyond the control or influence of the
Program team, such as new technology or regulatory requirements.
Risk Impacts include:
 Schedule risk
 Budget risk
 Scope (Quality) risk.

1.12.4. Risk Assessment

The Project Manager will compile the risks in the Risk Inventory and Assessment Worksheet.
The Project Manager will review each risk statement for complete information and assess risks
to ensure that they are not duplications or symptoms of identified risks or issues. Risks that are
rejected because they are duplicates or symptoms may provide additional information that can

21
be added to existing risks. The Project Manager should add reports of issues (risks that have
already occurred) to the Issues Log. The risk owner should indicate the action taken and return
a copy of the risk statement to the individual that identified the risk.
Actions to be taken include:
 Add risks to Risk Inventory and Assessment Worksheet.
 Notify submitter of risks not added to the Risk Assessment Inventory due to
incompleteness or duplication.
 Update to existing risks, as appropriate.
 Add to Issue Log, as appropriate.

1.12.5. Risk Quantification

Risk quantification includes evaluating risks and risk interactions to determine the range of
possible negative project outcomes and to quantify these outcomes. Quantifying risks
determines which risk events warrant response and the scope of the response. Note that risks
with multiple impacts should be quantified using each impact. The most significant impact
should be used to determine the risk value.
The outputs of Risk Quantification are risk values for each risk. Plotting the highest risk values
for each risk on the risk matrix determines the risk priority. The risk priority serves as an input to
the risk response process step. The Project Manager will work with the risk submitter and
SMEs to quantify risks via this method.

1.12.6. Risk Response Planning

Risk response planning involves defining actions to respond to risks. Risk response generally
fall into one of three categories:

 Avoidance – Eliminating a specific risk, usually by eliminating the cause

 Mitigation – Reducing the expected risk value by reducing the probability of
occurrence or the impact or both
 Acceptance – Accepting the consequences, actively or passively. Active acceptance
includes developing contingency plans to execute should the risk event occur. Passive
acceptance includes accepting the potential risk impacts.

1.12.7. Risk Monitoring and Control

Risk monitoring and control includes identifying enhancement steps for opportunities and
responses to risks. Risks will be reviewed weekly. The Risk Log will be used in weekly
Program status meetings to review risks, monitor for risk symptoms and track responses.
The Risk Log is used to track risks and provides a summary of the project risks. The Project
Manager will maintain the Risk Log, and update risks as they are identified, assessed and
quantified. The Risk Log will calculate the impact rating by multiplying the risk impact by the risk
probability. The resulting risk impact rating serves to prioritize risks. The risk impact rating
serves as an input to risk response planning. Risks with a high impact rating should receive
more response planning effort. The log used to track risks for the <CLIENT> <Project Name>
Project is maintained electronically on the project’s SharePoint site. The log is used to both
track and report on risks status, both to the project team as well as to the project’s key
stakeholders and the project owners / sponsor(s).

22
 1.13. Issue Management

Every project has issues that hinder progress. It is important to ensure that these issues are
identified and formally tracked by the project’s management team. As issues are identified, the
project’s management team needs to assign them to resources who can quickly resolve them,
identifying both the individuals who will do the work to resolve the issues and the individuals
who will monitor the status of the issues and the progress being made on the resolutions.
Each project will select a tool to implement the issue management procedure. The specific tool
chosen, whether simple or highly-specialized, will often drive the procedural details of Issue
Management. This document is intended to be tool-independent, however, the workflow or
sequence of events, the terminology used, and the specific forms and reports will vary from
project to project, depending on the tool and the environment. Adapt this document to reflect
the project environment, but be sure that each aspect of the procedure is adequately covered.

1.13.1. Issue Management Process

To effectively deal with issue management, the entire project team must be aware of the
importance of identifying issues and getting proper resolution. The following procedure will
ensure that issues are visibly tracked. A flowchart depicting this procedure is attached as Figure
5 below. References to the steps in the flowchart are included below in parentheses.
 Identify the issue. Throughout the project, any issues that could hinder the team’s
ability to meet the project objectives must be identified. Some issues may be broader,
identifying a problem or risk external to the project that may impact project or business
objectives. Issues can be identified by anyone involved with the project. Each project
must identify an appropriate tracking tool and determine how to apply this procedure by
entering and updating data using the tool.
 Document the issue (Step 1). The person who identifies the issue must document it.
The documentation must include the date the issue was identified, who identified and
documented it, and a description of the issue.
 Review and classify the issue (Step 2). The project’s management team must review
each new issue to determine if the documentation is adequate; when the issue will begin
to impact the project’s schedule, and therefore cost; and classify it by type. The typical
types of issues may specifically be defined by the tool being used and the way it is set
up, but, in general terms, they are action items, problems, changes, and risks.
 Identify duplicate and out-of-scope issues (Step 3). The project’s management team
must check whether the issue has already been reported and logged. Duplicate issues
should not be deleted, rather they should be cross-referenced. The Statement of Work
and project plan must be the basis for determining whether an issue is an in-scope
problem, such as a bug or missing hardware component, or an out-of-scope change,
such as a new business, process or technical requirement or a change in the
organizational responsibilities. Out-of-scope issues must be identified as such, and a
change request must be prepared to initiate the Scope Management procedure.
 Determine resolution approach and estimate of effort (Step 4). The project’s
management team must assign an appropriate individual to determine the optimal
approach for resolving each issue, which may vary depending on type of issue, and
prepare an estimate of the required effort. Action items usually require scheduling and
an updating of the project plan. Problems must be analyzed, estimated, and scheduled.
Changes must be analyzed, estimated, and approved using the Scope Management
procedure. Risks typically require a mitigation plan, accepted by management, and a
mechanism for monitoring, using the Risk Management procedure. The responsible
23
 person must be an individual who has the knowledge and authority to make decisions
regarding the issue.
 Approve or reject the resolution approach and estimate (Step 5). An appropriate
member or members of the project’s management team must approve or reject the
resolution approach and estimate of effort. The project manager must set the criteria for
determining the appropriate management team member, including escalation guidelines.
When an issue resolution approach and estimate is approved by the appropriate
management team member, the issue log and project management plans must be
updated accordingly. If rejected, the management team member must document the
reason for rejection and return to Step 4 for reassignment.
 Implement the resolution (Step 6). The project’s management team must assign an
appropriate individual to implement the approved resolution for each issue. The
management team must also assign a priority to the issue and a due date for resolution.
When necessary, the project’s management team may need to reset priorities or
reallocate issues so that a resolution is achieved. The individual assigned to implement
the issue resolution must confirm that the due date is reasonable based upon the
estimated effort. The due date for an identified risk may be the next follow-up date, the
next decision date, or a date when the risk will have passed. The issue log and project
management plans must be updated to reflect the assignment and the confirmed due
date.
 Monitor and control progress (Step 7). All issues must be tracked on an issue log that
will be maintained to formally track the status and resolution of the issues. The issue
log, usually generated by the tool being used, must at least include the issue number,
short description or title, classification, status, owner, priority, assigned due date, project
impact date, and expected completion date. This is the primary tracking mechanism for
action items and problems. Changes must be tracked in the issue log until resolved, and
then closed, including a reference to the change request number, if applicable. Risks
are typically monitored by following a Risk Mitigation Plan, but the status is often tracked
using the issue log.
 Report progress on issue resolution (Step 7). The issue log must be presented as a
part of the weekly status report, discussed in the weekly status meeting, and made
available to all team members. New issues and new resolutions must be presented at
an appropriate level of detail. All status changes must be confirmed and late resolutions
must be addressed, rescheduled, and perhaps reassigned. Also, a summary of the key,
unresolved issues should be used in the monthly status reporting to the client project
management and included in the monthly Delivery Excellence Project Status Report.
 Determine if the resolution has been implemented (Step 8). With every reporting
cycle, newly implemented resolutions are reported before being removed from the open
issue reporting.
 Communicate issue resolution (Step 9). Documented resolutions of issues must be
made available to all team members. The status of an issue is changed to Closed when
the resolution has been implemented.

24
Figure 5. Issue Management Process

25
 1.13.2. Issue Escalation Process

Technical issues are expected to be resolved within the <CLIENT> MP project team and
supporting <CLIENT> technical components. Issues that usually engage the <CLIENT> MP
project’s management team are related to schedule and product backlog prioritization and to
whether an item is in or out of Sprint or project scope.
On occasion, an issue may not be resolvable within the <CLIENT> <Project Name> project
team and its direct management team (<CLIENT> <Project Name> Project Manager and
<Consultant> <Project Name> Project Manager). Some examples of types of issues that might
be escalated to the <CLIENT> <Project Name> Project Sponsors and <Consultant>
management team.
 Policy Issues
 Schedule
 Scope
 Adverse project impacts
 Go/No-Go recommendations
 Vendor disputes
 Stakeholder disagreements
 Funding
 Critical staff issues

1.13.2.1. Examples of Types of Escalation

 Escalation will occur if at any time the necessary activities either are not being
completed or appear that they will not be completed timely, resulting in a risk to agreed
upon target dates.
 Escalation will occur if at any time it appears either requirements are not being met or
cannot be met or those requirements may be contrary to state or county expectations
with regard to quality of the system and its subsequent impact on state projects.
 Escalation will occur if at any time an issue is raised for which a decision is needed in
order to continue progress on the completion of the activities.
 Escalation will occur if the escalation governance structures are not able to reach
concurrence on an issue where concurrence is needed to proceed.

1.13.2.2. Escalation Process

This Escalation Process, as depicted in Figure 6 below, identifies the approach used to
coordinate the discussion and resolution of critical items. In addition to documenting the
approach to escalation, the process covers who participates in escalation, and how resolutions
are documented.

26
Figure 6. <Consultant>–<CLIENT> Management Interfaces and Roles and Issue Escalation Paths
For issues not resolvable within the <CLIENT> <Project Name> project team and its direct
management team (<CLIENT> <Project Name> Project Manager and <Consultant> <Project
Name> Project Manager), the <CLIENT> <Project Name> Project Manager will notify and meet
with the Project Owners in order to resolve the issue. In the event that the <CLIENT> <Project
Name> Project Manager and Project Owners are unable to resolve the issue, they determine
the urgency of the issue and escalate to the Project Sponsor.
If the issue resolution can be delayed until the next scheduled Project Owners meeting without
negative impact to the project, its schedule or its budget, the <CLIENT> <Project Name> Project
Manager will be asked to schedule the issue for the agenda of the next meeting. If timing is
critical or resolution cannot be delayed the Project Owners will be contacted to resolve the issue
on an emergency basis.
When an item is escalated, the appropriate participants are notified by e-mail, which includes
the date of the scheduled meeting. The issue should be incorporated into the next Project
Owners meeting within five work-days of the notification of escalation.
The notice of escalation includes a summary of the issue and the analysis of each party’s
position. The participants must review the analysis prior to the scheduled meeting. All
correspondence is stored on project’s SharePoint site and cross-referenced to the project’s
Issues Log.
The Project Owners will:
 Review escalated issues and solution alternatives.
 Approve or deny recommended resolutions.
 Commit appropriate resources to support the resolution.
 Provide expedited response and direction on issues which may impact the scope or
schedule of the <CLIENT> <Project Name> Project activities.

27
Additional items to consider when resolving the issue:
 Discuss who facilitates or leads the escalation meeting.
 Discuss how the meeting is structured (e.g., open discussion, facilitated discussion of
key points, or position-rebuttal format).
 Indicate if all participants are mandatory or if a general majority or quorum is
sufficient.
 Discuss who documents the meeting minutes and when they are distributed.
 If the item is resolved at the meeting, discuss how the resolution is documented.

1.14. Communication Management

The purpose of Communications Management is to consistently manage the distribution of

communications to all project stakeholders and to report progress on a regular, consistent basis.
Communications Management ensures that all stakeholders receive relevant and timely
information related to the overall <CLIENT> <Project Name> Project. This timely information
can then be effectively used to make informed decisions.
Communications is one of four Organization Support Systems, the others being Education,
Reward and Recognition, and Staffing. While Communications may initiate certain activities,
such as publicizing new assessment criteria, they will always complement and reinforce other
support system activities that raise awareness, increase understanding, and transfer knowledge
and skills.
Project communications fall into one of the following categories, each with its own procedures:
Ongoing Communications. These communications are produced once or updated
regularly and are always available 24 hours a day. Permanently posted Education Curricula
and Project Status are examples.
Supporting Communications. These communications are one piece of a bigger activity,
generally occurring only once or a couple of times. An example is the communication
announcing a new help aid, where the tool, itself, is the primary focus. Although some are
unforeseen, these communications almost always appear as project plan tasks within the
activity they support.
Communications Campaign. Special communication events and vehicles are being
planned to surround stakeholders with messages and generate enthusiasm. Examples are:
 Electronic “Newsletter”
 Brown Bag Lunches
 Stakeholder Interviews and Testimonials
 Frequently Asked Questions
 Lessons Learned Workshops
 Special Presentations
There are two aspects of the recipient organization relevant to the project communication
strategy. They are: (1) the values, beliefs, and attitudes of the organization’s culture, and (2) the
effectiveness of existing communication channels. Our intent is to define stakeholder
information needs, evaluate whether we currently meet those needs, and, if not, what we must
do to bridge the gap.
The following project stakeholders are considered to be the audiences in scope for
Communications Management:

 <CLIENT> <Project Name> Project team members (both <CLIENT> and <Consultant>)

28
  <CLIENT> <Project Name> Project solution end users
 <CLIENT> <Project Name> Project Owners and Sponsor
 Other <CLIENT> management and stakeholders
 <Consultant> management

1.14.1. Guiding Principles

The following guiding principles should be adhered to when developing and delivering project
related communications:
Make managers accountable for communicating critical messages to their direct
reports. The commitment to change by front line employees becomes moot without buy-in
from the person to whom they report. Since perceived power, not leadership style, is the
biggest influence on front line employees, and distributing information to all employees
equally fails to recognize the elevated status of management staff, communication intended
to change employee behavior will be delivered by an employee’s immediate boss. Each
communication will include an action item producing evidence that the message reached its
target audience.
Build feedback loops into all communications. Wherever appropriate, communications
will be two-way, providing the project team with immediate input for improving the project
and letting target audiences know their opinion counts.
Develop understandable messages. To avoid misinterpretation by and alienation of the
target audience, program communications will be clear and free of related jargon. Each
communication should contain only one key message or theme.
Provide opportunities for target audiences to ask questions.
Demonstrate alignment with business strategies. Where possible, Communications will
focus on content that clearly or explicitly supports the organization’s strategic objectives or
near-term strategies.
Adapt communications to fit the audience. Communication vehicles and message
content will be designed to address the requirements of individual targeted audiences.
Don’t let them forget. Project communications will be frequent, regular, and through
multiple channels, increasing the chance that messages will be noticed and instilling the
belief that the new approach “won’t just go away.” Whenever possible, communications will
be distributed in sufficient time to prevent stakeholders from first receiving information
“through the grapevine.”
Release communications in a timely manner.
Attend to outside influences. The communications strategy will recognize that, although
only a subset of the organization’s employees are targeted stakeholders, excluded
employees may nevertheless influence their co-workers’ behavior.

1.14.2. Communication Strategy

There are three variables to any communication with stakeholders. They are the:
Message. The message to be distributed.
Vehicle. The means for distributing a message.
Sender. The individual(s) in whose names messages are sent, although they may not
be the creators of the message.

29
We will shape our message, select our vehicle(s), and assign our sender(s) in different
combinations to suit the result we are looking for. However, the following task template will apply
to almost every communication we produce:
 Determine the purpose of a message and the information category it falls into.
 Select one or more communication vehicle(s) pre-chosen as appropriate for that
category and target audience(s). In general, the more important the message the greater
the number of vehicles used and the more frequent the delivery.
 Determine the pre-identified sender(s), depending on whether the message is intended
to change behavior or contains critical information stakeholders need to do their job.
 Develop the message.
 Test a prototype of the message with a representative from each of the primary
stakeholder target areas.
 Prepare the sender(s) for delivering the message and receiving related questions and
feedback

1.14.3. Communication Management Process

The <CLIENT> <Project Name> Project Manager will be the focal point for managing and
distributing all project communications. The <Consultant> <Project Name> Project Manager will
be responsible for all <Consultant>-<CLIENT> contractual communications for the project, and
will support the <CLIENT> <Project Name> Project Manager in preparing content for <CLIENT>
stakeholder or end user community or externally facing communications. The communications
strategy will be to communicate and report effectively, but not effusively, matching content and
audience with the appropriate tools. Communications will be targeted to support the <CLIENT>
<Project Name> Project objectives.
All non-contractual project communication will be processed through the <CLIENT>
Communication Manager. Communication will utilize standard templates where possible. The
<CLIENT> Communication Manager will be responsible for:
 Drafting or revising the content based on the target audience.
 Approving the content with subject matter experts (when needed).
 Choosing the appropriate communication media.
 Reviewing content with the internal communication team.
 Receiving a sign off release from the communication owner (or designated
representative).
 Receiving approval from the <CLIENT> <Project Name> Project Manager.
 Delivering the communication.
The following table (Table 3) outlines the information about the project needed by each type of
audience.
Target Information Need Key Messages Comments
Audience(s)
All Stakeholders  Why change is needed  This will happen  Both internal and external
 How it supports the  Senior Management staffing resources are extremely
business supports this limited in number, tenure and
 The Vision and Values  New opportunities depth of experience
 Long-term impact  We are institutionalizing  IT is trying to overcome the
 Short-term impact best practice increasingly negative image held
 Long-term strategy and  Cultural change takes by its clients
plan time  Voluntary IT turnover has been
 Current status  Adopting this new significant in recent years
 Who were the decision discipline will improve the  The organization’s IT has
makers service we provide and experienced numerous process

30
Target Information Need Key Messages Comments
Audience(s)
 Why wasn’t I involved our working environment improvement and redesign
 When I will become  This is an essential initiatives, all with limited
involved component of our growth success
strategy  Users are generally out-of-touch
with IT issues affecting them
 Users are currently not
accountable for managing to an
IT budget.
Business  How this improves results  I will be happy with the  Users are not used to being told
Sponsors  How I fit into the process results some IT investment requests
 What I need to do  I will receive a higher simply won’t get done
differently quality product with  Users generally have unrealistic
 Support I will receive greater business value expectations of what IT can
 Impact of IT <Client User>  Critical work will get done deliver
curve in time
Project  How I fit into the process  I will be held accountable  Undefined processes and role
Practitioners:  What I need to do  This is doable responsibilities are causing
 Project differently  I can get the help I need tension between business
Managers  When I’m expected to start  Management supports clients and IT Project Managers
 Analysts /  Support I will receive this
Programmers  <Client User> curve I face  This will help my career
 Business Clients  This will make my job
more enjoyable
IT Leadership:  How I can help  I share responsibility for  History shows that senior
 Chief Information  What I need to learn achieving the vision management behavior
Officer  What I should tell my  I am accountable for sometimes undermines the
 CIO Direct subordinates demonstrating my change process
Reports  What I can expect and support
 Directors when
 Managers

Table 3. Communication Requirements by Audience

1.14.4. Communication Vehicles

The following matrix maps categories of information to the communications vehicles most
appropriate under different conditions. This matrix represents the ‘general rule’ and as such may
be applied to all stakeholders. Obviously for some stakeholder groups, where a certain vehicle
may not apply to that audience, it is anticipated that an alternative vehicle will be chosen.

31
 Vehicle

Executive Committee Meeting

The Organization Today

Directors Staff Meeting

IT Department Meeting

Performance Review
Direct (Surface) Mail
Central Office News

CIO Staff Meeting

Brown Bag Lunch

Project Meeting
Teleconference

Training Class
Presentation

One-on-One
Voice Mail
IT News

Intranet

Poster
E-Mail

Video
Flier
Message Category
Emergency Messages
Training Messages
Education Messages (Non-Training)
Reward and Recognition Messages
Staffing Messages
Tool Messages
Transition Related Messages
Alignment Messages
Marketing Messages

Use for low, medium or high impact messages

Use only for medium or high impact messages
Only use for high impact messages
Table 4. Communication Vehicles

32
 1.14.5. Project Communication Matrix

The following matrix (Table 5) presents an initial structure and plan for communications for the <CLIENT> MP Project.
Type/Title Timing Vehicle Content Objectives Key Messages Receivers Senders Comments
Campaign
Project Sponsor <specific Presentation  Project  Introduce project to Asst.  IT is committed to change IT Superinten
Kick-Off Meeting date> Introduction Superintendents, Area Leadership dent
 Your commitment is
 Kick-off Superintendents, essential for this program
Presentation Directors to succeed
 Prime attendees so they
can hold their own kick-
offs
 Gain buy-in
Staff Kick-Off <specific Presentation  Program  Introduce Project  IT is committed to All Staff Area Each Area
Meeting date> Overview improving service Superinten Superintendent will
 Obtain buy-in
 Program Plans  The organization is dents hold a kick-off
investing in you session for each
 Your viewpoint is area
important
 There is a viable future in
IT
 This is an essential
component of the
organization growth
strategy
Letter to each <specific Direct (Surface)  Personal  Obtain buy-in  IT is committed to change All Staff CIO
employee from CIO date> Mail message from  Reinforce key messages  The organization is
CIO  Reinforce strength of investing in you
 Course checklist sponsorship  You must invest in your
own career
 This is an essential
component of the
organization growth
strategy
Project Introduction <specific e-mail  Program  Keep plant managers  Your viewpoint is Directors Project
for Directors date> objectives informed important Manager
 Outline Plan  Invitation to participate in  IT is committed to

33
Type/Title Timing Vehicle Content Objectives Key Messages Receivers Senders Comments
a kick off presentation improving service
Project Overview for <specific Presentation  Project overview  Inform managers of  IT is committed to Areas Project
Directors date>  Project Plan project details improving service Directors Manager
 Obtain buy in  The organization is
 Plan rollout details investing in you
 Your viewpoint is
important
Staff Social Kick Off <specific Social Event  Kick-off  Generate enthusiasm  IT is committed to change All IT staff NA
event date> presentation from  Reinforce strength of  The organization is
CIO sponsorship investing in you
 Progress report
from Sponsor
Business Sponsor <specific One-on-one  Project overview  Generate enthusiasm  IT is committed to Business Area Each director will
Kick-Off dates>  Plan improving service Sponsors Director be held responsible
 Obtain buy-in
 Introduce program  You will receive a higher for introducing the
quality product with program to their
greater business value business
 Your commitment is counterpart.
essential to success
 You have a role to play in
improving results
 This is an essential
component of the
organization growth
strategy
Poster Campaign <specific Poster Various to include:  Reinforce key messages  Will vary All IT Staff NA
date> on  Program  Maintain visibility
objectives
 Key measures
 Progress
Create Physical <specific Flyer/Poster Various to include:  Provide Information  IT is committed to change All IT Staff NA Information
Notice Board date> presented on board
 Program  Maintain visibility
objectives must be updated
 Key measures frequently to
maintain interest
 Progress
 Services
 FAQ’s
Create Web Site <specific SharePoint Various to include:  Provide central access to  Will vary with content All IT Staff Project

34
Type/Title Timing Vehicle Content Objectives Key Messages Receivers Senders Comments
date>  Project Objectives all project related Team
 Key measures information
 Progress  Provide a feedback
mechanism for staff
 Services
 FAQ’s
 Comms repository
 Education
Availability
Project Overview <specific HQ News  Program overview  Introduce program to the  IT is committed to All Central COO
date>  Success Stories wider business audience improving service Office Staff
within organization  IT is committed to change
Central Office  IT is delivering results
 Generate enthusiasm  This is an essential
within IT and business component of the
company growth strategy
Project Overview <specific Pamphlet/  Project Overview  Provide project objective  This is an essential All Staff CIO/COO Brochure to include
Brochure date> Brochure information to a wider component of the quote or
 Success Stories
business audience company growth strategy introduction from
 IT is committed to Superintendent
improving service linking the
 IT is committed to change importance of
improving IS to
 IT is delivering results
company strategy
Logo Campaign <specific Various Varies  Maintain visibility  Logo / slogan will be IT Staff Project The team is
date> merchandise designed to support idea Team planning to create
of commitment to various pieces (T-
improving service shirts, hats, mugs
etc) carrying the
program identity to
be used as
giveaways at
certain events.

Ongoing
Monthly project Every SharePoint Project status and  Maintain visibility  This will happen IT Staff Project
News posted to Month progress Team
 Provide information  We are delivering results
Web Site
 Increase confidence
Educational <month> SharePoint Education  Provide information  Staff can get the support IT Staff Project

35
Type/Title Timing Vehicle Content Objectives Key Messages Receivers Senders Comments
Curriculum Posted Updated curriculum they need Team
as Course descriptions  IT is committed to change
necessar
y
Business Brown Monthly Presentation Overview of various  Increase business  IT is an integral part of IT Staff Business
Bag Lunch after organization awareness of IT staff company operations Sponsor /
<month>. functions and how IT  Increase communication  This is an essential Area
supports the between IT and Education component of the Director
business goals community company growth strategy

Monthly Status for Monthly One-on-one  Project status and  Maintain enthusiasm  This will happen CFO COO
CFO progress  Provide information  We are delivering results
 Success stories  Maintain visibility
 Illicit support
Quarterly Update for Quarterly One-on-one  Project status and  Maintain enthusiasm  This will happen CEO COO
Superintendent progress  Provide information  We are delivering results
 Success stories  Maintain visibility
 Illicit support
Monthly update for Monthly Presentation  Project status and  Maintain enthusiasm  This will happen IT Staff CIO We will provide
staff progress information or
 Provide information  We are delivering results
 Success stories  Maintain visibility  Your viewpoint is present at the
important various monthly
 Solicit feedback
staff meetings that
take place within IT
Lessons Learned Monthly Workshop Key lessons learned  Provide information  Staff can get the support IT Staff Project
Workshops after from pilot projects they need Managers /
 Maintain enthusiasm
<month>  Demonstrate success  IT is committed to change Project
 We can help make your Team
life easier
 Adopting this new
discipline will improve the
products we produce and
our working environment
Project Every One-on-one Project  Provide mentoring  The project team is here Project Project
Management Clinic Thursday Management help support to non-pilot to support you Managers Team
1-4pm projects  We can help make your
life easier

36
Type/Title Timing Vehicle Content Objectives Key Messages Receivers Senders Comments
Frequently Asked Various SharePoint Answers to top  Provide answers to widely  The project team is here IT Staff Project
Questions questions asked at asked questions to support you Team
project management  Maintain visibility  We can help make your
clinic or during  Increase confidence life easier
mentoring sessions  Staff can get the support
they need
Project Status End SharePoint Key progress /  Maintain visibility  This will happen IT Staff Project
Thermometer <month>/ success metrics Team
 Increase confidence  We are delivering results
continuo  Demonstrate  Your commitment is
us management commitment essential for this program
to succeed
Supporting
Release of a When SharePoint;  Communicate the  To get them to user the  Short Term and Long IT Staff Project Detailed plans for
Feature or Service new email release of a new feature or service Term Impact Team the release of
feature or feature or service  I can get the help I need specific features or
service is  To point out the  IT is responding to my services will be
released value of this new needs created for each
feature or service. instance.
 Adopting this new
How it will help discipline will improve the
them or enhance features we produce and
what they do our working environment

New Training When a SharePoint; Communicate the  To get them to attend  To aid in the long term IT Staff Project Detailed plans for
Course new or email offering of a new or skill shift Team the release of
Announcement
revised revised class  I can get the help I need specific courses will
course is  IT is responding to my be created for each
being needs instance.
offered
 To obtain skills needed to
do job
 Adopting this new
discipline will improve the
products we produce and
our working environment
Availability of New When a Intranet / Communicate the  To get them to use tool  To aid in the long term IT Staff Project Detailed plans for
Tool new tool broadcast e- availability of the skill shift Team the release of
is being mail new tool  I can get the help I need specific tools will be
made  IT is responding to my created for each
available needs instance.

37
Type/Title Timing Vehicle Content Objectives Key Messages Receivers Senders Comments
 To obtain tools needed to
do job
 Adopting this new
discipline will improve the
products we produce and
our working environment

38
Appendix A. Change Request Sample

Change Request Form

Customer Name:
Project Name:
Project Manager: Phase/Iterati
on:
Request Type: <Change/Decision> Date
Requested:
Requested By:
Short Description Request #:
(Title):
Description of Request: Date
Required:
<New requirements, changes to existing requirements, revised understanding of
existing requirements and adjustments to the project’s schedule or cost must be
handled through change control (as prescribed in the project’s Governance Plan)
[Attach additional descriptive information if necessary.]>
Reason for Request:
<Describe why the request is important enough to warrant the impact that follows.
[Attach additional descriptive information if necessary.]>
Impact of Request: Date of
Response:
<Describe impact in dollars, time, change to project schedule & other ramifications.
[Attach additional descriptive information if necessary.]>
____________________________Change Item____________________________________
__Effort__
1.
Action: Date
Completed:
<Complete this section after this request has been completed. Describe action taken
and any other pertinent information. If the request was denied, describe why. [Attach
additional descriptive information if necessary.]>

<CONSULTANT> Approval
Name: <Project Manager>

Signatur
e:

Date:

<CLIENT> Approval
Name: <<CLIENT> MP Project Owner>

39
Signatur
e:

Date:

40