<Note: Replace (or delete) bracketed
and/or Greentext with required information>

[Project Name]

[Name of Ministry]

Master Project Plan

Project Manager:

Creation Date:[Date – YY/MM/DD]

Last Updated:[Date – YY/MM/DD]

Document Number:6450-25/[Project Number]

Version:0.0.0

MasterProjectPlan <insert project name>Page 1 of 27

Approvals:

Project Sponsor / Signature / Date
[Name]
[Title]
Project Manager / Signature / Date
[Name]
[Title]
[optional others] / Signature / Date
[Name]
[Title]

VERSION HISTORY

Version / Date / Responsible / Notes

Purpose of the Document

The Master Project Plan (MPP) defines the project in terms of objectives, scope, deliverables and stakeholders and describes how the project will be executed, monitored, and controlled. It is a primary deliverable in the planning phases of a project and links to the NRS Systems Development Life Cycle (SDLC) in the Initiation Phase of New Development. The detailed MS Project templateis a companion to this document and provides a foundation for preparing a workplan and schedule based on project deliverables and the work breakdown structure (WBS).

<The template is designed to align with other templates so information can be copied where appropriate. There are a number of similar sections in both the project charter and master project plan. In general terms, the sections are often expanded upon in the master project plan as more details become available at this point in the project.>

<Major changes to the master project plan are approved through change or decision requests. The workplan, including the WBS or Gantt chart, may undergo modifications periodically during the project.>

<The template includes sections to incorporate full requirements for significant projects. For smaller projects or where a particular section does not apply, leave in the section and note N/A.>

The purpose of the MPP is threefold:

  • To establish and ensure a common understanding between all parties of the objectives, scope and requirements this project will address;
  • To ensure a common understanding of the work to be performed, the deliverables, the methodology to be used and the roles and responsibilities of all parties; and
  • To provide the project team with a baseline document (scope, tasks, estimates and deliverables) from which to carry out the work, and to measure the progress and success of the project.

Related Documents:

  • add/delete as appropriate
  • Communications Management Plan,
  • Risk Management Plan,
  • Quality Management Plan,
  • Workplan, WBS, Gantt chart,
  • Budget and Cost Management Plan.
  • [etc.]

1.0Project Purpose

copy from or reference the Project Charter or Business Case, if appropriate, and expand as necessary>

Provide a concise statement of what the project is to achieve, its mission or goal.>

The purpose of the project is to ….

2.0Background

copy from or reference the Project Charter or Business Case, if appropriate, and expand as necessary>

Provide 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(e.g. to address corporate objectives), who will use the product, how it will be used, and what the expected life-span of the product will be.

3.0Objectives

<copy from or reference the Project Charter or Business Case, if appropriate, and expand as necessary. Suitable outcomes from the business case could also fit here.

Succinctly state the strategic level objectives of the project, focusing on how the project will make a difference. The objectives are clearly stated and S.M.A.R.T. (Specific, Measurable, Agreed upon, Realistic, Time-Bound). All stakeholders (project client, target users, steering committee, etc.) must agree on the objectives.>

The objectives of the project are to:

  • <list>

4.0Scope

copy from or reference the Project Charter or Business Case, if appropriate, and expand as necessary>

Describe the project boundaries in terms of its activities and the work to be performed. The scope should relate to the project goals and objectives, and cover all the work and only the work to be undertaken. Consider budget limitations, capacity of the project team and time constraints.

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

4.1In Scope

Work to be undertaken by the project, processes to be employed by the project, products to be produced by the project.

The scope of the project includes:

  • list

4.2Out of Scope

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

<Work that will not be undertaken by the project, processes that will not be employed by the project, products that will not be produced by the project.>

  • list

5.0Major Deliverables

copy from or reference the Project Charter or Business Case, if appropriate, and expand as necessary>

Identify the tangible final product(s) of the project in terms of the major deliverables. This is not the complete list of detailed project tasks that appear in the workplan.

The major deliverable products for this project are:

The following table’s content is meant as an example and is not complete. Each project will require its own specific set of major deliverables.

Major
Deliverable / Description / Target Date
Project Plan
Software Requirements Specification
Software Design Description
Development
Implementation
Project Management

