Chapter 17

Monitoring Progress and Setting Up Effective Controls

In This Chapter

Looking at time-driven and event-driven controls

Managing by exception and saving senior staff time – big time

Understanding tolerances and exceptions

Checking progress and keeping control of projects

Controls in PRINCE2 are simple but extremely effective. If you use controls well they save time and make progress on the project extraordinarily clear. In fact, one progress control – which is a natural progression from the product planning covered in Chapter 14 – is one of the clearest available and involves no extra work if you do your planning well.

The main control during the project stages revolves around a management approach called Exception Management. This idea comes from accounting and works very effectively in a project. The key principle in Exception Management is that if everything goes to plan, actually you don’t have too much to talk about. Only when something happens that’s significantly different to what you expected do you need to sit up and take notice. And yes, this chapter deals with what ‘significantly’ means too.

Controls in PRINCE2 break down into two groups: event-driven controls and time-driven ones. Most controls are event driven, which means that they’re triggered when something happens rather than when a certain period of time elapses. There are three time-driven controls; two progress reports at two different levels and an optional team meeting.

Controlling at Different Levels

As well as working with two basic types of control, event-driven and time-driven, the PRINCE2 controls also work at and between specific levels of management within the project. Some controls work at more than one level.

Reporting: Time-Driven Controls

The two time-driven reports in the method are both progress reports – the Highlight Report and the Checkpoint Report.

Highlight reporting

A Highlight Report is a regular progress report that the Project Manager gives to the Project Board members. The content of the report is largely predictable – schedule, budget, delivery, and information on any major problems. The Project Board specifies the frequency and exact content of the report and this is recorded in the Communication Management Plan, which is part of the Project Initiation Document or PID (there’s more about this in Chapter 5).

Although the Highlight Report is intended for the Project Board, it may have a circulation beyond that. For example, where a project is part of a programme, you normally copy the Highlight Report to the Programme Director – or Senior Responsible Owner – and Programme Manager.

Checkpoint reporting

The second time-driven progress report is from a Team Manager to a Project Manager that explains how work on a Work Package is going.

Work Package. An instruction from a Project Manager to a Team Manager to build one or more products or deliverables. The Work Package includes things such as reporting requirements and problem notification, including Work Package exception. For more on Work Packages please see Chapter 14.

Team Managers give these Checkpoint Reports at the frequency and with the contents set down in the Work Package instructions, and this builds in great flexibility. You can vary the frequency of Checkpoint Reports between Work Packages. So one Team Manager may produce a Checkpoint Report every two days, while another doing work at the same time produces one every two weeks. As with the Highlight Report, the idea is to keep things simple and, as with any PRINCE2 report, you may decide that it can be verbal.

A Team Manager normally produces a Checkpoint Report after a regular team meeting. Although there’s no requirement to hold team meetings, or to match Checkpoint reporting to team-meeting frequency if you do have them most people do. That meeting is actually the third time-driven control.

Using the Event-Driven Controls

The event-driven controls happen when the associated trigger event happens. The most important of these event-driven controls are the project stages.

Controlling the project with stages

You can’t say the word ‘control’ in PRINCE2 without immediately thinking ‘stages’. The stages (you may know them as phases) are the big controls in the method. A stage is a block of project work that the Project Board is willing to authorise to be done in one go.

Stages aren’t a uniform length in PRINCE2. You never, for example, say that a year-long project divides into six stages of two months each. Well, you can, but I may then call you in to cut your buttons off, crumple your hat, rip up any PRINCE2 certificate you hold, and point a sword towards you. Dangerous stuff, so don’t even think about it.

No, the stages are different lengths because they relate to the nature of the work, not to the turn of a page in a calendar. To determine the length of a stage, you consider things like the amount of risk in that part of the project and major decisions about the project. The stages are event driven, so when you reach the point you defined, the stage ends. If the work is slightly delayed, then the stage takes slightly longer and the Project Board meeting at the end of the stage is slightly later. If the stage finishes early, then the Project Board . . . ah, you’re getting the idea of event-driven controls rather well.

