Chapter 10

Running Effective Project Boards

In This Chapter

Understanding the vital responsibilities of the Project Board

Knowing the key points of involvement and decision making for the board

Avoiding common pitfalls

This chapter covers a vital subject, but one that organisations using PRINCE2 generally neglect: the effectiveness of the Project Board in controlling a PRINCE2 project. The Project Board is the group of managers who have overall responsibility for the project – a bit like the top management team of a department – and together they are the Project Manager’s boss. (To see the overall management structure in which the Project Board roles fit, please see Chapter 12.)

This chapter shows how to avoid the pitfalls so common to Project Boards and, if you’re a member of a board yourself, how you can be really effective in your role. Far too many Project Boards think that they can delegate responsibility for the project to the Project Manager and come back at the end to see whether everything is okay and, if so, take all the credit. If you’re a Project Board member for a PRINCE2 project and your project fails through poor control and poor management, guess who gets the blame.

Being part of the Project Board isn’t all doom and gloom, though. The chapter includes a step-by-step guide and real help on the key decision points and other times when the project actively involves the Project Board.

Introducing the Process Directing a Project

The work of the Project Board is covered by the process Directing a Project. If you’re new to PRINCE2, have a quick look at the model in Figure 10-1 now, but come back to it again when you’ve read the chapter and it’ll all make sense. Don’t get hung up on the activities because this is all much simpler than it looks at first.

Based on OGC PRINCE2 material. Reproduced under licence from OGC.

One of the activities in the diagram is a bit different from the rest. That is the ‘Give ad hoc direction’ activity which, according to the PRINCE2 manual, goes on continually through the development stages of the project. This gives the Project Manager advice and input but in fact it also has to happen during the Initiation, or planning, Stage and also through the work of ‘Managing a Stage Boundary’ where the Project Manager is preparing for a further project stage.

Understanding Five Key Responsibilities for the Project Board

Many managers think that implementing PRINCE2 in an organisation is about training their Project Managers in the method. Unfortunately, implementation isn’t that localised and involves others too, and the most significant of these are the Project Board members.

To have only the Project Manager functioning properly is an approach that I call ‘PRINCE2 with a limp’. To have the method working well and stepping out strongly, the minimum is for the Project Manager and the Project Board to understand the method properly and then use it intelligently.

The principles for setting up and running an effective Project Board are not actually that difficult. They’re very much the same as for organisational management. Remember that you can think of the project as a temporary department, and the Project Board as the group of senior managers in charge of that department.

The most important thing to remember is that as a Project Board member, you’re responsible for the project and for ensuring that it runs correctly.

Taking ownership of the project

The project doesn’t belong to the Project Manager, it belongs to the Project Board.

Taking the analogy of the department in an organisation again, the effective and correct functioning of that department is the responsibility of its senior managers and the head of department, not some operational manager further down the management chain. If the top management of the department decided to go on holiday for a year and just check back at the end to see how things went in that 12 months, they’d be sacked for failing to do their job.

Managing, not working

A board member’s involvement in the project is to help manage it. Like any senior management function, board members must resist the very strong temptation to start getting involved in ‘doing’. Things get a bit busy at certain points in the project with regard to advising and managing, but if you’re a board member you’re not involved with designing the system, or building the walls, or even specifying the requirements. Rather, your responsibility as part of the project management is to make sure that the project runs properly and delivers what’s required of it.

If one or more board members need to get involved with the project activity as well, that’s still not part of their Project Board work. They simply have two roles on the project – board member and also team member.

Getting sufficient authority

Project Board members need not be senior in the organisation, but they’re senior relative to the project. If responsibility for the project has been delegated to you by someone more senior in the organisation, make sure that they’ve also delegated the necessary authority. Project Boards must have sufficient authority to make decisions about the project. You’re ineffective if you have responsibility but no authority.

Checking availability

The person with the ultimate authority in most organisations is the CEO (Chief Executive Officer) or general manager. But does that mean that she should be in charge of every Project Board for every project in the organisation? Clearly not. Actually, the CEO is unlikely to be suitable to serve on any board at all – not because of a lack of competence (well, not in all of them anyway) but more because of a lack of availability. If I need to see the CEO of a multinational for just two hours sometime today because something just happened on my project, what are my chances? Somewhere less than zero.

In the same way that managers in a department must make themselves available to their staff, so too must Project Board members be available to the Project Manager, and sometimes at short notice.

