Chapter 6

Preparing for a Stage in the Project

In This Chapter

Looking at stages – the big control in PRINCE2

Knowing how and when you trigger an End Stage

Forcing an extra stage boundary if you need a major re-plan

Checking the ongoing viability of the project

Providing vital information for the Project Board

You can’t say the word ‘control’ in PRINCE2 without immediately thinking ‘stages’. Stages are the highest level of control and are powerful because at the end of each one, the Project Board must take stock before deciding whether or not to specifically authorise the next part of the project – the next management stage. This chapter covers the work of the Project Manager towards the end of a stage, getting ready for that Project Board decision by providing up-to-date information as decision support and also by creating the plan for the next stage.

As with other key decision documents in PRINCE2, the information that the Project Manager provides at the end of a stage shouldn’t come as a huge shock to board members, because they’ll have been consulted informally while the information was prepared. If you’re using the PRINCE2 manual alongside this book then look out because the manual gives the strong impression overall that the Project Manager goes away and does this work without any reference to the board. The diagram, Figure 6-1, shows you what I mean because there’s no reference to Project Board ‘ad hoc direction’. But that’s wrong and board members must make time available to talk to the Project Manager to help get things ready for the next stage. You can see just how much that’s needed as you follow the activities within the ‘Managing a Stage Boundary’ process covered in this chapter.

This work of the Project Manager towards the end of a stage is logical and so very predictable. As with just about all the rest of PRINCE2, this work is also very straightforward. Some projects may need quite a bit of work, but the overall concept isn’t difficult.

Understanding the Process of ‘Managing a Stage Boundary’

Five activities cover the stage boundary work in PRINCE2. These activities are the responsibility of the Project Manager who in turn consults with other people, including Team Managers and Project Board members, for the stage ahead.

Don’t get too bothered about the activities at first. Have a quick look at the diagram to get an overall idea and then read the chapter. Then, when you come back and look at the diagram again, it will all fall into place easily.

The stage boundary work has two alternative start points. The first is the normal planned close of a stage, and the other is corrective action if something’s gone significantly off track and calls for a major re-plan. To be clear on exactly what ‘significantly’ means, please see ‘Triggering an End Stage’ later in this chapter and Chapter 17 on progress and controls.

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

Providing Key Information at End Stage

To show that this End Stage work is very logical, imagine you’re a Project Board member attending a meeting at the end of a stage and the Project Manager asks you to authorise the next stage. What do you want to know before picking up your pen to sign and give your authority? You almost certainly want to know:

How did the last stage go?

• Did it run smoothly to plan or keep going off track – ahead, behind, ahead again?

• What happened with changes to the management of the stage? Were the adjustments due to genuinely unpredictable things and changes in the business area, or were they mostly corrective, for things missed off the plan or wrongly estimated?

• How did the stage finish in relation to tolerances (a range with a target value and then a plus or a minus maximum) on time and cost, but also against any other elements such as the scope?

• Were any significant problems encountered in the last stage that will affect the rest of the project?

• Is the project in control or can you see signs of delivery starting to slip and the spend edging upwards? If the stage did end within tolerance, was it by the skin of its teeth?

• Were there any problems with quality or was everything delivered to the right standard?

Is the Business Case still okay?

• Is the project still needed? Sometimes business circumstances change quite dramatically and you might need to stop the project rather than authorise the next stage.

• Is the project still on track to deliver the expected benefits, or does new information from the last stage indicate that the benefits may be lower, or higher, than anticipated?

• What are the latest estimates of cost and time and how do those now relate to the expected level of benefits?

What about risk?

• Have any significant new risks come to light that affect the balance of the project justification?

• Has the status changed on existing risks? Sometimes, of course, a project can go to a higher plane of risk not because of one big new risk, but a small increase across many risks – a cumulative effect.

• Is the risk under control, or are things starting to get out of control?

What about the plan for the next stage?

• Is the next Stage Plan realistic and achievable? Don’t even take the top off your pen with a thought of authorising the next stage unless you’re convinced that the plan is workable. If you sign off a plan that won’t work, then the failure that follows is your fault.

• Are the resources in place to do the work at the times set down on the plan, including any user resource from the business area?

In a nutshell this is a look-back – how did the last stage go?; a look at where the project is now – are the Business Case and risks okay?; and a look forward – is the next Stage Plan achievable?