Thinking ‘management’ stages not ‘technical’

You must appreciate that in PRINCE2 the stages are management stages and not technical stages. The management stages are the units of work that the Project Board is willing to authorise and a particular management stage may contain several technical stages. You may align some of the management stage boundaries to technical stage boundaries, almost certainly not all of them or you’re just running with the technical stages and missing out on the power of the management stage concept.

The stages in PRINCE2 give the Project Board superb control and means that it doesn’t have to authorise all the money and staff resources for the project at the beginning. The Project Plan sets down the spend of money and the use of staff and then the board authorises these in a controlled way – one stage at a time.

Deciding how many stages to have

Some people ask whether you can have a standard number of stages for a particular type or size of project. The answer is emphatically ‘no’. You just can’t define a calculation or algorithm because there are too many variables.

The bottom line is that the Project Board decides the number of stages and these factors are set out in Chapter 10 which covers the Project Board work. If you’re a Project Board member, do have a look at that chapter, because in PRINCE2 your work on the project is much more important than you may at first realise.

Counting the cost of stages

You need to be careful when thinking about the number of stages and where the stage boundaries are. The more stages, the more control you have, but the higher the cost. The fewer stages, the lower the cost but also the lower the degree of control. The Project Board must strike this balance. The board meet at the end of each stage and meetings can be expensive when you cost out everyone’s time. And don’t forget that the greater the number of stages, the greater the number of Stage Plans too, and they can take a lot of effort.

Approving stages – with a pen

No stage can start in PRINCE2 unless the Project Board gives its authority to do so. This makes the stage a powerful control, because you make a clear and recorded decision to carry on into the next stage. The project doesn’t just roll on because nobody said to stop.

Although the method doesn’t specify how the board give that authority, the pen is hard to beat. It’s a wonderful instrument for getting commitment. Wherever possible, board members should physically sign these authorities. You know yourself that a world of difference exists between telling someone ‘It looks all right to me’ and then actually signing your name to confirm your approval. That signed authorisation doesn’t have to be difficult – I’m not suggesting some handwritten parchment with a red ribbon round it. It can simply be a signature panel on the front of a Stage Plan.

Principle 4 – Manage by stages.

Making decisions at four key points

The stage boundaries form key decision points for the Project Board. Even before the first stage the board must decide whether the initial work of Start Up (see Chapter 4) shows the project to be viable and at least worth planning in more detail. If it does, the project starts to run the planning or Initiation Stage (see Chapter 5) and produces the Project Initiation Document or PID. The board must now decide whether the project should carry on or whether, after all, it’s not worth conducting and must stop. Then the board meet at the end of each stage for an End Stage Assessment to decide whether everything is okay and whether or not to authorise the next block of work, the next management stage. At the end of the last stage, the board check that everything is complete and authorise project closure.

End Stage Assessment (ESA). The Project Board meeting at the end of a stage in which board members review the stage just completed, check that the project is viable, and then either authorise the next management stage or stop the project.

Ordering Project Closure at Any Time

The Project Board can decide not to authorise a stage and stop the project instead. But it has another, more immediate control. PRINCE2 incorporates a mechanism where the board can order immediate closure of the project without waiting until stage end. In response to an event at any point in the project, the board can call in the Project Manager and instruct that the project goes into its close-down process. This could be in response to a serious problem that has taken the project out of control, or perhaps because of some new information that shows the project just isn’t needed any more.

A project was being run in an insurance company to upgrade and simplify some of its business procedures. But the project was suddenly stopped part way through. The insurance company had been taken over very suddenly by another company. There was no point in continuing the project to review the existing procedures because the new parent company had instructed that all business operations must now follow the existing parent company standards.

Managing ‘By Exception’

Financial and retail management uses Exception Management as a control. This is a simple device that PRINCE2 brings into the project environment. Basically, the Exception Management approach says that if everything goes as expected, you may want a report that confirms you’re on track but no decision has to be made.