A public body set up a 14-member board with very senior staff. When challenged over the number of people involved, the most senior person insisted that a board of that size was necessary. When asked about their personal availability to take part in a further discussion lasting two hours or so, the board members weren’t able to make any more time available for about four weeks and even then not all the 14 could attend. In admitting this, they demonstrated that the composition of the board wasn’t going to work in this project, which was high-profile and fairly fast moving.

Appointing small boards

In PRINCE2, small is beautiful when it comes to Project Boards. The ideal number is around three people, but you can have fewer. The minimum is actually one person who covers all three roles – Executive, Senior User, and Senior Supplier (see ‘Taking Individual Responsibility’, later in this chapter, for more on these roles). But a good maximum is about six, no matter how big the project is. Big Project Boards just don’t work and actually rarely meet because somebody’s almost always missing.

If you have a project where most of the work is being done by an outside supplier company, the minimum Project Board number is two because you need a manager from the customer side of the project and also one from the supplier who can authorise the team resource.

Taking Individual Responsibility

The Project Board consists of three roles, reflecting the three key viewpoints in PRINCE2 of business, user, and supplier. Chapter 12 explains the roles fully and they are covered here only briefly to put the specific duties in context.

Business viewpoint – the Executive

The role of Executive covers the business viewpoint. Although the project is the responsibility of the whole board, ultimately the responsibility lies with the Executive and this person is in charge. This role cannot be shared, so although the person who is the Executive can also have another Project Board role, two people can’t be the Executive. The Executive must also be a person. I’m not discriminating against extra-terrestrial or robotic executives (though seeing some managers you may think . . . no, let’s not go there), but rather saying that the Executive can’t be a committee or an organisation.

The Executive either does the Business Assurance for the project or delegates the task to one or more people who then report back. Business Assurance is part of Project Assurance and, put simply, is project auditing to check that the project is running properly. Please see Chapter 12 for more detail.

Although the Executive can delegate the activity of this audit function, she can’t delegate responsibility for the proper running of the project. This is like financial audit: If something is wrong, you don’t blame the auditors.

User viewpoint – the Senior User(s)

The role of Senior User represents the user viewpoint. The Senior User is someone who represents those who’ll use whatever the project delivers and who also specifies the business benefits that will result from doing the project. Unlike the Executive, this role can be shared and you can have more than one Senior User to cover different areas, such as departments.

The Senior User(s) either does the User Assurance for the project or delegates it. Again, User Assurance is part of Project Assurance, the project auditing.

Supplier viewpoint – the Senior Supplier(s)

The Senior Supplier represents the supplier viewpoint on the project. This is a manager who has control over supplier staff – the teams doing most of the actual project work. As with the Senior User, you can have more than one Senior Supplier. A common reason for multiple Senior Users is where you have organisational staff working on the project alongside project teams from an outside company. You may then have one Senior Supplier from your own organisation with authority over your staff, and another from the outside company who has authority to commit that company’s staff to the project.

The Senior Supplier is responsible for Supplier Assurance for the project or can delegate the activity to others who report back. If you do have more than one Senior Supplier and one is from outside the customer organisation, you need to make sure that the assurance standards are consistent. Normally they follow the standards in the customer organisation.

Taking Joint Responsibility

Together the members of the Project Board are responsible for the project and take management oversight of it. They are part of the PRINCE2 Project Management Team. So, although ‘senior’, the board members are part of the team and must co-operate with and support the Project Manager and Team Managers.

The Project Board are on the same side as the Project Manager and the Team Managers. This is true even if the Team Managers are from an outside company. Remember, if the Project Manager and Team Managers do well, you, as a Project Board member, do well. If they do badly, you do badly as well because the project suffers.

Making decisions without stepping over the line

As a Project Board member you mustn’t be afraid to make decisions. That’s largely what you’re on the board for. But in PRINCE2, as in general management, decision-making authority is set at different levels. The board must decide how much authority they give to the Project Manager. Although the Project Board do need to supervise the Project Manager, board members need to be careful not to interfere unless they have very good cause, such as following up a Project Assurance concern. To do otherwise undermines the Project Manager.

Jerry Madden at NASA produced ‘100 rules for NASA Project Managers’. Rule number 3 is: ‘Management principles are still the same. It is just that the tools have changed. You still find the right people to do the work and get out of the way so they can do it.’

Listening to the Project Manager