6.0Milestones and Project Plan

copy from or reference the Project Charter or Business Case, if appropriate, and expand as necessary>

<List the major milestones for the project and the schedule at which each of these milestones must be met. Milestones mark a significant point or event in the project such as the completion of deliverables, phase completion, or review and decision points.

The major project milestones / targets / review points for the project are:

The following table’s content is meant as an example and is not complete. Each project will require its own specific set of Milestones and target dates.>

Milestone / Target Date / Completion Date
Initiation
Software Requirements Specification
Decision Point for further approval
Detailed Software Design Description
Build
Implementation

7.0Stakeholders

copy from or reference the Project Charter and target groups in the business case, if appropriate, and expand as necessary>

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

From stakeholder interviews, briefly summarize their interests, expectations, and any potential issues or concerns. Stakeholders include all the people and organizations affected by the ultimate product or deliverables of the project. There are four sources of stakeholders (those people interested in the final product):

  • The program that owns or sponsors the project
  • Programs external to the sponsoring program that either affect or are affected by the project
  • Customers of the program(s) affected by the project
  • Organizational areas responsible for support of the project deliverables.

Identify stakeholders by organizational area and include the individual's name or position where known.

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

<The following table’s content is meant as an example and is not complete. Each project will require its own specific set of Stakeholders and representatives.>

Stakeholder / Represented by / Interests, Expectations, Concerns
Ministry Executive / Project Sponsor (Add Name)
Ministry Public Clients / (Names of people that represent this group)
Ministry Management & Staff
Information Management Branch

7.1Stakeholder Analysis

Stakeholder analysis is the process of identifying the individuals or groups that are likely to affect or be affected by a proposed action, and sorting them according to their impact on the action and the impact the action will have on them. This information is used to assess how the interests of those stakeholders should be addressed in a project plan, policy, program, or other action. Stakeholder analysis is a key part of stakeholder management with a goal of developing cooperation between the stakeholder and the project team and, ultimately, assuring successful outcomes for the project.

The following matrix is an example that can be used to categorize stakeholders based on their level of Power and Interest in the project.

<The matrix should be stored separately from the Master Project Plan due to the sensitivity of the information included. The information in the matrix can help with the development of the communications plan.>

8.0Links and Dependencies

copy from or reference the Project Charter, if appropriate, and expand as necessary.

Describe other projects or initiatives that will affect the outcome of project deliverables or timetable. It also identifies other projects that depend on the output of this project and describe 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:

  • list
  • A good example of a dependency for a system development project would be the Ministry e-Service look and feel standards.>

Projects and initiatives that depend on this project include:

  • <list>
  • If the system is to support a major initiative then the initiative may be in jeopardy.>

Success of this project is linked to the following:

  • <list>

Future work dependent on the completion of this project includes:

  • <list>
  • A good example of future work that is dependant would be that if this project was an Analysis and Requirements project for a system development. The future work that would depend on this project would be systems design and development.>

9.0Issues and Constraints

copy from or reference the Project Charter, if appropriate, and expand as necessary.

Describe any potential issues or constraints that could have an impact on the success of the project. Barriers to the project are listed, as well as activities and deadlines that must be met to ensure its success. 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>

Some examples could be:

  • Securing Ministry staff for the project.>
  • Access to Ministry staff for the duration of the project and the time allotted to the resource.>
  • <Short time line for delivery.>
  • Fiscal pressures. Project must be complete before the end of the fiscal year.>
  • <Budget.>
  • <Adherence to specific technology standards.>
  • <Alignment to legislation or policies.>

10.0Assumptions

Document all assumptions, including those used to build the MPP and project workplan. Typical assumptions might be related to legislation and policy, 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, education and training needs, etc.>

Note that any change in assumptions will probably result in a change to the workplan and possibly the MPP.>

All assumptions carry an element of risk and therefore should be included in the Risk Management Plan.>

The following assumptions have been made for the project:

  • list

11.0Budget

The project budget is summarized below:

The following table’s content is meant as an example and is not complete. Each project will require its own specific set of budget criteria.>

