Corporate Services for the
Natural Resource Sector
<Note: Replace (or delete) bracketed
and/or Green text 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
Approvals:
Project Sponsor
Signature
Date
Signature
Date
Signature
Date
[Name]
[Title]
Project Manager
[Name]
[Title]
[optional others]
[Name]
[Title]
Master Project Plan <insert project name>
Page 2 of 27
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 template is 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,
Work plan, WBS, Gantt chart,
Budget and Cost Management Plan.
[etc.]
Master Project Plan <insert project name>
Page 3 of 27
Table of Contents
Purpose of the Document .............................................................................................................................. 3
1.0
Project Purpose .................................................................................................................................. 5
2.0
Background ......................................................................................................................................... 5
3.0
Objectives ........................................................................................................................................... 5
4.0
Scope .................................................................................................................................................. 5
4.1
In Scope .......................................................................................................................................... 6
4.2
Out of Scope ................................................................................................................................... 6
5.0
Major Deliverables ............................................................................................................................. 6
6.0
Milestones and Project Plan ............................................................................................................... 7
7.0
Stakeholders ....................................................................................................................................... 7
7.1
Stakeholder Analysis ...................................................................................................................... 8
8.0
Links and Dependencies ..................................................................................................................... 9
9.0
Issues and Constraints ........................................................................................................................ 9
10.0 Assumptions ..................................................................................................................................... 10
11.0 Budget .............................................................................................................................................. 10
11.1 Sustainment ...................................................................................................................................11
12.0 Approach .......................................................................................................................................... 11
13.0 Project Organization ......................................................................................................................... 12
13.1 Project Structure ............................................................................................................................12
13.2 Roles and Responsibilities of Stakeholders and Project Team ......................................................13
14.0 Project Control.................................................................................................................................. 17
14.1 Integration Management ................................................................................................................18
14.2 Scope Management........................................................................................................................20
14.3 Time Management .........................................................................................................................20
14.4 Cost management ..........................................................................................................................20
14.5 Quality Management .....................................................................................................................21
14.6 Human Resource Management ......................................................................................................21
14.7 Communication Management ........................................................................................................21
14.8 Procurement Management .............................................................................................................22
14.9 Risk Management ..........................................................................................................................23
15.0 Project Infrastructure ....................................................................................................................... 23
16.0 Project Review and Completion Criteria .......................................................................................... 24
Appendix A: Workplan ................................................................................................................................. 25
Appendix B: Glossary / Lexicon ................................................................................................................... 26
Reviews and Document Control ................................................................................................................... 27
Master Project Plan <insert project name>
Page 4 of 27
1.0
Project 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.0
Background
<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.0
Objectives
<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.0
Scope
<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.>
Master Project Plan <insert project name>
Page 5 of 27
4.1
In 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:

4.2
<list>
Out 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.>

5.0
<list>
Major 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
Master Project Plan <insert project name>
Page 6 of 27
6.0
Milestones 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.0
Stakeholders
<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.>
Master Project Plan <insert project name>
Page 7 of 27
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
Ministry Executive
Project Sponsor (Add
Name)
Ministry Public Clients
(Names of people
that represent this
group)
Interests, Expectations, Concerns
Ministry Management
& Staff
Information
Management Branch
7.1
Stakeholder 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.
Master Project Plan <insert project name>
Page 8 of 27
<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.0
Links 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:


9.0
<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.>
Issues 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.>
Master Project Plan <insert project name>
Page 9 of 27






