Project Governance Plan

A Project Governance Plan is a document that describes the specific procedures and resources necessary for the fulfillment of the project according to the Clients stated requirements. These procedures should be established when the project is set up and reviewed and modified if necessary during the life of the project. This Project Governance Plan provides a high-level view of the project. It details the scope, objectives and overall approach for planning, designing, developing and implementing the solution for client. The Project Governance Plan provides for a common understanding between all project participants, helps manage expectations, and becomes the standard against which changes and deviations to process or product are identified and managed.

a. Project Description
This section should comprise the definition and background of the project, including: the identity of the project, the name of the Client, a brief description of the Clients activities in relation to the project, the agreed project value, an explanation of the overall environment of the project. A diagrammatic illustration should also be produced, giving the structure of the project as viewed by the Client, and indicating the system, subsystems and main elements. These elements, as well as their interfaces, should be clearly defined.

b. Project Objectives
This is a key section in which the fundamental objectives of the project should be specified. Both the high-level and project-level objectives should be outlined. The high-level objectives, in the context of the business case, which will have identified the need for the project in the first place, should first be stated (with the Client's agreement). If, for example, the project forms an element of a complete programme then its context in the programme and the related programme objectives should be stated. The project-level objectives should then be specified and can be categorised as follows: the Client's specific business objectives, to be achieved on the project, the system objectives and the Client's system expectations, the Client's organisational and functional objectives.

c. Project Critical Success Factors

An internal, business-related item that is measurable and will have, on an ongoing basis, a major influence on whether or not the project meets its objectives.

d. Project Scope
Specify the subject matter boundary of the project, the subset of the organization that will be involved in the project, the time frame from project start to completion, the estimated cost for the project's completion, and the deliverables to be produced during the project. Clearly state IN SCOPE and OUT of SCOPE as long as the Change Request Procedure.

e. Deliverables
The following table defines what the deliverables are and who is responsible, project team or the Client.

Deliverable

Responsible Party

f. Milestones
The contractual milestones, which the project will deliver, should be described in this section. Subsequent plans should be based upon these milestones, but should not be included in the Project Governance Plan. This will allow for update of the plans without the need for a full Project Governance Plan re-issue. The following project milestones should be shown in the project plan: Start date. Deadline. Intermediate dates linked to validation, reviews, visible stages, etc. Events linked to Client's obligations, such as providing equipment, approving deliverables, etc. Delivery dates. Go/no-go decision points.

g. Client Obligations
The corporate obligations of the Client to undertake activities as part of, or provide resources for, the project, are listed below: Examples: provision of working environment provision/maintenance of development environment provision/purchase of licences and software making available key personnel training, if not already covered by the project maintenance of the live system, if not already covered by the project operation of the live system, if not already covered by the project }

h. Assumptions And Constraints

In this section all key assumptions made about the project should be listed. The initial list may be taken from the Business Case and supporting documentation. It is particularly important to include all assumptions relating to deliverables, resources, and other factors to be supplied by the Client, upon which the project will be dependent. These dependencies should be clearly documented and carefully monitored. This section should also include constraints. Constraints may be external, that is to say, those imposed by Client, for example, limitations on the environment to be used, or restricted access for project team to areas or information. There may also be internal constraints, that is to say, those originating from project team, for example, limited availability of personnel.

i. Dependencies/Related Projects
This section defines the known external dependencies associated with this project i.e. dependencies this project has with other projects, areas of work, people or events outside of this project. Projects/Events that this Project is Dependent On Projects/Events that are Dependent on this Project

j. Organisation
The diagram summarizes the links that connect the parties involved in the project, and indicates the specific functions associated with the project. This section should display of all personnel and project teams involved in the project together with the links (hierarchical and functional) that connect them. An Organization Chart or diagram should be created so that the overall organizational structure of the project can be perceived at one glance.

k. Project Schedule
Use WBS approach to split activities in tasks, estimate effort and duration, dependencies between tasks, allocated resources.

l. Risk Management
This section should define: Risk name Probability Impact Composite grade Plan to reduce probability Plan to reduce impact Plan B

m. Communication Plan
This section should define Name of the event What kind of interaction Frequency Participants Documents (IN, OUT)

n. Customer Relationship Management

This section should include actions that should be performed to set and capture expectations, get feedback and prepare successful change within client organization. A Customer Satisfaction Survey should be part of CRM plan.