Click here to load reader
Upload
jaiveer-singh
View
23.163
Download
3
Embed Size (px)
Citation preview
Conducting a Post–Mortem Analysis
Learning from Projects
Presenter -Introduction
www.singhjaiveer.blogspot.com
www.project-management-practice.blogspot.com
@ singhjaiveer
http://www.slideshare.net/Jaiveer
Jaiveer Singh, PMP
A practitioner of Analytics, Information Modelling, Enterprise Project\Program\ Portfolio Management, Operational Productivity & Execution Management.
He has also setup PMO groups, PM Forums and led enterprise project management products implementation initiatives at global scale for MNCs.
He also writes articles/ blogs on project management, business intelligence, social analytics and conducts workshops on productivity & planning related software products like MS Excel, MS Project, Axure RP, Mind Map etc for the management community.
Session ContextThe creation of temporary enterprises for project-based work has become an increasingly salient feature of the new economy.
•These organisations specialise in execution of certain type of projects while leveraging their unique competencies, industry best practices and learnings from their past projects.
•Often learnings from firms' past projects execution acts as most important key differentiating factor while positioning their organisation as preferred partner/ vendor.
Leveraging Experience as Key Differentiator
Post Project Analysis
Post Project Analysis
What is a Project?
When Project is considered finished ?
What is involved in Analysis?
Apollo 11- Project
Neil ArmstrongJuly 20, 1969
We can learn from those who have gone before us.
Projects comes in all sizes & complexities
Projects comes in all sizes & complexitiesProject 1
Project Title/ Award date
Standard Operating Environment (SOEasy), Feb 2008
Scope Standardize desktop, network and messaging components for 60,000 public officers across 74 government agencies.
Industry / Type
Information, Communication & Technology
Timelines Mar 31, 2011- Delayed
Budget S$ 1.3 billion
Client IDA, Singapore Government
Vendor HP – EDS, Singapore
Project 2
e-government system , July 2006
It will provide information about services being provided by the government to the public in an easily accessible manner.
Information, Communication & Technology
Completed
USD $ 3.4 m
Maldivian government
NCS, Singapore
Project 3
Commercial Building, Apr, 2011
Construction of a commercial facility at Orchard Road having 12 levels above ground, one level below ground, and a gross floor area of 20,072 m2.
Construction, Commercial Building
Dec 15, 2013
8.3 billion Yen
RE Properties Pte. Ltd, Real Estate CompanySHIMIZU CORPORATION
Project Journey – What’s your experience
Were objectives clearly defined?Was journey planned well?Did you had your plans approved?Did you met your milestones on time?
What was your resources burn rate?What unexpected events happened?How many issues impacted project?
Budgets Over
What worked What didn't
Post Project Analysis
Did you find any learnings for future???
Game Over!
Retaining knowledge from Experience
Analyze
Identify
Document
Archive
Accessing past learnings- Project Library
Search
Category What Worked and What Didn't Work Learning DescriptionScope Mgmt WBS based techniques helped to ensure all work scope is accounted for
planningSoW must be detailed enough covering main & supporting work required to execute project deliverables
Resource Mgmt Required skills & compentency for team was not estimated properly which affected work quality and delayed deliverables completion
Key resources comptencies and availability should be checked with resource manager for entire project duration
Procurement Mgmt Decision to sub-contract one part of develolpment was taken too late which caused delays as vendors asked for min. lead time to setup team
Review of internal competencies and available capacity suiting project timelines must be done in early stages of projects to get job executed from outside in time
Issues Mgmt Many assumptions were not validated with stakeholders which caused rework later.
All positive & negative assumptions must be checked with stakeholders and data for similar projects using organisation project archives
Project Metrics – Run Rate/ Burn Rate
How well you did last time?
Experiential Learning
Experiential learning is the process of making meaning from direct experience.
Experiential learning is learning through reflection on doing.
While it is very effective way of learning, it comes with its associated high level of costs, therefore it is very important that we learn from others experiences and document our own experience for benefit of others.
So there is a need of a structure process to gather learnings from any experiences
Identify and Capture Project Learnings
Post Mortem Analysis
Post Mortem Analysis
A postmortem is both a process and a document (set of documents).
Setup Collect Data Discuss & Build Consensus
Consolidate Outcome
Recommendations
Analysis Summary/ Recommendations
Preparing for MeetingBefore Meeting1. Send out copies of mini, functional post-mortem results for
review.
2. Ask for people to send list of top issues to discuss—should be cross-functional issues that require the whole group in order to be resolved.
3. Send out agenda with a list of potential topics.(a) Prioritize topics to discuss.(b) Discuss each topic; emphasize what to do in future.(c) Summarize and prioritize recommendations.
4. Reserve large room, tape flipchart paper to walls.
5. Compose list of discussion topics.
Meeting- PreparationThe post-mortem meeting provides a chance for the team to get together and work through the important issues to create an action plan that will improve the development process for the team.
Meeting Length : 4 hours or less, Schedule 2-3 meeting if required with focus group
Room : Choose a room with a round or oval shaped table so people can easily see each other and no one appears as the boss at the table’s head.
Who Should Attend: Anyone who was involved in the project should be invited. If inviting everyone makes the group too large, consider having mini-postmortems with people who worked on specific parts of the project.
Facilitator: Ideally it should be someone who was not involved in the project and has no reason to be involved in the discussion.
Recorder: Taping large sheets of flipchart paper on walls or using white boards are very effective for recording information. This way everyone involved in the discussion automatically focuses on the recorded information (instead of on each other).
Analysis Guidelines
Cover all key disciplines
Scope Management
Issues Management
Risks Management
Communications ManagementProject Participants
Stakeholders
Be Inclusive
Analysis GuidelinesBe Self Critical
Participants should check their egos at the door.
The post-mortem will necessarily find “flaws” with processes and team members who executed (or failed to execute) aspects of the project.
Analysis Guidelines
Focus on issues and not on people
Be Professional
Discussions should cover a broad range of team issues anddynamics, from process to product issues.
However it should not under anycircumstances become personal. Most projects have enough elements that needto improve that any mention of names or specific instances can best be skipped
Analysis GuidelinesBe Factual
Documentation and data should be included in both the discussions and in the final report. Future projects will find it valuable to learn from project metrics and other project management data.
The post-mortem provides a good process for gathering that information and including it in the report.
Be Brief
Suggestions and commentary in the final report should be brief and agreed to by broad consensus. Although dozens or more issues will surface during the post-mortem process, the next project will benefit more from a small number of very specific suggestions.
Managing Meeting During Meeting
1. Start with reviewing and ranking topics to be discussed.
2. Begin with the top issue and record what went wrong as well as how to do it differently in future.
3. Stop “wrong” discussion after 5-7min. and start asking what to do differently.
4. Check that all functional groups have contributed.
5. Save time at the end to prioritize recommendations.
Discussion NotesTimeline and Resources:
This includes who was involved and amount of time each person was involved in the project.
What Went Poorly/Should Be Done Differently?
If the list of what went wrong was collected ahead of time, go over it now and ask for anyadditions. Once you have the list generated, the facilitator will need to prioritize the list so that the most important issues are discussed first (in case you run out of time or energy).
What Went Well
The team simply needs to list what participants thought went well and record why it was successful.
Recommendations:
Looking back at the information recorded for both the “good” and “bad” discussions summarize what the group would recommend for future Projects.
Case Study - Outcomes
Microsoft- Case StudyMicrosoft is the one of highly successful global software product company. Project Name: MS Word Version 6 - Development
Key Findings from Post Project Analysis
Teams participating in post mortem analysis meeting
1. Word 6 development2. Word 6 program management3. Word 6 testing
Microsoft- Word 6 Case StudyWord 6 development
* “Scheduling on [Word 6] was not done well and was seen later in the project as totallyunrealistic. Milestones were left before they were really complete. This meant carryingbugs and work from the pervious milestone over to the next. By the time we realizedwhat shape we were in it was too late to make adjustments. [Word 6] milestones werelonger milestones than on any other project, this should have been an indicator thatthere was a bigger problem.”
* “Many of the problems with proposed features do not become obvious until development has starting working on it. By this time it is usually later in the project and program management has very little flexibility redesigning a feature.”
Microsoft- Word 6 Case StudyWord 6 program management
* “The project was too large with too many primary goals. We ended up touching toomany areas of the product without consciously realizing it at the outset of the project.There were times individuals got so caught up in their feature, that it was hard toremember the priorities for the project as a whole (“what did I spend four days on thatfeature for?”). This highlighted the fact that the decision making process was not welldefined. There was no one key person that would make the final decision when the teamcould not reach consensus on a problem.”
* “There were two principal reasons we were six months late in shipping: the inability to cut features and not know what to cut. We should have been more ruthless about cutting features in order to meet the schedule. People knew we were slipping (it was obvious after we missed the first Major Milestone), yet no one wanted to cut features. Development was concerned that it would hurt morale. When in fact, morale was hurt more by not being honest about the slipped date.”
Microsoft- Word 6 Case StudyWord 6 testing
* “The size and complexity of [Word 6] had changed dramatically from WinWord 2. 0. Yetit was never acknowledged that different processes and tools were needed to managesuch a large project. It was planned and managed as a small project. Once again, careshould be taken on the front end instead of full steam ahead and hoping that it will allwork out.”
* “The schedule became everything. Individuals across all groups knew that the schedule was a myth but all were discouraged from communicating any slips in their work. Test knew where we were at with bugs, but this was not broadly communicated. Development Leads did not share this information with their team members because it was seen as de-motivating. As a result of this schedule deception, poor decisions were made (i.e., quick fixes instead of well thought out changes, other tradeoffs were managed very poorly) based on inaccurate schedule information
Group Activity
PlanningResourcesProject Mgmt/ SchedulingDesign & SpecificationsCommunicationTeam/ OrganizationProductManagementTools & PracticesGeneral
Scope Mgmt Time Mgmt Quality Mgmt
Cost MgmtHuman
Resources Mgmt
Communication Mgmt
Risks Mgmt Procurement Mgmt
Integration Mgmt
Identify top 10 list of things which often didn’t went well in your projects and top 10 things which worked for your projects
Seat No Group Topic
2-9 1 Scope Mgmt
10-17 2 Time
18-25 3 Quality
26-33 4 Cost
34-41 5 Resources
42-49 6 Communication
50-58 7 Risks
59-66 8 Procurement
Group Activity
Presenting Group Findings
Each group representative present their list of top issues & tips
www.project-management-practice.blogspot.com