General Rules
- Lessons Learned sessions tend to bring out the negatives, be sure to ask "What Went Right"
- Conduct Lessons Learned meetings
- Depending on the size and type of project there can be one or more LL session.
- Use survey questions (recommended below) to solicit feedback
- Meetings and questions should address both PM and non-PM Lessons Learned
Before the meeting
- Use online anonymous survey to collect feedback, distill down to areas of discussion and focus actual meeting(s) around identifying specific actions to follow
- Prepare the team in advance of the meeting for what will be discussed
- Take steps to ensure that the meeting will be comfortable and non-confrontational
- Involve a "scribe" or two to ensure that all notes get captured - the PM could be considered for this role
- Project Manager of the project should not be facilitator of the lessons learned - get another PM or strong facilitator
- Who is invited? Should include team members, customers, other stakeholders
- Try to plan to feed people (when possible), breaks may be needed as well
- Encourage creative thinking - make it a relaxed environment for having the discussion - go to a less familiar, interesting place
During the meeting
Introduction
- Be clear about the agenda, what the goals are for the meeting
- Develop a list of ground rules - have the team develop these (suggested set - be nice, don't blame, be constructive)
- Hand out set of topics and ask team which items they would like to talk about - go around the table to discuss - make sure each person gets a turn
- Start session with an overview of the project - goals, what we accomplished, any particular challenges encountered
During discussion
- Focusing the discussion around actions/solutions rather than rehashing the past
- Identify top items to be worked on
Closing
- Identify clear actions and owners where appropriate
- If you use a meeting to collect the feedback, save a period of time at the end to focus on identifying solutions for the most important issues
After the meeting
- Followup on actions agreed upon
Other considerations
- Start out focusing on the positive lessons learned - what went well
- Be prepared to discuss specific problems (problem, perceived cause, what should have been done differently)
- For large projects, don't do it only at the end of the project - do LL at various key milestones
- Develop standard LL templates for online surveys
You can conduct surveys using questions selected from the following
Sample Questions for Lessons Learned Sessions
Mid-Project Lessons Learned
- What is going well that we want to continue?
- What isn't going well that we want to fix?
- What can we do to improve?
Key End of Project Questions
- General
- List top significant project successes? (keep to a manageable number)
- What obstacles or unanticipated circumstances made it difficult to complete the project?
- Based on what you know now, what should have been done differently in this project?
- Communications
- Were communications adequate in all activities? (right time, right audience, right information, right type) If not, in what ways could communications be improved?
- Was documentation appropriate, timely, and clear? If not, what should be included for future efforts?
- Project Management
- What value did project management bring to the project?
- Project Planning
- How well was the project staffed to complete the project?
- How well was the project planned?
- How well were roles and responsibilities defined?
- How well was stakeholder input factored into the project planning process?
- Project Execution
- How well did we execute according to plan?
- How well were the stakeholders involved in the execution of the project?
- How well were issues resolved?
- How well did the teams/sub-teams work together?
- Testing
- Was adequate testing performed (if applicable)? If not, what should be done differently next time?
- Cutover
- Was cutover planned well? Executed well? If not, what should be done differently next time?
Additional questions you may want to consider
- Project Planning
- Was the project plan realistic or unrealistic?
- Did the planning effort include key stakeholders?
- Were all major activities accounted for?
- Did the individual team members responsible for the work provide the estimates?
- Were appropriate staff involved in the planning effort?
- Do you believe the technology PM applied provided a better ulimate outcome for this project?
- Communications
- Were communications effective?
- Were meetings effective?
- Were expectations clear?
- Did you know where to go to get information about the project?
- Did communications go to the right people, at the right time?
- Were communications with our consultant effective?
- Did we escalate effectively and at the right time?
- Were issues dealt with effectively?
- Staffing, Roles, and Responsibilities
- Were people appropriately assigned to the project?
- Was staffing sufficient?
- Were roles and responsibilities clear?
- Did team members and stakeholder fulfill their roles appropriately?
- Was leadership and governance effective?
- Have you participated in this type of technology project before?
- Project Execution
- Was the project executed according to plan?
- Was there an appropriate level of commitment and urgency?
- Was change management performed appropriately?
- Was risk management performed appropriately?
- Was issue management performed appropriately
- Would you recommend this technology PM service to a peer?
- Was the project flexible enough to adapt to unforeseen circumstances?
- Did the project unduly stray from identified goals and objectives?
- How well were scope changes managed
- Teamwork
- Did the teams/sub-teams work effectively together?
- Did the teams share a common goal/mission?
- All stakeholders were appropriately engaged, involved, and available?
- Cutover
- Was the cutover successful?
- Was the cutover well planned?
- Were cutover communications effective?
- Anything else?
- What tools or techniques worked well?
- How well did the project meet objectives?
{"serverDuration": 83, "requestCorrelationId": "f111da8b64d0b4cf"}
6 Comments
user-60629
Comments and questions from Stephanie and Butch...
We looked at the surveys/checklists from the perspective of several points-in-time during a CPMM project lifecycle (closeout, initiation, mid-project/at milestones)... please see comments associated with each deliverable/point-in-time below and consider if there should be different checklists/surveys to fit similar points in a Scrum project (perhaps interview someone familiar with Scrum and see what they have!).
1. Project Initiation
Need? Pre-meeting survey
Need? Before meeting checklist... suggested items: review LL's & BP's with prior PM, prior team members
Need? During meeting checklist (agenda?)
Need? Post meeting checklist
2. Mid-Project (at Milestone)/Daily Scrum (these probably are different enough to need different checklists/surveys)
√ Done! Pre-meeting survey... another suggested question: "what do we need to do to prepare for the next phase of the project?"
Need? Before meeting checklist
Need? During meeting checklist (agenda?)
Need? Post meeting checklist
3. Project Closeout/Retrospective
√ Done! Pre-meeting survey... question: should there be separate surveys, i.e. one for PM, one for "other"?
√ Done! Before meeting checklist
√ Done! During meeting checklist... question: what does the agenda look like to conduct a meeting to "focus actual meeting around identifying specific actions to follow"?
√ Done! Post meeting checklist (PMI suggestion: have resource managers review LLs)
user-60150
What about non-project based use of these surveys/checklist (ie. workgroups)?
user-60150
Is there potential/need for capturing "one off" questions for special future surveys?
user-60150
Can we recommend CIT PMO adopt a survey tool (would help facilitate use of pre-made templates)?
user-60150
Who else might find these tools useful (ie. CUFA)?
Stephanie P. Herrick
On 02/03/09, Mike Scullin provided the following feedback in response to the LLWG Facilitation Team "Adoption Proceedings" meeting notes:
In the two LL sessions I've been in as a tech resource, the main difficulty I saw was in getting the facts straight. Both sessions were about production failure incidents. Both returned an approximate version of the facts, and an incomplete, although very valuable, set of recommendations.
Each person involved in the incident had a different view of what actually happened, and what the immediate cause was. There were multiple views of what the effects were. Naturally, there were also multiple guesses as to how to prevent recurrence.
I believe the same principle applies to project work.
Without insuring you have the facts clear (logs, emails, notes, samples of output, reconciling all viewpoints, etc.) you can't proceed to any kind of rational conclusion. Going ahead without knowing what occurred is a waste of time.
This is an extremely difficult, but vital part of the analysis.
Ask what was done, and what resulted, over and over, until you get a scenario everyone can accept as valid. Then you can begin to draw conclusions that mean something. This is the true skill involved in LLWG facilitation.
Does your method include reporting a discussion of "what might have helped but would be too expensive to implement"? This has value in that the cost of such things may drop in the future.
Hope this helps,
Mr.Mike