Problem:    How do we translate Lessons Learned into concrete actions to improve processes and projects (best practices)?

Team:

Members: Nathan Reimer, RJ Davies,  Greg Menzenski, Andy Slusar

Assumptions:

  • Lessons Learned repository exists
  • Best Practices are not limited to Project Management Lessons Learned

Approach:  

Take Lessons Learned and modify Best Practices and Standards by Project Type


 


Project Standards:

  • CPMM
  • SOW
  • WBS
  • ENV
  • Equip
  • Communications Plan
  • QA Standards
  • Development Standards
  • Other Standards

Project Types:

  • Small Projects
  • Upgrades
  • Large Projects
  • Custom Development
  • Vendor Product Implementations

Recognized that standards and best practices can be either public or private

  • Some sensitive material may not be appropriate for public consumption
  • Need mechanism to store and share both types of LLs

Lessons Learned should include all aspects of projects

  • Analysis processes
  • Development processes
  • QA Processes
  • Implementation processes

Process:

Best Practices

  • Form Working group to collect Project Best Practices and create a first draft in confluence.  We recommend the Project Management SIG be this working group.
  • Best Practices should include any project related templates. Practices and templates should be categorized by project type when applicable.
  • PM SIG reviews LLs periodically
  • PM SIG agrees on best practices changes
  • Implement changes

Mentoring program:

  • Create Project Catalog - List of who did what project by project type and date.
  • Encourage PMs to conduct a knowledge transfer session, when beginning a project, with a PM that has done a similar project recently.

Recommended next steps

  • Form PM Sig  and make the LL process described above part of its charter
  • Establish governance process for PM SIG and determining best practices
  • Collect Best Practices
  • Collect Project Templates by project type
  • Create Project questionnaire/checklist by type
  • Create process for periodic review of LLs
  • Create Mentoring Program
  • No labels

1 Comment

  1. user-60629

    Comments and questions from Stephanie and Butch...

    • Love the robustness of the Project Management flavor of the process you have mapped out.  It's very clear it can be a path to increase the effectiveness of our PM practices... or at least increase the chances that our learnings might lead to improved PM practices.
    • As was mentioned in the Session 2 BP team feedback, improvement of other (non-project) practices is less clear.  Will there be separate/informal processes/SIGs for non-PM BP's?  What is the proposed membership of the BP SIG (beyond PM SIG members)?
    • Suggestions for improved practices will be valuable for PMOs, Projects, Divisions, Departments, Programs, and even individual contributors.  Do you have any thoughts about elaborating further on the communication of such suggestions to stakeholders other than the PMOs?
    • It seems the PM SIG will filter Lessons Learned and periodically suggest some best practices.  What of the valuable lessons not "picked up" by the PM SIG?  Assume that all lessons learned possibly translate to better practices on someone's part. 
    • Can you elaborate further on the OIT PMO initiative to establish a PM SIG and how this proposal might be included in their charter?
    • How do your processes address the following:
            * Lessons Learned performed several times throughout a project's life cycle.  Some lessons are relevant to the project or to a smaller group of stakeholders. 
            * Some Lessons Learned may be more time sensitive than others... for example, sometimes a lesson learned needs to be acted upon quickly and needs to be "fast-tracked" into a BP 
            * Some may include suggestions for improvement to stakeholders outside of CIT. 
    • Please spell out acronyms (for example, some folks might not know what "ENV" stands for.)
    • Will Best Practices only result from information stored in the Sharing Outcomes repository?
    • Does the Sharing Outcomes repository contain sufficient information to "feed the Process"?  For example:
            * If the "Group" for the LL artifact is "Project Management", would it be useful to specify "Phase" to distinguish LL's from the analysis from LL's from development, etc? 
            * Anything else missing, such as "Project Type" that separates Small Projects from Capital Projects from No Project?
    • Suggest that BP team review the repository with the "feed the Process" in mind, also make this one of the first agenda/action items for the new BP SIG.  Perhaps the first "Best Practice" is how to use the Sharing Outcomes repository?
    • Where will BP's "live"?  Will "Associations" to other SForge items be encouraged?
    • Say more about "public vs private" LL's... seems that anything not considered "public" may require multiple repositories, each secured from one and other and even having more granular levels of security within the individual repositories.