If you’re a board member you can get help with checking that the Stage Plan and Project Plan are achievable and workable. You can appoint Project Assurance (the audit function of the project) to help check out exactly this sort of thing. Have a look at Chapter 12 for more on Project Assurance.

What about when the board can’t meet – say they’re in different parts of the world? You can use another mechanism, such as a video link, telephone conference, or even e-mail. These ways are decreasingly effective, though – e-mail is less effective than a phone conference, which in turn is less effective than a video link. Nothing is quite as good as a face-to-face meeting, so do hold one unless this is impossible.

Triggering an End Stage

During the project two things trigger the End Stage work:

The planned end of a stage (including the Initiation Stage but excluding the final stage): The Project Manager checks the stage status and sees that the end of the stage is approaching. Therefore, now’s the time to start planning the next stage and preparing for the End Stage Assessment – the meeting of the Project Board.

Exception: If the projections for the stage show that it may exceed the tolerances (such as time and cost) for the stage, the Project Manager refers this to the Project Board. If the Project Board decides to run the stage differently to get it back on track – perhaps using different products, different activities and different resources – then you can’t use the existing Stage Plan to control the stage. Instead, you need to do a major re-think and produce a replacement plan. This Exception Plan is a replacement Stage Plan that covers the period from the point of the problem until the end of the stage. This forces a new stage boundary and so the work now comes under that category.

End Stage Assessment (ESA). The Project Board meets at the end of a stage to conduct an ESA, in which they check the project, especially the stage just finishing, and either authorise the next stage or stop the project. Instead of ESA, people commonly use the phrase ‘stage gate’, which is much more descriptive and a whole lot better.

Exception Plan. You replace part of an existing plan with an Exception Plan because something changes that makes the existing plan unusable. This swap usually takes place at stage level, but it can have a knock-on effect on other plan levels as well; often the Project Plan.

Stage planning in Start Up and Initiation

In PRINCE2 you plan each stage just before that stage is due to start so, with one exception, that’s towards the end of the previous project stage. The exception is with the plan for the first stage of the project, the Initiation Stage, where no stage comes before it. But the pattern of ‘just before’ is still the same because you prepare the Initiation Stage Plan towards the end of Start Up. However that planning work is covered in the ‘Starting Up a Project’ process as it isn’t an End Stage and you don’t need the other End Stage stuff (such as an End Stage Report) covered in this chapter.

The plan for the first delivery stage – the one that comes after the Initiation Stage – is done towards the end of the Initiation Stage. So, while the Initiation Stage is primarily to plan the whole project at a project level of detail, it also includes the lower-level Stage Plan for the stage that comes straight after it.

More about exceptions and stages

Having a stage boundary when the stage isn’t complete may seem odd, but this is part of exception handling and is logical when you think it through. For example, say a stage is one-third through and a significant problem arises that changes things substantially so that the rest of the stage now needs to be run differently. The Exception Plan covers the point between now, one-third through, and the end of the stage. But what about the one-third that’s already completed? Obviously, you don’t need to plan what’s already done, so instead that third is closed down as if it were a stage end. The remaining work is re-planned with an Exception Plan and the previous work in the stage is reported on as if it were an End Stage, even with an End Stage Report.

The End Stage behaves exactly as normal and the board authorises work to continue the stage as if it were a brand new stage.

Exception Assessment. In an Exception Assessment the Project Board meets to approve an Exception Plan and authorises work to commence on the basis of the plan (unless they close the project instead). This assessment is like an End Stage Assessment; the difference is that you didn’t plan the stage boundary originally; it’s reactive because of the exception situation.

Principle 4 – Manage by stages.

Planning the Next Stage

You may have a lot of work to do to create a Stage Plan for the next stage, but as is usually the case in PRINCE2, the concept is straightforward enough. It’s a plan for just one management stage that’s very like the Project Plan in terms of content and techniques. It’s just that it covers a single management stage rather than the whole project and is in much more detail than the Project Plan.

Using product planning in more detail

