Chapter 7

Controlling a Stage

In This Chapter

Understanding the day-to-day work of the Project Manager

Giving out assignments to Team Managers and keeping an eye on the work

Checking and reporting on progress

Dealing with problems and referring some things to the Project Board

This chapter deals with the day-to-day work of the Project Manager during a delivery stage. That includes picking up on any problems and reporting progress. The chapter doesn’t cover the activity of the Project Manager towards the end of the stage in getting ready for the Project Board meeting to approve the next one. Chapter 6 describes all that work, which is mostly done as the stage boundary approaches.

Understanding the Process Controlling a Stage

Like the other six processes in PRINCE2, Controlling a Stage has a lower-level diagram that shows the activities taking place inside it and the order in which they’re normally done. It’s the busiest of the processes – if you take the number of activities as a sign of busyness. But happily the process is not only straightforward but actually one of the easiest to follow. If you just think about what a Project Manager is doing in the main part of a delivery stage, you could build the model yourself:

Giving out work assignments to Team Managers, checking the progress of that work and then getting delivery of products when they are finished – built and tested

Dealing with any inbound risks and issues (– including problems – and taking any necessary action to deal with them

Keeping track of the progress of the whole stage, and reporting that progress to the Project Board at the frequency they asked

Taking any action needed to keep the stage on track, or passing the matter up the line to the Project Board if things have gone beyond the limits the board set down at the start of the stage

Having set down those four main areas of work, have a look at Figure 7-1 that contains a diagram of controlling activities.

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

The eight activities in the diagram map relate to the four work areas. The bottom three activities are to do with controlling work assignments, or Work Packages. The upper one on the right-hand side is to do with handling Issues, which are things like reported problems, and any newly identified risks. The two on the far left deal with correcting problems in the running of the stage. This is done by the Project Manager taking ‘corrective action’ within his own authority or by ‘escalating’ the matter to the Project Board if it’s beyond his authority. The two activities in the middle deal with progress checking and reporting.

The rest of this chapter looks in detail at the activities in the four main groups just described.

Controlling the Flow of Work to Teams

The Project Manager, as the role title suggests, manages. This means that Team Managers and their teams don’t just start doing stuff when they feel like it. Instead, the Project Manager authorises work a bit at a time using Work Packages.

Work Package. An instruction pack given to a Team Manager by the Project Manager that asks him to build one or more products that it makes sense to build together. Each Team Manager normally works through a series of Work Packages in each stage in which his team is involved, but of course he may only be involved in a single one.

Figure 7-2 shows you how Work Packages fit in with the stage. As to the exact content of a Work Package, you can find all the detail in Chapter 8, which covers the work of the Team Manager in receiving the Work Package and then building the products it describes.

Giving out the Work Packages

If you’re the Project Manager and you give a Work Package to a Team Manager, the two of you won’t end up having big disagreements. You’ll have already talked things through with all of the Team Managers when you drew up the Stage Plan and resolved any problems then. Discussion at this point is fine-tuning to make sure that the Team Manager involved is clear on what’s required, including controls and reporting while the work’s being done.

If the Team Manager decides that he needs a more detailed plan than the Stage Plan to control the Work Package, then this Team Plan will be agreed with the Project Manager before work starts.

When giving out the Work Package, the Project Manager – or Project Support – may need to create Configuration Item Records for the version control of products involved, depending on the approach being taken. You can read more about this version control, including CI Records, in Chapter 16.

Checking progress on Work Packages

While the teams are working to build the products, Team Managers will be reporting progress to the Project Manager using Checkpoint Reports. You can find more on this reporting in the next chapter, Chapter 8, which covers the Team Manager’s responsibilities in PRINCE2.

Checkpoint Report. A progress report that a Team Manager gives to the Project Manager. The required content and format of the report is specified by the Project Manager in the associated Work Package.

Usually the Team Managers send in time sheets and spending information along with the Checkpoint Reports and these actuals (how long things have actually taken and how much things have actually cost) can be fed into the Stage Plan. If you’re the Project Manager you can do this yourself, but if you have some administrative help – Project Support – those staff do it for you.

To keep an eye on the quality, the Project Manager also checks to make sure that the right tests are being done at the right time by the right people while the products are built by the teams. This is really simple and fast in PRINCE2 because the information is all in the Quality Register (see Chapter 13), which is basically a list of all the quality actions to be taken, such as testing, and a record that they were properly carried out.

Receiving completed Work Packages back

When all of the products in the Work Package are completed, the Team Manager delivers them to the Project Manager or notifies him that they’re complete if that’s more appropriate – the sections of a suspension bridge are often too big to fit into an envelope without tearing the sides.

Importantly, because the completed products are excellent progress milestones the delivery date is put against those products on the Product Checklist. Chapter 14 on planning explains how to create and use the Product Checklist because it forms part of the plans.

Dealing with Risks and Issues

If you’re the Project Manager you can expect to receive project Issues – and in some projects, you can expect to receive a lot of them. Strangely, in the PRINCE2 themes, Issues are covered under the heading of Change Control (for the detail please see Chapter 16). That’s odd because the Issue needn’t be to do with a change at all – perhaps the Team Member is passing on a good idea, for example.

Issue. A communication sent directly to the Project Manager from anyone in the project or, if you’re brave and agree with the PRINCE2 manual, anyone with an interest in the project. An Issue can be sent in at any time, and can be about anything to do with the project.

Deciding how to handle an Issue or risk

If you are the Project Manager, then when you receive a Project Issue, your first decision is on whether or not you need to handle it formally or informally. If the answer is that it’s best handled informally, you can simply note it in the Daily Log. If it needs formal tracking, then a register is used; use the Risk Register, fairly obviously, for a risk and if it’s an Issue then use the Issue Register. In the case of an Issue, you first transfer the details of the Issue into an Issue Report.

Issue Report. The formal record of an Issue that’s normally created by the Project Manager on receipt of an Issue, but if it comes from someone knowledgeable in the project, such as a Team Manager, he may already have written an Issue Report and submitted the Issue in that form.

Examining the issue or risk

After you record the issue or risk you look to see what action, if any, you need to take. This work is sometimes called impact analysis.

You’re probably not a subject expert in all areas of your project. But you have other people available who are. Often when you receive an Issue, your reaction is, ‘I don’t have the faintest idea what this is about or what to do.’ That’s fine, really. Just go and talk to the people who do know.

As part of this analysis, you need to look at a number of dimensions. Ask yourself the following questions to see which dimensions are relevant:

Is the issue really an issue or the risk really a risk? Sometimes a team member has misunderstood something and you can reply and close the matter within a minute or two.

Does it affect cost?

Does it affect timescales?

Does it affect the Business Case or the timing or level of benefits?

Does an issue affect the nature of a product or products?

Is the impact of any issue or risk contained within the present stage, or does it knock on into future stages or even the whole project?

Is it likely to affect any other projects and so does it need communicating to other Project Managers or, if you’re in a programme, to programme level?

What action can you take to address the issue or risk, and is that action within your own authority limit or do you have to go to the Project Board?

To help answer these questions, you may need to talk to a number of different people, such as:

Team Managers.

Team specialists (for example, for technical implications).

Supplier companies.

Project Board members (for example, on resource matters).

Project Assurance (for example, Business Assurance to look at impacts on the Business Case).

Project Managers of other projects, or the Programme Manager if your project is part of a programme (if you need to assess the impact on other projects or on the whole programme).

Having looked at the possible courses of action and the impacts, as Project Manager you then need to work out whether you can deal with the issue or risk within your own authority or whether you need to go to the Project Board. Part of that decision depends on where you are at the moment. If the action requires £12,000 and you have £15,000 to spare for adjustments like this, then you can get on with it. If, however, you have only £15 to spare, you need to take the matter to the board. Those options are covered by the two actions in the Controlling a Stage process of ‘Take corrective action’ and ‘Escalate issues and risks’. In the latter case, the Project Manager then awaits the Project Board’s guidance on what to do.

Checking how the possible actions sit with where you are at the moment carries on neatly on to the next heading of ‘Monitoring and Progress Reporting’.

Even if the Project Manager is working within his delegated authority (tolerances) he can still go and talk something through with a Project Board member informally. This is a bit like any staff member going to discuss something with his boss to get the boss’s view on it, even though the staff member is fully within his authority to take the decision. Chapter 10, on the Project Board, has more explanation on this ‘ad hoc’ or informal contact.

Monitoring and Progress Reporting

You must check regularly during the stage to see where you are against the plan. But you also need to check where you are if you’re dealing with an Issue in order to see if you have capacity to absorb the impact of any action, or if you must refer the matter to the Project Board.

This activity is all about making a thorough check on the progress of the whole stage, including forward projections, to see whether you’re still likely to finish the stage within the limits – or tolerances – that the Project Board set down at the beginning of the stage. This progress check is much more thorough than the ‘Review Work Package Status’ activity, which is a much higher-level check and limited to the progress of a particular Work Package.

Checking risk and the Business Case

As a minimum, you review and update the Business Case and Risk Register at the end of each management stage, but you certainly want to check them and maybe update them more often than that. In a high-risk project, for example, you’re likely to do a systematic review and update of all risks at regular intervals during each stage and the required degree of control will have been defined in the Risk Management Strategy.

Strangely the method only refers to checking if any benefits should be measured as part of this activity, not checks of the Business Case itself. But in many projects you need to check the Business Case regularly too in order to be satisfied that the project is still on track to deliver the expected benefits –as previous manual editions made clear. Although you may well do this checking as part of the analysis of inbound information coming in on Issues, a regular review is often more than advantageous and not least if a benefits tolerance has been set by the Project Board.

Firing off other parts of PRINCE2

This status check of the stage can trigger other work, depending on what you find. You may find that the project is:

Going off the plan but still within delegated limits: Can you deal with it within your own delegated authority? If so, fine, get on and do it. (See the later section ‘Correcting a Stage or Reporting an Exception’).

Going off the plan and finishing outside delegated limits: You need to report any Exception (a projection that you will go outside the tolerance limits for the stage) to the Project Board. Again, you can read more later in the chapter in the section ‘Correcting a Stage or Reporting an Exception’.

In Exception. A stage is said to be ‘in Exception’ when it’s projected to go outside one or more of the tolerance limits set down by the Project Board, and the Project Manager can’t correct this by taking action within his own authority. But exception also refers to the position of the whole project. It could be that some new information comes in and although that doesn’t have an impact on the current stage, it does affect a future one and will cause a breach of the project tolerance limits. In that case, the Project Manager must report it immediately, just like a stage exception.

You don’t need to report an Exception if you can adjust the running of the stage to bring things back within the specified limits. Exception is where you can’t ‘project manage’ your way out of the problem and you’ll breach the limits no matter what you do.

Getting near the end of a stage: Okay, time to start the End Stage stuff and then to get ready for the Project Board meeting. Turn to Chapter 6 for all the detail on the End Stage work.

Getting near the end of the project: When you approach the end of the last stage, start project closure. The detail of the closure work is in Chapter 9.

Reporting progress to the Project Board

The Communication Management Strategy included in the Project Initiation Document (PID) sets down how you’ll report stage progress to the Project Board, including the information you give and how frequently. In PRINCE2, this progress report is called a Highlight Report. As with all PRINCE2 reports, the report can be verbal, but again the Comms Strategy determines that (for more on the Communication Management Strategy, please see Chapter 5).

The PRINCE2 Highlight Report isn’t supposed to be a huge, unwieldy thing. Rather, you should spend less than an hour producing it and usually fit it on just one or two sides of A4. Some people use a dashboard-type layout with things like budget status shown as a petrol gauge. Being visual can be effective as well as concise.

The Highlight Report needs little explanation because, once again, the contents are straightforward. If you think it’s rather detailed and your Project Board is unlikely to be interested in that level of detail, don’t forget you can adjust it. The Communication Management Plan is where you define and agree the content and format of Highlight Reports for this particular project.

Warning the board of issues and risks

As you can see from the report headings, the Project Manager has the opportunity to tell the board members about any significant issues and risks, but contrary to an impression given by PRINCE2, he doesn’t need to tell the board absolutely everything. The idea of the board as the Project Manager’s boss is helpful here. If a subordinate tells his boss absolutely everything, the boss may wonder why he hired that person. Managers expect their staff to inform them of significant things only, not a mass of routine detail.

Reporting on progress with the Product Checklist

PRINCE2 has a very useful control document that doesn’t figure in the Highlight Report, but you may want to take advantage of it. It’s the Product Checklist mentioned earlier in the chapter in the context of noting the delivery of products completed by teams. The Product Checklist is useful in the context of the Highlight Report to show which products have been delivered that are due to be completed in the next reporting period. The Product Checklist is a particularly powerful progress monitoring and reporting tool and readily understandable for a Project Board.

Chapter 14, on planning, has more information on the Product Checklist and how, very simply, you can make it even more useful to the Project Board than covered in PRINCE2 by combining it with another technique. But it’s worth emphasising here that the checklist is extraordinarily powerful as a progress measure and the PRINCE2 manual has always understated its value and continues to do so.

Logging and reporting lessons that have been learned

The Lessons Log is for the Project Manager to record which lessons from previous projects can be applied to this one, and which lessons are being learned in this project that may be of value to future projects. Although such lessons can be noted at any time, obviously one or more may come to mind as the Project Manager reviews the stage. In that context, one final thing to single out from the Highlight Report headings is the Lessons Report. If something significant has been learned and logged, it may well be worth passing it back into the organisation now so that other projects can make immediate use of the information, and the Lessons Report serves that purpose. Read more about the Lessons Report in Chapter 6 that covers the stage boundary work, because that’s the more usual place for lessons reporting.

Correcting a Stage or Reporting an Exception

Projects go off track, which is why they need Project Managers. If the stage does go off track, clearly you need to react and do something about that. What you do depends on the nature of the problem and if you can bring it under control or not. You’ll have discovered the deviation from the plan (to use the PRINCE2 term) when checking the status of the stage – covered in the ‘Monitoring and Progress Reporting’ section a bit earlier in this chapter.

Correcting the stage

If you’re the Project Manager and can make some adjustments to the running of the stage that would mean that the stage would finish within the tolerances, then you get on and do that. That may mean making some changes to the plans and the work given to the teams. But the important point is that you’re working within your delegated authority and so can do this without reference to the board. This is just the same as ordinary business management where you’d expect one of your staff to get on and solve problems if he can, and not bring them all to you.

Reporting an Exception

If the Project Manager finds that no matter what action he takes within his own authority, he cannot adjust the running of the stage to finish within the limits of the tolerance, he must report this to the Project Board immediately. The stage is now ‘in Exception’. He must not take any action at all other than quickly to investigate the size of the problem and produce an Exception Report in the format set down in the Communications Management Strategy (which is in the Project Initiation Document). The Exception Report isn’t necessarily a document, but may be a meeting or a phone call.

Escalating apparently minor matters

Although the Project Manager can take action to get the stage projections back down inside the tolerance limits, he may not be able to if something else limits his authority to take action. For example, if an adjustment would cost only one penny and take one minute to do but would have huge business implications, the Project Manager almost certainly won’t have the authority to take that action. He has to go to the Project Board and in turn the board probably has to take it to more senior managers in the organisation.

With an exception, the Project Manager recommends how it should be dealt with, but the Project Board decides how it will be dealt with.