The Project Manager attends the meetings of the Project Board, but isn’t a member. The Project Manager can’t have a role on the board, because if she does, she becomes accountable to herself, which rather defeats the object. Often, the Project Manager can advise and suggest action though, such as on a sensible number of stages when planning the project, or the action to take to overcome a particular problem. Board members need to listen carefully to the Project Manager’s views, although they’re not bound to follow them.

Deciding the Level of Control

The degree of control is a very personal decision. Just like in general management, as a board member you decide how much you want to supervise those working for you and what degree of autonomy you give them. Obviously, the more you supervise, the finer the degree of control you have, but also the greater the cost in everyone’s time. Also, if you supervise experienced staff too closely and too frequently, you’re likely to demotivate them – in the same way you get fed up if your boss checks up on you excessively and without reason. ‘Control freak’ managers don’t usually have happy, productive staff.

Setting Project Manager authority levels

PRINCE2 uses three helpful mechanisms when setting Project Manager authority levels:

Exception Management: Here the board can set upper and lower limits for the Project Manager’s authority. If the Project Manager projects that a stage will exceed a ‘tolerance’, then she must report that to the board immediately. The two most common tolerances are on time and cost, but the board can also decide to set additional limits on any or all of risk, business benefits, scope, and quality. For full detail on Exception Management and tolerances see Chapter 17, which covers the Progress theme.

Change Budget: The budget for each of the project stages is for what you plan to do. But what if someone wants a change? Unless the board want the Project Manager to come back to them at frequent intervals to get authority to do minor changes, allocating a Change Budget makes sense. The Change Budget can have two dimensions: a total Change Budget, but then with no one change being more than a set amount. A mid point is to set up a Change Authority between the Project Board and the Project Manager with an intermediate level of authority. Chapter 16 covers the Change theme including the handling of budget.

Risk Budget: This is an authorised budget set against each risk where a valid action requires funding. If the risk occurs, the board has already authorised the Project Manager to spend the associated contingency money without the need for further approval. This risk management mechanism is set out in more detail in Chapter 14.

These three points don’t cover everything and the board members need to talk through the specifics of project authority with the Project Manager.

PRINCE2 uses an Exception Management approach during each stage. This is a technique adapted from the world of finance. In financial control a budget profile is set at the beginning of a financial year. As the year progresses, as long as the spending or earning pretty much follows the profile, no one is particularly interested in it right up to the end of the financial year. However, if a budget bucks the trend in either direction, finance staff immediately start investigating to see why it isn’t behaving as predicted. In the same way, if a stage is going to plan you have little to talk about. The Project Manager calls in the board only if she projects that the stage will go off the plan by more than the amount the board specified with the tolerances.

The traditional ‘monthly progress meeting’ doesn’t exist in PRINCE2 and is unnecessary if the stage is going to plan. Instead, as a Project Board member, you’ll receive regular Highlight Reports that advise on progress and things you should know about (see ‘Determining highlight reporting’, later in this chapter).

You may need to explore other authority limits in addition. For example, as a Project Board member you may be entirely happy for your Project Manager to go ahead with any change up to the Change Budget limit in each stage. But you may not want to give the Project Manager authority to commit your multinational company to a procedural change that affects operations worldwide, no matter how cheap it is.

Deciding on the management stages

In PRINCE2 the project stages are management stages and not technical stages. The board may be happy to authorise work on several technical stages that can be done in one block before another Project Board meeting takes place. You may have any number of management stages in a project, and the board members must consider a whole set of factors when deciding how much control to exercise and so how many stages they require.

Overall then, choosing how many management stages to have is a balance between control and cost. The more stages, the more control points but the higher the cost. Meetings can be expensive, but then producing Stage Plans involves a lot of work – so just how many stages do you want?

One company issues all its senior managers with swipe cards, and outside every meeting room is a swipe card reader. When the managers go into a meeting room they swipe their cards through the reader. The reader is connected to a PC, which in turn interfaces with the payroll system to pick up each manager’s hourly rate. At the front of every meeting room is an electronic display, and every 15 minutes it flashes up what that meeting has cost so far. Awesome. Whoever thought of that deserves fame and fortune.

Fixing the level of risk acceptance

In line with the Project Board owning the project, the board fix the level of acceptable risk. Again, there’s no algorithm to help you with this and the level of acceptable risk depends on how ‘gung-ho’ the board are. If the board members all do parachuting and snowboarding in their spare time, they may be happy to accept a high threshold of risk with little control action. If they’re very cautious members who think that going for a walk in the park is high adventure, then the threshold is low and they’re willing to authorise, and pay for, a lot of action to control the risks. And ‘pay for’ is significant, because it indicates that the decision here is often a business one and so rests primarily with the Executive, though the whole Project Board have a say.