<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.0 Assumptions
<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.0 Budget
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
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
Project
Management
Travel
Training
Master Project Plan <insert project name>
Page 10 of 27
Sustainment
STOB
FY 13/14
Maintenance*
FY 14/15
FY 15/16
FY 16/17
FY 17/18
20%
15%
10%
10%
Total
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.1 Sustainment
<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
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.
Responsibility
Other
12.0 Approach
<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.>
Master Project Plan <insert project name>
Page 11 of 27
<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.0 Project Organization
13.1 Project 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.>
Master Project Plan <insert project name>
Page 12 of 27
November 28, 2014
Systems Development Life Cycle Roles and Responsibilities
The following diagram illustrates the reporting organization of the project.
1 TYPICAL PROJECT GOVERNANCE
PROJECT
SPONSOR
STEERING
COMMITTEE
PROJECT
CHAMPION
BUSINESS
LEAD
PROJECT
MANAGER
BUSINESS AREA
PROJECT TEAM
VENDOR
TEAM
IMB
TEAM LEADS
13.2 Roles 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.>
Master Project Plan <insert project name>
Page 13 of 27
13.2.1 Business 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.
Application Administrator (AA)
Indicate both duration
and effort.
Refer to NRS SDLC or specify, if
roles are different
Business Area Project Team
(BAPT)
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.>
X months at Y%
X months at Y%
13.2.2 Vendor 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.
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%
Master Project Plan <insert project name>
Refer to NRS SDLC or specify, if
roles are different
Page 14 of 27
Vendor Roles
Resource Role & Name
Time Estimate Range
Major Tasks /
Responsibilities
Specify if different than the SDLC
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.3 NRS 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.
Application Delivery Specialist
(AD)
Business Analyst (BA)
Indicate both duration
and effort
Client Business Solutions
Director (CBSD)
Client Contract Administrator
(CA)
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)
NRS Business Service Desk
(NRSBSD)
NRS Chief Information Officer
(CIO)
X months at Y%
Refer to NRS SDLC or specify, if
roles are different
X months at Y%
X months at Y%
X months at Y%
X months at Y%
X months at Y%
X months at Y%
Master Project Plan <insert project name>
Page 15 of 27
NRS IMB Roles
Resource Role & Name
Time Estimate Range
Major Tasks /
Responsibilities
Specify if different than the SDLC
Project Manager (PM)
X months at Y%
Project Management Office
(PMO)
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%
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.4 CSNR Resources
Time Estimate Range
Major Tasks /
Responsibilities
Sample roles follow. Add,
delete, change, or move, as
needed.
Financial Business Analyst (FBA)
Indicate both duration
and effort
Refer to NRS SDLC or specify, if
roles are different
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.>
CSNR Roles
Resource Role & Name
Specify if different than the SDLC
X months at Y%
13.2.5 CITZ 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.
DataBC (DBC)
Indicate both duration
and effort
Knowledge and Information
Services (KIS)
Ministry Privacy Officer (MPO)
X months at Y%
Refer to NRS SDLC or specify, if
roles are different
X months at Y%
X months at Y%
Master Project Plan <insert project name>
Page 16 of 27
CITZ & OCIO Roles
Resource Role & Name
Time Estimate Range
Major Tasks /
Responsibilities
Specify if different than the SDLC
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.6 Special Committees
The following committees will be necessary for this project:
Special Committee Roles
Time Estimate Range
Major Tasks /
Responsibilities
Sample roles follow. Add,
delete, change, or move, as
needed. List members of the
committees as known or
expected.
Steering Committee
 Project Sponsor (chair)
 <positions likely to be
included>
<Name> Working Group
 <positions likely to be
included>
Application Scrutiny Committee
(ASC)
IM/IT Strategic Planning Council
(SPC)
Technical Advisory Group (TAG)
Indicate both duration
and effort
Refer to NRS SDLC or specify, if
roles are different
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.>
Resource Role & Name
14.0 Project Control
This section describes how the project will be managed. It has been subdivided into the 9
Project Management “Knowledge Areas” defined by the Project Management Institute
“Project Management Body of Knowledge” (PMBOK).
Master Project Plan <insert project name>
Page 17 of 27
<Sample paragraphs have been written in each section. Use and change as appropriate.>
<Note any special concerns about project priority here.>
14.1 Integration Management
<Integration management describes the processes required to ensure the project is properly
coordinated.>
14.1.1 Project Governance
<In this section, explain how the project will be governed (sponsorship, steering committees,
etc.). Explain any collaborative relationships, funding relationships or engagement models
that may apply.>
<Section 13.0, Project Organization includes a governance structure. This section should
describe only those items that are not included in Section 13.0.>
Reference Section 13.0, Project Organization
14.1.2 Project Co-Ordination
The project will be coordinated using a combination of the Systems Development Life Cycle
Processes for the Natural Resource Sector, industry standard project management practices
and guidelines, and general management principles. The project work plan (WBS and
schedule) will be base-lined and becomes a companion document to this MPP.
The project plan, combined with the issue and change management systems, help drive the
project and will be monitored closely by the project management team.
Progress will be reported to the Project Manager regularly as tasks are completed, enabling
the work plan to be kept up to date. During the project, team meetings will be held every
<insert frequency> where issues, action items and progress will be discussed. In addition, full
project management meetings will be held <insert frequency> to focus on milestones, action
items, issues and concerns.
14.1.3
Project Change Management Approach
Project changes may affect scope, budget, or timelines or cause rework of previous
deliverables. Change within the project will be controlled through formal change control
procedures. Changes to the project will be documented and approved using NRS standard
change request and/or decision request forms. The changes will be recorded in a change log
that resides <insert location>. Change requests beyond the approval level of the project
manager will be evaluated and approved either by the Project Sponsor or by the Project
Steering Committee <or insert role(s)>.
Status of change requests will be reviewed at team meetings.
14.1.4 Organizational Change Management Approach
<If organizational change is required, describe the approach that the project will take in order
to facilitate organizational change management.>
Master Project Plan <insert project name>
Page 18 of 27
The overall project will require organizational change in a number of different stakeholder
organizations in order to be successfully implemented.
In order for this project to be successful, the organization will need to <specify organizational
changes and how they will occur>.
14.1.5 Issue Management
An issue is any concern that, if not resolved, can jeopardize the success of the project in terms
of schedule, cost or quality. An issue may be raised by any member of the project team. All
issues will be logged in an issues log that resides at <insert location>.
Outstanding issues shall be resolved through the following escalation process:


