1. Goals
1.1. Understnanding what happened and why
1.2. What to do differently to improve
1.3. What to keep as good practice
2. Process
2.1. Preparation for retrospective session
2.1.1. PM
2.1.2. Project timeline
2.1.3. Project WBS
2.1.4. Actuals and deltas
2.2. Retrospective workshop
2.2.1. Project team & Engagement
2.2.2. Optionally a session with customer
2.2.3. Review timeline & map events
2.2.3.1. e.g. actual higher - detail the reasons
2.2.4. Project health excercise
2.2.4.1. collect team feedback how project was doing during execution
2.2.4.2. understand the link between project events and status across timeline
2.2.5. Review planning vs actual
2.2.5.1. SoW definintions
2.2.5.2. Detailed project plan
2.2.5.3. Deltas on resource demand
2.2.5.3.1. Actual vs SoW vs Plan
2.3. Produce retrospective report
2.3.1. PM
2.3.2. Detailed view
2.3.2.1. As defined in outputs
2.3.2.2. Use AKS practice documents
2.3.3. One-pager
2.3.3.1. Slide
2.3.3.2. What to improve
2.3.3.3. What to keep
2.4. Communication
2.4.1. Present in last project review meeting
2.4.2. Communicate to stakeholders
2.4.2.1. PMs group
2.4.2.2. Engagement group
2.4.2.2.1. Country
2.4.2.2.2. Product / EMEA
2.4.2.2.3. CoP
2.4.2.3. Management
2.4.2.3.1. Benelux
2.5. How to do something afterwards?
2.5.1. PMs
2.5.2. Engagement
3. Rules
3.1. When to apply retrospective
3.1.1. Project closing meeting is mandatory for all Lead projects > 100kEUR
3.1.2. Project value
3.1.2.1. bigger that 150kEUR?
3.1.3. Complexity
3.1.4. Single or Programme
3.1.5. Customer
3.2. Where to store outputs
3.3. Relationship with Lessons Learned
4. Team
4.1. Core delivery team
4.1.1. PM
4.1.2. Solution Architect
4.1.3. Lead Implementation Consultant
4.2. Engagement team
4.2.1. Engagement lead
4.2.2. Technical lead
4.2.2.1. The person bringing solution insight during pre-project steps
4.2.2.2. Work breakdown
4.2.2.3. Estimations
4.3. Presales
4.3.1. perform high-level solution scoping
4.3.2. Account manager
4.4. Customer
4.4.1. Separate session, with project team
4.4.2. Depends on customer
5. Outputs
5.1. Successes and Failures
5.1.1. What to share for future projects
5.1.2. What did we learn
5.1.2.1. Could be anything relevant
5.1.2.2. Solution
5.1.2.3. Communication
5.1.2.4. Stakeholders
5.1.2.5. ...
5.1.3. What problem does it solve
5.1.4. How?
5.1.5. Feed into the Lessons Learned DB
5.2. Timeline
5.2.1. Key project events
5.2.1.1. Successes
5.2.1.2. Issues
5.2.1.3. Product-related events
5.2.1.3.1. New releases
5.2.1.3.2. Now products in scope
5.2.1.4. Changes
5.2.1.5. Team members mob/demob
5.2.2. Project 'health' across time
5.2.2.1. Emotional Seismograph
5.2.2.2. -10 (total failure) to + 10 (great success)
5.2.3. Group the findings
5.2.3.1. Events vs project 'health'
5.3. Work plan
5.3.1. Project planning
5.3.1.1. SoW work packs
5.3.1.2. Detailed planning during initiation
5.3.2. unforeseen events
5.3.2.1. In which area
5.3.2.2. Why was it missed
5.3.3. Work packs definition
5.3.3.1. Gaps
5.3.3.2. Not clear, need change
5.3.3.3. Things not required
5.3.4. Assess alignment with Advantedge
5.4. Estimations
5.4.1. Detailed plan vs SoW breakdown
5.4.1.1. As planned at start
5.4.2. Actual spends vs SoW WP
5.4.3. Actual resource demand vs SoW
5.4.4. Analyse deltas
5.4.4.1. Map to project events