Determining highlight reporting

Under the Exception Management principle, the Project Board doesn’t meet during a stage but only at the end of it. But PRINCE2 has a regular progress report, which the Project Manager produces, that keeps the board up to date during each stage – the Highlight Report. Chapter 7 covers this in more detail, but briefly it normally includes:

The position on delivery: The report shows what products have been produced and what remains to be built in this stage. These are the powerful milestones in PRINCE2 that give superb progress visibility.

The position on schedule: Often presented as a Gantt chart, this shows where the stage is in relation to time.

The position in relation to tolerance: For example, the report may show that the stage is 1 per cent over cost but 7 per cent ahead on time, but within the plus or minus 10 per cent that the board set.

Any Project Issues: These are things like problems, changes, and new risks, that the Project Manager wants the board to know about.

A Highlight Report is basically very simple, but highly effective. The Project Manager may be able to prepare one in an hour or so. Board members need to beware of requiring reports that are too complicated and therefore time-consuming and expensive: the board may never read the reports because of their complexity.

The Project Board must specify the content required in the Highlight Report, and also the reporting frequency through the project. This is recorded in the Communication Management Strategy, which forms part of the PID. (For more on these documents, see Chapter 5.)

Sorting out project and quality assurance

PRINCE2 identifies two levels of checking or auditing of the project to make sure that it runs well: Project Assurance and Quality Assurance.

Project Assurance

Project Assurance is the responsibility of Project Board members under their three key interest areas of business, user, and supplier (see ‘Taking Individual Responsibility, earlier in this chapter) to make sure that the project is running properly. But board members can delegate the actual checking to other people if they want. This may be because board members are too busy to do the detailed work, or because they don’t have those sorts of skills.

If the Project Board delegates Project Assurance activity, the board members must then make time available to work with assurance staff to explain what they must check, and then to receive and discuss the reports.

Project Assurance must be positive and as such welcomed by the Project Manager. In turn, board members must delegate to people who are positive and helpful rather than obstructive and fault-finding. But the other side to this is that if the Project Manager is hiding things from the board, then the board will get to know. Assurance is independent of the Project Manager and the people carrying out the assurance work aren’t scared of reporting things as they find them.

Quality Assurance

Quality Assurance, as set down in the 2009 edition of the PRINCE2 manual, is the checking of the project from outside. Senior managers in the organisation may require that all projects are checked over, and that includes keeping an eye on the management activity of Project Board members. Although the idea of Quality Assurance is a check initiated from outside the project, Project Boards can find this really helpful as an independent view. The people involved in the check aren’t involved with the management of the project and so are likely to see things more clearly. For that reason, Project Boards have an option to ask for Quality Assurance checks, not just wait for them to be imposed.

Giving Advice When Asked

Using Exception Management significantly reduces the need for Project Board involvement in the main part of each stage. However, as a Project Board member, you must be available to discuss things informally with the Project Manager when she needs advice or a steer. This includes times when the Project Manager actually has the authority to make the decision but still wants to run it past the boss first. Two examples are:

A control decision is needed to adjust the stage and although the Project Manager is still safely within the tolerance limits, she nevertheless wants to talk it through with the Executive before making a call.

A change has been asked for by a member of the user staff. The Project Manager has the change budget to deal with it but would like to know the Senior User’s view before making a decision on whether or not to go ahead.

Getting Involved at Specific Points

Being available to give advice is something that’s ongoing throughout the project. But beyond that involvement, the Project Board has four very specific decision points, detailed in Figure 10-2. One, the decision about whether or not to authorise the next project stage, repeats for however many stages are involved in the project.

Starting up

The Executive is always appointed during Start Up, and the Project Board usually is too. The Executive has to establish the Business Case and develop the Project Brief – the outline of the project idea. The Project Manager and others may do much to help with both of these. The Senior User is particularly responsible for specifying business benefits that will result from running the project, and actually for delivering those benefits afterwards. But if it’s not clear in Start Up who should be the Senior User, then benefits may be set down by the Executive and current Project Manager, and confirmed later by the Senior User when the appointment is made.

Then the board, and particularly the Senior Supplier, need to work with the Project Manager to identify anything that affects how the project is planned and run, and what the project delivers. This is known as the Project Approach. For example, there may be a constraint on the make of equipment used and on which staff are used and when. A constraint affecting the outcome or the solution (if yours is that sort of project) may be to limit the options for an office move. It may have to be a move out of a city location to where building costs are lower, for example.