A project stage contains a lot of plans – product plans, activity plans, resource plans, and financial plans. The Product Checklist provides excellent progress monitoring and gives you a lot of milestones for tracking delivery of project products very closely (see ‘Monitoring Progress and Controlling Projects’, later in this chapter). If everything runs pretty close to those plans, and demonstrably so, the argument is that little or nothing needs to be discussed.

In PRINCE2, the monthly progress meeting is gone – it’s history. The Project Board doesn’t meet until the end of the stage unless something goes ‘significantly’ off track, which means finishing outside the tolerances (limits) that the board itself specified. Cutting out the monthly progress meeting saves large amounts of senior staff time. Instead PRINCE2 has the Highlight Report, which is both informative and quick to prepare.

If you’re a Project Board member and worry that you may not be getting wholly accurate information on the Highlight Reports, remember that Project Assurance, the audit function in the project, checks the information. If the information you receive is wrong, assurance staff tell you immediately. Please see Chapter 12 for more on Project Assurance.

Principle 5 – Manage by exception.

Specifying the Limits: Tolerances

Very few projects, stages, or even Work Packages run exactly to plan. Suppose I’m a Project Manager in a £500,000, 10-week stage in a multimillion, 15-month project, and you’re a member of the Project Board. In Week 2 my latest projections from team estimates and other information are that the stage won’t cost £500,000 after all; it’s going to cost £500,002 – £2 more. Should I call you in with the rest of the board to discuss the £2 projected overspend? I don’t think so, although when I posed this question once somebody answered, ‘It depends on whether there’s a free lunch’, which I thought was an extremely good answer.

But wait, I miscalculated. I’m afraid that this stage is going to cost £8 million – a £7.5 million overspend on a £500,000 stage. Should I call you in now? The same person answered, ‘It depends on whether there’s a free lunch,’ which I thought was an even better answer. But I think that most people would be slightly concerned at this degree of overspend and if you’re on the Project Board you’d want the Project Manager to call you in – and fast.

This leaves one question: At what point do I call you in? Is it £3, £500, or £7 million? What’s the point between £2, where you don’t want me to call you in, and £7.5 million, where you do?

The limits, both upper and lower, are the tolerances. If something comes in at significantly lower cost than expected, you want to know that as well. Perhaps you need to inform others in the organisation and certainly this affects the Business Case, because the project now has even better justification.

You can do the same with time. If the Project Manager projects that the stage will take ten weeks and one hour, rather than the ten weeks initially agreed, do you want him to call you in? If the project is 42 weeks over and the Project Manager now estimates that it will take a year rather than 10 weeks, do you want him to call you in? A tolerance is specified on this too with plus and minus limits, which you can set down as a percentage or a number of days, say 10 weeks, plus or minus 10 per cent, or you may say plus or minus three days. The lower limit can be as important as the upper one, because if the project comes in a lot earlier than expected, taking advantage of this may have all sorts of business implications.

Setting unequal tolerances

The plus and minus amounts specified for a tolerance don’t have to be the same, and they don’t have to be the same across all types of tolerance. For example, you may decide on plus or minus 10 per cent on time, and plus 5 per cent and minus 15 per cent on cost. Actually those figures are often used because underspends are generally less sensitive than overspends, but not always, so you need to think about the sensitivity in the context of the business environment in which you work.

For time and cost, you can show the tolerances graphically. Figure 17-1 shows the expected expenditure and time, with upper and lower limits. Those limits form a box at the top right of the graph, the tolerance box.

The box represents the Project Manager’s delegated authority to manage the stage. All the time that the projections end in the box, the Project Manager can keep going, though he regularly reports progress with a Highlight Report. Exception Management gives the Project Manager some space to get on with his job without undue interference and without unnecessary meetings.

In his ‘100 Rules for NASA Project Managers’, Jerry Madden says:

Rule #3: 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.

