Chapter 15

Reviewing the Project

In This Chapter

The importance of project evaluation

Two points at which to look back on a project

Measuring the project benefits, including multiple measures

Checklists to help with evaluation and reporting

After the main work of the project you should carry out a review and produce a report at two points. The first is when the project is completed, and that will involve producing a Project Closure Report. The closure report records an account of how the project went and records the final figures for things like spending. The report should also give details of any benefits already achieved. The second is a review which takes place some time after the end of the project with a Project Evaluation Report. The second review focuses on the achievement of benefits and the effectiveness of project products (deliverables) after an initial period of use.

Reviewing the project at the end is important. The most obvious reason is to report the return on investment. If you invest money in something like shares or a savings account you want to know the return – how well your investment has performed. So too with the project. The organisation has invested money and, perhaps even more significantly, staff time, and it should know what the return is on this investment. That return will primarily be the realisation of benefits. There are other reasons for the reviews, though, such as to report on the performance of the project as a whole and to assess the operational suitability of project products or deliverables.

Different approaches adopt a different pattern to closure and review, so check what your organisation requires if it has a chosen approach, or make your own mind up if it doesn’t. Figure 15-1 shows the process for the end and review of a project.

Closing and Evaluating a Project in PRINCE2 and PRIME

Two project methods with which I’m particularly familiar have rather different ways of dealing with closure and evaluation. PRINCE2 closes down when the project closes down and the Project Manager produces an ‘End Project Report’ (PRINCE2 isn’t fully ISO compliant and sadly that includes its sometimes awkward terminology). Evaluation after the end of the project, including measurement of benefits, is left to the organisation and isn’t part of the method. However, perhaps because the evaluation isn’t part of the method, it’s common for organisations to neglect it and either do it very superficially or not do it at all.

The person who chaired the PSG or Project Board is often responsible (or assumed to be responsible) for any evaluation after the project. If the project didn’t turn out very well and didn’t deliver anything like the benefit that he claimed so confidently and optimistically at the start, then it’s rather more comfortable for him to forget all about project reviews and benefits measures. It’s clearly much more important to focus on the success of the next project and deal with all the other important-stuff-I-have-to-do-that-you-wouldn’t-understand.

The PRIME method keeps the project open until the evaluation is complete. It says that there’s unfinished business until the evaluation is done. That makes it harder for evaluation to be quietly forgotten. PRIME has a Project Completion Report (the method has been built to be fully ISO compliant and so uses the ISO report name) at the end of the closure stage. Then it has an Evaluation Report after the final evaluation, which in turn may be some time after all of the delivery work has been finished. PRIME doesn’t shut down until after the Evaluation Report has been presented.

If you’re fairly new to projects, you may find it hard at first to get your head around the idea of a project still being ‘open’ after all its products have been delivered. PRIME uses the example of a shop, and you may find that helpful. When a shop closes, it isn’t the end of the business day. There’s still work to be done to tidy up and count the day’s takings before everyone can finally go home. So too with a project.

Project Completion Checklist

There’s quite a lot to do towards the end of a project so you’re a long way from putting your feet up, breathing a sigh of relief and thinking it’s all over. Here’s a checklist to help you get organised and make sure that you don’t miss anything.

• Product completion: Check to be quite sure that all project products are completed, which includes successfully passing any tests and checks. If you’re doing version control you should check that too and make sure that everything has a ‘complete’ status.
• Signoffs and handovers: Check that all necessary products have been signed off as okay, and that any handovers to users have been done.
• Handover documentation: If there should be formal handover documentation (such as legal documents), check that it’s been completed and is properly stored.
• Acceptance criteria: Check to ensure that the project acceptance criteria (set down in the Charter) have been met. Hopefully that will be all of them, but see the tip below if not.