Project Board decision point – at the end of Start Up: At the end of Start Up, the board need to make the decision as to whether or not the idea looks good enough to take things forward, start the project, and run the planning or Initiation Stage. In making a decision to go forward and start the project, the board only commits to this first planning stage and not yet to the whole project.

Initiating the project

The Initiation Stage is the first stage of a PRINCE2 project and only covers project planning. No specialist work at all is done in this stage. Instead, the Project Manager works with the Project Board and others to develop the PID. For more on Project Initiation and the PID, please see Chapter 5 and please do look at that because as a board member you need to be very familiar with the PID; the whole of your project is based on it.

As a Project Board member, when you sign the PID you’re responsible for it. Don’t think it’s the Project Manager’s document, even though she may have done most of the work to write it. So be sure that you understand all of it and you agree all of it. No ‘executive summaries’ in the PID!

If, as a Project Board member, you say you haven’t got time to go through all of the PID before you sign, you’re really saying you shouldn’t be on the board for this project. If you find that hard to accept, just go back to the analogy of the project being like a temporary department. Would it be acceptable for one of the top management team of the department not to have time to read the department’s annual strategy and objectives document?

Although the process diagrams in the PRINCE2 manual can give the impression that the Project Manager goes away to write the PID and just brings it back to the board for approval, that’s very far from the truth – as the text of the manual points out. Project Board members must be available to the Project Manager during Initiation, because they have a lot to discuss, a lot of decisions to make, and a lot of input to provide on the different management aspects of the project. Just some of the areas where board members must give input and make decisions are:

How many stages do we need?

How frequently do we want to see Highlight Reports, what information should be in them and how should they be presented?

What staff resource is available and when?

What should the exact scope of the project be, and if there’s pressure on time and/or resource and/or quality, what are the essentials and what can be left out?

What is the trade-off between resource levels and delivery date?

What degree of risk is acceptable, and what risk actions will we authorise?

What level of quality do we require, and how much can we afford?

What involvement does the user side require in testing project deliverables?

Must the Project Manager always refer any changes to the board or a Change Authority, no matter how low the cost, or shall we authorise a change budget? Do we want to appoint a Change Authority?

The Project Manager will assemble all the Project Plans in the PID and as a board member you need to be sure that you’re familiar with the whole document and agree with it. The PID is hugely important because it defines what the project is and exactly how it will be controlled. Nothing in the document must come as a surprise when you give it a final review before making a decision on whether or not to approve it and commit to the project. Accompanying the PID is also the plan for the first delivery stage (the stage after the Initiation Stage), so that if you decide to go ahead, the project can continue without delay.

Project Board decision point – at the end of Initiation: At the end of the Initiation stage, the board decide whether or not to commit to the whole project and specifically to authorise the first delivery stage. The board may stop the project before the end if circumstances change, but the intention now is to run the project through to the end.

Getting involved during a delivery stage

As a Project Board member, you may get involved from time to time during the delivery stages. However, because of Exception Management this isn’t usually a big time commitment – PRINCE2 actually saves managers a lot of time. During a stage, you may get involved to give what the method calls ‘ad-hoc direction’; in other words, one-off advice to deal with something specific. Ad hoc direction includes:

Receiving Highlight Reports and noting progress

Having an informal discussion with the Project Manager if she asks for your view on something

Doing Project Assurance work or receiving reports from whoever you delegated that work to

Dealing with things referred to you by the Project Manager because they’re beyond her delegated authority. This includes deciding how to deal with an exception if the Project Manager gives an Exception Report

Project Board decision point – when it receives an Exception Report: You may be able to resolve the exception easily and the Project Manager can then simply carry on. Perhaps the cost of a piece of equipment rose unexpectedly. The board may simply decide to authorise the extra funds and the Project Manager makes a note of that authority and carries on.

Sometimes, however, you need much more work to deal with the exception, to the point that the rest of the stage has to be completely re-planned. In that case things are more serious and an additional stage boundary is forced. Clearly, re-planning the work done to this point in the stage is pointless, so you shut that down as if it’s the end of the stage. The remaining work is then re-planned by the Project Manager who brings this Exception Plan to a board meeting so that the board members can authorise it like any other stage-level plan.

Exception Assessment. This is the meeting of the Project Board to consider an Exception Plan.

