Directing a Project Process

The directing a project process is one of the seven PRINCE2 processes. It covers the work of the project board from the very beginning of the project until the very end. Unlike the managing a stage boundary process (which happens at the end of each stage) or the controlling a stage process (which handles day-to-day work), directing a project runs continuously. The project board does not sit idle between meetings — it remains available to make key decisions whenever the project manager needs one.

Every PRINCE2 project has three levels of management: corporate or programme management (the organisation that owns the project), the project board (which directs the project), and the project manager (who manages the project day to day). Directing a project is the process that belongs to the project board. Its purpose is to enable the project board to make key decisions and to exercise overall control over the project. These decisions include: authorising initiation (giving permission to start planning the project in detail), authorising the project (signing off the project plan and allowing work to begin), authorising stage plans (approving each stage before it starts), giving ad hoc direction (handling exceptions, changes, or problems that arise between stage boundaries), and authorising project closure (signing off the final product and formally ending the project).

The process has five key activities, each of which maps to a major decision point. First, the project board authorises initiation. This happens after the initial idea (called the project mandate) has been received. The board appoints the project manager and provides the terms of reference (a brief outline of what the project should achieve). The project manager then creates the project brief and the initiation stage plan. The board reviews and approves these, allowing the project to move into its initiation stage.

Second, the board authorises the project itself. At the end of the initiation stage, the project manager presents the project initiation documentation (PID) — the full detailed plan, business case, risk register, and quality plan. The board decides if the project is worth doing. If they approve, the project moves into its first delivery stage. This is a critical gate: the board must be confident that the project remains aligned with the organisation’s strategy and that the benefits justify the costs.

Third, the board authorises each stage plan throughout the delivery phase. Between stages, the project manager submits an end stage report and a plan for the next stage. The board reviews progress, checks that the project is still viable, and either approves the next stage or stops the project. This is how PRINCE2 prevents runaway projects: the board must actively say “go” at every stage boundary.

Fourth, the board gives ad hoc direction. This is the “continuous” part of directing a project. If the project manager discovers a problem that exceeds their tolerance (the allowed deviation from the plan), they must escalate it to the board. The board then decides whether to allow more time, more budget, or a change of approach. This could happen at any time, not just at stage boundaries.

Fifth, the board authorises project closure. When the final product is delivered, the project manager produces a project closure report and a lessons report. The board reviews these, confirms that all objectives have been met, and officially closes the project. They also ensure that benefits will be measured after the project ends (this is done in the managing product delivery process and the benefits management approach).

The project board has three roles: the executive (the single person who owns the business case and is ultimately accountable for the project’s success), the senior user (who represents the people who will use the product), and the senior supplier (who represents the team that will build the product). These three roles together make all key decisions. PRINCE2 insists on a three-way balance so that no single perspective dominates.

Why does this process exist? In many organisations, projects fail because nobody with enough authority is paying attention, or because too many people are trying to make small decisions. Directing a project solves both problems: it gives the project manager the freedom to manage daily work, and it forces the most senior stakeholders to focus on the few decisions that truly matter. It replaces chaos with a clear governance structure. Without it, a project might start without proper approval, continue past the point where it makes sense, or close without anyone signing off the result.

Imagine you work as a project manager for a mid-sized retail company called GreenLeaf. The board of directors wants to launch a new online ordering system. In a PRINCE2 environment, here is exactly how the directing a project process plays out.

First, the board receives a project mandate from the CEO saying “we need an e-commerce upgrade.” The executive (the company’s operations director) calls a short meeting with the senior user (the head of customer service) and the senior supplier (the IT director). They decide: yes, this is worth investigating. They authorise initiation — they create a brief outline, appoint you as project manager, and give you a small budget to plan the initiation stage.

You spend two weeks writing the business case, the project plan, and the risk register. You present the PID to the board. They ask questions: “Have we considered the risk of the payment gateway failing? Is the budget realistic?” After a 90-minute meeting, they authorise the project. Now you can start building.

The work is split into three stages: design, build, and test. At the end of the design stage, you present an end stage report. The board notices that the design phase finished late and the budget is slightly over. They ask you to explain. You show them the revised plan for the build stage, and they approve it — but they tighten the tolerances (they allow less extra time before you must escalate).

During the build stage, the lead developer discovers that the chosen payment service is about to double its fees. This would blow the entire budget. You calculate that the cost overrun will exceed your tolerance. You call an emergency board meeting (ad hoc direction). The board decides to switch to a different payment provider, even though it will delay the project by two weeks. They authorise the change.

At the end of the test stage, the system passes all checks. You produce the closure report and lessons log. The board meets one last time — they check that the new system can handle Black Friday traffic, and they confirm that the customer service team has been trained. They sign off the project as complete. The executive ensures that benefits measurement will continue for the next six months.

The key actions an IT professional must take in this process are:

Note that the board never writes code, never tests the system, and never talks to vendors directly. Their job is pure governance. If they start doing the project manager’s job, the process breaks down.