Capital / STOB / FY 13/14 / FY 14/15 / FY 15/16 / FY 16/17 / FY 17/18 / Total
Requirements
Design
Build
Implementation
Infrastructure
Project Management
Operating / STOB / FY 13/14 / FY 14/15 / FY 15/16 / FY 16/17 / FY 17/18 / Total
Project Management
Travel
Training
Sustainment / STOB / FY 13/14 / FY 14/15 / FY 15/16 / FY 16/17 / FY 17/18 / Total
Maintenance* / 20% / 15% / 10% / 10%
Amortization**
Licensing Fees***

*Maintenance is typically calculated as 20%in year one, 15% in year two, 10% in year three and 10% subsequent years of the development cost.

**Capital is amortized over five years once the system has been implemented (amortization is paid in 60 equal monthly payments).

***Licensing fees will cover expenses such as annual license or maintenance fees.

11.1Sustainment

This section should clearly identify to the project sponsor that the operational business unit must allocate funding or negotiate funding from overhead on an annual basis to maintain and enhance the resulting custom built system or pay support or licensing fees on a COTS solution.>

After the resulting system is implemented, annual support funding must be allocated in order to allow for release updates to be implemented. Release updates may cover bug fixes or additional functionality (enhancements) identified during use of the system or changes to business process. The funding for maintenance releases is covered by operational dollars while enhancements are covered under capital. Major or minor release deployments are anticipated to occur <X times per fiscal year>. A custom built computer system typically has a lifespan of eight to ten years.

The table below identifies the responsibility for sustainment costs resulting from this project.

Sustainment / Description / Responsibility
Maintenance / Maintenance is typically calculated as 20% in year one, 15% in year two, 10% in year three and 10% subsequent years of the development cost.
Amortization / Capital is amortized over five years once the system has been implemented (amortization is paid in 60 equal monthly payments)
Licensing Fees / Licensing fees will cover expenses such as annual license or maintenance fees.
Other

12.0Approach

<Describe the high level direction being taken and activities that will be performed to achieve the project’s objectives. Include how methodologies will be used including major phases. Include any contracts, prototyping, pilots, training, subprojects, etc.>

<The following paragraph is provided for reference and can be changed to meet the needs of this project. Include documentation to reflect deviation from the NRS SDLC standard approach.>

The NRS SDLC will be applied throughout the duration of this project. The NRS SDLC describes the process for conducting systems (application) development projects and assignments in NRS. The life cycle includes initiation, analysis, design, build, and implementation phases and stipulates mandatory, recommended, and optional tasks and deliverables according to the project complexity. This project is categorized as<insert results of the complexity assessment tool>.

Categories include:

  • New Development – Simple, Moderate, or Complex
  • Maintenance
  • Business Architecture
  • Lightweight

Refer to the NRS SDLC website for descriptions and details of each of the phases.

The table below highlights the approach or methodologies for major activities and phases.

<The content is meant as an example only. Each project will require its own specific list.>

Activity or Phase / Approach or Methodology
Procurement/Contracts / <Project management services and project resources will be procured.>
<The project will be completed using in-house resources only.>
Prototypes / <Prototypes will be used prior to preparing detailed design specifications.>
Pilots / <The application will be piloted for three months prior to implementation.>
Training / <Training will be conducted using a train the trainer method.>

13.0Project Organization

13.1Project Structure

The typical project governance for NRS IM/IT projects has been inserted. Highlight the object and select Presentation Object and Edit to make changes. Or remove and insert your own project organization diagram.>

The following diagram illustrates the reporting organization of the project.

13.2Roles and Responsibilities of Stakeholders and Project Team

The NRS SDLC identifies the roles and responsibilities of the resources involved in producing a particular deliverable or conducting an activity within the SDLC for all NRS IM/IT projects.

The following tables define the primary roles and time estimates for the resources to support this project.

For convenience and reference, the tables have been pre-populated with the resource roles identified in the NRS Roles and Responsibilities document. Remove, add, or move roles to indicate the primary resources for this project by responsibility group. If necessary, use the Major Tasks/Responsibilities column to identify differences from the SDLC R&R, exceptions, or applicability. Otherwise, refer to the roles and responsibilities document posted on the NRS SDLC website.>

13.2.1Business Resources