Project Board decision point – Exception Assessment: The board meet to approve the Exception Plan and, if it’s okay, give authority to proceed with the rest of the stage on the basis of that plan. The board will usually agree to carry on because you can usually recover from a problem and you still need the project. If the situation was drastic enough to warrant stopping the project, then the board would probably have realised that when they received the Exception Report and called a halt then.

Ending a stage

At the end of a management stage, except for the last stage at the end of the project, the board meet to hear how the last stage went and to authorise the next one. The End Stage Assessment (ESA) is the name of the Project Board meeting on the stage boundary.

Project Board decision point – End Stage Assessment.

At the End Stage Assessment the board

• Hears the Project Manager’s account of the stage that just finished with the End Stage Report that covers the cost and time of that stage, how things went with risk management and quality, and any other factors, particularly if some may carry forward to the next stage.

• Checks that the risk situation is still acceptable and that risk controls are appropriate for the present level of risk. The Project Manager has updated the Risk Log to show the very latest position.

• Checks that the Business Case is still sound – that the project is still necessary and viable. The Project Manager will have updated the Business Case in consultation with the Executive.

• Takes note of any early benefits reported from a benefits review, and checks to see that they’re in line with what was anticipated. This is significant because if the predicted level of early benefits is not forthcoming, it may indicate that other benefits projections are over-optimistic and in turn that may call the project viability into question.

• Ensures that the plan for the next stage is complete, workable, and achievable. Board members will normally have checked this out before the meeting or Project Assurance will have done this on their behalf.

• Gives authority to proceed with the next stage or, if board members find that they can’t sign up to the next stage despite having discussed it while the plan was being drawn up, they can order the project to be closed down instead.

Ending the project

Whether the project is closing down as planned or stopping early, the Project Manager goes through the closure activities (for more information on closure, please see Chapter 9). After that work has been done, the Project Manager comes to the Project Board for the board to authorise closure in a Project Closure Meeting or ‘Close Out’.

The main things the Project Manager provides for the board are:

An End Project Report.

Details of acceptances and handovers.

A Benefits Review plan for measuring benefits that will come on stream after the end of the project.

Follow-on Action Recommendations – actions that the project is passing back into the organisation, such as ongoing risk management action.

A Lessons Report (developed from the Lessons Log).

The End Project Report is the Project Manager’s account of how things went on the project, including the final cost and time and delivery of quality. However, the Project Manager probably consulted Project Board members during this work, so as a board member you’re probably already familiar with much of the content. You may need to pass the report on to others with an interest in the project, such as senior organisational managers.

Project Closure Notification. The method refers to a Project Closure Notification being prepared by the Project Manager, then sent by the board to others in the organisation to tell them the project is shutting down. But in practice relatively few business projects operate in such a formal environment, even very large organisations.

Measuring early benefits

If measuring any benefits is possible immediately at the end of the project, that will have been set down in the Benefits Review Plan produced for the PID. Any such measurements will have been made and the results set down in the End Project Report so that, as a Project Board member, you have an indication of whether the project was successful. You don’t have to wait until Benefits Reviews that are after the project.

Post Project Benefits Review. A check at some point after the end of the project when benefits are clear and measurable. The review may be in the form of a meeting and there may be more than one if different benefits will come on stream at different times.

Checking acceptances and handovers

Acceptances, such as the legal acceptance of a new building from the company that built it, may have been obtained at different points in the project. At this stage you need a final check that the acceptances are all in place before the board authorise closure. This check is normally rapid, because the Project Manager has specifically checked these acceptances before getting as far as the Project Board and the closure meeting. Indeed, board members may already have checked acceptances themselves or asked any appointed Project Assurance staff to check on their behalf.

PRINCE2 doesn’t cover benefits review after the project; it shuts down when the project shuts down. But the method includes planning for any such review(s), and the Project Board checks the Benefits Review Plan again before they finally close the project. This check is important because the board itself will be closing down and any further action on benefits measures will be passed to one or more staff in the organisation. Those organisational staff may well be same managers who were the Executive and Senior User in the project, but it could be others such as finance staff.

Follow-on Action Recommendations

Follow-on Action Recommendations are what the board recommend for the organisation to do after the project. The Project Manager assembles a list, but the board need to agree it. It can include things such as

Good ideas put forward in the project as Project Issues, but which there was neither time nor budget to include in the project

Ongoing controls, such as Configuration Management (version control) and Risk Management, which continue into the working life of products

Recommendations for adjustments to organisational standards, such as project or risk management procedures, in the light of project experience