Chapter 9
Finishing the Project
In This Chapter
Making sure that you’re finished
Closing the project early, if you need to
Measuring any benefits and checking plans for further benefits reviews
Recommending any actions needed after the project
Preparing the report on how the project went
A lot of projects sort of fizzle out. People go off to do other things and organisational managers ask, ‘Is that project finished or is someone still doing something on it?’ Not so in PRINCE2. Closure starts with the work of the Project Manager, who checks that everything is really done, sees what needs to be passed back into the organisation and then reports how the project went. Closure ends when the Project Board agrees that everything is okay and that the project can be shut down.
This chapter looks at the first part of the closure: it covers what the Project Manager does to get ready for the Project Board’s confirmation of closure. As always with PRINCE2, the work isn’t difficult, but it’s important, so don’t be tempted to leave it out.
So where does this closure work fit into the project? ‘Er, silly question,’ you say, ‘at the end, of course.’ Yes, that’s true, but I mean in terms of the project stages. In PRINCE2, the project closure work is something that you do towards the end of the last stage. Unlike some other approaches to project management, project closure isn’t a stage in its own right. Having a closure stage does actually have some value, but that’s not relevant in this introduction to the chapter because PRINCE2 just doesn’t do things that way.
Closure can come at a time other than the planned end though and that’s when you do an ‘emergency stop’ – which may be at any point. It may be, for example, that some new and unforeseen business development shows that you just don’t need the project after all. Either way, project closure in PRINCE2 handles it.
Closing a Project
Closing a Project has five activities, which include two alternative entry points: you do the planned close for the project or you deal with an early or ‘premature’ close. Take a quick look at the model shown in Figure 9-1 to get the general idea and then come back when you’ve finished the chapter when you know exactly how it all fits together.
A repeated message in PRINCE2 For Dummies through both editions has been that you should always fit the method to the needs of the project. That’s worth emphasising here because, as you’ll see, in its full extent the work and documentation in closure can be extensive. But even in a very large project you may not need anything like this maximum so do think very carefully. Don’t put your hand up for unnecessary work that not only takes time and money, but possibly annoys others with over-large documents. A common result of a document that’s too big is that people, especially busy senior people, don’t read any of it. A smaller one often has a much better chance of being properly considered.
I was told in one multi-national organisation that for their documents, the title is the Executive Summary. That’s because when given a document their senior managers rarely manage to read more than the title!
Principle 7 – Tailor to suit the project environment.
Figure 9-1: The activities of Closing a Project.
Planning the Planned Closure
The name of the first ‘entry point’ activity is not very well worded because it involves rather more than just planning the closure, important though that planning is.
Making sure that you’ve done everything
When you say you’re finishing a project, you need to check whether everything is done or nearly done. In a small project you may know this anyway if you’re closely involved with the team, but even then sometimes a quick check does no harm to make sure that you don’t overlook anything.
You also need to check that the project meets the Acceptance Criteria on the Project Product Description. Some of these criteria may relate to the project itself, and others may relate to specific final deliverables of the project, particularly if the project is the sort that makes one big delivery at the end. Please see Chapter 8 for more on the Project Product Description.
Three things help you check whether you’ve finished a project:
1. If you used the powerful progress measuring tool in PRINCE2, the Product Checklist, you can see if the sign-offs are done for most of the project deliverables or products. You can read more about the Product Checklist in Chapter 14 because you produce it when doing the planning.
2. The Checkpoint Reports (progress reports) from Team Managers on the remaining products to see how they’re progressing.
3. The status information for products, which is part of the Configuration Management or version control information, to confirm that the status of all but the final few products is set to ‘complete’ – or ‘approved’ if you have the type of project where further approval is needed on some or all products. The Project Manager can ask Project Support to produce a Product Status Account. Chapter 16 has more on this.
Checking for sign-offs and acceptances
The completion check isn’t complete unless you’re sure that any necessary acceptances and handovers have been done properly. You don’t usually get those acceptances now, but check that none have been left out when things may have been signed off – and even taken into operational use – throughout the project. Not all projects are ‘big bang’ with everything delivered in one hit at the end.
The need for formal acceptances will have been noted on the Product Descriptions and Work Packages that set down the exact requirements for deliverables. In turn they will have been influenced by the Project Approach in which you identified legal requirements and mandatory handovers. As with so much of this closure work though, this is a final check. Usually the other controls (such as the return of a Work Package) will have worked very well to make sure that nothing was missed.
Product Descriptions and Work Packages. A Work Package is a work assignment given to a Team Manager to build one or more products – or deliverables. Each of those products is defined on a Product Description. The Work Package is like an instruction pack, and part of it is to say how products are to be returned on completion, including sign-off requirements. (For much more on products see Chapter 14 and for more on Work Packages, please see Chapter 8.)
Planning a Premature Closure
Although this is a separate activity box in the process diagram at Figure 9-1, it isn’t hugely different from planning the planned close. The key differences are the following:
You usually go faster than usual. The objective is to close the project quickly so as not to use any more resource than is absolutely necessary.
You don’t check that everything is complete. Instead, you look to see if any of the work that the project did carry out is worth saving, to get at least some benefit from the project. As with the planned close, you may use a Product Status Account but this time to establish what has been finished and how far through their development any unfinished products are. For example, if some are almost finished and would still be valuable to the business area, is it worth completing them?
You may need to tell people. As staff resources are released early, there may be some people you need to warn. Equally on finance, you’ll be releasing money that now won’t be spent so your Finance Director may be more than a little interested. You may have some important work to do here, including work on the legal side if contracts are being ended prematurely. Let’s hope you remembered to put a clause in the contracts to cover early close without incurring full costs!
Benefits reviews. There may be benefits from products that have already been delivered, but it won’t be the full range of benefits that would’ve been there if the project had been completed. You therefore need to adjust the Benefits Review Plan or, if there won’t now be any worthwhile benefits, scrap it.
Your review of lessons learned looks at whether anyone could have seen this problem coming. If someone had spotted the problem earlier, perhaps you could have closed down earlier and so saved more time and expense. Knowing that may help a future project in the same circumstances. If the project was shut down because it ran out of control, you need to examine the reasons for that. In turn, that may lead to Follow-on Action Recommendations (see later in this chapter) to change project procedures.
Handing Over the Final Product(s)
You will be passing one or more products back to the users of the project at the end, and it may be everything; the ‘big bang’ project. But in some cases it’ll be the final deliverables or products because things will have been taken into operational use throughout the project; perhaps just drip-fed or in phases of release.
Checking the working environment
PRINCE2 is impressively responsible. The end project work includes a check to make sure that project products can move smoothly through into their working life. The planned work, especially during the last project stage, should already have done this but in the close-down process this final check makes quite sure of a smooth transition. That’s very responsible, and very different from teams throwing products at users and running out quickly before people discover that nothing works!
The check should also make sure that enough resource is available in the early life of deliverables where users need more ‘hand-holding’ and where technical problems are more likely as things settle down or the need for small adjustments becomes apparent. Just in passing, these are actually some of the arguments in non-PRINCE2 methods for having a full stage dedicated to closure. Even in very high-quality environments, not everything will have been tested so you can expect some degree of trouble.
Looking at business benefits
Checking the business benefits falls into two areas. The first is those benefits that are visible immediately at the end of the project and that you can measure and report straight away. The second group is often bigger – those benefits that won’t be clear for a while, and which you can’t report accurately straight away. You need to measure and report this second group some time after the end of the project, and so after PRINCE2.
Measuring benefits that you can see now
No Project Board member wants to wait three months for the first report of benefits if some useful indicator already exists showing that the project seems to have been successful. So if you can measure and report any benefit now, even a single benefit, you do.
The Stage Plan for the final project stage includes any work to measure benefits during project closure, and the Business Case and Benefits Review Plan include information on what benefits need to be measured and how to measure them. The Project Manager includes this benefits information in the End Project Report – see ‘Reviewing How the Project Went’, later in this chapter.
Planning for benefits review after the project – did it deliver?
In many projects you can’t measure most benefits accurately at the end. Things are still settling down and the exact level of benefits isn’t yet clear. For a new business procedure, for example, in the first few weeks the staff are still getting used to it. Only after four or five weeks can you establish clearly how fast the staff can now operate the new procedure and the number of staff hours it saves. Measuring immediately while staff are going slowly because of unfamiliarity, for example, just isn’t accurate.
PRINCE2 shuts down when the project shuts down. Therefore, neither PRINCE2 nor the project is still running when you do the benefits reviews after closure. The Benefits Review Plan covers reviews after the project as well as any within it and is checked as part of project closure before being passed on to someone in the organisation to do as a Follow-on Action from the project. That person will usually be the manager who was the Senior User on the Project Board but it could involve others, such as financial specialists.
Answering the question ‘How long after the project should you measure benefits?’
A simple answer to this commonly asked question is when you can measure the benefits and report them accurately. Many people say that the length of time is always six months, but that’s not correct; it’s when the benefits can be measured. But anyway, you may need more than one review. For example, if you can see different benefits clearly at different times, you may have one review after three months, say, and another after six months. Or things may gradually become clear and you want a provisional review to give a ball-park idea of the benefits one month out, and then a precise one when things really settle down after four months. If your project is part of a programme of projects, you may need to have a review when the whole programme is finished and the full benefits are measurable. All of this should already be in the Benefits Review Plan, but you do a final check here before closing down and passing responsibility for reviews back into the organisation.
Reviewing How the Project Went
Now comes an important review of how the project went and, with that, the production of the End Project Report. This is where you look at the project in the context of the original Project Initiation Documentation (PID) – the detailed plan at project level – please see Chapter 5 for more detail. The PID includes things like timing, cost, and key objectives.
Recording the follow-on actions
You may have noted Follow-on Action Recommendations – things you recommend that the organisation does after the end of the project – right through the project but especially in the last activity in this process where you’re thinking about products and handovers. The Follow-on Action Recommendations are summarised in the End Project Report. The Project Board should normally approve, and then make, the recommendations.
Writing the End Project Report
The Project Manager produces the End Project Report, which is his view of how things went, as well as a presentation of key facts and figures from the project.
The End Project Report goes with other closure products to the Project Board and then back into the organisation. But unless it is confidential, a copy of the report should then be stored where future projects can find it and refer to it, not in the bottom of a locked filing cabinet in the lower basement.
Writing the Lessons Report
In the review of the project and while thinking through what you will include in the End Project Report you may think of more lessons that are worth passing on. You can put these into the Lessons Log, but then you need to close that log and produce a Lessons Report.
If you have a permanent Project Office, that’s often a great place to keep Lessons Reports so that Project Office staff can tell Project Managers about relevant reports from previous projects. Or you may put the Lessons Report on a network directory. You may find it worthwhile to index these reports, or split up the recommendations so that you can search for individual items (such as all comments about Issue handling across all projects) as well as retrieve a whole Lessons Learned Report for a particular project. Again, Project Office staff can help you.
Recommending Closure
The last activity is very simple and that is to gather up the end project documentation and put it to the Project Board with the recommendation that the project be shut down. You will find the other end of this activity in the Chapter on the Project Board, Chapter 10, with the corresponding activity of ‘Confirming project closure’.
You may need to warn people that the project is closing though, and then there is also a bit of tidying up to do.
Closing down the logs and registers
As part of the end project work, you close down the logs and registers. If any further action is needed on any items in the logs, you will have created Follow-on Action Recommendations.
Storing the project records
Clearly, where you have physical documents, you don’t normally want to store stuff that was just working documentation and that you don’t need in the operational life of products. But be careful not to overdo the weeding. You need to think carefully whether documents may be helpful for maintenance. You also need to consider whether you may need certain documents if anyone has to check back on the project as a final audit to make sure things were done properly. But even with physical documents, you can always scan them and store them electronically if you’re in any doubt.
A problem with storing computer files over a long period of time is that, while the data records remain intact, sometimes the software and even computers and operating systems you need in order to read the files disappear. The BBC had a project many years ago to store information about what life was like in Britain at that time. All the computer data files are intact, but the BBC has had to ask whether anyone still has the type of old computers it used and the original software it needs to read that data. Those involved with archiving information have now realised that an excellent storage medium is . . . wait for it . . . paper. If something is on paper, you can scan it into new software and make a new electronic record.
So you need to think not only about what you need to store, but how you store it. How can you retrieve it? Storing something is pointless if you can’t find the information you need because it’s buried in a mass of redundant stuff. You can consider, for example, putting key information in one set of directories, and the larger mass of stuff that you probably won’t need again in others.
Some years after a motorway was built and opened, problems developed. Cracks appeared in some sections of the support structure, and although traffic volumes were greater than originally predicted, they were still well within the ultimate load capacity. The designs and records for the project were still stored in an old aircraft hangar and maintenance staff were able to consult the records to help establish the cause of the problem.