The Lessons Learned Lie

It is likely that every organization has some type of lessons learned methodology in place to assess previous projects. Output of this process is assumed to be positive changes in the way future projects are handled. Some may call this activity project postmortems, however the objective is the same; to identify areas for improvement and to take note of what worked well. Do keep in mind that a postmortem should only be considered a subset activity in an ideal lesson's learned framework.

Most organizations will minimally capture the most obvious project challenge areas via a lessons assessment. Some will implement changes to those challenges and others purely retain a learning for future reference. The more in depth challenges tend to remain elusive to most organizations lesson's learned process, remaining undiscovered because the process to uncover them was not comprehensive enough. In the majority of cases either the lessons learned depth is not sufficient to expose low level systemic issues, or many of the learning's never lead to a positive change in future projects. Where does your organization stand on the quality of lessons learned?

The practice of lessons learned in a New Product Development process is not an indicator that an organization's development process is optimized or even close to optimized; believing otherwise is one aspect of the "lessons learned lie".

The overall effectiveness of the learning's process varies greatly, with most agreeing that there is a large gap between what is being done and what could be done. A lack of time is the primary reason that I hear for limited quality of lessons learned. This is really more of an excuse than a reason. The fact is if there is time for unknown challenges to impact projects in ways that can't even be fathomed, there is certainly time to learn about and fix them. Not enough time to properly assess a project and make changes is another facet of the "lessons learned lie".

Effective top down support of a lessons learned strategy comes down to an unreserved sponsorship of a continuous improvement culture and mindset. Either an organization is doing it, or they are talking about doing it. One provides visible results Lessons and the other is a smoke screen promising better results tomorrow, a tomorrow that never comes. Management support of a high quality continuous improvement environment will be rewarded with a never-ending stream of incremental improvements in project execution.

Toyota has set the standard for making lessons learned work in auto manufacturing. Consider setting a new standard for lessons learned in your organization by means of this clear-cut leadership attitude: positive emphasis on the value of thorough learning's and their application to continuous improvement. If competition is whittling away an organizations future, it's time to come to terms with the "lessons learned lie". Is your organization up for the challenge in revving up lessons learned to become a major player in continuous improvement?

Case Study: Discovery & Solution

The following describes a case study where formal discovery was utilized to identify the unknown challenge areas within a NPD team.

Situation Appraisal
A product development organization of a large US based semiconductor company was interested in opportunities to provide improved project predictability, a higher throughput and improved first time success. The expectation was that Test, Product Engineering, packaging, project management and design must reach a higher level of alignment to objectives in order to achieve this heightened productivity and the minimization of silicon spins. The business motivation was purely a reduction in time to revenue.

Potential deliverable/receivable disconnects within design, as well as to their product development partners were identified as the primary focus for improving the efficiency of the overall NPD team execution. Projects were progressing at a generally acceptable level; however, there was a desire to identify opportunities to step up the productivity of the team. There were well known issues to be resolved in addition to an emphasis upon finding unknown challenge areas that needed to be understood and resolved. Indications of unknowns were displayed as expectation disconnects between individuals as well as recurrent project redirection that would divert the team from the mainstream execution plan.

Download Full Case Study from the White Paper page at Jorvig Consulting's website.

Managing Towards Change - the Basics of Addressing an Issue

Making a change to address an workflow issue can be a fairly straightforward process, assuming some basic concepts are followed. A change activity must start off with a clear objective; be careful to keep any bias towards solution out of the objective. An objective must be purely results oriented such as "reduce requirements closure time by 30%" or "implement a scope change process that formally addresses any change in requirements and provides continuous clarity of requirements to the team".

People will be the most challenging aspect of a change because of their emotions, notions, passions, fears, opinions and motivations. Additionally each person is a firm believer that they have the right solution to what's ailing the organization. Your mission is to align the majority of them to a common solution, one that they believe in. Failure in achieving this and any change is destined for the change graveyard. Inclusion over exclusion of individuals must be a priority, no matter how painful that may be. The pain of dealing with those excluded will be far worse later on than it will be by engaging them from the start.

Another major step is clearly identifying what it is that you are doing now; that is what is the current process of today. One of the greatest errors in implementing a change is to make any assumptions about how things are currently being done. You must investigate it, map it out and gain consensus that you have captured the "as-is process". This exercise in itself will likely be enlightening, with a lot of "I did not know you did that" or "I did not know you needed that" along the way. A success here will make a smooth transition to solutions. I always suggest formal discovery as a predecessor to defining the as-is process, thereby ensuring that no activities, decisions or deliverable expectations are buried and left behind.

The final step is to make the necessary changes and finalize consensus. The problem areas to be resolved should be fairly obvious; assuming some quality work was completed in defining the "as-is" process. Work out the solution possibilities in a brainstorming type fashion and then whittle them down to a largely agreed upon solution. Odds of 100% agreement are slim, although if you practice inclusion over exclusion of members, everyone will understand the behind the scenes reason for a decision. Those that participate will be apt to respect the decision, even though they may not fully agree with it. Document your changes, update any process guides and rollout the change. Follow this simple formula and you will successfully change something for the better, even when many believe it could not be done. Now do this again and again to become a practitioner of continuous improvement. Even better, let the ideas for change flow from the bottom up and then facilitate the details, decisions and implementations. Become an agent for change in everything you do, every day.