Initially, issues shall be documented and logged, then addressed by <the Project
Manager, team leaders, other>;
Outstanding issues that cannot be resolved by the above people will be raised by the
Project Manager <or insert role> to the Project Sponsor and, as needed, to the Project
Steering Committee. These may result in a change request to be initiated.
14.1.6 Project Repository
<Describe the project repository structure and where the documents reside – e.g. SharePoint,
Network Drive, other. Sample paragraph follows.>
The project follows NRS IMB project repository guidelines.
The project repository is located at <insert location including full path>. Electronic versions of
all deliverables will reside at this location and will be retained for audit, permanent record,
and review purposes.
A SharePoint site <insert shortcut and include path> will be used for project collaboration and
interim document storage. All files will be moved to the project repository at regular intervals
and at the project close-out. The SharePoint site will be deleted at the end of the project if it
is no longer required.
Source code will be delivered via Subversion https://a100.gov.bc.ca/pub/svn/.
14.1.7 Documentation Management
Project documentation will be prepared using standard NRS SDLC or Government templates
wherever applicable. Documentation will reside in NRS standard project repositories as
described in section 14.1.6.
The Project Manager <or insert role> will manage the production of all documentation
deliverables and oversee the review and approval process for all documents. Project
documents will be prepared, reviewed, and approved according to standard IMB practices and
the processes documented within the NRS SDLC.
At the completion of the project all documentation deliverables will be placed in the project
repository.
Master Project Plan <insert project name>
Page 19 of 27
14.1.8 Configuration Management
All project deliverables will be managed to ensure that they are always at a known state of
development, review, acceptance or use. This includes requirement specifications, technical
design specifications, policy documents, tools, test data generators, procedures, management
plans, systems and user documentation, etc.
NRS IMB uses IRS to record application inventory and releases. Application Delivery
processes and versioning control are described on the NRS SDLC website. Data Architecture
standards and guidelines such as data naming and modeling standards are also available on
the NRS SDLC website.
14.2 Scope Management
[The processes required to ensure that the project includes all the work required, and only the
work required to complete the project successfully.]
The scope of the project is identified at a high level in the project charter. The review and
approval of the MPP and work plan will confirm the project scope. All changes to the scope
will be handled through change control as outlined in section 14.1.3 Project Change
Management Approach.
14.3 Time Management
[The processes required to ensure timely completion of the project.]
Planning is an iterative process involving all members of the project team. The major planning
for the project <has been done in conjunction with this MPP or will be completed>, and is
detailed in the project work plan. Subsequent planning will be done with project team
members at regularly scheduled meetings as identified in Section 14.1.2 <or insert frequency if
different> and for project change requests.
The Project Manager <or insert role> is responsible managing the work plan and schedule for
the project. The work plan will be maintained by gathering progress information on a regular
basis and by updating the work plan accordingly. The schedule will be reviewed with the
client sponsor and steering committee at the regular status meetings or as required.
Any changes to the schedule that affects major milestones or the final completion date will go
through formal change control, resulting in a new base lined version of the project work plan
and possibly a revision or new version of the MPP.
14.4 Cost management
[The processes required to ensure that the project is completed within the approved budget
(resources and dollars).]
The Project Manager <or insert role> is responsible for controlling the budget for the project.
The detailed project budget has been prepared and is summarized in Section 11. Financial
records will be collected throughout the project and reconciled to this budget and the
Government’s Corporate Accounting System on a monthly basis. The budget will be reviewed
Master Project Plan <insert project name>
Page 20 of 27
with the client sponsor, steering committee, and/or expense authority at regular status
meetings or as required.
Any changes to the budget which affect the approved budget limits will go through change
control, resulting in a new base-lined budget and possibly a new version of the MPP.
14.5 Quality Management
[The processes required to ensure that the project will satisfy the needs for which it was
undertaken.]
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.
A separate Quality Management Plan <has been/will be> developed that documents the
quality management requirements and responsibilities for this project.
14.6 Human Resource Management
[The processes required to make the most effective use of the people involved with the
project.]
The resource requirements for this project are documented in Section 13 of this MPP and in
the project work plan.
The acquisition of internal resources will be negotiated with each respective IMB director.
Similarly, all contract resource requirements will be planned for and included in the
acquisition procedures. The project work plan will be the major input for establishing each
resource requirement.
The Project Sponsor <or insert role> will have the responsibility for the staffing and resourcing
of the project team. The Project Manager is responsible for establishing and monitoring
resourcing requirements and effort. All major project team-staffing changes (e.g., a team lead)
will be authorized by the Project Manager and communicated to the Project Sponsor, IMB
Director, and Project Steering Committee.
As new people join the project team, they will be given an orientation including meeting other
team members, an overview of the project, team charter, and prerequisite documentation to
allow them to quickly become productive. When people leave the team, an exiting procedure
will be followed which may include providing information for performance reviews.
Project team meetings will be scheduled at regular intervals as identified in Section 14.1.2 <or
insert frequency, if different> to provide a forum for project information exchange and team
building.
14.7 Communication Management
[The processes required to ensure timely and appropriate generation, collection, dissemination,
storage, and ultimate disposition of project information.]
Master Project Plan <insert project name>
Page 21 of 27
Using the NRS Communications Plan template, a communications plan and matrix will be
developed early in the project and will address target audiences, message content,
media/methods, frequency, and who is responsible for message delivery.
<If a separate Communications Management Plan (CMP) document and matrix are not being
produced, describe how the project will communicate with stakeholders, other projects and the
project team in more detail here.>
14.7.1
Communications approach for external project stakeholders
The Project manager will….<add approach>
14.7.2
Communications approach for project team and management
The Project Manager will produce a <insert frequency> status report that will summarize
major work completed, in progress and due to start, and major issues and concerns. The NRS
status report template is available on the SDLC website.
The Project Manager will chair <insert frequency - reference the frequency in Section 14.1.2, if
appropriate> status meetings with the project team to track progress and discuss outstanding
issues.
The Project Manager will ensure that minutes are taken and distributed for every project
meeting.
14.7.3
Project Partnership Communications
<This section is unique to collaborative, joint initiatives and special engagement models.>
<name of partner(s)> project management and technical staff will attend project workshops
where appropriate. <name of partner(s)> staff will attend decision meetings and project
status meetings when required and appropriate to ensure a clear understanding of project
progress and current issues that may be provided to <name of partner(s)> management and
executive staff.
Joint participation in additional meetings may also be required e.g. technical review meetings,
design alternative meetings. The <name of partner(s)> Project Manager <or insert role> and
the Project Manager <or insert role> for this project will determine participation.
14.8 Procurement Management
[The processes required to acquire goods and services from outside the performing
organization.]
Procurement of goods and services from outside the organization (e.g. contractors) will follow
the Government and NSR IMB established contract and procurement standards, processes,
and policies. Procurement references can be found on the NRS SDLC website.
Contract resource requirements are identified in Section 13.2.2, Vendor Resources.
<State any significant processes that are needed to manage procurement. For example, add
statements for soliciting, selecting, negotiating, purchasing, administering, and completing
procurement. Include contracts, RFP’s, ITQ’s, software and hardware leases, warranties, etc.>
Master Project Plan <insert project name>
Page 22 of 27
14.9 Risk Management
[The processes concerned with identifying, analyzing, and responding to project risk.]
Risk Management for the project will be controlled through the existing formal risk
management procedures defined by Risk Management Branch and Government Security
Office, Enterprise Risk Management plus by following Core Policy, Chapter 14, Risk
Management and Core Policy, Chapter 15, Security.
The Project Manager <or enter role> has overall accountability to ensure that project risks are
appropriately managed. The actual task of risk management is, however, a team effort that
includes the Project Sponsor, Project Steering Committee, Project Team, and the Project
Manager.
A Risk Management Plan and Risk Register <will be / have been> developed for the project and
are <will be> located in the project repository. The risk plan will be maintained and updated
<according to the following schedule [list schedule here]> or <as defined in the Risk
Management Plan (separate document)> or <at key intervals of the project identified in the
workplan>, and at major change points of the project. Risk Management Plan and Risk
Register templates are available on the NRS SDLC website.
The Risk Register will be used to list, track, and monitor all risks. Major risks will be reported
on monthly <or insert frequency> in the project’s status reports.
Relevant risk management information will be disseminated according to the communications
plan.
The project workplan and budget have been developed with some contingency to allow for
both known risks and unknown risks.
A Quality Management Plan <will be / has been> developed for the project and is <will be>
located in the project repository. The Quality Management Plan will be maintained and
updated <according to the following schedule [list schedule here]> or <as defined in the Quality
Management Plan (separate document)> or <at key intervals of the project identified in the
workplan>, and at major change points of the project.
A Security Threat and Risk Assessment (STRA) <will be/has been> prepared for the project and
is <will> reside in iSmart. Reference to STRA is available on the Office of the Chief Information
Officer website.
A Privacy and Information Assessment <will be/has been> prepared for the project and is <will
be> located in the project repository. Reference to PIA is available on the Office of the Chief
Information Officer website.
15.0 Project Infrastructure
The project infrastructure includes all the services, tools and work environment facilities
available to the project team to allow them to do their work.
Master Project Plan <insert project name>
Page 23 of 27
<Use this statement if it applies> The project team will use standard facilities and tools already
available, such as meeting rooms, desktop computers, etc. No special requirements are
expected.
<Otherwise document the following special needs of the project:>
The project requires special needs as listed below:






