Master Project Plan Light Template

[note: Fill in File/Properties on this Word document for Project Name, Project Number & Author]

Ministry of

Project NameMaster Project Plan

(MPP-Light: Charter and MPP combined)

[Note: Use this template for smaller projects where a separate Project Initiation Document is not required.]

Project #: Project Number

Author: Project Manager's NameCreation Date: [Date]Last Updated: October 17, 2009Document Number: 6450-20/Project Number/PM.020LVersion: 0.1

Approvals

Project Business Sponsor Signature Date

Project Sponsor's Name

[Title][Organization]

Director Strategic Initiatives Signature Date

H.B. Teo

Director

Education Sector CIO Signature Date

James Shypitka

Education Sector CIO

Master Project Plan Project Name

Purpose of Document

This document defines the project in terms of objectives, scope, deliverables and stakeholders and also describes how the project will be managed. It is the main deliverable from the Project Initiation and Project Planning Phases, and combines the information from both phases. The detailed MS Project workplan (see Appendix F) is a companion to this document.

Table of Contents

Approvals................................................................................................................................................ 1Purpose of Document.............................................................................................................................. 2Table of Contents.................................................................................................................................... 21.0 Project Purpose.......................................................................................................................... 42.0 Background................................................................................................................................ 43.0 Objectives.................................................................................................................................. 44.0 Scope......................................................................................................................................... 4

4.1 In Scope......................................................................................................................... 44.2 Out of Scope.................................................................................................................. 4

5.0 Major Deliverables...................................................................................................................... 56.0 Stakeholders.............................................................................................................................. 57.0 Links and Dependencies.............................................................................................................58.0 Issues and Constraints...............................................................................................................69.0 Assumptions............................................................................................................................... 610.0 Approach.................................................................................................................................... 611.0 Project Development Documents................................................................................................6

11.1 Project Management......................................................................................................711.2 Procurement Documents................................................................................................711.3 System Development.....................................................................................................8

12.0 Milestones................................................................................................................................ 1413.0 Budget...................................................................................................................................... 14

13.1 Development Costs......................................................................................................1413.2 Operational Support Costs............................................................................................15

14.0 Resource Requirements............................................................................................................1514.1 Internal Resources.......................................................................................................1614.2 External Resources......................................................................................................1614.3 Special Committees......................................................................................................1714.4 Hardware/Software Requirements................................................................................18

15.0 Organizational Structure, Roles & Responsibilities.....................................................................1815.1 Project Organization Chart............................................................................................1815.2 Roles and Responsibilities............................................................................................18

16.0 Project Control.......................................................................................................................... 2316.1 Project Coordination.....................................................................................................2416.2 Documentation Management........................................................................................2416.3 Quality Management....................................................................................................2416.4 Communication Management.......................................................................................2416.5 Risk Management........................................................................................................24

17.0 Project Infrastructure................................................................................................................2518.0 Project Review and Completion Criteria....................................................................................25Appendix A: Level of Project Management............................................................................................26Appendix B: Communications Plan Matrix.............................................................................................27Appendix C: Risk Identification & Mitigation..........................................................................................28Appendix D: Privacy Impact.................................................................................................................. 29Appendix E: Application Portfolio Management System Update............................................................30Appendix F: Workplan.......................................................................................................................... 31

Last revised: 2009-10-17 of 30/tt/file_convert/555a64afd8b42a972b8b46c2/document.doc


Reviews and Document Control.............................................................................................................32



1.0 Project Purpose

[This section is one concise statement of the project’s goal.]

The purpose of the project is to

2.0 Background

[This section contains a brief discussion of the business need for the project, its customers or users, their interest in its completion, and the opportunity that has made the project necessary or viable. This section includes relevant historical background information.]

[Include why the project is needed (eg, to address corporate objective), who will use the product, how it will be used, and what the expected life-span of the product will be.]

Type background information here

3.0 Objectives

[This section succinctly states the program area’s strategic level objectives of the project, focusing on how the project will make a difference. The objectives are clearly stated, specific, attainable, and measurable. All stakeholders (project client, target users, steering committee, etc.) must agree on the objectives.]

[Objectives should be S.M.A.R.T. (Specific, Measurable, Agreed-to, Realistic, Time-constrained).]

The objectives of the project are to:

[list]

4.0 Scope

