Purpose of the Document - B.C. Homepage - Province of ... · Web view . Documentation Management Project documentation will be prepared using standard NRS SDLC or Government templates

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

[Name]

[Title]

Project Manager Signature Date

[Name]

[Title]

[optional others] Signature Date

[Name]

[Title]

Master Project Plan <insert project name> Page 2 of 27

VERSION HISTORY

Version Date Responsible Notes

Purpose of the DocumentThe 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.]


Table of ContentsPurpose of the Document..............................................................................................................................41.0 Project Purpose..................................................................................................................................62.0 Background........................................................................................................................................63.0 Objectives..........................................................................................................................................64.0 Scope.................................................................................................................................................6

4.1 In Scope............................................................................................................................................64.2 Out of Scope.....................................................................................................................................7

5.0 Major Deliverables.............................................................................................................................76.0 Milestones and Project Plan...............................................................................................................77.0 Stakeholders......................................................................................................................................8

7.1 Stakeholder Analysis........................................................................................................................98.0 Links and Dependencies.....................................................................................................................99.0 Issues and Constraints......................................................................................................................1010.0 Assumptions.....................................................................................................................................1111.0 Budget..............................................................................................................................................11

11.1 Sustainment....................................................................................................................................1212.0 Approach..........................................................................................................................................1213.0 Project Organization........................................................................................................................13

13.1 Project Structure.............................................................................................................................1313.2 Roles and Responsibilities of Stakeholders and Project Team......................................................14

14.0 Project Control.................................................................................................................................1814.1 Integration Management.................................................................................................................1914.2 Scope Management........................................................................................................................2114.3 Time Management..........................................................................................................................2114.4 Cost management...........................................................................................................................2114.5 Quality Management......................................................................................................................2214.6 Human Resource Management.......................................................................................................2214.7 Communication Management........................................................................................................2214.8 Procurement Management..............................................................................................................2314.9 Risk Management...........................................................................................................................24

15.0 Project Infrastructure.......................................................................................................................2416.0 Project Review and Completion Criteria..........................................................................................25Appendix A: Workplan................................................................................................................................26Appendix B: Glossary / Lexicon...................................................................................................................27Reviews and Document Control...................................................................................................................28


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


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:

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

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

MajorDeliverable

Description Target Date

Project Plan

Software Requirements Specification

Software Design Description

Development

Implementation

Project Management


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 projectPrograms external to the sponsoring program that either affect or are affected by the projectCustomers of the program(s) affected by the projectOrganizational 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.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.

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

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

<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 ComplexMaintenanceBusiness ArchitectureLightweight>

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


The following diagram illustrates the reporting organization of the project. November 28, 2014 Systems Development Life Cycle Roles and Responsibilities

1 TYPICAL PROJECT GOVERNANCE

STEERING COMMITTEE

BUSINESS AREA PROJECT TEAM

PROJECT MANAGER

VENDOR TEAM

PROJECT SPONSOR

PROJECT CHAMPION

IMB TEAM LEADS

BUSINESS LEAD

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


13.2.1 Business Resources

Business Roles

Resource Role & NameTime 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.2 Vendor Resources

Vendor Roles





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%


Vendor Roles




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





Indicate both duration and effort


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%


NRS IMB Roles




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.4 CSNR Resources

CSNR Roles







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.5 CITZ and OCIO Resources

CITZ & OCIO Roles







DataBC (DBC) X months at Y%Knowledge and Information Services (KIS)

X months at Y%

Ministry Privacy Officer (MPO) X months at Y%


CITZ & OCIO Roles




Records Management (RM) X months at Y%Total Effort for CITZ & OCIO Resources


13.2.6 Special Committees

The following committees will be necessary for this project:

Special Committee Roles



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)

Total Effort for CITZ & OCIO Resources



14.0 Project ControlThis 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).

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

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.


https://a100.gov.bc.ca/pub/svn/

At the completion of the project all documentation deliverables will be placed in the project repository.

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


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


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 InfrastructureThe project infrastructure includes all the services, tools and work environment facilities available to the project team to allow them to do their work.


http://www.cio.gov.bc.ca/cio/priv_leg/foippa/pia/pia_index.page

http://www.cio.gov.bc.ca/cio/priv_leg/foippa/pia/pia_index.page

http://www.cio.gov.bc.ca/local/cio/informationsecurity/policy/summaries/7_sec_threat_risk.pdf

http://www.cio.gov.bc.ca/local/cio/informationsecurity/policy/summaries/7_sec_threat_risk.pdf

http://www.fin.gov.bc.ca/ocg/fmb/manuals/CPM/15_Security.htm

http://www.fin.gov.bc.ca/ocg/fmb/manuals/CPM/14_Risk_Mgmt.htm

http://www.fin.gov.bc.ca/ocg/fmb/manuals/CPM/14_Risk_Mgmt.htm

http://www.fin.gov.bc.ca/pt/rmb/erm.shtml

http://www.fin.gov.bc.ca/pt/rmb/erm.shtml

<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 EnvironmentServices AssistanceTechnical Environments and Special RequirementsSharePoint for collaborationOther 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; andall project files are completed and documentation archived.


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


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:


Reviews and Document ControlReviews

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

Name Position

Project Management

Name Position

<name> Project Manager