Tools
Work Environment
Services Assistance
Technical Environments and Special Requirements
SharePoint for collaboration
Other Requirements]
<Note: If the project requires other infrastructure, then list and/or include in Resources and
Budget as applicable.>
16.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. Some
sample statements follow (add/modify/delete as needed)>.
The <name of group> will conduct a brief post project evaluation review to assess the project
management of the project, to identify any “lessons learned” and improvements to
methodologies and procedures, and to identify potential enhancements to the final product.
<For a long project, periodic interim project reviews should be held.>
<Some projects may require an Audit. Define this here, including when they will occur.>
<Consider using an exit survey for each project team member to provide input to the project
review process, rather than leaving it all to the end of the project.>
A Post-Implementation Review will be held three to six months <or insert time period> after
implementation to assess the system in full production.
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.
Master Project Plan <insert project name>
Page 24 of 27
Appendix A: Workplan
<The project work plan, often developed in MS Project, is a companion to the MPP. A summary
of the work plan (Gantt Chart, Major Milestones, Major Deliverable) can be inserted in this
appendix or include a link to the work plan.>
<The work plan that is approved with (or before) the MPP is referred to as the Baseline Version
1.0 work plan. All subsequent approved work plans will be given a new version number and
must also be saved in the same locations. Note: the ideal situation is to have the work plan
completed with the MPP. In practice, the details of the work plan may not be known until
more planning is completed.>
<The major milestones from Version 1.0 are recorded in Section 6 of this MPP (also refer to the
Sections under 13.2 for resourcing). Changes to milestones in subsequent approved versions
should also be recorded as a change to the MPP and in the work 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.>
A summary of the work plan is provided below <or insert link to work plan>:
<Remove the work plan appendix if not applicable.>
Master Project Plan <insert project name>
Page 25 of 27
Appendix B: Glossary / Lexicon
<Insert any clarification of common words and definitions here. Remove the glossary appendix
if not applicable.>
The glossary below is provided to clarify words, acronyms, and definitions that may be unique
to this project:
Master Project Plan <insert project name>
Page 26 of 27
Reviews and Document Control
Reviews
This document has been sent to the following for their review and comment.
Name
Position
Project Management
Name
Position
<name>
Project Manager
Master Project Plan <insert project name>
Page 27 of 27