Where am I? | Home Service Transition Post-Implementation Review
ITIL Post-Implementation Review Template

ITIL Post-Implementation Review Template

The Post-Implementation Review takes place after a Change or a Project has been implemented. A Post-Implementation Review determines if the Change or Project was successful, and identifies opportunities for improvement.

If you like our site please spread the word by telling your friends about us. We like to be Liked.

Post-Implementation Review
User Rating 4.32 ( 31 Votes )

Post-Implementation Review Template (MS Word)                 Post-Implementation Review Template (Adobe PDF)
MS Word           Adobe PDF

1. Executive Summary

[Write a brief summary of the content of the Post-Implementation Review. The executive summary is produced for business purposes, with the objective that an executive can read it and understand the message without having to read the whole document.

Use concise language, summarizing ideas in the same order that they appear in the detailed contents. The summary must be able to be read separately from the rest of the document and transmit the message.]

This document is a report with the findings of the Post-Implementation Review that has been conducted to evaluate the results of the project to migrate the server infrastructure of the organization to Windows Server 2008 R2. The high-level goals of the project were to reduce IT costs, simplify management, improve security and increase application performance.

From the findings, the conclusions obtained have been:

  1. Accomplishment of project goals: The stated initial goals have been accomplished.
  2. Performance metrics: The implementation has solved the problems that previously existed with some of the performance indicators. As a result, all of the KPI are in agreement with the SLA.
  3. Side-effects: Under the new architecture, the proprietary client-server application that manages the Customer Relationship Management (CRM) of the organization is sometimes freezing. A workaround has been implemented to temporarily manage the resulting incidents.
  4. Residual risks: The predicted risks have been effectively managed.
  5. Costs: Costs slightly exceeded predictions due to delays in one step of the implementation.
  6. Schedule: Delays in the deployment phase were caused by a failure in Supply Management to engage appropriately a third party supplier responsible for servers.
  7. Customers and users satisfaction: Customers and clients satisfaction with the migration and with the final outcome is at acceptable levels.

The following recommendations arise from this report:

  1. Raise a Request for Comments (RFC) and generate a problem ticket to resolve the incompatibility in the proprietary client-server application.
  2. Service Level Management and Supply Management must revise underpinning contracts to further support the objectives of the services.
  3. The Configuration Management Database (CMDB) must be revised to update all the relevant dependencies between Configuration Items.
  4. Project procedures should be improved to further diminish the impact of the transition on users.

2. Introduction

[The Post-Implementation Review report is a document intended to capture the results of an ITIL Post-Implementation Review. The Post-Implementation Review is aimed at determining to what extent a change or project has been successful, and to identify opportunities for improvement.

In this section you explain the background, objectives, scope of the Post-Implementation Review, and members of the team who executed the review.]

2.1 Background

[Expose the background to this change/project, including why it was launched and how it was implemented. You can also explain how the Post-Implementation Review was conducted and how its results are feeding this report.]

After an extensive analysis of benefits and cons was conducted, a decision was taken to migrate all the infrastructure servers in the organization to Windows Server 2008 R2. Some of the benefits expected were:

  • Reduce costs through efficient virtualization and less power consumption.
  • Simplify Management.
  • Improve Security.
  • Increase application performance through new architectures.

At that time, most of the servers in the organization were based in Windows Server 2003 and Windows Server 2008. Virtualization was not still implemented although several proposals were made calling to virtualize either using Hyper-V from Microsoft or ESX from VMWare. The approved project called for a phased migration of all Microsoft servers to Windows Server 2008 R2 and the implementation of a Hyper-V solution.

After successful implementation of the project, a Post-Implementation Review was conducted to evaluate results six months after successful migration. The findings from this review are documented in the current document.

2.2 Objectives

[An ITIL Post-Implementation Review is performed to confirm that the change/project has met the stated objectives; that customers, users and stakeholders are happy with the results; and that there have been no unexpected side-effects. It is also an important tool to correct course if needed and to improve the change/project process in future recurrences.]

The objectives of this Post-Implementation Review have been:

  • Demonstrate that the project has achieved its objectives and the proposals in the business case.
  • Check if customers, users and stakeholders are satisfied with the outcomes.
  • Deal with unexpected and/or undesirable side-effects.
  • Help to decide if any corrective action is needed.
  • Learn lessons to improve future changes/projects implementation.

2.3 Scope

[Explain here which elements of a review have been included and which others have been excluded. Some of the elements to define the scope may be:

  • Change/project has accomplished the desired objectives.
  • Users, customers and other stakeholders are satisfied with the outcomes.
  • There are no unexpected or undesirable side-effects to functionality and service levels.
  • The resources used to implement the change were as planned.
  • The release and deployment plan worked correctly.
  • The change was implemented on time and to cost.
  • The remediation plan functioned correctly, if needed.


This document reviews the results of the implementation of the project “Migration to a Windows Server 2008 R2 infrastructure”. The elements included in the review have been:

  • Accomplishment of project goals.
  • Performance metrics.
  • Side-effects.
  • Residual risks.
  • Costs.
  • Schedules.
  • Users and customers satisfaction.

This document does not include:

  • Remediation’s plan effectiveness, because its activation was not needed.

2.4 Post-Implementation Review Team Members

[Include here the members of the team who conducted the Post-Implementation Review. If possible, members of the Post-Implementation Review Team should not have participated in the actual implementation of the change/project, although people who defined the original requirements or gave technical advice could be included. They should have been selected as impartial reviewers without any interest or benefit in the positive or negative outcome of the review.]

The personnel that participated in the Post-Implementation Review are shown in Table 1. Post-Implementation Review Team Members, below:

Name Position
John Doe Post-Implementation Review Chief
Jane Doe Change Analyst
Jane Smith Business Relationship Analyst
John Smith Senior User

Table 1. Post-Implementation Review Team Members.

3. Findings

[The central part of the Post-Implementation Review is to compare the original goals of the change/project with the achieved outcomes and then learn any lessons from results to improve the success of future changes/projects. Comparisons are to be held following the scopes defined in the section 2.3 above. Select subsections in your document accordingly]

3.1 Accomplishment of Project Goals

[Determine whether the implemented system has achieved its proposed outcome and has provided the desired benefits in support of the mission and goals.]

To measure effectively the intended benefits of the project against the actual outcome, several Key Performance Indicators (KPI's) and measurements were previously defined. The results are shown in the Table 2. Initial, projected and real outcomes of the Migration.

Objective Initial Projected Outcome Deviation
Reduce costs in Datacenter through efficient virtualization $ 504.8 /day $401 /day $400.9 /day - $0.1 /day
Less power consumption in the Datacenter 56 KWh /day 32.8 KWh /day 32.9 KWh /day +0.1 KWh /day
Simplify Management 2.5 h /1000 users/day 1.5 h /1000 users/day 1.1 h /1000 users/day - 0.4 h /1000 users/day
Improve Security 0.067 incidents /day 0.010 incidents /day 0.0055 incidents /day - 0.0045 incidents /day
Increase application performance through new architectures 0.1 s /transaction 0.65 s /transaction 0.55 s /transaction -0.1 s /transaction

Table 2. Initial, Projected and Real Outcomes of the Migration.

The deviations observed in each of the defined key indicators are within the accepted ranges as defined in the design of the project.

The indicator of security improvement may appear to indicate an over-investment because measurement is far better than predicted. This behavior is expected and is the result of the adoption of strictest controls through Federation Services in a parallel project.

3.2 Performance Metrics

[Check that the system turns to be or continues to be fit for purpose as defined in the ITIL Service Level Agreement, Contract or other agreements. Metrics can describe performance factors like availability, capacity, continuity or security. Provide metrics for as much areas as can be affected by the change/project.]

To ensure the stability of the network services provided after the project, the main KPIs from the Service Level Agreement (SLA) were selected to check their behavior before and after the implementation of the migration project. Results are shown in the Table 3. Performance metrics.

Metric SLA Initial Final Status
Percent of Directory access within agreed response time 95 96.5 96.5 In compliance
Percent of Web access within agreed response time 95 91.2 96.2 In compliance, improved, problem solved
Incidents solved within agreed time 95 97.8 97.6 In compliance
Availability of network services 99.5 99.29 99.99 In compliance, improved, problem solved

Table 3. Performance Metrics

Results show that stability of the system has been guaranteed after the migration and even improved. Some important problems were also solved as a result. Previous breaches in Web access services were solved through migration of servers to 64-bit architecture. General availability was also improved thanks to the implementation of Live-Migration techniques.

Time to solve incidents slightly deteriorate at first as a result of the learning curve, but later has been improving.

3.3 Side-Effects

[Explain unexpected or undesired side-effects that might have been appeared as a consequence of the change/project.]

One unexpected side-effect arising from the migration is a temporary freezing in the proprietary client-server application that manages the CRM of the organization. This effect was not detected during the Evaluation phase of the change and is currently been investigated by the Development Team. A workaround has been put in place to be executed each time the incident occurs until a final resolution can be manage through Problem Management.

3.4 Residual Risks

[The purpose of this section is to evaluate how risks identified as part of the change/project have been mitigated through the selected countermeasures and which residual risks remain. Validate that all risks have been identified, that a plan exist to mitigate them and that individual risks have been mitigated if they occurred.]

As part of the Evaluation process, the proposed change was evaluated under business, financial and technical impacts. Several risks were identified in the document (Doe, "The Client". IT Service Migration. Risk Assessment Report., 2012) and countermeasures were designed to mitigated them during the transition, early life support and operation phases.

The risks of instability during the transition phase were addressed through remediation and undo plans. Risks during early life support and operations phases were addressed through a knowledge plan aimed to better prepare the personnel to face unpredicted consequences. It has not been necessary until the current date to activate any of the remediation or undo plans except for test purposes.

Residual risks remain that some instability could still arise from the use of the new technologies. Those hypothetical events could defy the capacity of the personnel to deal with them, putting at risk the achievement of the guaranteed services levels. The probability of such scenario has been calculated as been below 0.1% under the assumptions in the aforementioned document.

3.5 Cost

[Assess whether the project was completed within planned budget and that financial estimates were as predicted.]

The costs incurred as part of the migration project has been as shown in the Table 4. Costs.

Item Predicted Real Deviation
Capital Costs [USD]
Hardware 22800 22160 -640
Software 45000 45000 0
Project design, implementation & commissioning 21000 21850 850
Operational costs [USD per day]
Staff 320 320 0
Equipment 52 52 0
Supplies 29 28.9 -0.1

Table 4. Costs.

As seen in the table, capital costs due to project design, implementation and commissioning exceeded their budgeted figure. This happened due to some delays in the time spent in implementation. This figure was compensated in some extent by a decrease in the price of hardware.

The operational costs to operate the migrated services have been behaving as predicted.

3.6 Schedule

[Assess whether the change/project was executed within the scheduled timeframe. Check if all key milestones and deliverables were met in the predicted time.]

The predicted and actual completion date for each milestone is shown in the Table 5. Milestones Completion.

Milestone / Deliverable Planned completion date Actual completion date Deviation [days]
- Vision document
- Project structure
7/7/12 7/6/12 -1
Migration plans
- Functional specifications
- Project schedule
- Risk assessment
7/21/12 7/19/12 -2
Prototype - Prototype testing report 7/28/12 7/26/12 -2
Pilot - Pilot testing report 8/9/12 8/7/12 -2
Deployment - Deployment report 8/15/12 8/17/12 +2
Early life support - Service review results 8/21/12 8/23/12 +2

Table 5. Milestones Completion.

As indicated in the table, project execution got delayed during the deployment phase. Reason for that setback was an unexpected failure in support from a third party supplier of the hardware equipment.

3.7 Customers and Users Satisfaction

[Surveys are conducted to sense whether customers and users perceive the results of the project/change as satisfactory. While customers are the final receivers of the services, users are those who directly interact with the interfaces of the service.]

In order to measure satisfaction with the migration process and with the services after completion of the project, separate surveys were delivered:

  • A customers’ survey was given to business managers.
  • A users’ survey was given to users directly interacting with the interfaces of the services.

A scoring system was defined to measure satisfaction:
5: Very happy.
4: Happy.
3: Neutral.
2: Unhappy.
1: Very unhappy.

Global results are shown in the Table 6. Customers and users satisfaction.

Topic Score
Did project goals support your needs? 4.6
Are you seen tangible benefits from the outcomes? 4.8
Was transition adequately managed to minimize potential effects in the quality of services received? 4.1
Are you satisfied with the quality of services after the conclusion of the project? 4.5

Table 6. Customers and users satisfaction.

Since the threshold defined for acceptable satisfaction is 4, it can be concluded that the migration process has been accomplished with acceptable customers and users satisfaction.

More emphasis must be put into future transition procedures in order to further minimize the impact on users.

4. Conclusion

[Describe how the change/project met (or did not meet) the objectives initially stated. Here you can include lessons learned and recommendations.]

4.1 Lessons Learned

[Describe any lessons learned in this change/project that can be helpful for future changes/projects. The easiest way is to capture events as they occur and write down what can be learnt from them.]

From the findings, the following lessons can be extracted to serve as a feedback into future changes or projects:

  1. Accomplishment of project goals: A clear vision to which the project adhered effected a total fulfillment of the stated goals with very little deviation from the desired outcomes.
  2. Performance metrics: A careful design and phased implementation, oriented to the business objectives, resulted in a positive outcome, with all the key indicators within the values agreed in the SLA and the resolution of some of the previous performance problems.
  3. Side-effects: An unexpected result was an incompatibility in the proprietary client-server application that manages the CRM of the organization. That came as a result of insufficient testing in the Evaluation phase. Inconsistencies in the way that the CRM application is incorporated into the Configuration Management Database (CMDB) brought about a failure to predict and test the possible technical impact in the application service.
  4. Residual risks: An effective risk assessment in the initial steps, together with the appropriate selection of countermeasures, resulted in the acceptable mitigation of the risks detected. Tested undo plans were ready although there was no need for real activation.
  5. Costs: Costs slightly exceeded predictions due to delays in one step of the implementation. Special care must be put in managing uncertainties to avoid exceeding the budget.
  6. Schedule: Delays in the deployment phase caused a moderate financial loss. Reason for the delay was a failure in Supply Management to engage appropriately a third party supplier. Supply Management and Service Level Management must improve their procedures to compromise suppliers with the desired outcome.
  7. Customers and users satisfaction: The engagement between Business Relationship Management and customers from the beginning and a careful planning resulted in acceptable levels of satisfaction from customers and clients. More emphasis in planning future changes and projects might improve the customers and users perceptions about the transition procedures.

4.2 Recommendations

[Here you may include both change/project-specific recommendations and recommendations to improve the overall IT change/project management processes. Recommendation must be as much actionable as possible.]

To solve the problems detected in this Post-Implementation Review and to improve results in future changes and projects, the following recommendations are given:

  1. Raise an RFC and generate a problem ticket with Problem Management to resolve the incompatibility in the new architecture of the proprietary client-server application that manages the CRM of the organization.
  2. Service Level Management and Supply Management must ensure that third party providers be compromised with the objectives of future projects. Underpinning contracts should be revised or created if they do not exist to further support the objectives of the services.
  3. The CMDB must be revised to update all the relevant dependencies between Configuration Items.
  4. Project Management, IT Service Continuity Management and Release and Deployment Management should improve their procedures to further diminish the impact of the transition on users.

5. Annex

[Insert here anything you may like to attach to support the document.]

5.1 Glossary

[This section provides the definitions of terms, acronyms, and abbreviations required to understand this document.]

Term Definition
Business Case Justification for a significant item of expenditure. The business case includes information about costs, benefits, options, issues, risks and possible problems.
Business Relationship Management The process responsible for maintaining a positive relationship with customers.
Capital Cost The cost of purchasing something that will become a financial asset
Change The addition, modification or removal of anything that could have an effect on IT services.
Configuration Item (CI) Any component or other service asset that needs to be managed in order to deliver an IT service.
Configuration Management Database (CMDB) A database used to store configuration records throughout their lifecycle.
Customer Someone who buys goods or services. The customer of an IT service provider is the person or group who defines and agrees the service level targets.
Deliverable A planned output.
Deployment The activity responsible for movement of new or changed hardware, software, documentation, process etc. to the live environment.
Early Life Support (ELS) A stage in the service lifecycle that occurs at the end of deployment and before the service is fully accepted into operation.
Impact A measure of the effect of an incident, problem or change on business processes.
Incident An unplanned interruption to an IT service or reduction in the quality of an IT service.
IT Service Continuity Management The process responsible for managing risks that could seriously affect IT services.
Key Performance Indicator (KPI) A metric that is used to help manage an IT service, process, plan, project or other activity.
Operational Cost The cost resulting from running the IT services
Pilot A limited deployment of an IT service, a release or a process to the live environment.
Post-Implementation Review (PIR) A review that takes place after a change or a project has been implemented. It determines if the change or project was successful, and identifies opportunities for improvement.
Problem A cause of one or more incidents.
Problem Management The process responsible for managing the lifecycle of all problems.
Project A temporary organization, with people and other assets, that is required to achieve an objective or other outcome.
Remediation Actions taken to recover after a failed change or release.
Request For Change (RFC) A formal proposal for a change to be made.
Resolution Action taken to repair the root cause of an incident or problem, or to implement a workaround.
Response Time A measure of the time taken to complete an operation or transaction.
Risk A possible event that could cause harm or loss, or affect the ability to achieve objectives.
Service Level Agreement (SLA) An agreement between an IT service provider and a customer. A service level agreement describes the IT service, documents service level targets, and specifies the responsibilities of the IT service provider and the customer.
Service Level Management The process responsible for negotiating achievable service level agreements and ensuring that these are met.
Stakeholder A person who has an interest in an organization, project, IT service etc. Stakeholders may be interested in the activities, targets, resources or deliverables.
Supplier Management The process responsible for obtaining value for money from suppliers, ensuring that all contracts and agreements with suppliers support the needs of the business, and that all suppliers meet their contractual commitments.
Underpinning Contract A contract between an IT service provider and a third party.
User A person who uses the IT service on a day-to-day basis.

Table 7. Glossary.

5.2 List of Tables

Table 1. Post-Implementation Review Team Members.
Table 2. Initial, Projected and Real Outcomes of the Migration.
Table 3. Performance Metrics
Table 4. Costs.
Table 5. Milestones Completion.
Table 6. Customers and Users Satisfaction.
Table 7. Glossary.

5.3 References

Doe, J. (2012). "The Client". IT Service Migration. Risk Assessment Report.


Newsletter Sign Up

Sign up to receive occasional newsletters from Fast ITIL Templates. Registration will ensure you're notified of new templates and articles as they become available. We do not spam or share your email address with others.


Copyright © 2012 The Corporation, Inc.
Mark Piscopo