Post-Project Reviews in R&D
R8 assembled its picture of good practice from interviews rather than theory, so what follows is a description of what capable organisations were observed doing — not a standard, and not a process anyone certified.
What a post-project review is, and what it is not
R8 is a 2003 practitioner-journal study combining a survey of R&D managers with an interview programme, and it opens by fixing the term. The definition is short and worth holding to, because most of what goes wrong downstream starts with a review that was never scoped as one.
A post-project review
- Looks outward, to projects that have not started yet
- Asks what is transferable from this project's experience
- Produces recommendations addressed to other teams
- Succeeds or fails on whether anything downstream changes
A project closure meeting
- Looks inward, at this project's own obligations
- Confirms deliverables, accounts and handover are settled
- Produces a closed project
- Succeeds when the project is formally finished
R8 sets one precondition before anything else. A post-project review requires a project — and it is often unclear precisely when a project is formalised, which pre-project activities belong to it, or when it formally ends, because projects frequently transition smoothly into follow-up or next-release work with no defined ending. A clear beginning, a clear end and a defined project goal are named as key inputs to any review.
The starting condition R8 reports is stark. In its survey, 80 percent of R&D projects were not reviewed at all after completion, and most of the remaining fifth were reviewed without established guidelines. Those are findings of one survey of 63 R&D managers, not a rate for the field. Why organisations behave this way, and how to assess where yours sits, is the subject of barriers and maturity in post-project review. This page is about how to run one.
The six conduct rules
R8 presents these as a summarised list of what many interviewees considered successful review practice. They are observed practice from an interview programme, not a validated method, and R8 is explicit that no single right practice exists.
R8's six rules for conducting a post-project review
Run the review like a mini-project
Set a goal. Allow creativity and diverse input at the beginning, then apply discipline to funnel the session toward a tangible output at the end. The shape is deliberately divergent-then-convergent, and the tangible output is what separates a review from a discussion.
Have a trained and independent facilitator run the meeting
This lets key project members concentrate on the review results rather than on running the room, while the facilitator supplies neutrality, process experience and review technique. R8 adds a specific argument for outside facilitators: they can identify the four principal review problems uncritically, and address them more effectively than an insider can.
Ensure the team is prepared for the review meeting
Pre-review work covers questions about the project itself. R8 records one addition worth copying — a request to each participant for the most unusual or surprising artifact or observation from the project. It surfaces material that a structured question set will not reach.
Select the right environment and time
Offsite meetings reduce interruptions from day-to-day work and create more opportunity for informal communication. If the review is held on site, limit it to half a day, and break it into two meetings if the agenda does not fit.
Invite key stakeholders of current and selected future projects
Include managers and engineers, key customers, marketing and sales people, and — R8 names this last and deliberately — the project administrator or department secretary. The point of cross-functional attendance is to widen the range of issues that get raised.
Produce a summary document
The written report should not stop at enumerating general project problems. It should state concrete conclusions, warnings and recommendations for subsequent teams, and assign responsibilities for taking action on those recommendations.
When the review is held, and where
R8 records two legitimate timings and refuses to rank them. Which one is right depends on what the review is for, and choosing without deciding that first is how organisations end up with reviews that answer questions nobody asked.
Choosing the timing
The two-year delay is an illustrative practice from one organisation, not a recommended interval. What is transferable is the reasoning: a review timed for fresh memory and a review timed for complete evidence are answering different questions, and R8 treats both as defensible.
On venue, R8's preference is clear and its fallback is specific. Offsite is preferred. On site, cap the duration at half a day and split into two meetings rather than running long. The constraint exists because an on-site review competes with the day job, which is the managerial barrier operating in miniature.
Who runs it, who attends, and what gets asked
THE ANATOMY OF A POST-PROJECT REVIEW AS R8 DESCRIBES IT
| Element | What R8 records | Where the practice comes from |
|---|---|---|
| Who runs it | A trained, independent facilitator drawn from an internal coaching or quality management department, or hired externally. Some organisations deliberately keep the review a completely internal meeting | Interview programme. In most cases the quality and result of the meeting depends on the skill and talents of the facilitator |
| Who attends | Key stakeholders of current and selected future projects: managers, engineers, key customers, marketing and sales, and the project administrator or department secretary | The six-rule checklist. Cross-functional attendance is used specifically to widen the range of issues raised |
| What is prepared | Pre-review work on questions about the project itself, plus a request for the most unusual or surprising artifact or observation from the project | The six-rule checklist |
| What is collected during the project | At higher maturity levels, teams are trained to collect information during the project for later use in the review — logbooks, and records of important events that may be useful for future corrective action | R8's maturity model, level three |
| What is discussed | A known weak point. In R8's survey about 40 percent of reviews focused mostly on technical criteria, and devoting substantial review time to analysing project management methods was done by fewer than 20 percent of companies | Survey findings, 63 respondents |
| How the room is run | Like a mini-project — goal first, divergence at the start, discipline toward a tangible output at the end. Atmosphere kept low-key rather than formal | The six-rule checklist, plus interview practice |
| What is produced | A written summary document stating concrete conclusions, warnings and recommendations for subsequent teams, with responsibilities assigned for acting on them | The six-rule checklist |
All percentages are findings of R8's survey of 63 R&D managers, representing more than 40 companies across more than 12 industries, collected in 2000 and 2001. They describe that sample, not the field.
The content finding deserves attention. If two reviews in five concentrate mostly on technical criteria, most reviews are producing engineering lessons rather than delivery lessons — and it is the delivery lessons that transfer between unrelated projects. Analysing the project management methods used is the harder conversation and the rarer one, and it is where a review starts to inform questions like those in what distinguishes successful R&D projects.
What is produced, and what is done with it
The summary document is the deliverable, and R8 is specific about what makes it useful. A list of general project problems is not a review output. Concrete conclusions, warnings and recommendations addressed to subsequent teams, each with an assigned owner, is.
What the summary document must contain
- Concrete conclusions, not a catalogue of things that went wrong
- Warnings a subsequent team would act on before making the same choice
- Recommendations addressed to specific downstream teams, not to the organisation in general
- A named owner against each recommendation
- At review-process level two, a post-completion report built on a pre-defined template
- At level four, review results collected and made available across the organisation, against quantified quality goals
Dissemination is where R8's survey is least flattering and most instructive. Asked how review output actually travelled, respondents named individuals moving to new projects most often at 52.4 percent, ahead of written documentation at 39.7 percent. Only 8 of the 63 respondents said review results were effectively used to improve project management or formed an integral part of inter-project learning.
That ordering cuts against a documentation-first approach to learning. It does not mean the document is pointless — the document is what a person moving between projects carries and cites — but it does mean that a review whose only output is a filed report has chosen the weaker of the two observed channels.
The transfer mechanisms R8 records
Identify and notify who benefits
Work out who would potentially benefit from the review outcome and notify them of the results directly. R8 records a military practice that institutionalises this as a standing question — Who Else Should Know — asked so that individuals and teams elsewhere learn of a lesson and can act on it immediately.
Coaches who are not on the technical work
Some organisations use coaches who carry in-depth process knowledge from past projects to new teams while staying out of the technical work themselves. The knowledge being transferred is about how projects run, so technical independence is the point.
Rotation, assignments and handovers
Personnel rotation, temporary project assignments and core team handovers act as informal carriers. This is the channel R8's respondents named most often, and the one least likely to appear in a knowledge-management plan.
Professional networks and clubs
Informal platforms for exchanging project management know-how across organisational boundaries. R8 lists these alongside the formal routes without ranking them.
Running your first one
R8 does not offer a sequence, so the ordering below is this library's synthesis of its six rules and the anatomy it describes. Nothing here goes beyond what the paper records, but the paper does not present it as a procedure. If you want a single-page consolidation of this and the other R&D frameworks in this stream, see the R&D project management quick reference.
- Confirm the project had an end
- Set the review goal
- Appoint a facilitator
- Brief and prepare the team
- Run the session
- Write the document with owners
- Notify who benefits
Two adjacent decisions sit outside this page. Whether a project should have been stopped earlier is a different discipline with different criteria — see making better project termination decisions. Whether the organisation is structured to act on what reviews produce is a governance question, treated in governing R&D decisions organisationally.
What to carry forward
- A post-project review examines lessons that may be learned and used to benefit future projects. It is not the closure meeting, and treating it as one guarantees an inward-looking session.
- No clear beginning, end and goal means no reviewable object. Fix that before scheduling anything.
- Use an independent facilitator, prepare the team in advance, and ask each participant for the most surprising thing they saw.
- Cap an on-site review at half a day and split it rather than running long. Prefer offsite.
- Invite someone from a project that has not started yet, and invite outside the engineering line — including the project administrator.
- The document must carry concrete recommendations with named owners. In R8's survey, people moving between projects carried more learning than documents did.
Frequently asked questions
How is a post-project review different from a project closure meeting?
The closure meeting settles the project's own affairs — deliverables, accounts, handover — and its success criterion is that the project is formally finished. The review looks outward at what other projects can use, and its success criterion is that something downstream changes. R8 records organisations that run both, plus a separate retrospective on the development process.
Should the review happen straight after the project or later?
It depends what you want from it. Immediately after the last milestone gives fresh memory and an intact team, which suits process and execution learning. Waiting until after launch brings in customer feedback and product performance, which suits outcome learning. R8 records both as legitimate and lets the purpose decide.
Do we really need an external facilitator?
R8's rule is a trained and independent facilitator, which is not the same as an external one. Independence lets project members focus on the content rather than the process, and R8 argues that outside facilitators can name the review's own problems uncritically. Roughly 10 percent of surveyed companies used external moderators, and some deliberately keep reviews internal.
What should the review actually discuss?
R8 flags content as a weak point: about 40 percent of reviews in its survey focused mostly on technical criteria, and fewer than 20 percent of companies devoted substantial time to analysing the project management methods used. Technical lessons stay within a technology; delivery lessons transfer between unrelated projects.
Is a written report enough?
Only if the report carries concrete conclusions, warnings and recommendations addressed to subsequent teams, each with an assigned owner. R8's warning is that documentation without downstream action produces database graveyards, and its survey found people moving between projects to be a more common transfer route than documents.
Should we review projects that were cancelled?
Yes, and R8 identifies this as the case most often skipped. Prematurely terminated projects almost never receive a retrospective analysis of what caused them to fail, which means the projects with the most available learning are the ones least likely to be examined.
References and source attribution
- R8 — post-project reviews in R&D. Practitioner-facing mixed-methods study in a journal for research and technology management, September–October 2003; 7 printed pages; 13 references; two figures and two sidebar boxes. Survey of 63 R&D managers representing more than 40 companies across more than 12 industries, collected at two executive training events in September 2000 and October 2001, supported by 27 interviews with R&D managers from 13 multinational companies conducted between 1997 and 2001. Sections used here: the definition, the six-rule conduct sidebar, the comparative account of how reviews are used, and the survey results.
- The benchmarking study of 79 highly regarded R&D organisations, which found that fewer than a quarter made full use of post-project reviews, is cited within R8 as corroboration. It was not supplied to this library, and R8 is not itself evidence for that figure.
- The dated practice examples in R8 — a vehicle manufacturer's 1998 review procedure, a computing and instruments firm's project management initiative of 1989 reinforced by a 1993 council, and a manufacturer that waits approximately two years after product launch — are illustrative practices of individual organisations at the time of writing, not benchmarks.
- Eleven copyrighted journal articles on R&D project management, supplied as a reading set assembled by a student for a literature review and profiled for this library. Front matter, abstracts, framework sections, tables and figures were read; article bodies were not reproduced, and all content here is paraphrase. The set is a reading list, not a systematic or representative survey of the field.
- Supplied teaching source for this library (research methods and research process materials). Used here for page conventions and voice; it does not treat post-project review.
Suggested questions for Ask KEVOS
- Draft an agenda for a half-day on-site post-project review that ends with a tangible output.
- Write the pre-review brief we send to participants, including the surprising-artifact request.
- Turn a set of review notes into a summary document with concrete recommendations and named owners.
- Who should we invite to a review of a project whose successor has not been scoped yet?
- Help us decide whether to review this project now or after the product has been in the market for a year.
- List the questions that would move our reviews off technical criteria and onto project management methods.