When preparing a Stage Plan, PRINCE2 expects you to use the product-based approach to planning. Products are effectively what the teams deliver, or produce, in each stage – the deliverables. Products are things like brick walls, computer programs and new logo designs. At project planning time you identify 15 to 30 products for the whole project. In each Stage Plan you go into more detail on the products that’ll be built in that particular stage – maybe 3 out of the 30 – and break them down to a lower level until you have 15 to 30 again. So at project level you may have identified the product ‘new business procedures’ but now, for the stage in which those procedures will be designed, you show the six individual new procedures that make that up. For lots more help on the product planning and the activity and resource planning that are also included in the Stage Plan, please see Chapter 14 that also explains the powerful product planning techniques in detail.

You also create documents needed for version control of the new lower level products – Configuration Item Records – but please see Chapter 16 for full detail on version control.

Preparing the Product Checklist

You develop one additional product planning element when you’re stage planning – the Product Checklist. When you’ve identified the 15 to 30 lower-level products that will be developed in the stage, write them out as a list. After you do the activity planning and risk analysis you can then determine the delivery date for each product and add that to the Product Checklist.

This checklist now forms an extremely simple but powerful progress monitoring tool for running the stage. As each product is completed (which means it’s been quality checked and signed off), the delivery date is noted on the Product Checklist and the milestone is completed. Doing this shows exactly where the stage is with no debate or human judgement: Is the product delivered – yes or no? There are 15 to 30 products in the stage, and so 15 to 30 milestones where you can determine progress very exactly – and all for free with product-led planning. Although the PRINCE2 manual says you shouldn’t use every product as a milestone, you lose the huge power of the Product Checklist if you follow that advice. Please see Chapter 17 on progress and controls for more on progress monitoring.

You can extend the Product Checklist to include other dates, such as the date you plan to send the product for testing and the date it actually goes. That can be really useful to get early warning of likely delay in product delivery, but the ultimate power lies with delivery dates themselves.

Getting detailed with quality

You prepare the Quality Management Strategy in the Initiation Stage as part of the Project Initiation Document (PID), but the strategy is exactly that, a strategy. As you come to stage planning you need hard detail and in PRINCE2 that’s locked in with the product planning. That lock-in makes quality very clear and specific as Chapter 13 on Quality explains.

The quality criteria for individual stage-level products are decided and recorded on the Product Descriptions that define those products. Together with the criteria, the way that each product will be tested is set down (Quality Method) and then also the responsibility – who does those tests (Quality Check Skills and then the Quality Responsibilities). If any new quality requirements are thrown up during this work you may need to update the Quality Management Strategy. No problem, and in fact you keep all four of the strategies up to date throughout the project.

You then take this testing information forward into the activity planning. Enter the quality related activities onto your Precedence Network and Gantt chart, and for the Gantt you enter the resource information of who does the test. So you deal with specific quality at stage level by actually building it into the product and activity plans.

A vital action now is for you to update the Quality Register with a list of all the tests that must be performed during the stage, together with a planned test date. To do this you extract two bits of information from the Stage Plans. You can take the details of the tests themselves from the ‘Quality Method’ sections of all the Product Descriptions or from the activity plans, and the planned test dates and responsibilities from the schedule – usually a Gantt chart.

The Quality Register is set up in Initiation and is simply a list of quality activities, including tests, that you carry out in a stage. As the stage progresses and each test is done, it gets signed off in the Quality Register. This forms a very simple but highly effective audit trail. You can see at a glance whether a test has been done or not, and because several people check the register, you won’t forget a test. Chapter 13 explains more.

Updating the Project Management Team

As part of stage planning the PRINCE2 manual says that you should check for changes to the Project Management Team Structure. You may prefer to do this when you make checks across all project-level documentation to keep it up to date (see ‘Updating Project Documents and Plans’, later in this chapter) – that’s fine, as long as you do check at some point.

Movement often occurs in and out of teams around a stage boundary, although it can happen during the stages too. Look out for changes with the other roles as well. For example, perhaps a change of Senior Supplier is not only necessary but was planned for this point. Perhaps one external supplier company put in teams for the first six months of a year-long project to do structural work, and a second external supplier company is now taking over to do the final six months’ work in fitting out. This is the one valid exception to the general line that the Project Board needs to be stable.

Building an Exception Plan

You may be doing stage boundary work not because it’s a planned stage end, but in reaction to an exception – where the stage goes significantly off track (see ‘More about exceptions and stages’, earlier in this chapter). It may have been decided to re-plan the rest of the stage and do it differently to recover from the problem.

One other reason to have an Exception Plan is to build in a major change that’s a really good idea and worth all the re-planning effort. Chapter 16 explains this as part of change control.