Business Roles
Resource Role & Name / Time Estimate Range / Major Tasks / Responsibilities
Specify if different than the SDLC
Sample roles follow. Add, delete, change, or move, as needed. / Indicate both duration and effort. / Refer to NRS SDLC or specify, if roles are different
Application Administrator (AA) / X months at Y%
Business Area Project Team (BAPT) / X months at Y%
Business Lead (BL) / X months at Y%
Data Custodian (DC) / X months at Y%
Data Resource Manager (DRM) / X months at Y%
Data Standards Manager (DSM) / X months at Y%
Project Champion (PC) / X months at Y%
Project Sponsor (PS) / X months at Y%
Subject Matter Expert (SME) / X months at Y%
User Test Team (UTT) / X months at Y%
Total Effort Business Resources / Provide approximate total effort to complete the 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. Note the ranges in the budget, if applicable.

13.2.2Vendor Resources

Vendor Roles
Resource Role & Name / Time Estimate Range / Major Tasks / Responsibilities
Specify if different than the SDLC
Sample roles follow. Add, delete, change, or move, as needed. / Indicate both duration and effort plus estimated cost. / Refer to NRS SDLC or specify, if roles are different
Development Team Lead (DTL) / X months at Y%
Est. cost $X.
Development Team (DT) / X months at Y%
Est. cost $X.
Development Team Quality Reviewer (DTQR) / X months at Y%
Est. cost $X.
Independent Consultant (IC) / X months at Y%
Est. cost $X.
Technical Lead (TL) / X months at Y%
Est. cost $X.
Vendor (VNDR) / X months at Y%
Est. cost $X.
X months at Y%
Est. cost $X.
Total Effort and Cost for Vendor Resources / <Provide approximate total effort and cost to complete the 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. Note the ranges in the budget, if applicable.>

13.2.3NRS IMB Resources

NRS IMB Roles
Resource Role & Name / Time Estimate Range / Major Tasks / Responsibilities
Specify if different than the SDLC
Sample roles follow. Add, delete, change, or move, as needed. / Indicate both duration and effort / Refer to NRS SDLC or specify, if roles are different
Application Delivery Specialist (AD) / X months at Y%
Business Analyst (BA) / X months at Y%
Client Business Solutions Director (CBSD) / X months at Y%
Client Contract Administrator (CA) / X months at Y%
Data Architect (DA) / X months at Y%
Database Administrator (DBA) / X months at Y%
Infrastructure Director (ISD) / X months at Y%
Infrastructure Services (IS) / X months at Y%
Sector Information Security Officer (SISO) / X months at Y%
NRS Business Service Desk (NRSBSD) / X months at Y%
NRS Chief Information Officer (CIO) / X months at Y%
Project Manager (PM) / X months at Y%
Project Management Office (PMO) / X months at Y%
Technical Architecture (TARCH) / X months at Y%
Technology Services (TS) / X months at Y%
Web Analyst (WEB) / X months at Y%
X months at Y%
Total Effort for NRS IMB Resources / <Provide approximate total effort to complete the 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. Note the ranges in the budget, if applicable.>

13.2.4CSNR Resources

CSNR Roles
Resource Role & Name / Time Estimate Range / Major Tasks / Responsibilities
Specify if different than the SDLC
Sample roles follow. Add, delete, change, or move, as needed. / Indicate both duration and effort / Refer to NRS SDLC or specify, if roles are different
Financial Business Analyst (FBA) / X months at Y%
Total Effort for CSNR Resources / <Provide approximate total effort to complete the 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. Note the ranges in the budget, if applicable.>

13.2.5CITZ and OCIO Resources

CITZ & OCIO Roles
Resource Role & Name / Time Estimate Range / Major Tasks / Responsibilities
Specify if different than the SDLC
Sample roles follow. Add, delete, change, or move, as needed. / Indicate both duration and effort / Refer to NRS SDLC or specify, if roles are different
DataBC (DBC) / X months at Y%
Knowledge and Information Services (KIS) / X months at Y%
Ministry Privacy Officer (MPO) / X months at Y%
Records Management (RM) / X months at Y%
Total Effort for CITZ & OCIO Resources / <Provide approximate total effort to complete the 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. Note the ranges in the budget, if applicable.>

13.2.6Special Committees

The following committees will be necessary for this project: