Post-Implementation Review Template

Purpose

This template is used to review changes after implementation, assess whether objectives were met, identify issues and lessons learned, and capture improvements for future changes. Post-Implementation Reviews (PIRs) support continuous improvement of Swedwise's change management process.

Instructions

1. Complete within [TBD - e.g., 7 days] of change implementation
2. Involve the change team: Include implementers, technical owners, and affected stakeholders
3. Be honest and constructive: Focus on learning, not blame
4. Capture lessons learned: Share insights with broader organization
5. Define follow-up actions: Address any outstanding issues or improvements
6. Update knowledge base: Add learnings to change management knowledge base

---

Review Information

Field	Details
Change Request ID	[CHG-YYYY-NNN from SW-IMS-FRM-011]
Change Title
PIR Date	[YYYY-MM-DD]
PIR Facilitator	[Usually Change Manager]
Review Participants	[Names of all participants in this review]

---

Section 1: Change Summary

Original Change Description:

[Brief summary of what was changed - from original Change Request]

Change Objectives:

[What were the intended outcomes? What was this change supposed to achieve?]

Change Type:

• Standard Change
• Normal Change
• Emergency Change

Original Risk Rating: [ ] Low [ ] Medium [ ] High [ ] Critical

---

Section 2: Implementation Review

2.1 Implementation Timeline

Milestone	Planned Date/Time	Actual Date/Time	Variance	Notes
Change Approved
Implementation Started
Implementation Completed
Validation Completed
Change Closed

Was implementation completed on schedule?

• Yes - On time
• Yes - Ahead of schedule
• No - Delayed (explain below)

If delayed, what caused the delay?

2.2 Downtime and Service Impact

Metric	Planned	Actual	Variance
Downtime Duration	[Minutes/hours]
Services Affected
Users Impacted

Was the actual impact within acceptable limits?

• Yes - As expected or better
• No - Greater than expected (explain below)

If impact exceeded expectations, why?

2.3 Resource Utilization

Resource	Planned	Actual	Variance	Notes
Staff Time	[Person-hours]
Financial Cost	[SEK]
External Support
Other

Was the change completed within budget?

• Yes - On budget or under
• No - Over budget (explain below)

If over budget, what drove additional costs?

---

Section 3: Objectives Achievement

3.1 Success Criteria Assessment

Were the change objectives achieved?

Objective	Success Criterion	Achieved?	Evidence	Notes
1.		[ ] Yes - Fully [ ] Yes - Partially [ ] No
2.		[ ] Yes - Fully [ ] Yes - Partially [ ] No
3.		[ ] Yes - Fully [ ] Yes - Partially [ ] No

Overall Objectives Achievement:

• Fully Achieved: All objectives met
• Mostly Achieved: Most objectives met; minor gaps
• Partially Achieved: Some objectives met; significant gaps
• Not Achieved: Objectives not met

For any objectives not fully achieved, what is the plan to address?

3.2 Business Benefits Realization

Expected Benefits (from original Change Request):

[List expected benefits]

Benefits Achieved:

Expected Benefit	Achieved?	Evidence/Measurement	Notes
	[ ] Yes - Fully [ ] Yes - Partially [ ] No [ ] Too Early to Tell
	[ ] Yes - Fully [ ] Yes - Partially [ ] No [ ] Too Early to Tell
	[ ] Yes - Fully [ ] Yes - Partially [ ] No [ ] Too Early to Tell

Unexpected Benefits:

[Were there any positive outcomes that weren't anticipated?]

Negative Consequences:

[Were there any negative outcomes that weren't anticipated?]

---

Section 4: Issues and Incidents

4.1 Implementation Issues

Were there any issues during implementation?

• No issues
• Yes - Minor issues, easily resolved
• Yes - Significant issues, required workarounds
• Yes - Major issues, nearly caused rollback

Issue Log:

#	Issue Description	Severity	Impact	Resolution	Resolved?
1		[ ] Critical [ ] High [ ] Medium [ ] Low			[ ] Yes [ ] No
2		[ ] Critical [ ] High [ ] Medium [ ] Low			[ ] Yes [ ] No
3		[ ] Critical [ ] High [ ] Medium [ ] Low			[ ] Yes [ ] No

Root Cause of Issues:

[What fundamentally caused the issues? Planning gaps? Testing gaps? Assumptions?]

4.2 Post-Implementation Incidents

Have there been incidents related to this change since implementation?

• No incidents
• Yes - see details below

Incident Log:

Incident ID	Description	Date	Severity	Status	Related to Change?
					[ ] Definitely [ ] Possibly [ ] Unclear
					[ ] Definitely [ ] Possibly [ ] Unclear

If incidents occurred, what corrective actions are needed?

4.3 Outstanding Issues

Are there unresolved issues from this change?

• No - all issues resolved
• Yes - see outstanding issues below

Outstanding Issues:

#	Issue	Impact	Owner	Target Resolution Date	Status
1					[ ] In Progress [ ] Planned
2					[ ] In Progress [ ] Planned

---

Section 5: Process Review

5.1 Change Management Process

How well did the change management process work for this change?

Process Step	Rating	Comments/Improvements
Change Request Submission	[ ] Excellent [ ] Good [ ] Fair [ ] Poor
Impact & Risk Assessment	[ ] Excellent [ ] Good [ ] Fair [ ] Poor
Approval Process	[ ] Excellent [ ] Good [ ] Fair [ ] Poor
Communication	[ ] Excellent [ ] Good [ ] Fair [ ] Poor
Implementation Planning	[ ] Excellent [ ] Good [ ] Fair [ ] Poor
Testing & Validation	[ ] Excellent [ ] Good [ ] Fair [ ] Poor
Rollback Planning	[ ] Excellent [ ] Good [ ] Fair [ ] Poor
Documentation	[ ] Excellent [ ] Good [ ] Fair [ ] Poor
Post-Implementation Review	[ ] Excellent [ ] Good [ ] Fair [ ] Poor

Overall Process Rating: [ ] Excellent [ ] Good [ ] Fair [ ] Poor

Process Strengths:

[What worked well in the change management process?]

Process Weaknesses:

[What didn't work well? Where did the process fall short?]

5.2 Planning and Preparation

Was planning and preparation adequate?

• Yes - Very thorough
• Yes - Adequate
• Somewhat - Some gaps
• No - Significant gaps

Planning Gaps Identified:

[What should have been planned better?]

Preparation Gaps Identified:

[What should have been prepared/ready that wasn't?]

5.3 Testing and Validation

Was testing adequate?

• Yes - Comprehensive testing
• Yes - Adequate testing
• Somewhat - Some testing gaps
• No - Insufficient testing

Testing Gaps:

[What should have been tested that wasn't? What tests were inadequate?]

Validation Process:

• Effective - Quickly confirmed success
• Adequate - Validation worked but could be improved
• Inadequate - Validation process had gaps

Validation Improvements:

5.4 Communication

Was communication effective?

Stakeholder Group	Communication Rating	Comments
Change Team	[ ] Excellent [ ] Good [ ] Fair [ ] Poor
Affected Users	[ ] Excellent [ ] Good [ ] Fair [ ] Poor
Management	[ ] Excellent [ ] Good [ ] Fair [ ] Poor
Customers	[ ] Excellent [ ] Good [ ] Fair [ ] Poor [ ] N/A

Communication Strengths:

Communication Gaps:

---

Section 6: Risk Management

6.1 Risk Assessment Accuracy

Were the identified risks accurate?

• Yes - Identified risks materialized as expected
• Mostly - Most risks were accurate
• Partially - Some risks missed, some didn't materialize
• No - Risk assessment was inaccurate

Risks That Materialized:

Risk (from Impact Assessment)	Did It Occur?	Was Mitigation Effective?	Notes
	[ ] Yes [ ] No	[ ] Yes [ ] No [ ] N/A
	[ ] Yes [ ] No	[ ] Yes [ ] No [ ] N/A

Risks That Were Missed:

[What risks should have been identified but weren't?]

Risks That Didn't Materialize:

[What risks were identified but didn't occur? Were they over-estimated?]

6.2 Risk Mitigation Effectiveness

Were risk mitigation measures effective?

• Yes - Very effective
• Yes - Mostly effective
• Partially - Some mitigations worked, others didn't
• No - Mitigations were ineffective

Effective Mitigations:

[What mitigations worked well and should be reused?]

Ineffective Mitigations:

[What mitigations didn't work and should be reconsidered?]

---

Section 7: Lessons Learned

7.1 What Went Well

What aspects of this change should be repeated in future changes?

Best Practices Identified:

[Practices that worked exceptionally well and should become standard]

7.2 What Didn't Go Well

What aspects of this change should be avoided or improved in future changes?

Anti-Patterns Identified:

[Approaches that clearly didn't work and should be avoided]

7.3 What We Learned

Key insights and learnings from this change:

Knowledge Gaps Identified:

[What did we realize we didn't know? Where do we need more expertise?]

Skill Gaps Identified:

[What skills do we need to develop for future changes?]

7.4 Recommendations

Specific recommendations for future changes:

Process Improvements:

Technical Improvements:

Competence/Training Needs:

---

Section 8: Follow-Up Actions

8.1 Immediate Actions

Actions required immediately to address outstanding issues or risks:

#	Action	Owner	Due Date	Status
1				[ ] Not Started [ ] In Progress [ ] Complete
2				[ ] Not Started [ ] In Progress [ ] Complete
3				[ ] Not Started [ ] In Progress [ ] Complete

8.2 Process Improvement Actions

Actions to improve the change management process based on this review:

#	Improvement Action	Owner	Target Date	Link to Process
1				[Which procedure/form to update?]
2
3

Submit improvement suggestions using SW-IMS-FRM-002 (Improvement Suggestion Form).

8.3 Knowledge Sharing

How will lessons from this change be shared?

• Update change management knowledge base
• Add to standard change procedures (if applicable)
• Present at team meeting
• Include in change management training
• Document in procedure/guideline
• Share in CAB meeting
• Other: _______________________

Knowledge Base Updated? [ ] Yes [ ] No [ ] N/A

Shared With: [Teams, individuals, or forums]

---

Section 9: Overall Assessment

9.1 Change Success Rating

Overall, how successful was this change?

• Highly Successful: Exceeded expectations; smooth implementation; all objectives achieved
• Successful: Met expectations; minor issues; objectives achieved
• Moderately Successful: Some challenges; most objectives achieved; lessons learned
• Unsuccessful: Significant issues; objectives not met; required remediation
• Failed: Change rolled back or caused serious problems

Rationale for Rating:

9.2 Would We Do This Change Again?

Given what we know now, would we still do this change?

• Yes - Definitely worth it
• Yes - Benefits outweigh costs/issues
• Maybe - Marginal benefits
• No - Not worth the effort/risk
• No - Should have chosen different approach

Explanation:

If we had to do a similar change again, what would we do differently?

---

Section 10: PIR Completion

10.1 Review Summary

PIR Completed By: _______________________

PIR Completion Date: [YYYY-MM-DD]

PIR Status: [ ] Complete [ ] Pending Follow-Up Actions

Key Takeaways (3-5 bullet points):

10.2 Approval

PIR Reviewed and Approved By:

Name	Role	Date	Signature
	Change Manager
	Technical Owner
	Service Owner (if different)

10.3 Distribution

This PIR has been shared with:

• Change Management team
• Change Advisory Board (CAB)
• Management Team
• Technical Teams
• Change Requester
• Affected Stakeholders
• Other: _______________________

---

Notes for Users

When to Conduct a PIR

Mandatory PIR for:

• High/Critical risk changes
• Emergency changes
• Changes that were rolled back
• Changes with significant implementation issues
• Changes that exceeded budget or timeline by >20%
• Changes requested by management or CAB
• Changes affecting SaaS platform or customer-facing services

Optional PIR for:

• Low-risk standard changes that went smoothly
• Routine changes with no issues

Timing:

• Initial PIR: Within 7 days of implementation
• Follow-Up PIR (if needed): 30-90 days post-implementation for benefit realization assessment

PIR vs. Blame

PIRs are NOT about blame. They are about:

• Learning: What can we learn from this experience?
• Improving: How can we do better next time?
• Sharing: How can we help others avoid similar issues?

PIRs should foster:

• Psychological safety: People feel safe admitting mistakes
• Constructive discussion: Focus on systems and processes, not individuals
• Action-oriented thinking: What will we do differently?

If someone made an error, focus on:

• Why was the error possible? (system/process gap)
• How can we prevent similar errors? (controls, training, procedures)
• NOT: Who is to blame?

Conducting Effective PIRs

Preparation:

• Review all change documentation (CR, impact assessment, implementation logs)
• Gather metrics (actual vs. planned time, cost, downtime)
• Collect stakeholder feedback
• Identify discussion topics in advance

Facilitation:

• Keep discussion focused and time-boxed
• Encourage all participants to contribute
• Capture insights in real-time (don't rely on memory later)
• Use "5 Whys" or similar techniques for root cause analysis
• Balance critique with recognition of what went well

Follow-Through:

• Document lessons learned while fresh
• Assign follow-up actions with clear ownership
• Share insights with broader organization
• Actually implement process improvements (PIRs are wasted if learnings aren't applied)

Common PIR Findings

Typical "What Went Well":

• Thorough testing caught issues before production
• Clear communication prevented confusion
• Good rollback plan provided confidence
• Cross-functional collaboration was effective

Typical "What Didn't Go Well":

• Inadequate testing (especially integration/performance testing)
• Poor communication to affected users
• Unexpected dependencies or interactions
• Insufficient rollback testing
• Overly optimistic timelines
• Inadequate understanding of current state before change

Typical Lessons Learned:

• Involve stakeholders earlier in planning
• Test in production-like environments
• Verify assumptions before implementation
• Communicate more than you think necessary
• Plan for worst case, not best case
• Don't skip rollback testing

Integrating PIR Insights

PIR lessons should feed into:

• Change Management Process: Update procedures, templates, checklists
• Training: Update training materials with real examples
• Knowledge Base: Build library of change patterns, solutions, and pitfalls
• Risk Assessment: Improve risk identification and estimation
• Standard Changes: Document successful patterns as pre-approved standard changes
• Continuous Improvement: Submit improvements via SW-IMS-FRM-002

PIR Documentation and Retention

• Store: In change management system alongside change record
• Retain: Minimum [TBD - e.g., 3 years] or as required by ISO audit
• Access: Available to all change management participants and CAB
• Summary Reports: Periodic summaries (quarterly/annually) of PIR trends and aggregate learnings

---

Document Control

Version	Date	Author	Changes	Approved By
1.0	[TBD]	Change Manager	Initial template creation	[TBD]

Next Review Date: [TBD]

Document Classification: Internal

Document Owner: Change Manager