What is a Project Mandate?

Project mandate – the basis for a project

The project mandate is the formal basis for carrying out a project. In most companies, it is issued after project initiation and before project planning. The project order corresponds to an authorisation for project implementation, which, depending on the organisation, is given by the management – the management, the department head or also the Project Management Office.

If a project starts without a project mandate, this quickly leads to so-called submarine projects in organisations, which access scarce capacities, cause friction losses and possibly impair the performance of the entire company.

In addition to these points, a project mandate – also known as a project charter, project agreement or a project order – can also contain information on the scope or the elements that are “out of scope”, as well as on further documents such as initial project plans, a risk matrix, a target diagram, etc. Possible interfaces and dependencies to other projects can also be described.

Questions for the creation of project mandates

There are a number of questions that help when writing project mandates¹:

• What is to be achieved by the project and what is not? (project goals and anti-goals)
• Who is behind the project and wants to see it realised? (project client)
• Who is pursuing which interests and goals? (stakeholders)
• What are the benefits of the project, where are the opportunities and what are the risks?
• What are the framework conditions, which are unchangeable, which can be changed if necessary?
• Who is involved, to what extent and with what competences? (project team)
• What are the time frames (start, end), what are the dependencies on other projects or the availability of resources?
• What determines the success or failure of the project?

Asking about similar projects in the past can also help in creating a project mandate.

The documentation of project mandates

Unless it is a part of the contract between the client and the contractor, a project mandate does not have to be recorded in writing. Especially in smaller organisations, where projects tend to require little effort, where only one or two people are needed for implementation, and where projects are repetitive rather than one-off, the assignment is often verbal.

In organisations that carry out complicated or complex projects, for which revision security, IT compliance and traceability are important, the project order contains too much information that cannot be conveyed verbally in a few sentences. In such cases, the project order is an internal document that contains the project definition and orders project execution. Project approval is accompanied by the release of financial resources, employees are allocated for the duration of the project, and project work can begin.

Project mandate and business case

What is the relationship between a business case and a project mandate? A business case assesses the benefits, costs and risks of a project and evaluates the impact of a company’s project investment. It thus provides the basis for approving or rejecting a project. In a positive case, it can be the basis for the project mandate, but since not every project justifies the effort required to create a business case, it does not have to be the basis.

In the real project context, there is another difference between a project mandate and a business case: the business case is not only a one-time, but also a continuous justification of a project. It is always a snapshot, i.e. it assesses a situation and various options for action at a certain point in time. Since parameters can change quickly, the business case can also be adapted in the course of a project. In theory, it would of course also be possible to adapt the project mandate, but such an adaptation rarely takes place in project management practice.

Tips for creating project mandates

There are some tips that are useful when creating project mandates. Here is a selection:

• Research the history of the project. For example, ask why the project is happening now, what will happen if the current situation does not change, and what has already been tried to solve the existing problem?
• Use simple and clear language. Technical terms are often understood in different ways, so it may make sense to avoid using them.
• Document success criteria so that the parties involved know how the success of the project is measured.
• Put the project brief up for discussion. Ideally, it should be reviewed and commented on by all parties involved – especially key stakeholders. It is advisable to allow enough time here, as any omission, any misunderstanding will be comparatively more expensive in the course of the cooperation than if you intervene early on.

And last but not least, use checklists or templates.

Impulse to discuss:

The project mandate  is the life insurance for the project manager and the project team.

Notes:

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

[1] A meaningful project mandate is based on the common understanding of the parties involved. This understanding needs to be worked out in the course of clarifying the mandate – ideally with very individual questions.

Here you can find a German language video about clarifying the project mandate.

Here you can find additional information from our t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.