The Exception Plan is, effectively, a Stage Plan, but for just the remainder of the stage. It has a few characteristics that are worth bearing in mind:

The Exception Plan only covers from the point of the problem until the end of the stage, so don’t waste time re-planning what’s already done.

An End Stage Report covers the work done up to now in the stage, just as with a planned End Stage.

The text of the Exception Plan is usually a bit more problem-focused than a Stage Plan, because the Exception Plan needs to explain how the plan addresses the exception.

Although the Exception Plan does change the stage, a lot of the work is likely to be the same, so you can bring forward the relevant information from the Stage Plan that you replace – you don’t start from scratch.

Updating Project Documents and Plans

You keep at least some parts of the PID up to date throughout the project. With the information from the Stage Plan you just finished, and armed with the new information from the Stage Plan you just produced for the stage ahead, now you make sure that the project information set is up to date and consistent.

Updating the Project Plan

Updating the Project Plan may sound an odd thing to do if you use a computer scheduling tool, because as you update the stage level of detail on a Gantt chart, for example, you keep the project level in line with that automatically; they form a single computer file. But don’t forget that you may need to adjust other parts of the plan besides activity networks and Gantt charts. For example, you may need to adjust the project-level product plans.

Sometimes updates to the Project Plan are considerable because you reach a point in the project where for the first time you can see to the end clearly. The PID may describe this entirely predictable update.

In a project to perform ten-year maintenance on an industrial installation, the first part of the project was to close down the plant and do a thorough survey to see what machinery needed to be replaced – including components not normally visible because of heat shielding – what could be maintained, and what didn’t need any work. It wasn’t until that survey had been done that the exact nature of the rest of the project could be determined with complete accuracy. The organisation knew the normal amount of work for a ten-year service on this type of installation from previous experience, and the initial Project Plan, produced at the start of the project, was based on that. But significant change to the plan in either direction was possible when the results of the survey were available.

Updating the Project Approach

In the light of new information coming from the last stage and the production of the new Stage Plan, you may need to adjust the Project Approach. For example, you may need more information to develop the new business procedure than you first realised, and some of that additional information may be commercially sensitive. You may therefore need to comply with additional security requirements, not only for the operation of the new business procedure itself, but also for the project because project teams will now be working with that sensitive information.

Other changes can affect things such as technology, where newly available equipment from a new manufacturer is so advantageous that it removes a previous constraint to only use equipment from the normal manufacturer in order to minimise maintenance costs.

Reviewing Risk

Part of the work in the ‘Update a Project Plan’ activity is a systematic review of every risk in the Risk Register, together with thinking about whether any new risks are now apparent. The PRINCE2 manual always was a little light on this review but it’s now positively featherweight with only a short bullet point reference. But be alert because you may face significant work here – especially, of course, if yours is a high-risk project. For example, if you decide that a risk has changed significantly and that you also need to change the risk management actions, this may involve changes to the Stage Plan just produced. It may also need quite a lot of discussion with a range of people in the project (depending on the nature of the risks) to perform the risk analysis and with the Project Board.

In fact one of your key consultations regarding risk is with the Project Board members and especially the Executive. The board members own the project and at Initiation they decided what level of risk they were willing to accept and what management actions were appropriate. They also decided how much they were willing to pay to control the risks. Therefore, any change to the level of risk, or any planned action to control new risks, needs similar consultation.

The Executive is especially important, as the Executive is the final ‘owner’ of the project and, representing the business viewpoint, is primarily responsible for ensuring that the project is value for money. Planning actions that cost any significant amount without checking them with the Executive isn’t acceptable. The Executive is also more aware of what’s happening in other parts of the organisation and so is well placed to help evaluate how changes in the business impact risks. This involvement is part of the ad-hoc, informal direction from the board – even though the diagram from the manual in Figure 6-1 doesn’t show this happening. You can read more about the need for board members to give a steer in this way in Chapter 12. It’s a bit like your boss being available to you if you need to talk something through.

You also need to consult others in the project, not just the board members. Team specialists and suppliers may identify changes in the environment that can have an impact on risk. Although you may say that the specialists and suppliers should have reported these changes during a stage and not waited until End Stage (and you may be right), the fact remains that sometimes people don’t realise something until you specifically ask them. How many times have you started a sentence, ‘Well, now you come to mention it . . .’?

