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
Project Sponsor | Signature | Date | |
[Name] | |||
[Title] | |||
Project Manager | Signature | Date | |
[Name] | |||
[Title] | |||
[optional others] | Signature | Date | |
[Name] | |||
[Title] |
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.]
Table of Contents
6.0 Milestones and Project Plan. 7
12.0 Project Infrastructure. 10
13.0 Project Review and Completion Criteria. 11
Reviews and Document Control 14
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.>
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.>
Major Deliverable | 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 project
- Programs external to the sponsoring program that either affect or are affected by the project
- Customers of the program(s) affected by the project
- Organizational areas responsible for support of the project deliverables.
<Identify stakeholders by organizational area and include the individual’s name or position where known.>
The following stakeholders’ (internal and external) interests, expectation, and potential concerns must be considered throughout the project:
<The following table’s content is meant as an example and is not complete. Each project will require its own specific set of Stakeholders and representatives.>
Stakeholder | Represented by | Interests, Expectations, Concerns |
Ministry Executive | Project Sponsor (Add Name) | |
Ministry Public Clients | (Names of people that represent this group) | |
Ministry Management & Staff | ||
Information Management Branch |
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 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.>
*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.
12.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.
<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.>
13.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.
Appendix A: Workplan
Gantt Chart
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 |