Put a post-project review in scope

D E F I N I T I O N

A post-project review (PPR) is a debrief at the end of the project that analyses what went well and what the key challenges were.

The objectives of a review like this are:

• to bring everyone together at the end of the project to formally close it;

• to formalize the key lessons learnt during the project;

• to record this knowledge in such a way that it can be used by other projects in order to avoid the mistakes your project made or to benefit from implementing things that worked especially well.

Many organizations do not routinely carry out PPRs and have no formal way of capturing and sharing project learning. If this is the case in your organization, then it is still very worthwhile putting a PPR in the scope of your project. You and your team can personally benefit both from highlighting the pitfalls encountered in this project to avoid in your next endeavour and from the closure such a review brings.

R E V I E W I N G U N I V E R S I T Y R E C R U I T M E N T

A university in the British Midlands implemented an HR recruitment initiat­

ive over a five-year period. The project team and stakeholders had planned no formal review of the initiative. Denise Skinner, a researcher at Oxford Brookes University, interviewed key stakeholders to try to find out manage­

ment’s view on PPRs and why a formal review had not happened for this piece of work.³² She found that, in principle, the project team felt that evalu­

ating the recruitment initiative was a good idea, but that a formal review had been made pretty much impossible as the project had no definite object­

ives or success criteria, and so there was nothing against which to compare.

‘Those implementing the initiatives perceived that senior management did not place any value on planned, explicit evaluation,’ she writes in her paper on the subject in Human Resource Management Journal. The team was also concerned that a PPR would end up as divisive and critical, as they perceived the university as a blame culture and this kind of evaluation as inviting neg­

ativity.

‘The absence of any planned evaluation did not, however, mean that eval­

uation of the initiative was not taking place,’ Skinner continues. Informal evaluations had happened at all levels within the university, resulting in

Put a post-project review in scope

conflicting conclusions. The director of the diversity unit believed that the recruitment initiative mirrored the university’s cultural values, and senior management felt the project was successful. ‘The unquestioned belief that there would be a benefit to the organization from introducing these partic­

ular change initiatives reduced any perceived need to incorporate planned evaluation – those responsible for their initiative already “knew” that their effect would be positive,’ writes Skinner.

But lower down the management chain, the view of the project was dif­

ferent. Individuals felt that they lacked the wider vision of the initiative and wanted to have more information about the implementation. ‘There was no recognition of the potential, or need, for shared learning or interpretation, particularly outside management circles,’ Skinner concludes. ‘Individuals at all levels were engaged in making their own assessments and constructing their own “reality” in relation to their experience of the change initiatives.

Consequently, future actions were being influenced by assessments based on personal perception and subjective evaluations that resulted from relatively narrow perspectives.’

Including a PPR in the scope of the project will be a step towards making sure the review actually gets done. Add the PPR into your scope statement and the report from the PPR meeting as your project’s final deliverable. As the project moves into its final stages, book the date and a room for the meeting, and start asking people to keep the time free. Bear in mind, though, that the fundamental reason for doing a PPR is to ensure that the resulting information is shared and added to your organization’s corporate knowledge base in order to avoid ‘project amnesia’.³³ This can be done in a very formal, structured way – through a database of lessons learnt, for example – or, as with all things in project management, in an informal way whereby you help the team to reflect on the key messages so that as individuals they will benefit from the experience of the project and take that forward into their next assignments. In reality, you will probably end up being some way along the spectrum of possibilities, producing a report of successes and challenges, which will be circulated to the project team and interested parties.

A N E C D O T E

Learning from past mistakes could have averted delays and overspends on UK government IT projects over the past 10 years. The Public Accounts Committee has published a good practice guide, which states that it identified problems on over 25 occasions throughout the 1990s. ‘Many of the inherent problems had, however, been identified by the committee throughout the 1990s and might have been avoided if action had been taken sooner,’ says the 2005 government report into achieving value for money in the delivery of public services. The report says that, despite problems being identified, subsequent projects continue to make the same mistakes, showing that there

Project Management in the Real World

is a failure to implement lessons learned more widely across public-sector projects.³⁴

The PPR should be held at the end of the project and should involve as many as possible of the people who contributed. Invest some effort thinking about what kind of format you want for the review. A meeting where you go through a checklist of questions relating to each phase of the project (see, for example, Table 18.1) may not prove to be the open and honest learning environment you were hoping for, especially if the project hit some serious difficulties.

You might decide to interview each individual or team separately, collate and circulate their responses anonymously, and then hold a brief review meeting with everyone in order to agree and share the output. Whatever the format, the same questions will need to be addressed:

• What are you evaluating? Which parts of the project fall into the scope of the PPR? If some parts are excluded, why? Will they be reviewed separately?

• What criteria will the project be assessed against? Can you refer back to the project’s stated objectives and success criteria?

• Will you do the PPR yourself? Sometimes it can help to bring in another project manager or an experienced facilitator to run the meeting so you can participate fully. It also makes the environment more neutral, which is especially helpful if you expect sparks to fly between team members.

• In what format will the output be? Are you aiming to produce a report, a memo or a set of database entries? Knowing this will help you structure the meeting to get the best output for you.

• What ground rules do you want to set for the session? It can be useful to specify at the outset that the meeting is not aiming to apportion blame for failures. Agreeing some ground rules can also help (turn off mobile phones, give constructive criticism only, avoid commenting about an individual’s performance, depersonalize feedback with language relating to their role in the project or their department and so on).

Pin up the ground rules at the beginning of the meeting so they are available for reference as the session goes on.

• Consider getting agreement on whether each point can be docu­

mented Be sensitive about what remarks may best be kept within the four walls of your meeting room if the PPR report is going to senior management.

Put a post-project review in scope

Table 18.1 PPR checklist: example questions to ask during the post-project review Initiation/start-up Were the project objectives, scope and critical success factors

identified and agreed? By whom?

Was a project organization established, with clearly defined roles and responsibilities? Were these documented and signed off?

Was a cost/benefit analysis or business case drawn up and signed off?

Planning Was the content of agreed deliverables established?

Were all products and responsibilities agreed?

Were dependencies recognized and key milestones identified?

Was a meaningful schedule created?

Was a critical path established?

Monitoring Was progress monitored against the plan?

Were issues, risks and dependencies recognized and managed in an appropriate way?

Did the project schedule and budget prove to be realistic and achievable?

Was effective action taken to address changes to scope, poor qual­

ity, time slippage, cost overages and resource issues? How was this done? Did it work?

Were changes to the schedule and business case appropriately approved and communicated?

What status reporting was done, and was it accurate?

Structure/ Was the established project organization effective?

organization

Did the project team function well, sharing views and opinions and owning joint decisions?

Did the steering committee or project board function effectively?

Was communication effective at all levels? If not, why?

Outcome/result Was the project delivered on time and within budget?

Is the quality of the solution robust enough for the job?

Does the delivered solution meet the business objectives and detailed requirements?

Has an operational handover already been done? If not, when is it scheduled for?

What are the outstanding tasks, and who will take responsibility for them?

Project Management in the Real World

G O L D E N R U L E S

Plan for a PPR at the beginning of your project. Put it in scope and then follow it through, sharing the output with the team and organization for other people to benefit.