Clarifying Some Key Points

The process Directing a Project is quite small, with just five activities, so it’s quite easy for it to pass you by in a blur without you grasping its significance. The Project Board is a pivotal part of PRINCE2 and in live projects it’s actually a common point of failure in using the method. For the exams, you must make sure that you understand how the process functions and, if you covered the process quite quickly when learning it, that you haven’t missed something important.

The process acts as a series of checks running through the project. These checks align with the management stage boundaries. PRINCE2 still insists on using the unwieldy name of End Stage Assessments for the end stage meetings of the Project Board to check the project, but pretty much the rest of the world calls them stage gates. The word ‘gate’ is actually a very good one in this context. It’s a barrier you stop at, but one which can then open to allow you through to the next area.

There’s a bit more to the process in the activity ‘Give ad hoc direction’. That ad hoc direction activity can be fired off by a number of different things and includes giving general advice to the Project Manager, not just making decisions.

Understanding that boards manage, not do

It’s easy to lose the focus on roles when thinking about particular people in the project. The word role is very significant because one person’s job on a project may cover a single role, more than one role, or just part of a role. If you don’t feel clear on this, have a look at the clarification of some key points in Chapter 12.

Project Board roles are all about managing the project, not about any aspect of doing it. Let’s say that again for emphasis. The Project Board roles don’t do anything on the project in terms of building or testing products. That doesn’t mean that people on the board can’t also do something in the project, but they don’t do it in their role as Project Board members.

Focusing on decision making

The process Directing a Project is overwhelmingly about decision making. Where you encounter a situation in the exam where the board is involved with the Project Manager, then normally the Project Manager will be recommending something but the board will be deciding it. That’s like normal day-to-day management in an organisation. A staff member may well recommend something to the boss, but can’t often insist on it. It’s the boss who makes the decision, which may or may not align with the staff member’s recommendation.

So, too, if the Project Manager needs to refer something to the board. The Project Manager will put the matter forward with a recommendation on a course of action. The board, as ‘the boss’, then makes the decision. The board may agree with the Project Manager, or may take a different view and instruct the Project Manager to take a different course of action. For example, as a solution to a problem, the Project Manager may recommend allocating an additional £50,000 to the project budget and carrying on. Having carefully considered the Project Manager’s argument, the board may disagree and instruct the Project Manager to stop all work and shut the project down instead.

The activities and decisions are:

Authorize Initiation – decision: Looking at the Project Brief and deciding whether it looks promising enough to justify starting the project and planning in detail (Initiation).

Authorize the project – decision: Looking at the PID and deciding whether to commit to the delivery stages or to stop here. If the PID is okay, then looking at the Stage Plan for the first delivery stage and, if it’s also okay, giving the Project Manager permission to start on that stage.

Authorize a Stage or Exception Plan – decision: Checking the plan and authorising the Project Manager to tackle the next stage at the planned end stage (for authorising a stage) or where a stage boundary has been forced by an exception situation that requires the stage to be re-planned.

Give ad-hoc direction: Giving advice, receiving reports and decision making. This activity is partly about making decisions on things that are beyond the Project Manager’s delegated authority, such as changes that are beyond the limit of the Project Manager’s change budget. It’s partly about receiving Highlight Reports, though, and that part of the activity doesn’t require any decision making. It’s also about giving guidance to the Project Manager when asked, and passing on inbound information from programme or corporate management.

Authorize project closure – decision: Checking that everything is complete and making the decision to close the project down.

So, of the five activities, four are solely decision making, and the fifth – Give ad hoc direction – includes a significant element of decision making.

Seeing where the process kicks in

Directing a Project is largely a responsive process. The activities are mostly triggered by the Project Manager, but could be triggered by programme or corporate management. Just occasionally, the trigger may come from within the board, and so within the process. In summary, the activity triggers are as follows:

Authorize Initiation – Project Manager submits the Project Brief.

Authorize the project – Project Manager submits the PID and the stage plan for the first delivery stage.

Authorize a Stage or Exception Plan – Project Manager submits an End Stage Report for the work just completed together with a Stage Plan for the next stage or an Exception Plan for the rest of the current stage.

Give ad hoc direction – Project Manager escalates an issue, or asks for advice or submits a Highlight Report, or programme or corporate management information arrives, or the Project Board itself triggers the process to give instructions to the Project Manager on some aspect of the project.

Authorize project closure – Project Manager submits the End Project Report with a closure recommendation and related documents.

Wondering what an Exception Assessment is

One of the weaknesses of the 2009 PRINCE2 manual is the very limited reference to the term Exception Assessment. This assessment is an important control in PRINCE2, but it’s hardly mentioned by name, and not at all in the ‘Authorize a Stage or Exception Plan’ activity within Directing a Project, which covers it. If you’re vigilant – or it’s been pointed out to you – you may have seen one passing reference in a paragraph. [Manual 10.3.4 Stage-level exceptions]. The only other reference is in, of all places, the glossary. Someone with long experience of PRINCE2 suggested to me that this may simply be a mistake, and that it was intended to remove the term from the 2009 edition but two bits got left behind. That sounds plausible, but either way it can be rather confusing to those learning the method, and that may include you.

You need to be clear on what the assessments are and what an Exception Assessment is in the context of the activity ‘Authorize a Stage or Exception Plan’. The two triggers to this activity reflect the two plans mentioned in the activity name. At the planned end of stage, the Project Manager will produce a Stage Plan for the following stage. Together with an End Stage Report, this is given to the Project Board for the members to check the plan and approve it to authorise work to start on the following stage; that’s the first trigger.

The second trigger can happen during the stage and occurs if something goes significantly wrong (usually) to the point that in order to recover from the problem, the rest of the present stage must now be run differently. Clearly, if the stage is now going to be run differently, the existing stage plan won’t be of any use. So the Project Board tells the Project Manager to force a stage boundary that wasn’t originally planned. The Project Manager produces a replacement plan – the Exception Plan – which, like any plan at project or stage level, must be approved by the board. Because an end stage was forced, there must be an assessment, but because it’s not at the planned end stage, the meeting is called an Exception Assessment rather than an End Stage Assessment.

The two assessments – for a planned end stage, and a forced end stage because of the need for an Exception Plan – now clarify the title of the activity ‘Approve a Stage or Exception Plan’.

Seeing the integration of exception management

Chapter 19 covers revision on how the method fits together, including how the seven PRINCE2 principles are supported through the method. However, it’s important to spotlight one of the principles here in the process Directing a Project, because it’s so fundamental. The important principle is that of ‘manage by exception’. In the context of the Project Board, that basically means letting the Project Manager get on with things and standing back. Unless, that is, something goes significantly off track. If it does, the Project Manager must go back to the board, which will then step in to decide what to do.

The ‘standing back’ means that, in a PRINCE2 project, the Project Board does not have any regular progress meetings. The traditional monthly progress meeting is a no-no; it doesn’t exist. More than that, regular progress meetings are anathema in the method. The Project Board won’t meet until the end of the stage, unless something goes significantly off track. ‘Significantly’ means by more than the amount of leeway that the board members specified.

You’ll find more on exception management in Chapter 17, which covers the Progress theme, and also in PRINCE2 for Dummies. [P2FD Ch17]

In the Practitioner exam, if the scenario mentions a monthly meeting of the Project Board, you should instantly be alerted, because this isn’t the PRINCE2 way of doing things. In questions on how the project should be corrected, you should then be selecting options that say the meetings should be stopped and that if the project is to continue, then it should be using exception management.