The trouble with the term ‘project acceptance criteria’ is that it sounds as though the project won’t be accepted unless it meets them. While that may be true for some projects, in most cases a failure to meet one or more of the criteria will be a disappointment, but not a reason to abandon the whole venture. If delivery is a bit late, for example, a supplier may have to make a compensation payment, but the customer will still accept the new computer system or building extension. The PSG should be clear at the start about which criteria really are show-stoppers while the rest, although perhaps very important, are actually negotiable if push comes to shove.

• Resource release: Finalise the release of project staff back to their home departments, or perhaps on to new projects.
• Celebration: Assuming that the project was successful, it’s time to celebrate with the project staff. Although you might think this is a light-hearted point, it’s actually a serious one. It’s important that you mark the achievement by thanking the staff for their work and celebrating the success. And don’t forget supplier staff and support staff when preparing the invitation list.
• Physical resource release: Arrange the return of equipment and the release of accommodation, such as team rooms and perhaps even whole sites.
• Benefit measures: Often, some benefits will already be visible at the end of the project, so they can be measured now and reported now.
• Metrics: Calculate the final totals for financial spending, staff hours, performance and any other figures required for the Project Completion Report.
• Cost code: Arrange for the project cost code(s) to be closed, unless it is to be kept open for any modification to products after project closure.
• Assess the controls: Think back over the project and evaluate to see whether the controls worked or whether there were problems.
• Assess the plans: Think back and assess whether the plans worked, or whether they were too detailed or not detailed enough to exercise effective project control.
• Assemble lessons information: Prepare a statement of lessons learned during the project. Check back through your Project Log to make sure that you pick up everything relevant.
• Project Completion Report: Prepare the Project Completion Report together with a business presentation, if this is required by the PSG. You’ll find a template for the report in Chapter 17.
• Project Completion Meeting: Ensure that preparations are in hand for the completion meeting of the PSG (it’s like a final Stage Gate), such as a room booking, presentation equipment and refreshments.

Crash Stop Checklist

Sometimes things go badly wrong with a project, or perhaps it simply isn’t needed any more because of a change in the business. In that case, the project must be shut down early with a crash stop. That stop might be at the end of a stage if the PSG decides that it can’t authorise the next stage, or it might be because something happens during a Delivery Stage.

In an early close follow the points on the last checklist for a normal close but note these variations.

• Resource warnings: Warn home departments and suppliers that staff will be released earlier than expected because of the early project close.
• Review products: Think carefully about products which are currently under construction and discuss their states with the PSG. It may be worth finishing some of the products which will still be usable and so give some benefit.
• Lessons: This item is on the list for normal completion, but in the event of a crash stop think particularly carefully about two additional areas.
  • Avoidability: If the crash stop was because of severe project problems, think whether those problems were avoidable and whether early action could have saved the project. If so, note that for future projects.
  • Forewarning: If the project simply wasn’t needed any more or was overtaken by events, could that have been spotted earlier resulting in the saving of more staff time and expense?

Evaluation Plan Checklist

Think through what you need to do to evaluate the project, and when, and make a simple plan.

• Business Case: Review the Business Case to see what benefits are to be measured, how and when.
• Plan the review points: Group the benefits measures according to when you’ll need to do them. For example, one set of benefits might need to be measured one month in and the rest three months in.
• Early use: Think what you need to do to assess the suitability of project products. For example, have they proved easier or more difficult to use than was expected? Note down what assessment work is needed and when, and add that to your Evaluation Plan.
• Resource planning: Consider what staff resource you’ll want for benefits measures and usability assessment. Think whether you need specialists, such as finance staff, to help with the evaluation.
• Resource confirmation: Check that the people you need are actually available, explain the work to them and let them know when they’ll be needed.
• Reporting: Think through what you need to do to produce the Evaluation Report and make any necessary business presentation. Add this work to the plan.

Sometimes you may have to measure a benefit more than once. For example, PSG members and organisational managers may want an early, ballpark figure of staff savings at first, then a more accurate figure when things have settled down some weeks later.