Unit 16: Post Implementation Review

1. Unit 16: Post Implementation Review CSEM04: Risk and Opportunities of Systems Change in Organisations Dr Lynne Humphries & Prof. Helen M Edwards

2. Overview • What is a post mortem review (and when to conduct it? • Full Post Mortem Reviews • Plan a Project Review • Gather Project Data • Hold a Project History Day • Analysis the findings • Synthesise Lessons Learned • Create of a Plan For Change • Close the Loop

3. Overview (cont.) • An Example of a Lightweight Post Mortem Review • “One Meeting” Version • Prerequisites • People/Roles • Processes • Brainstorming • Structuring • Analysis • Reporting

4. Issues Initial Trouble- shooting Settling Down PIR Fine Tuning Final Improvements Go Live Time A post-mortem review • Review of a project • By the project stakeholders • After it has “gone live”. • To build up understanding of the issues in that project. • To take “lessons learned” • To improve prospects of future projects being conducted successfully. Diagram from www.epmbook.com/

5. +ve Fine Tuning Final Improvements PIR Initial Trouble- shooting Benefits seen from project Time Settling Down -ve Post-Implementation Review Diagram from www.epmbook.com/ • Review of a project • By the project stakeholders • After it has “gone live”. • To build up understanding of the issues in that project. • To take “lessons learned” • To improve prospects of future projects being conducted successfully.

6. Full Post Mortem Reviews Based on De Marco and Collier’s Guidelines www.projectreview.net

7. Main Stages

8. Plan a Project Review • Project reviews are expensive in terms of investment of time. • So there has to be a justification for conducting them. • and a plan for what they’ll achieve • (cost benefit analysis) • After the end of a project most team members are working on the next project (not necessarily together) • It takes a energy and commitment to successfully review a project • To ensure an effective Project Review, teams must select the appropriate activities that suit that project and their needs.

9. Gather Project Data • Each participant has a view on what happened during the project and why. • One goal of the Project Review is to help create a common view of reality. • use objective and subjective data to evaluate perspectives. • The data used should be specific to the project and should reveal underlying issues in your development process: • Look for information that will reveal where the problems lay. • if the project suffered from scarce resources: consider the resources on the project (planned and actual) by month. • Problems with feature creep? Check and list of each time the features were revisited and list the changes made.

10. Hold a Project History Day • (Aka 'Project Review', or Postmortem) • A meeting where all of the information you have gathered is presented for review and evaluation. • The Project Review team and other key participants review the events that occurred during the project along with the rich set of collected project data. • Problem solving methods are used to discover key insights into the project dynamics and driving forces behind the project. • The Project History Day is the most complex and critical part of the project review process. It also is the most valuable in that the output is prioritized and actionable.

11. Analysis the findings • At the project history day participants review all of the information that has been collected. • They identify problems that the team experienced during the project • Then dig deeper so they can understand what caused them. • Often use “fish bone” diagrams. • Identify a problem • Ask: why? • Ask: why? • …

12. Synthesise Lessons Learned • This step is the most time consuming and most valuable activity in the process. • This is where insight* and imagination* lead to • a common view of the problems experienced • and the solutions needed to fix them. (*creative thinking techniques come to the fore here)

13. Create of a Plan For Change • Take your “lessons learned” foreward • Be pro-active • assign improvement activities to individuals or groups • check early in the next project(s) to see that changes are being • implemented and • tracked for impact • Ask “what can be done to improve the way the next project is run”?

14. Close the Loop • Collect and study information gleaned from Project Reviews from multiple projects. • Begin to evaluate problems and successes • across projects and • between different teams. • Introduce systemic changes throughout the organisation. • Begin by • documenting findings and • communicating them to the team and management.

15. An Example of a Lightweight Post Mortem Review Based on “A practical guide to Lightweight Post Mortem Reviews” Torgeir Dingsøyr, Tor Stålhane and Nils Brede Moe Department of Computer and Information Science Norwegian University of Science and Technology

16. “One Meeting” Version • Aim: to capture experience from a finished project, • with 3 to 10 project participants in one meeting. • suitable when a project has been finished, or has completed a phase, • To give new views on known issues, • To elicit issues that people usually do not think of themselves, • An efficient way of documenting experience.

17. Prerequisites • As many as possible of the project participants for up to five hours, • and • two people to facilitate using around eight hours each for preparation and • Materials • Post-it notes • Pencils with thick ink • A meeting room with a blackboard or whiteboard • Sound recording equipment (optional)

18. People/Roles • Moderator – will announce a Post Mortem Meeting, and moderate discussions. • Secretary – will document the results of the meeting. • If possible, the secretary can use recording equipment, and later transcribe important parts of the meeting. • Project participants – will contribute with their experience to get it documented. • Usually the process manager and secretary rotate between each part given below

19. Processes • Brainstorming: • Structuring • Analysis • Reporting

20. Brainstorming • Acquire important aspects from the completed project • Each participant has four Post-it notes • writes one topic on each • Each of the participants sticks up one of their Post-it notes, and explains why this issue was important in the project. • Then the next participant presents an issue and so on...

21. Structuring • After the brainstorm session, structure the result by placing Post-it notes with similar or related topics close to each other, and give each group a name that describe the content. • Give priorities to each topic, so that the most important are analysed.

22. Analysis • Find “causes” for the most important issues, • use “fish bone” or Ishikawa diagrams • start by drawing an arrow on the whiteboard with one issue. • indicate with other arrows what the causes for this issue was • (possible also with subcauses).

23. Reporting • Document the result, using report structure:- • Abstract • Introduction to the project and the method applied in the lightweight Post Mortem Review. • The main problems in the project, with explanations from the Post-it note presentations, and fish bone diagrams showing causes. • The main successes in the project, presented in the same way as the problems. • Appendixes: All information from the Post-it notes, and transcription of the presentations of the issues on the notes (if using sound recording equipment).