Project Management

by Alan Harpham, Tony Kippenberger, Graham Bosman

From mandate to brief

Before you start making the business case for your project, there is a crucial question you need to ask: is there a mandate for the project?

First things first: the mandate

The mandate should identify the person(s) responsible for authorising the project – the project owner/sponsor. It can, and ideally should, also contain – albeit at a high level – outline information on

  • The background to the project
  • The reasons the project is needed
  • The project’s objectives
  • The way project success might be measured
  • Its scope
  • The constraints within which it may have to work
  • The interfaces it is expected to have (both with people and equipment)
  • Quality expectations
  • Probable tolerances (for example, in terms of time and money)
  • The customer(s) or user(s)
  • Any other interested parties (stakeholders – internal or external).

Ideally, the mandate should contain sufficient information to enable an informed choice as to who would fit the roles of both project sponsor and project manager. If no such document exists, then beware. It probably means that nobody is taking responsibility for the project and much of the rationale for its existence has not been thought through. Any project manager should ask for such a Mandate before going any further. If there is no mandate, you should be prepared to put one together and get it formally signed off by the project owner/sponsor.

Top tip

Always make sure the mandate is signed off by someone who has the level of authority that matches the anticipated risk, cost and size of the project.

Even if there is a mandate, always check that it comes from someone who has the level of authority that matches the anticipated risk, cost and size of the project. Indeed, many more advanced organisations will have express levels of authority for initiating and approving projects.

Moving on from a mandate

One of the problems that project managers face is that while there is an identified need – the reason for the project – it is quite often at a very high level. In order to come up with a business case (and a project plan), it will be necessary to identify the user requirements clearly and in more detail. So it’s not enough simply to know that a new IT system is needed to improve customer relations or that a brochure is intended to attract new customers. The people who will ‘use’ the outputs need to define what it is that they actually require.

Users typically want the best that is available (regardless of cost) as quickly as possible. Or, even worse, they can’t define what it is that they do want – either because they haven’t thought long and hard about it or they simply don’t know enough about the different possibilities or solutions.

Having tied down the user requirements, there is then the issue of determining whether the organisation can afford to meet them. Frequently, the answer is ‘no’ and it is part of the project sponsor’s role to determine which of the needs can be met and how. Clearly, a project manager has a significant advisory role in this.

Project brief

The purpose of the project brief (or a statement of work, or some form of terms of reference) is to take the potential project on from its original mandate. It is prepared by the project manager (based on the mandate) and needs to be agreed by the project sponsor and the project board. The ‘brief’ firms up a number of things and goes into more detail on

  • The project’s rationale or justification
  • Its objectives and its scope
  • The project’s main outputs/deliverables and ultimate outcomes (benefits)
  • The constraints it faces
  • The interfaces it may have
  • An outline business case (reinforcement for the reasons for the project and confirmation as to why it is needed)
  • The acceptable tolerances in variation of output
  • Why this is the chosen option (if there were several possibilities)
  • Customer/user’s quality expectations
  • What the criteria are for the project’s outputs to be accepted
  • Known risks

The brief is an important input to the creation of a proper business case. In PRINCE2, this would be the starting point of the Project Initiation Document (PID).