Before the project: the mandate and pre-project

Every PRINCE2 project begins with a trigger from outside the project: a request, an instruction or an idea from the business layer that something should be done. PRINCE2 calls this trigger the project mandate. This lesson looks at what a mandate is, what it should and should not contain, who issues it, how good mandates differ from poor ones, and why the period before a project is authorized needs its own deliberate, lightweight management. It sets the scene for starting up a project, which turns the mandate into a project brief.

What a project mandate is

A project mandate is the external information that triggers starting up a project. It comes from whoever has the authority to commission the project: corporate management, a program management team, or a customer organization. It may be a formal document such as a strategy decision, a council resolution or a program's project definition, or it may be as informal as an email or a conversation recorded in a meeting note. PRINCE2 does not prescribe a format for the mandate, because by definition it is produced outside the project and before the project exists.

What matters is that the mandate gives enough information to identify at least the prospective executive and the reason the project is being considered. Everything else can be developed during starting up. A mandate that tries to be a full business case is usually a sign that someone has already decided the answer and wants the project to rubber-stamp it. A mandate that contains only a solution, with no problem or purpose, is a sign that the starting up process will need to work hard to establish why the project exists.

Who issues the mandate

In a single organization, the mandate usually comes from corporate management: a senior executive, a management committee, a board of directors or, in the public sector, an elected council or its delegate. In a program, the program management team issues a mandate, often with more detail, because the program has already decided why the project is needed and how it contributes to program benefits. In a customer–supplier situation, the mandate may come from the customer, and the supplier may run its own project to meet the customer's needs.

The source matters because it defines the business layer for this project: who sets the project tolerances, who must be consulted about project-level exceptions, and who will receive the closure notification. If starting up cannot identify who has issued the mandate and with what authority, the project has no clear escalation route, and that gap will reappear the first time a forecast breaches project tolerance.

For a US municipal utility such as Ridgeline Water, the business layer is typically the general manager or city manager acting on behalf of the city council or utility board, with the council or board approving capital spending above a threshold set in the municipal code and capital improvement plan. Federal agencies work under OMB guidance and their own capital planning rules; a federal project would align its PRINCE2 stage boundaries with those approval points rather than invent new ones.

Good and poor mandates

The quality of a mandate varies enormously. A good mandate is short, says why change is needed, names who will own it, and states the constraints that really matter. A poor mandate is either so vague that nobody can say what success would look like, or so prescriptive that it closes off options before anyone has examined them. Neither is fatal. Starting up exists precisely to turn whatever arrives into a project brief that the board can decide on. But a poor mandate tells the project manager where the effort in starting up will need to go.

When the mandate already names a solution, the project manager should not simply ignore it, nor treat it as unchallengeable. The outline business case in the project brief records the options considered, and if the business layer has genuinely ruled options out, that becomes a stated constraint with its reason. If it turns out that nobody can explain why the named solution was chosen, the executive should take that question back to the business layer before money is spent on initiation.

Why pre-project needs managing

Before a project is authorized, nobody has a budget, a plan or formal authority. Yet work is already happening: people are talking to suppliers, sketching solutions and forming opinions. If this period is unmanaged, two things go wrong. Some ideas drift into full-scale work without anyone ever deciding that they are worth it. Others are killed by enthusiasm in the wrong direction, because a solution was chosen before the problem was understood. Starting up a project gives this period a light structure and a clear end point: a decision about whether to invest in initiation.

PRINCE2's principle of continued business justification applies even here. The question in starting up is not yet 'is this project definitely worth doing?' but 'is it worth spending the money and time to find out properly?' That is a much smaller question, and it deserves a much smaller answer. Many organizations waste effort by writing what is effectively a full business case before initiation has been authorized, only to rewrite it once the project plan exists. PRINCE2 keeps the early version deliberately outline.

Projects that should not start

One of the most valuable outcomes of starting up is a decision not to proceed. The executive may find that the problem is better solved by a change to business as usual, that the organization lacks the capacity to run another project this year, or that the idea duplicates work already under way elsewhere. Stopping at this point costs very little. Stopping halfway through delivery costs a great deal, both in money and in the credibility of the people who championed the idea. A board that never refuses to authorize initiation is not directing; it is approving.

Ridgeline Water's mandate asks for options. During starting up, the project manager discovers that IT is planning a billing system upgrade next year that will change the interfaces any metering system must use. This does not stop the project, but it becomes a key dependency recorded in the project brief, and it influences the project approach: the metering project will build its billing interface against the new system, and the initiation stage plan includes time to agree the interface with IT.

Checking a mandate before starting up

The code below checks a mandate's content against the minimum that starting up needs to begin: a reason, an executive, and at least one constraint or objective. It also flags mandates that contain a solution but no reason. The check is deliberately simple; its purpose is to show the project manager where the gaps are before the first conversation with the executive.

mandates = {
    "Ridgeline Water": {"reason": "Manual reading costly; no leak data", "executive": "Director of finance and operations",
                        "objectives": ["Accurate bills", "Earlier leak detection"], "constraints": ["About 10 million capital"],
                        "solution": None},
    "Fleet telematics": {"reason": None, "executive": None, "objectives": [], "constraints": ["By June"],
                         "solution": "Install Brand Y trackers"},
    "Records digitization": {"reason": "Paper archive full", "executive": None, "objectives": ["Searchable records"],
                             "constraints": [], "solution": None},
}
for name, m in mandates.items():
    gaps = []
    if not m["reason"]:
        gaps.append("no reason")
    if not m["executive"]:
        gaps.append("no executive")
    if not m["objectives"] and not m["constraints"]:
        gaps.append("no objectives or constraints")
    if m["solution"] and not m["reason"]:
        gaps.append("solution without a reason")
    status = "ready for starting up" if not gaps else "clarify first: " + "; ".join(gaps)
    print(f"{name:21} {status}")

Ridgeline Water       ready for starting up
Fleet telematics      clarify first: no reason; no executive; solution without a reason
Records digitization  clarify first: no executive

Ridgeline Water's mandate is ready. The fleet telematics mandate names a solution and a deadline but no reason and no executive, so the first job is to find out who wants it and why. The records digitization mandate has a clear problem but nobody accountable; starting up cannot properly begin until someone agrees to be executive, because the executive is the first appointment and the project manager is appointed by the executive.