Sunday, July 15, 2012

Reflection: Lessons Learned vs. Retrospective – Which one will you implement?

Throughout my career, I’ve managed several projects and one of the final project rituals which is a must do is the notion of lessons learned.  Earlier in my career, I decided that I would make lessons learned part of a weekly status reporting exercise.  I’m not a fan of doing lessons learned at the end of the project and logging it to a repository which no one will use or look.  

This week, I’ve been thinking a lot about a notion of lessons learned – Are they really valuable?  Whether you do it at the end of a project or throughout, do we get the right lessons and is it agreeable with the whole team?  Here is a typical lessons learned exercise:
  • Project manager holds an hour meeting at the end of the project to discuss lessons learned
  • The team discusses what went well and what needs to be improved 
  • Project manager logs lessons learned in a log
  • The document gets filed in a repository
If you look at the above steps – how do you know if the entire team was engaged or whether the lessons learned will be reviewed by a subsequent project team?  These exercises are typically great for extroverts like me – Love to talk and love to throw suggestions – but what about the rest of the team?  

In the Agile world, Scrum introduces a retrospective ritual which is conducted at the end of the sprint.  During retrospective, the team provides feedback on the sprint and the process.  A way that our coach has trained us is by following the below framework:
  • Give sticky notes to each team
  • Scrum master places the following categories on a white board:  Went Well, Went Bad, One-Time Occurrences
  • When the team places the sticky on the board, they make sure their statement is unique and not a duplicate
  • At the end of 10 minutes, scrum master asks the team to vote by placing a dot on the sticky.  Each person will have 3 voting dots per category
  • Scrum Master discusses with team their three highest vote item per category and documents the results
  • Next – Scrum master places the following categories on the board:  Start, Stop, and Continue 
  • The process of writing, voting, reviewing, and documenting occurs as previous
  • At the end of the retrospective, the team makes the commitment to work on the highest vote and the document gets posted to a place where it is visible to the team
Sounds simple – Tools that are used are white board, sticky notes, and markers.  I have several introverts in the group and I see them engaged throughout the process.  There are two main things that allow this process to be effective:
  •  Reflection vs. Brainstorming – Each team member is empowered to write their thoughts on the categories.  Since this is a reflection exercise and not brainstorming, the fear is eliminated of talking to group on your thoughts.  It eliminates the feeling that you are being judged or getting cut-off.
  • Voting – The only items that are discussed are ones that have the highest votes.  This allows the group to focus and discuss items that are most important.  This process engages all personality types and doesn’t get overshadowed by the extroverts or the one that has a lot to say at all times. 
I’m sold on the notion of retrospectives – whether I run a project via traditional waterfall or agile, in order to get “lessons learned”, the retrospective framework provides the tools and techniques to effectively get team’s thoughts on how the project or sprint is going and what practices should start, stop, or continue.

Sunday, July 8, 2012

Top Gun Project Managers

Richard Morreale, our June PMI Triad guest speaker, discussed with our group on what it takes to be on the top of the PM profession.  Here is a recap:

·         Most projects fail due to costs, schedule, expectations, and positive experience
·         Reasons for project failure

o   Lack of agreed requirements

o   Users/business unit are not co-located

o   Lack of proper planning

o   Poor change control – Too bureaucratic

o   Inadequate cost control

o   No agreed process

o   Poor communication

o   Lack of focus

o   Lack of commitment

This was a really interesting point:  In the late 1970s/early 80s showed a project failure rate of 70%.  Companies spent millions on project management methodology, tools and technology, project planning and control, reporting, cost and schedule maintenance, risk and issue management, project metrics, and quality assurance.  In year 2000, the statistic of project failure rate was still at 70%. 
After spending so much money on training and tools, why were projects failing?  What does it take to allow projects not to fail?  Here is a laundry list of each PM to evaluate against.  If you are lacking in any of these areas – develop a personal development plan to work on improving:
·         Hard Skills – Only 20%! – What we learned when we got our PMP certification
·         Soft Skills:

o   Enthusiasm

o   Energy

o   Commitment to excellence and success

o   Passion

o   Positive Attitude

o   Approachable

o   Go the extra mile

o   Get it done attitude

o   A “no problem” person

o   Motivator

o   Communicator

o   Interpersonal skills

Richard ended his presentation with an idea of a PM to be a master of paradox.  For example – Have the ability to be a visionary but know when to go into details.  Another example is the ability to be both a manager and a leader. 
To learn more about Richard Morreale - go to