Post Implementation Review of Project Completion

Presented by: Amul Shrestha (114) Lokesh Joshi (119) Bhupendra Yadav (120) Santosh Kumar Das (122)

 A Post-Implementation Review (PIR) is a review and assessment of the completed working project The Post Implementation Review (PIR) is conducted after a project has been completed. By conducting PIR, an organization can ensure that investment intensive projects achieve intended goals and make necessary modifications throughout the implementation of project. It will be performed after a period of live running, sometimes after the project is completed.

The purpose of the PIR is to evaluate how successfully the project objectives have been met and how effective the project management practices were in keeping the project on track. The main purposes of a PIR are: to ascertain whether the project has achieved its intended objectives to review the performance of project management activities to capture learning points for future improvements.

Example A department has introduced a telephone booking service to improve its appointment booking service. A PIR was conducted to evaluate the project achievements. The review team found that the telephone booking service was delivered on schedule and within budget. Instead of making an appointment in person, customers can make use of an Interactive Voice Response System (IVRS) and complete the booking within two minutes. The project was considered a success on its own. However, most of the departments customers are elderly persons and they are not used to making appointments through IVRS. As a result, the project has made little impact on improving the departments overall appointment booking service.

A PIR helps answer questions such as: whether the project was successful or not and for what reasons? to what extent has the project achieved its intended outcomes? to what extent has the project delivered its agreed outputs? what may be done to improve the current or future projects?

Why conduct a PIR?

The Government has a responsibility to make the best use of public resources to deliver services to the community, and to demonstrate accountability. Speci cally, a PIR can help: identify measures to improve the project being reviewed assess the contribution of the project to the departments business objectives provide an effective means to demonstrate accountability evaluate whether the intended project outcomes have been achieved improve bene ts realisation and project implementation improve the delivery and outputs of future projects by learning from the past

What projects should be reviewed?

The PIR process requires time and effort, especially for a fullscale review. Careful consideration should be given to selection of projects for review to ensure that the costs of conducting a PIR would not outweigh its benefits. The selection criteria are specific to the projects being considered and are different depending on the purposes of the review. Below are some suggested criteria: Importance: in terms of costs, resources and impact It is worthwhile to review projects which involve high costs and resources and/or have high impact.

Purpose: pilot/exemplary projects and joined-up projects A PIR can be conducted to determine whether new approaches or service models should be continued, modi ed or adopted for wider application. Nature: on-going versus one-off projects A one-off project is less likely to be replicated in future. PIRs for this kind of projects may have a lower reference value. Outcome: successful and unsuccessful projects It is equally important to identify best practices/lessons from successful and unsuccessful projects.

When should a PIR be conducted?

A PIR can be conducted after project closure to assess the full impact of the project and identify improvement opportunities for future projects. For long duration projects, it can be conducted at an appropriate time after completion of critical milestones or after the outputs or benets are expected to materialise. It can also be conducted when major issues are encountered to see if there is a need to modify the original project plan. A PIR conducted too soon may not be able to assess the full impact, while a review conducted too late may fail to inuence the delivery and outcomes of current project and/or future projects. PIRs may not be a one-off exercise. A project may last for a long time and different outcomes may be achieved as the project proceeds, and some may take years to realise. For these projects, it may be useful to conduct PIRs periodically

Example For an initiative on prevention of domestic violence, the short-term outcome may be increased awareness of domestic violence while the longterm one may be reduced domestic violence. A PIR can be conducted after the launch of a publicity campaign to assess the public awareness. When the reduction of domestic violence is expected to be more apparent, another PIR can be conducted to examine the change in the extent.

The PIR Four-Step Process The four-step process is the same for each review-plan, prepare, conduct, and follow upthough the products of the process differ. Where the Release Readiness Review produces action plans and communications for the current release, the post-implementation review produces action plans and lessons learned for future releases.

1. Plan for Review

Most of the post-implementation planning and preparations are the same as they were for the Release Readiness Review. The team lead (change manager for post-implementation) sets and communicates the review parameters, including meeting location, date, time, and meeting technology. The functionality, geography, organization, and technology reviewed match those in the Release Readiness Review. The date of the post-implementation review should be long enough after the release to ensure that all necessary review data and metrics can be collected, but not so far after the release that team members' recollections have faded. Two to five weeks after implementation is a good range. The length of a post-implementation review meeting depends on the size and complexity of the release and on how closely its results match the plans. Large, complex deployments might require a full day to review.

2. Prepare for Review Team member preparation is different, however, focusing on how the plans for the release compare with the actual results. They rely heavily on the templates completed in the Release Readiness Review meeting. Each team member annotates these previously completed templates with actual results and talking points for the meeting, focusing on results that differed from the plan and the probable reasons.

3. Conduct Review
The review team lead facilitates the review meeting with assistance from the timekeeper and minutes-taker. The goal is to examine the plannedversus-actual results of the release and to identify reasons for any differences. The review proceeds in five parts as follows: Release deployment - The review team lead facilitates a discussion of the planned-versus-actual results relative to the deployment of the release. Target environment (organization and infrastructure) deployment - The review team lead facilitates a discussion of the planned-versus-actual results of the release on the target environment. Rollout plan - As in the previous two discussions, the review team lead facilitates a discussion of the planned-versus-actual results of the rollout plan. The complete plan should include the following six elements: "Day of" plan Build plan Test plan Contingency plan Communications plan Contact information

 Risk management - The review team lead facilitates a discussion of the risks associated with the release. Questions to ask the team include the following:
Did we anticipate all potential risks? If not, what did we miss? How effective was our analysis? Did we accurately predict the probability and impact of the risks we identified? How effective were our mitigation plans for the risks we identified?

Lessons learned - The review team lead facilitates a discussion of the lessons learned from this release. Action plans - The review team lead facilitates the development of specific action plans required to enact the lessons learned from this release. If action items are identified, each must have the following components:
Description of the action. Owner of the action. Deadline for completion. Criteria for completion.

4. Follow Up on Review
After the post-implementation review meeting is complete, the minutes-taker circulates a detailed set of meeting minutes to all team members, with a deadline for review and comments. (In the case of emerging IT service providers such as B2B and ASP scenarios, a communication to the end customer may be in order to describe what was done and how it is meant to improve or further ensure service levels.) Team members review these minutes and, where appropriate, send comments back to the team leader. A Review Meeting Minutes template is available online at Operations Templates. The review team lead is responsible for compiling and documenting the lessons identified in the review meeting. This is intended for the reference of future development and operations teams so that they may directly benefit from anything learned during this release. Lessons learned should be grouped into two major categories: things to repeat and things to avoid in future deployments. Each lesson learned should have the following three components: A title that describes the lesson learned.

 An overview of what happened and what benefit (or detriment) resulted. Specific action items to be taken to ensure that these benefits are realized in future releases (or that these detriments are not). Lessons learned are valuable only if the entire organization can benefit from them. Lessons-learned documents should briefly summarize what was learned-they shouldn't note every detail. They are designed to be starting points for conversations between people, not detailed transcripts of everything learned during an implementation. They need to be cataloged in a standard manner and stored in a searchable location so that personnel outside the original review team can easily find and retrieve them. A template for the lessons-learned document is available online at Operations Templates.

 The review team leader is also responsible for coordinating the completion of the action items identified in the lessons-learned document. This entails following up with individual review team members to ensure that committed action items are completed. The change review is the last set of activities for the change management process. If the postimplementation review judges the change to be successful, the RFC is closed and responsibility is transferred to the Operating and Supporting Quadrants.

Thank You