The tolerances allow the Project Board to get out of the Project Manager’s way, but within limits that board members themselves set.

A lot of misunderstandings occur among those people using PRINCE2 who don’t have the intelligence and foresight to buy a copy of PRINCE2 For Dummies. These people quite often say that if a stage is high-risk, you apply zero tolerance. Zero tolerance may be fine as a concept in managing crime, but it simply doesn’t work in projects – not unless you provide sleeping accommodation for the Project Board, because they end up in permanent session. Bringing in a Project Board for a penny’s projected overspend, then a penny’s projected underspend, just isn’t workable. Even if the board approve the new cost, they then have to start reviewing the project’s timing because now the stage is five minutes over the planned ten weeks because you didn’t include that meeting in the plan. Use a tight tolerance maybe, but not zero.

Guarding against wishful thinking – tolerance lines

You may have encountered a problem if you manage staff who have budget allocations. The staff give their spending profiles to you at the beginning of the financial year with fairly modest spending plans. You approve the budget, and then after three months you get their first spending report. Your staff spent rather more than planned, but they reduced the estimates for the rest of the financial year and it all meets the original total. Then, after another three months, another overspend occurs, but the staff reduce the remaining six-month forecast and maintain the annual limit. Same story after another three months, except they now say they won’t spend anything at all in the last quarter. Then comes the report for the last quarter, which shows spending higher than the previous three periods all added together.

This problem stems from wishful thinking. ‘Yes, things are a bit overspent, but we’re bound to save some money later.’ ‘Yes, we’re a bit behind, but the team’s bound to get faster as the stage goes on.’ Really? Perhaps, but if you’re a Project Board member you may just want to check that.

Using the graphical approach again, you have an option to include tolerance lines all the way up the S curve (see Figure 17-2). If the Project Manager forecasts that the stage will go outside this ‘tolerance corridor’, as someone has aptly named it, the Project Manager calls the board in, even if the projection is that the angle may ease off later and the stage will finish inside the tolerance box.

If the board aren’t concerned about deviations during the stage as long as the Project Manager projects that the stage will finish inside the box, then they can just specify the box limits and not the lines.

You may want to think about whether to bring the tolerance corridor into force a little while into the stage and not from the beginning. In the first part of the stage the corridor is very narrow and can send the stage into Exception much too easily. In that first part, you may be better off not having lines at all and using the box only, or specifying a set tolerance amount and time for that first period, not a variable one depending on the distance along the S curve. If you play around with a spreadsheet you can see that an overspend of, say, £1,000 causes a minor blip towards the end of a stage, but the same amount sends the stage well into exception at the beginning.

Outlining the six types of tolerance

You can specify tolerances in some or all of the six PRINCE2 control areas. Time and cost are the most common areas.

Time: Few projects run exactly to time, so having a margin is sensible, to avoid calling the board in for minor variations in the predicted end point.

Cost: As for time, there’s no point in calling the board in over minor variations. Doing so may cost more in senior staff time than the amount the variation involves.

Scope: In some projects carrying out some changes in scope without reference to the board may be acceptable. A common example is in Rapid Applications Development (RAD) projects to build computer systems within a set time limit. The team is empowered to ‘de-scope’ products to fit the specified ‘time box’.

Risk: If a risk dramatically increases in severity, or new information shows that a really severe risk has gone and now can’t damage the project, then the board want to know immediately. Chapter 15 has more on risk management and how to show risk tolerance against impact and probability.

Business benefits: If the projection of benefits changes to go outside a given range, then the board want to know at once. If new information shows that the project will now give considerably more benefits than previously estimated, the board want to know so that they can boast to – sorry, inform – corporate management. But if new information shows that benefits may be significantly less than predicted, the board may want to consider closing the project down immediately.

Quality: Upper and lower limits may apply on quality variations, for example on the number of errors found.

Quality tolerance can sound a bit odd in the context of errors. If you find more than a certain number of errors then you have a clear quality problem that the board need to discuss. But strangely, not finding enough errors can be serious too, and may be enough to bring a board in very quickly.

