Project Mandate
Scope
This document contains the concept of the project as supplied by the Project’s Owner[1]. It provides the authority it is used as a tool for realizing the benefits described in the Business Case within the given constraints.
During the project, this document will supply a baseline to be referred to every time a question is arisen about the feasibility of the proposed actions within the established boundaries.
Quality
The effectiveness can be measured with these parameters:
- The level of authority is commensurate with the anticipated size, risk and cost of the project
- There is sufficient details to allow the appointment of an appropriate Executive and Project Manager
- All the known interested parties are identified
- The Project Mandate describes what is required
- This document is signed by the Project’s Owner.
RACI (who does what)
| Operation desc./Roles[2] | Owner | Spr | PM | SME | Stkhd |
| Collecting all necessary information[3] |
A |
C |
R |
C |
C |
| Issuing the document |
A |
C |
R |
C |
C |
| Approving and signing it |
A |
C |
C |
C |
C |
Document structure
Distribution list
This kind of information has to be made publicly available (read-only).
Registrar section
All “standard” information (e.g. date, version etc) are described in the following post.
These are the key fields
| Project Mandate ID | |
| Responsible authority | Person or board that holds the necessary authority to allocate the resources |
| Background | Reference to the company’s rules |
| Project objectives | Any reference to feasibility studies or Cost/Benefit analysis |
| Scope | What the project has to achieve within the given resources. |
| Constraints | Any known limit (e.g. legal, organizational, marketing etc). |
| Interfaces | Listing all the components, either technical or organizational, to which the project and its product has to deal with. |
| Customer’s quality expectations | Outline what will be expected. The details will be described in the “Acceptance Criteria” |
| Outline Business Case (reasons) | The reasons for doing the project |
| Project tolerances | The values forming the “band” where the variations are accepted without explicit order from the sponsor. |
| Reference to any associated documents or products | The project lives and produces in a specific environment made of a myriad of elements. In this document, the most important things have to be listed and then the required communication protocols clearly defined. |
| An indication of who are to be the Executive and Project Manager | The indications should be both in essential traits (personality and experience) and in potential candidates |
| The customer(s), user(s), and any other known interested parties | This document will form the first input for the “Communication Management Strategy” |
| Any other useful information that may come from previous ones which had the same size, duration and a view of the risks faced by the project | Any further reference to history will increase the quality of the initial works (e.g. Risk Analysis). |
Technical domains
Any reference to the existing feasibility study
Financial / Commercial domains
Any reference to the market / organization analysis
Notes
References
[1] This role could be attributed to the company’s board or the person with all the necessary power for allocating the resources necessary to produce what has been agreed. This person will be external to the projects’ team or at least will hold the “Sponsor” role.
[2] Spr Sponsor, PM Project manager, BA Business Analyst, TL Technical Leader, Prd Producer, Stkhd Stakeholder
[3] Usually these can be produced by a “Feasibility Study”