[This section describes the project boundaries in terms of the activities and the team's role and responsibilities to the clients or users. The scope should relate to the project goals and objectives, cover the work to be undertaken, the processes to be used, and the product(s) to be delivered. Address any constraints on the project that may affect its scope.]

[Use subheadings such as “In Scope” and “Out of Scope” to clarify what (work, processes and products) will be included within the project’s scope and what will be excluded. ]

Type scope information here

4.1 In Scope

The scope of the project includes:

[list]



4.2 Out of Scope

The following items are out of scope and provided here to help clarify the scope boundaries of the project:

[list]

5.0 Major Deliverables

[This section documents the tangible final product(s) of the project in terms of the major deliverables. Major deliverables include systems ,databases, interfaces ,training, major documentation etc. The list in this section should refer only to the major products or services to be produced for the customer.

Systems development documentation requirements are extensive and must be planned in detail during the planning phase, and recorded in a separate section of the Master Project Plan. Application Development projects should refer to “Deliverables for Classic Projects” for a list of standard application development deliverables.]

The major deliverable products for this project are:

[list]

6.0 Stakeholders

[This section lists stakeholders (internal and external) whose interests must be considered throughout the project.]

[To minimize the impact of personnel changes, identify stakeholders by organizational area rather than by the individual's name. Stakeholders may include FOIPOP, Financial Risk and Controls Audit, Data Administration, Security, etc., as appropriate to the project.]

The following stakeholders’ (internal and external) interests must be considered throughout the project:

Stakeholders Interests

7.0 Links and Dependencies

[This section describes other projects or initiatives that will affect the outcome of this project’s deliverables or timetable. It also identifies other projects that depend on the output of this project and describes the nature of the relationship.]

[Some sample paragraph lead-ins follow. Use one or more of them (or change them) as appropriate]

This project is dependent on the following:

Projects that depend on this project include:



Success of this project is linked to the following:

Future work dependent on the completion of this project include:

[list]

8.0 Issues and Constraints

[This section describes any potential issues or constraints that could have an impact on the success of the project. Include issues and constraints that will have to be managed as the project progresses. Areas of constraint could include: budget, resource availability, technology, current applications, client willingness and readiness, schedule, policies, organization, and external factors.]

Issues and constraints that could impact project success include:

[list]

9.0 Assumptions

[Document all assumptions, including those used to build the MPP and project workplan. Typical assumptions might be the use of tried and true technology or an off-the-shelf solution, availability of key people, that a related project will complete its contribution to this project’s work, access to funding, etc.]

[Note that any change in assumptions will probably result in a change to the Workplan and possibly the MPP]

[Assumptions are used in the Risk Identification and Mitigation section of the MPP, Appendix B.]

The following assumptions have been made for the project:

[list]

10.0 Approach

[This is a high level description of the direction being taken and activities that will be performed to achieve the project’s objectives.]

Type approach description here.

11.0 Project Development Documents

[This section provides a detailed list of the documents resulting from the project and system development processes, in order to produce the major product deliverables listed in Section 6.]

[Add or subtract deliverables to suit the project as required. Note that changes must be negotiated with the IT Quality Assurance Group.]

[Note: The Project Workplan must include these deliverables as separate task items.]



The deliverables of the project will be produced using IMG standards, unless otherwise agreed and documented here. The following table lists the deliverable documents and identifies which individuals or organizations will produce, review and approve them.

11.1 Project Management

Deliverable Documents

QA Process Provided by Reviewed by Accepted by

Master Project Plan Review Document

Project Manager IT Portfolio Manager

IT Quality Assurance

IT Client Lead

Business Owner

Business Sponsor

Strategic Initiatives Director

Sector CIO

Project Workplan Review Document

Project Manager IT Portfolio Manager


IT Client Lead

Business Owner

Business Sponsor


Sector CIO

Project Evaluation Document (PM.200)

None Project Manager N/A Accepted on delivery

Project Completion Checklist

None Project Manager IT Portfolio Manager

IT Client Lead

Business Owner

Business Sponsor


11.2 Procurement Documents



Request for Estimate Review Document Project Manager IT Procurement Administrator

IT Portfolio Manager


IT Client Lead

Business Owner

Business Sponsor


Business Management Director





Work Order Review Documents IT Procurement Administrator

Project Manager Business Sponsor


Business Management Director

11.3 System Development

[Adjust the table to match the actual documentation that will be produced.]

Definition

Deliverable Document


Business Requirements Document

Review Document IT Quality Assurance

IT Client Lead

Business Owner

Business Sponsor

High Level Business Function Model


IT Client Lead

Business Owner

Business Sponsor

Data Architect

Initial Business Data Model


IT Client Lead

Business Owner

Business Sponsor

Data Architect

Glossary Review Document IT Quality Assurance

IT Client Lead

Business Owner

Business Sponsor

Data Architect

Analysis & Design



Application Architecture Document


IT Client Lead

Project Manager


IT Client Lead

Project Manager





Application Design Deliverables (as defined in Application Architecture Document)


IT Client Lead

Project Manager


IT Client Lead

Project Manager

Module Functional Documentation


IT Client Lead

Project Manager


IT Client Lead

Project Manager

Module Technical Documentation


IT Client Lead

Project Manager


IT Client Lead

Project Manager

Data Conversion Strategy


IT Client Lead

Project Manager

Data Architect

IT Client Lead

Project Manager

Logical Database Design


IT Client Lead

Project Manager

Data Architect

System Data Model Review Document IT Quality Assurance

IT Client Lead

Project Manager

Data Architect

System Function Model


IT Client Lead

Project Manager

Data Architect

Technical Architecture Document


IT Client Lead

Project Manager


IT Client Lead

Project Manager

Testing Strategy Review Document IT Quality Assurance

IT Client Lead

Project Manager


IT Client Lead

Project Manager

Training and Support Strategy


IT Client Lead

Project Manager

Business Owner

Business Sponsor




Build, Test Implement



Application Source Code



Runtime Meta Data IT Quality Assurance


Conversion Modules IT Quality Assurance

Data Architect

Converted and Verified Data

IT Client Lead

Data Architect

Business Sponsor

Physical Database Design


Database Administrator

Production Database DDL


Database Administrator

Operations Support Guide


IT Client Lead

IT Service Manager

AMS Service Manager

IT Service Manager

Unit Test Results Development Manager


IT Client Lead

IT Service Manager

AMS Service Manager

IT Service Manager

System Test Results Development Manager


IT Client Lead

IT Service Manager

AMS Service Manager

IT Service Manager

Load Test Results Development Manager


IT Client Lead

IT Service Manager

AMS Service Manager

IT Service Manager





User Acceptance Test Plan


IT Client Lead

Development Manager

Project Manager


IT Client Lead

Business Owner

User Acceptance Test Results

User Acceptance Test Team

Project Manager

Business Owner

Development Manager

Business Sponsor

IT Service Manager

Training and Support Materials

IT Client Lead

Project Manager

Business Owner

Business Sponsor

Implementation Plan Review Document IT Quality Assurance

IT Client Lead

IT Service Manager

AMS Service Manager

Business Sponsor

IT Service Manager

12.0 Milestones

[This section lists high-level project milestones from the detailed Work Plan, including target completion dates. Milestones mark the completion of deliverables, or phase completions. ]

The major project milestones are:

Milestone Target Completion Date

Actual Completion Date

13.0 Budget

The project budget is summarized below. The Master Project Plan identifies development costs (costs that will be managed during the project) and future operational support costs (costs that will be managed by the ITMB client manager).

13.1 Development Costs

The following are the estimated development costs for the project:



Item Detail FY 2010-11 FY2011-12 FY2012-13 Total

Capital CostsProject Management Fees $0 $0 $0 $0PM Expenses $0 $0 $0 $0Developer Fees $0 $0 $0 $0Developer Expenses $0 $0 $0 $0Etc. $0 $0 $0 $0Etc. $0 $0 $0 $0

Sub-Total $0 $0 $0 $0

PC Capital CostsDesktop Hardware $0 $0 $0 $0Desktop Software $0 $0 $0 $0

Sub-Total $0 $0 $0 $0

Non-Capital CostsPre-project Management Fees

$0 $0 $0 $0

Pre-project Management Expenses

$0 $0 $0 $0

Requirements Analysis Fees

$0 $0 $0 $0

Requirements Analysis Expenses

$0 $0 $0 $0

Trainer Fees $0 $0 $0 $0Training Materials $0 $0 $0 $0Etc. $0 $0 $0 $0

Sub-Total $0 $0 $0 $0

Project Total $0 $0 $0 $0

ITMB Staff Travel $0 $0 $0 $0Client Staff Travel $0 $0 $0 $0ITMB Staff # FTE # FTE # FTE # FTEClient Staff # FTE # FTE # FTE # FTE

13.2 Operational Support Costs

The table below summarizes the estimated operational support costs for the project. The table includes estimated amortization costs, contracted application support costs and staff administration costs. The amortization period for mainframe capital costs (application development) is five years. Amortization costs are charged to the operating account beginning in the year of system implementation.

[State the expected costs to operate the product or system once it is in production. If there are operational savings, such as the retirement of an older system, provide operational savings.]

[If you cannot estimate the operational costs, then choose a percentage (suggest 15%) of development costs annually and state that assumption here.]

[Include amortization and state the target implementation date.]

The target implementation date is [mmm dd yyyy.]



Year 0 Year 1 Year 2 Year 3 Year 4 Year 5

Capital Amortization

$0 $0 $0 $0 $0 $0

PC Capital Amortization

$0 $0 $0 $0

Contract Support Labour

$0 $0 $0 $0 $0 $0

Total $0 $0 $0 $0 $0 $0

ITMB Staff # FTE # FTE # FTE # FTE # FTE # FTEClient Staff # FTE # FTE # FTE # FTE # FTE # FTE

14.0 Resource Requirements

[This section describes the resources (staff and contractors) required for this project, based on the project workplan.]

[Note: this should match Section 13 Budget for Labour (capital + non-capital), the project workplan in Appendix F, and Section 15 Organization Roles & Responsibilities. Add/change as required]

The following table shows the expected resource requirements for the project. This table summarizes the resources documented in the workplan (see Appendix F). As the project progresses and the workplan undergoes change, this table may also change. See next section for the Organization Structure, Roles and Responsibilities.

14.1 Internal Resources

Estimated resource requirements from [your organization name] include:

[Sample resource roles follow. Make sure the responsibilities for the roles identified in sections 14.1 to 14.3 are described in Section 15.]

Resource Role Resource Name(s) Org Effort (in days) / Timeframe

Project Manager [Define most likely range of effort.]

Project Team Leaders

Analysts (e.g. business, policy, technical, legal ...)

Experts (e.g. business, technical …)

Technical Resources

Communications Staff

Business Area Test Team

Technical Writer / Documentation Analyst

Trainers



Resource Role Resource Name(s) Org Effort (in days) / Timeframe

Project Team Scribe

Specialists [name of specialties]

(etc.)

Total Effort [Provide approximate total effort to complete project]

[Present a range of effort depending on the level of risk, organization and project policies. An example could be 70% for optimistic and 140% for pessimistic. The ranges should be noted in the budget where applicable.]

Based on the calculation of 70% for optimistic and 130% for pessimistic, the estimated range of effort for internal resources required for this project should be between yyy and zzz months.

14.2 External Resources

Resources from outside the organization/unit include:

[Sample resource types follow.]

Resource Type / Source

Why Needed Effort / Timeframe

Estimated Cost

Other Government Organizations

Non-Government Organizations

Client Representatives

External Consultants

Vendors and Suppliers

(etc.)

Total [Provide approximate total effort to complete project]

[Provide total estimated cost]

[or, if none:]

No additional resources are anticipated.

[Present a range of effort depending on the level of risk, organization and project policies. An example could be 70% for optimistic and 140% for pessimistic. The ranges should be noted in the budget where applicable.]

Based on the calculation of 70% for optimistic and 130% for pessimistic, the estimated range of effort for external resources required for this project should be between yyy and zzz months.



14.3 Special Committees

The following committees will be necessary for this project:

[examples follow, use as applicable]

Committee Purpose of Committee Membership Timeframe / Frequency

Steering Committee

Provides project direction & guidance

Ensures stakeholder interests

Discusses/resolves issues

Reviews/approves changes & deliverables

Project Sponsor (chair)

[positions likely to be included]

Advisory Committee

Provides expert advice to sponsor [and/or steering committee]

[external and internal representatives]

[may or may not be stakeholders]

Working Committee

Provides expert advice to the project manager [and/or specific project teams or groups]

[internal experts]

[may or may not be stakeholders]

[etc]

14.4 Hardware/Software Requirements

[Include what is required as part of the deliverables in Section 5 and what is required to do the project. Include the costs in the budget in Section 13.]

Resource Type

Why Needed Timeframe Estimated Cost

$0

$0

$0

Total $0

[or, if none:]

No additional hardware or software resources are anticipated.

15.0 Organizational Structure, Roles & Responsibilities

15.1 Project Organization Chart

[A sample organization chart is provided. Develop an organization chart to match the actual project reporting structure.]



The following illustrates the reporting organization of the project.

15.2 Roles and Responsibilities

[Add/change this table as appropriate. The following list provides boilerplate responsibilities for roles that may contribute to a project, particularly an IT project. This table should match Section 14 Resource Requirements.]

The following descriptions define the general roles and responsibilities of the resources to support this project.

Role Responsibilities

Project Sponsor Responsible for the project

Establishes business objectives

Confirms and approves project scope

Acquires and ensures sufficient funding is obtained

Acquires and ensures sufficient program resources

Chairs Steering Committee

Promotes project

Monitors overall progress

Approves major deliverables

Ensures major objectives are being met

Reviews and approves Change Requests

Provides direction to project manager and client manager

Resolves issues arising from the project

Responsible for final sign-off of the project.

Project Steering Committee

Provides project direction and guidance

Ensures stakeholders interests are maintained

Discusses and resolves project issues




Reviews and resolves scope and change requests

Ensures that all acceptance sign-off activities are completed or returned within [one/three/five] business days.

Reviews regular project status reports

Reviews and approves major project deliverables

Advisory Committee Provides expert advice to the Sponsor and Steering Committee

Project Manager Responsible for the delivery of the final product and all interim deliverables as agreed in this MPP and by subsequent change control.

Plans and controls all project activities.

Identifies and acquires resources.

Attends all Joint Application Design, project status and review meetings as detailed in the project plan.

Completes the assigned tasks at the scheduled time as indicated in the project plan.

Manages issues, decisions, changes, and problems to resolution.

Communicates status and project information to sponsor, committees, and project stakeholders on a regular basis as agreed.

Ensures all project tasks and deliverables conform to Quality Management standards where they exist and are appropriate to the project.

Manages the project team including contributing to performance processes.

Monitors contract(s) and ensures that contracted deliverables meet the specifications defined in Schedule A of the contract

Working Committee Provides expert advice to the Project Manager and Team Leaders.

Client or Business Area Manager

Responsible for defining business requirements

Responsible for business process re-engineering

Defines acceptance criteria

Responsible for acquiring business area expertise

Participates in planning processes

Attends all Joint Application Design and review meetings as detailed in the project plan

Completes assigned tasks at the scheduled time as indicated in the project plan

Verifies that the business analysis and business requirements truly meet the business needs

Identifies issues, impacts and remedial actions

Reports user status to sponsor and steering committee

Communicates project status and business concerns to the project team

Reviews and approves interim project deliverables

Recommends sign-off of project deliverables to the Steering Committee




Responsible for user documentation

Responsible for acceptance testing

Assists with final implementation [ note: may manage the implementation]

[Name of Contract Company] Project Manager

Manages the production of all [contractor] deliverables

Ensures deliverables are completed on time, within budget and working according to specification.

Communicates project status to the Project Manager.

Receives and acts on any Change Requests from the Project Manager.

Identifies and participates in the resolution of problems and issues

Ensures all specifications defined in Schedule A of the contract are met.

Ensures skills’ transfer training to technical and/or business area staff

Team Leader of Project Sub-Component

Provides first point of contact for communication with the sub-component project team

Negotiates delivery dates with project manager

Produces and validates sub-component plans

Ensures production of sub-component deliverables

Manages and motivates the project team on a day-to-day basis

Ensures all resources are supplied on time

Confronts issues and escalates problems

Monitors standards

Performs inspections and acceptance as required by quality management plan

Provides advice to the Project Manager as required.

[Senior] Business Analyst Identifies, collects and ensures priortization of business requirements

Documents clearly and consistently the business requirements

Ensures the business requirements truly meet the business needs as defined by the Client Manager

Ensures the conceptual design meets the requirements

Completes assigned tasks at the scheduled time as indicated in the project plan.


Business Expert(s) Defines business requirements

Defines acceptance test scenarios and cases

Provides business expertise

Verifies the documented business requirements

Develops user documentation

Reviews and approves acceptance test results

Identifies and participates in resolution of problems and issues




Participates in development of user training

Liaisons with external business areas

Policy Analyst Identifies policy requirements

Analyzes existing policies

Develops / revises policy statements

Develops policy communication and implementation plans

Technical Coordinator Ensures consistency of design with existing standards

Ensures that all technical components are compatible with others

Provides a centre of expertise for the use of the tools in the project

Manages and directs the use(reuse) of generic code, objects and components

Establishes and ensures use of naming conventions, coding standards, field lengths etc

Organizes and runs technical review sessions as required by product descriptions

Monitors Configuration Management, version control and change control during development

Lead Developer Provides a first point of contact with the technical development team

Negotiates delivery dates with the Team Leader

Produces and validates development plans

Motivates technical development team

Designs and builds product deliverable(s) according to specifications

Communicates with User representatives

Confronts issues and escalates problems

Attends workshop sessions to input or demonstrate as required

Developer / Contractor Development Team

Provides input to planning processes

Designs and builds product deliverable(s) according to specifications

Plans, runs, records and acts upon results of Unit Tests

Implements determined standards

Communicates test results to Technical Coordinator

Communicates with User representatives

Advises Technical Coordinator on implementation issues

Attends workshop sessions to input or demonstrate as required

Client / Business Area Responsible for defining business requirements

Responsible for business process re-engineering

Defines acceptance criteria

Completes assigned tasks at the scheduled time as indicated in the project plan

Verifies that the business analysis and business requirements truly meet the business needs




Reviews and approves interim project deliverables

Recommends sign-off of project deliverables to the Sponsor

Responsible for user documentation

Responsible for acceptance testing

Acceptance Test Team Executes the User Acceptance Test Plan

Documents the results of the tests

Re-tests as required.


Implementation Team Installs and implements client software (including documentation) into production environment.

Project Team Scribe Acts as configuration librarian to ensure Configuration Management, version control and change control

Documents review and records change requests

Ensures documents and models are retained in accordance with product descriptions and quality standards

Produces workshop materials

Ensures timely distribution of documentation to workshop attendees, reviewers, management etc

Creates and maintains project directories

Updates Project Journal

Workshop Facilitator Provides skilled, disinterested workshop facilitation as required

Prepares for and follows-up facilitated workshops

Ensures production of facilitated workshop documentation and materials before, during and after workshops

Specialist – Database Administrator

Establishes and maintains project environments, including Development, Test, Production and Training

Manages system/application security

Provides access as required

Migrates system/application from Development to Test, Test to Production, and Test to Training as required

Provides technical advice within the scope of database administration

Specialist – Quality Assurance

Reviews project deliverables and provides advice with regard to ministry standards

Specialist – Standards and Architecture

Provides guidance to the project as required with regard to ministry standards

Reviews project deliverables and provides feedback

Specialist – Project Management Office

Provides guidance to the project with regard to project management and project management documentation

Reviews project management documentation and provides feedback

Trainers Develops training material

Trains user staff in the use of the system.




Technical Writers / Documentation Analysts

Develops technical documentation

[and/or] Develops user documentation

16.0 Project Control

Based on the Government project management guidelines, where project triggers and risks are assessed in order to determine the Level of Project Management (LOPM) required, the project has been ranked ‘[low/low-medium/medium/medium-high/high] (xx [lopm score])’ for project complexity. See Appendix A for the detail analysis.

[Hyperlinks to Level of Project Management Tool and Assess Level of Project Management Required on the Ministry project management Web Site.]

[Note any special concerns about project priority here.]

This section describes how the project will be managed.

[Sample paragraphs have been written in each section. Use and change as appropriate.]

16.1 Project Coordination

The project will be coordinated using a combination of the Ministry’s Project Management standards and guidelines, and general management principles. The project workplan (Appendix F), developed in MS Project, will be baselined and approved as part of this MPP.

At the beginning of each project phase, the workplan will be reviewed and revised, based on the information and experience of the previous phase and any new information.

During the project, team meetings will be held [weekly, bi-weekly, …], where progress will be reported, tasks assigned, and issues raised.

16.2 Documentation Management

The Project Manager will manage the production, review and approval of all documentation deliverables. Information Management Group standards will be used where standards exist

Documents will be stored on the [name of drive/subdirectory] and will be migrated to the Oracle Designer Repository on delivery. All logical database design details will be recorded in the Oracle Designer Repository.

At the completion of the project all documentation deliverables will be provided to Records Management for long-term storage and maintenance. All project documentation will be archived using standard government and organization procedures.

16.3 Quality Management

[Note: The Project Manager should meet with the Information Management Group early in the planning process to determine the specific quality assurance requirements required for the project.]


http://www.ole.gov.bc.ca/itmb/projectsupport/requirements.htm


http://www.ole.gov.bc.ca/itmb/projectsupport/forms/lopmtool.htm


All project deliverables will be subject to a review and approval process and will be signed off by the project sponsor and stakeholders with a vested interest in the particular deliverable. All technical components, including data models, application code and database deliverables will be formally reviewed by the Information Management Group.

An acceptance test task is included in the workplan to enable the business area to test the final product in a production-like environment prior to implementation. The initial requirements for this acceptance test will be documented during the business design.

All deliverables will be signed off prior to migration to production.

16.4 Communication Management

The project manager will provide a monthly status report to the Project Support Office and others as determined.

A matrix illustrating the Project Communication Plan is provided in Appendix B.

16.5 Risk Management

No major risks are expected for this project.

[ or ]

This project has significant risk associated with it. Refer to Appendix C [and/or separate Risk Management Plan] for a comprehensive analysis of the project risk.

The project manager will continually assess the project for unforeseen risk and take remedial action. See Appendix C.

Any issues that occur will be tracked and resolved in a timely manner.

17.0 Project Infrastructure

The project team will use standard facilities and tools. No special requirements are expected.

[Note: if this isn’t true, list exceptions. The Project Manager should verify infrastructure requirements with the Technology Services Group and Information Management Group early in the planning process. ]

[Note: If the project requires other infrastructure, then list and include in Resources and Budget as applicable. Refer to section 18 of the full-version Master Project Plan template for a list of potential infrastructure requirements.]

18.0 Project Review and Completion Criteria

[It is important to know up-front (1) “when you are done”, (2) “when you have won”, and (3) “who gets to decide”. Develop the completion criteria with the client, stakeholders and team members early in the project so that everyone will know when the project is complete. Use this section to define the criteria for project completion. Some sample statements follow (add/modify/delete as needed) ]



The project will be deemed successful when all the objectives have been met.

The project will be deemed complete when:

all tasks in the project workplan have been completed;

all project documents are complete and signed off by the project sponsor;

all project issues have been addressed;

the project evaluation has been completed;

the post implementation review has been scheduled;

all project staff and physical resource release activities have been completed;

all project-related contract finalization activities have been completed; and

all project files are completed and documentation archived.



Appendix A: Level of Project Management

Based on the Government project management guidelines, where project triggers and risks are assessed in order to determine the Level of Project Management (LOPM) required, the project has been ranked ‘[low/low-medium/medium/medium-high/high] (xx [lopm score])’ for project complexity.

The following is the detailed result from the LOPM Analysis:

[Include report from LOPM tool by copy/pasting the e-mail note generated from the tool.]

[Hyperlinks to Level of Project Management Tool and Assess Level of Project Management Required on the Ministry project management Web Site.]

[Note: The LOPM is only a guide for project complexity and does not consider priority. If the project has a particularly high management priority or significance, discuss here.]




http://www.ole.gov.bc.ca/itmb/projectsupport/forms/lopmtool.htm


Appendix B: Communications Plan Matrix

[ Provide a schedule of communication activities or events that will be performed during the project. The activities should identify the audience and describe how the communication will be done and what will be communicated. Indicate who is responsible for delivering the communication. Indicate when the communication should take place (e.g., weekly, September). These activities should be incorporated in the project workplan.]

The following table shows the communications activities that will be performed during the project.

Activities Responsibility Audience Method Date

1 Collect Project Status

Team Leaders

Team Members

Project Manager MS Project

Status Report

Team Review Mtg

Email

Weekly

2 Status Report Project Manager Sponsor

Stakeholders

MS Word document

Monthly

3 Milestone Report Project Manager Sponsor

Stakeholders

MS Project

Report

Review Mtg.

Monthly (with status rpt)

4 Report Project Status

Project Manager ITMB Management MS Project Report Monthly

5 Information Bulletins

Communications Manager

Stakeholders

Public

Web Quarterly

6 (etc.)



Appendix C: Risk Identification & Mitigation

[All projects experience a degree of risk. Risk is usually lower for projects that have clear and visible sponsorship with accountability for results. These projects tend to stay on track and achieve their objectives. Risk identification is conducted with members of the project team, project management and stakeholders.]

[Risks are associated with the assumptions that have been identified for the project. For every assumption that doesn’t hold true there is a risk of project delay or failure. The project manager should regularly review these assumptions and assess their status against the workplan, budget, scope and quality, and make adjustments where necessary.]

The following Risk Assessment has been developed by consensus by a combined ITMB and Client group, and reflects the risks as known at the date below. Risks change on a regular basis, and this Risk Assessment will be repeated at periodic intervals throughout the project.

Date of Risk Assessment: [insert date]

ID Rank Risk Statement Probability

Impact Mitigation

1 Lo/Med/Hi Lo/Med/Hi

2

3

4

5



Appendix D: Privacy Impact

A Privacy Impact Assessment (PIA) is a foundation tool/process designed to ensure compliance with government’s privacy protection responsibilities and is a requirement under the Freedom of Information and Protection of Privacy Act section 69(5). The PIA is intended to support government business objectives, including electronic government initiatives. If used as part of normal business processes, the PIA can ensure that privacy requirements are identified and satisfied in a timely and cost efficient manner. It is important that a PIA be completed during the early developmental stages of any program, system or other initiative as a component of the project/business plan.

Please answer the following questions regarding the product to be produced by this project. If unsure about how to answer any of the following questions or if the answer to any of the following questions is "yes," contact the information and privacy coordinator at [email protected]. If the answer to all of the following questions is "no," further assessment is not required.

The process to complete a PIA involves answering a series of questions according to a pre-set template which can be viewed at http://www.mser.gov.bc.ca/privacyaccess/index_toc.htm#PIA .

Branches or program areas need to designate a staff person to work with Privacy and Records Management Branch staff to answer the questions about the program and input the information. Contact the information and privacy coordinator at [email protected] for more information.

No Yes

Is personal information being collected?

Is personal information being used?

Is personal information being disclosed?

Is personal information being stored?

Are you planning an Information Sharing Agreement with another body that involves the collection, use, disclosure or storage or personal information?

Are you planning a research agreement with another body that involves the collection, use, disclosure or storage of personal information?

Are you contracting out a portion of you program, initiative, system development that requires the collection, use, disclosure or storage of personal information?

Are you designing a new computer system to store personal information?

Are you amending legislation that deals with the collection, use, disclosure, or storage of personal information?

Has anyone raised a privacy concern or question that relates to your legislation, program, initiative or system?


mailto:[email protected]

http://www.mser.gov.bc.ca/privacyaccess/index_toc.htm#PIA

mailto:[email protected]


Appendix E: Application Portfolio Management System Update

The Application Portfolio Management System (APMS) is an information system aimed at providing an accessible source for:

Management data for application planning. Application operational and infrastructure information. Application technology information.

These objectives are met only when sufficient application information is captured in APMS for the applications.

APMS data capture is a distributed activity - not a centralized activity within ITMB. It is intended to do the data capture at source. APMS is now an integral part of the application development and change management processes. For more information about APMS contact the project support office.

If this project will create a new application system or substantially alter the business function, infrastructure or technology architecture for an application, answer “yes” to the following question (otherwise answer “no”):

APMS update required? Yes No

If APMS update is required, specify when the update will be made and to whom the update task will be assigned.

APMS updated/to be updated on (date):

APMS updated/to be updated by (name):

Comments:


http://www.ole.gov.bc.ca/itmb/adestandards/contacts/welcome.htm#pso

http://www.ole.gov.bc.ca/itmb/adestandards/contacts/welcome.htm#pso


Appendix F: Workplan

The project workplan, developed in MS Project, is a companion to this MPP: Lite. A [Summary Gantt Report / Major Milestone Report / Deliverables Report] from this workplan is included as this Appendix. For review of the complete workplan, refer to the Project Manager.

[Workplans should include all project resources with estimates of effort. The cumulation of these form the information for Sections 13 (Budget) and 14 (Resources).].

[MS Project Plans are difficult to include in a MS Word Document. You may choose to refer to a separate MS Project Workplan document here.]

[The workplan that is approved with (or before) the MPP is referred to as the Baseline Version 1.0 workplan. After approval, it must be saved in the Project Support Office directory and gardcopy files. All subsequent approved workplans will be given a new version number and must also be saved in the same locations.].

[The major milestones from Version 1.0 are recorded in Section 12 of the original MPP: Light. Changes to milestones in subsequent approved versions should also be recorded as a change to the MPP: Light and in the MS Project plan because they form a new baseline. Actual milestone completion dates should also be recorded. At project closing, the Project Evaluation will compare original dates, revised dates and actual dates.]

[attach workplan here]



Reviews and Document Control

ReviewsThis document has been sent to the following for their review and comment.

Name Position

Project Management

Name Position

[name] Project Manager

Document Control

[Drafts start at 0.1 whereas a document ready for signature becomes version 1.0. ]

Date Version Change Reference Reviewed by

[date] 1.0 Original document


Master Project Plan Light Template

Documents

Transcript of Master Project Plan Light Template