Safety-critical computer developments have a norm for errors. If you find significantly fewer errors, they result from two possible causes and the board will want to know which applies. The first is that the team has written the software to a particularly high standard and fewer errors are present than expected. But the other reason is that the testing is inadequate. The errors are there, but the tests aren’t finding them. That means errors can go through into a safety-critical system, which is, obviously, extremely serious. One way of checking is to do more stringent testing of some sample areas to see whether this confirms that no more errors are present, or whether many more come to light and so show up weaknesses in the original testing regime.

Reporting Projections Outside of Tolerance: Exception

If you project that you’re going to break any tolerance limit, you must report it immediately. The stage is ‘in Exception’ and this reflects the name of this approach – Exception Management.

In Exception. When the projection is that something will finish outside the tolerance limits specified. If you can manage the situation with your own delegated authority so that things now stay in tolerance – it alters the projections – then you’re not in Exception. You’re in Exception as soon as you establish that you can’t complete that part of the project within the limits. Exception isn’t when you finally go outside the tolerance corridor or miss the box. If you project in week 2 that you can’t complete a stage within the upper limit of week 10, you’re in Exception in week 2, not in week 10.

Giving an Exception Report

A stage exception is reported using an Exception Report. PRINCE2 is just so complicated sometimes, isn’t it? You ‘give’ an Exception Report, though, so that doesn’t necessarily mean write it. You can make a phone call to each Project Board member, for example. The Communication Management Plan in the PID sets down what needs to be in the report and how to give it.

Deciding what to do

When the Project Manager recommends an action for a stage-level exception it’s just that, a recommendation; the Project Board actually decide the action. This is the first part of the Exception Management procedure. The board members take very careful note of what the Project Manager thinks and they may then follow his recommendation, but they may not.

The Project Board may decide on an action that doesn’t have any impact on Stage or Project Plans. For example, the board may decide to close the project. Or perhaps the cost of a piece of equipment goes up a lot and takes the stage into cost Exception. The board may simply authorise the additional funds and the Project Manager just needs to note this on the budget. You don’t have to do any re-planning because the timing of the stage, the staffing, and the activities and products are the same. This board give their decision to the Project Manager and that ends the first part of the procedure.

Revising the plans

If you have to run the stage very differently to recover from an exception, clearly the original Stage Plan isn’t much use. You need to re-plan to show the changed products, activities, schedule, and resources. But re-planning what you’ve already done so far in this stage is pointless.

Revising the plan forces an extra stage boundary. Because you don’t want to re-plan what you’ve already done, you close that work down as if this was the end of a stage. You even produce an End Stage Report for it. You re-plan the remaining work in the stage as if it were a new stage and that plan is an Exception Plan. There’s more on this in Chapter 6, and on the detail of planning in Chapter 14. Whereas the Exception Plan is normally exactly the same as a Stage Plan, it’s usually a bit faster to prepare, and this is for two reasons. First, it doesn’t cover the whole of the stage, only the bit that’s left. Second, it is very unlikely that everything will have changed and some parts of the existing Stage Plan are almost certain to be usable.

Exception Plan. A replacement plan for a stage that covers the period from the point of the exception until the end of the stage. It may also need to include an updated Project Plan if, for example, this stage now takes longer to complete, that timing change knocks on to the timing of the other stages and the project end date.

The Project Board must see and approve any plan at stage level. You then need to hold an End Stage meeting to check things out and either approve the plan or stop the project. This behaves exactly like a planned End Stage, but because you didn’t originally intend it – you’re reacting to the exception – the meeting has a different name; an Exception Assessment.

Exception Assessment. A meeting of the Project Board that works just like an End Stage Assessment except you didn’t originally plan it. You hold it to consider an Exception Plan.

Using Tolerance at Different Levels

The discussion on Exception Management so far in this chapter relates mostly to the stage level. But one of the strengths of Exception Management is that you can use it for control between all the management levels in the project:

