Make Lessons Learned a Part of Your Culture

An organization with process maturity will close the loop on Lessons Learned.

By closing the loop, I mean that the organization will ensure the capture, distribution, and institutionalization of the lessons taught by the school of hard knocks.

While the Project Manager should identify and collect Lessons Learned, Quality Assurance should categorize and preserve them.  QA should take further steps to communicate the lessons.

First, leaving it to everybody to go searching the LL database does not work.  Like that will ever happen! Ha!

Instead, QA should sort the LLs by function and subject and distribute the information to affected functional managers across the organization.  This ensures that, for example, the Integration Engineers in different programs and at different locations receive the expensively acquired knowledge.  If the functional managers fail to communicate the lessons to their people, upper management should give QA the authority to do so.

Second, QA should incorporate applicable improvements to the Organizational Process Assets.  This way, QA does not merely deposit critical knowledge into the Tribal Knowledge Bank, but actually institutionalizes it.  This introduces accountability when QA audits process compliance.  It also allows the lesson to be moved to a section of the database that lists rationales for historical purposes.  Not every Lesson Learned needs to be researched for normal operations.

Note that this involves Change Control at both the project level and at the organizational level.

As an example, engineers delivered documents to a customer without the necessary review and approval of the Chief Engineer.  The incident led to rework and incorrect customer expectations.

Tribal knowledge had established a channel that would have ensured proper review before release.  However, new employees did not know it, and management had nothing in writing that allowed them to discipline experienced employees who knew better.

Engineering stepped in where corporate management had left a gap.  They instituted processes for document review and approval and for an engineering communications manager to coordinate release of documents to clients.

Thus, an incident led to a Lesson Learned.  The Lesson Learned led to policy and procedural changes.  The new practice became part of the formal procedures and did not get lost in a database that ever researched.

Copyright 2013, Richard Wheeler -- Permission granted for non-profit or personal use with a link to this post.

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e

Links to Management Resources

General Management Resources

• World Health Organization - Leadership and management topics
• Defense Acquisition University - Search engine for DAU resources
• Department of Energy - Directives, delegations, and requirements
• EverySpec - Collection of free US government (NATO, too) specs, standards, handbooks

Process Asset Samples and Templates

• Project Management Docs - PMBOK based project management templates
• Brad Egeland - Sample PM plans & templates, with links to related articles

Project Management Newsletters

• The Program Manager's Paper - Articles and links to articles useful to project managers

Project Management Resources

• Lessons Learned.info - Lessons learned (LL) in the context of project management (PM)
• Certified Enterprise Risk Manager® Academy - Risk-based problem solving & decision making, enterprise risk management: resources, training, certification, newsletter
• Herding Cats - Informative blog entry on uncertainty, risk, and risk management

Project Management Tools

• PM Tools Review - Project management & PM-related tools and services

PM Social Media and Online Study Groups

• Google Plus - Project Management, PMI, PMP Certification - Oliver Lehmann's outstanding Google+ group for PMP test prep, Agile, PM news recommended articles, almost everything PM
• PM Lessons Learned - Conference calls for PMP exam study, job hunting, and best practices every Tuesday plus the first through third Thursdays, 9 PM New York time; Archives of presentations and also a discussion capability are available at http://groups.yahoo.com/group/pmlessonslearned/

Technical References

• Department of Energy  - References, regulations, and requirements
• University of Maryland Space Systems Laboratory Spacecraft Design Reference Library
• EverySpec.com - Government and military standards, specifications, handbooks, and documents

PM Blogs

• The Southern Project Manager - Harry Hall's practical project management insights and tips

PM Study and Free Resources

• PM Study - Free Simulated Practice Test, Sample Guides and Podcasts, Work Experience Hour Calculation Tool
• PM Success - 400 Questions of the Day
• Head First Labs - Free PMP Practice Exam
• Simplilearn - Articles and instructional videos

Agile Study and Free Resources

• ScrumStudy - Free learning resources (including the ScrumStudy BOK) - Hat tip to Kylie Wilson in the Comments.

This is a work in progress. Add links to your favorites in the comments, below, and I'll add them.

Politics and the Project

Question:

Cultural norms include a common knowledge regarding how to approach getting things done. It also takes into account formal and informal leaders who exist in almost every organization. Most organizations have developed unique cultures that manifest themselves in many ways. Which attributes of a company culture is NOT consistent with the discussion of cultural "norms"?

A. shared vision, values, beliefs, expectations
B. policies, methods and procedures
C. consistent political views
D. view of authority relationships

I was given answer as "C".

Shared vision, values, beliefs, expectations; political views; and views of authority relationships are all cultural factors. Each is a valid topic of discussion to the degree that it affects the project and the organization.

Political views include both those related to national government and those related to the company goals, culture, and hierarchy.

Western employees are taught that religious and political views are inappropriate topics. However, Political Correctness (PC) is alive and well. For example, some countries suppress "subversive" or "counter revolutionary" political views. This can affect project success.

Even in the USA, many employers will fire you if you oppose certain movements such as homosexual marriage or affirmative action (discrimination in favor of disadvantaged minorities). The reasoning goes like this:

• Diversity has value.
• People who oppose a PC (politically correct) view create a workplace that is hostile to favored minorities and an atmosphere where conflict may arise.
• This hurts members of those minorities, limits diversity, subjects the company to legal liability, and disrupts teamwork.
• Thus, inconsistent political views concerning some topics can hurt the project.

You don't have to like PC, but it exists. PMs have to deal with it and sometimes even enforce it.

Consider a different meaning of "political views:" Every organizational hierarchy has "office politics." Competition, conflicting opinions, and popularity can affect whom you can rely on. A stakeholder or resource may oppose you, or others may not support your resource. Such factors affect how one succeeds in getting things done.

We may say (C) is an inappropriate topic, but political views are certainly a part of cultural norms, and some version of PC is enforced anywhere you go. Moreover, the question is not, "what is appropriate," but "which attributes of a company culture is [sic] not consistent with the discussion of cultural 'norms'?"  (C) cannot be correct.

While culture may affect policies, methods, and procedures, they are classified not as part of the enterprise environment (that is, external factors that affect the project), but rather as organizational process assets. (B) is correct.

Copyright (C) 2013, Richard Wheeler. Permission granted for use not involving publication.