Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

How  Lessons Learned are Managed

GMAT lessons learned include things that we did well and should keep doing, and large scale things we should be doing to improve the software or our project.   Lessons learned are each discussed by the team and if we decide there is a real issue, we require a plan for improvement.   To make sure we are efficiently handling lessons learned, here are some high level guidelines for creating them.

What is a Lesson Learned

Lessons learned are issues that cause significant problems or could have caused significant problems, or are issues where we did something that significantly improved the software or our project.   Lessons learned require group discussion and probably a change in team habits, process or strategy.

Lessons learned satisfy one the following criteria:

  • Issue that is putting the project at greater risk than necessary
  • Issue that is causing significant inefficiency
  • Issue that is significantly lowering quality

What is Not a Lesson Learned

A lesson learned is not a minor annoyance, a tweak to an existing process, or something that can be resolved between team members in the everyday process of getting work done. Team members should bring these types of issues up at meetings, or work them among the team members involved.

A minor issue, (i.e.  not a lessons learned), satisfies one of these criteria:

  • Tweak to an existing process
  • Minor annoyance or gripe
  • Can be resolved by just picking up the phone, or discussing via email, or weekly meeting
  • Does not require significant change in habits or processes

Things We Should Keep Doing

  • [ JHE ] Assigning managers to oversee specific aspects of the release (code freeze, visual freeze, test freeze) helped make the release make steady progress 
  • [ JHE ] Continue using dashboards and tags to track the release progress and categorize the priority of different tickets towards the release
  • [ MES ] Start paperwork process at the start of development for the next release; mainly internally but be in touch with lawyers and others about any issues we anticipate. Main thing is to write a draft of the release contents section and keep track of contributors as we go along. In our tracking of progress paperwork should be a parallel path to the technical, in other words not in the line of progress between the various freezes (although technical milestones do help understand progress, I don't think the paperwork depends on the completion of any of them until we are staging for release and must have the final approval.

Things We Should Change

Do Better

  • [ XXX ] Insert text
  • [ XXX ] Insert text

Stop Doing

  • [ XXX ] Insert text
  • No labels