Project Tolerance: Corporate management or the Programme Director can give the Project Board tolerances for the whole project.

Stage Tolerance: The Project Board give the Project Manager stage tolerances for each stage.

Work Package Tolerance: The Project Manager can put tolerances on Team Managers for individual work assignments or Work Packages.

Tolerances can run right down the levels of the project, but they can also trigger exceptions running right up to the top. An exception on a Work Package can send a whole stage into Exception, which in turn could trigger a Project Exception and require the Executive to report to corporate or programme management.

In its handling of Work Package exceptions PRINCE2 yo-yos from one edition of the manual to the next, so I guess you can feel even freer than usual to make your own mind up. The present position is that a Team Manager won’t use an Exception Report to notify an exception, rather, he’ll usually submit an Issue. However, the exact mechanism to be used is set down on the Work Package itself so there always was flexibility.

Monitoring Progress and Controlling Projects

The PRINCE2 method incorporates different ways of controlling work during a project and checking progress.

Controlling teams with Work Packages

In PRINCE2 the Project Manager controls the flow of work by authorising Work Packages. A Team Manager can’t start work until he receives the package. While the team works on the products, the Team Manager reports progress from time to time using a Checkpoint Report. Chapter 7 explains the Work Package control. The concept of the Work Package is used by many project management approaches, not just PRINCE2, but as already hinted in this chapter, the idea is a great one because it allows fine-tuning of controls. Different controls such as reporting frequency and exception handling can be applied to different Work Packages, though you may well define some default settings, which you then use for most of them.

Measuring progress with the Product Checklist

PRINCE2 has a very powerful progress-measuring mechanism, the Product Checklist. You develop it as part of product planning (you can find out more about this in Chapter 14) and the checklist is simply a list of products or deliverables together with their target delivery dates and, later, their actual delivery dates. These form highly effective milestones within a stage because the products are unambiguous in terms of delivery. Either a product is delivered, which means quality checked and signed off, or it isn’t delivered. You can’t have a halfway house of ‘nearly delivered’.

Product planning typically identifies 15 to 30 products in each stage, which gives 15 to 30 milestones where you know exactly where that stage is with no debate at all.

Avoiding ‘percentage complete’

Most project approaches, including computer scheduling tools, use the ‘percentage complete’ measure on activities to determine progress. However, percentage complete is unreliable and activities can stay ‘nearly finished – 90 per cent’ for a remarkably long time.

Beware of strange views on product planning. If you stick to the approach set down in this book you’ll be fine. Some people argue that different ‘states’ of a product don’t matter: They’re the same product and you should model them as one thing. Not only is that illogical (try convincing a child that a muddy potato is exactly the same thing as a packet of nice crispy fries in their favourite fast-food outlet) but it also undermines quality (the quality criteria are different), activity planning, resource planning (the resources are often different for arriving at the different points in development), but now it also undermines progress monitoring and use of the Product Checklist.

You can extend the Product Checklist slightly by putting in other dates such as the expected and actual dates for testing. That can be really useful as an early warning of delay, but the key information is the delivery information.

Controlling quality

The PRINCE2 method includes some highly effective ways of controlling the quality in the project. This exploits the power of product-based planning. For the detail on these, please see Chapter 13 for quality and Chapter 14 for product planning, including setting quality criteria for the individual products.

Looking for Financial Controls

If you’re looking for an effective way of controlling project finance in PRINCE2, then you’re going to be terribly disappointed. Other than the S curve and cost tolerance (see ‘Guarding against wishful thinking – tolerance lines’, earlier in this chapter), the method doesn’t offer anything. This is a major omission in PRINCE2, which targets project planning and control, of which financial control is clearly an important element. You need to look outside PRINCE2 for help on financial control.

As a start on financial planning, you can make a spreadsheet with budgeted costs, actual costs, and the variance. That’s easy to construct. Then you can also look for information on the Earned Value Analysis technique, because that fits PRINCE2 well and again is fairly simple to use.