This review of risk is extremely important on the stage boundary, as it gives the members of the Project Board the exact and latest position on risk for their decision on whether or not to authorise the next stage. The review of risk interacts with the review of the Business Case. If the risk increases but the benefit projections fall significantly, the board may well decide to stop the project. This level of risk exposure may not be worth facing for this reduced business benefit. However, if the risk increases slightly but the benefit projections increase by a large amount, the board may decide that continuing, and even spending more on risk management action to help secure those benefits, is worthwhile.

If you detect a change in risk that affects the way that risk as a whole should be managed in the project, then you may need to update the Risk Management Strategy, but once again this needs some discussion with the Project Board and especially the Executive. Please see Chapter 15 for more information on the Risk Management Strategy, on risk analysis and management, and when you carry these out, including at End Stage.

Checking the Business Case

In a PRINCE2 project, the Business Case must be reviewed at least at the end of each stage. Project Board members then have the very latest information to hand on which they can base their decision on whether to carry on with the next stage or not. The Business Case may have been modified during the stage in the light of problems or new information, for example.

At the end of the stage you conduct a more thorough and systematic review of the Business Case, including checking the projection and timing of benefits, the cost of the project, the time you need for the project, and the risks. You take the cost and time from the Project Plan, which has now been updated using information from stage planning. If there’s any change to how and when benefits will be reviewed you’ll also need to update the Benefits Review Plan.

Principle 1. Continued business justification.

While on the subject of the Business Case and benefits, it’s possible that benefits start to be seen during the project itself and not just at the end or after it. This is especially the case if project deliverables are being taken into operational use throughout the project and not just in one ‘big bang’ at the end of it. The Benefits Review Plan shows when benefits should be measured, and if one of those points is at the present End Stage then the measures should be taken and you must make sure that they’re reported now. These measures, where done, will be included in the End Stage Report.

Preparing an End Stage Report

The End Stage Report is the Project Manager’s report to the Project Board on the stage just finishing. You think through the form and content of the End Stage Report in the Initiation Stage and record the details of it in the Communication Management Strategy. Normally small is beautiful, and informal (such as verbal reporting to the Project Board) can be pretty attractive for some projects too.

The contents of the report are predictable: basically, how did the stage go, what did it cost, how long did it take in comparison to the plan, and were the quality requirements met? In full, the report is very extensive but as always, do cut it down wherever possible for your organisation and project.

One problem with the PRINCE2 End Stage Report is that it has a lot of headings and many Project Managers feel obliged to write a fair amount under each heading to show that they’ve completed the document thoroughly and so did their job well. This backfired quite nicely in one organisation where a Project Manager caused project delay because he couldn’t think what to write, but then the project proceeded to the next stage without the End Stage Report being presented but promised later. In that way the PRINCE2 documentation was completely divorced from the project management and this stripped the method of its power – the project proceeded without the method and PRINCE2 was reduced to just some documentation system lagging some weeks behind where the project really was.

Reporting any lessons

You keep the Lessons Log up to date throughout the project, which means during the stages (for more on this log, please see Chapter 4). But having said that, the point at which you write the End Stage Report is a great time for reflection on the stage as a whole: Think about whether any more can be learned from the experience that would be of value to others in future projects – both good things that worked well, and bad things to try to avoid if similar circumstances arise.

A mechanism is available for reporting lessons back to the organisation at the end of the project, but if something comes up that the organisation would benefit from knowing now, it can be reported now. The Project Manager can prepare a Lessons Report, which is then included in the End Stage Report and which the Project Board can then pass back into the organisation. Chapter 9 has more on the Lessons Report, as it is produced anyway at project closure.

Asking for Sign-Off and Authority to Proceed with the Next Stage

The Stage or Exception Plan goes with the End Stage Report (if this is a written report), the updated Business Case, and the updated Risk Register to the Project Board, who then hold an End Stage Assessment (ESA) or, in the case of an Exception Plan, an Exception Assessment. The board members must approve the stage that just finished and then give their authority to proceed with the next stage – or else stop the project. That authority on a stage boundary helps avoid the problem of projects that just carry on blindly even if things are going badly wrong.

You can make it very simple for the board to give authority to proceed at stage boundaries. Just put a signature panel on the front of the Stage Plan. If the board members sign, they authorise work to start on the basis of that plan.