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.

Breaking Down Barriers to Enable Positive Change

The majority of teams that I talk to have something that they wish would be different, something that has been a problem for a while and is limiting productivity or predictability in some fashion. What I find interesting is the length of time project thorns such as this continue. The difficulty gets plenty of dialogue around the lunch table, or at the local watering hole, however an actionable plan to do something about it is frequently put on the back burner. The reasons sited are typically one or more of money, time, "it will never get better" or "not my problem".

These long term project thorns are similar to an old pair of our favorite shoes. They may be ugly in ways, have obvious defects to most people and everyone is telling us we need to get new ones. We are blind to these facts because they are so comfortable and we know how to walk just fine with them. However, in reality they are probably causing us some physical problems that we may not even be aware of, since the negative change with time is so subtle. Why are we reluctant to buy new shoes? We are comfortable with the ones we have and new shoes will hurt for a while until we work into them. In reality we are afraid of how peculiar the new shoes will feel vs. the familiar old ones and how long it will take for us to adjust to them.

For our projects the major reason we tend to hold back on changing something is also fear centered more often than not. Ouch - am I really afraid to change something? The odds are high that fear is a major non-starter for implementing changes to improve a less than perfect work flow situation. Fear is the result of the unknowns that exist on the path to a change. If we diddle with something to make it better, will I be OK with any impact on my work situation? The common reasons for this fear are outlined below:

• Things may end up worse after the change.
• I already feel overwhelmed; will defining and making this change increase my load?
• Skeptical - will my concerns/ideas be heard and addressed?
• I may be impacted by a change in an unfavorable fashion.
• Change of Habit - Things may not be perfect now, but I know what I am going to do every day when I go to work. How will this change my day?
• I am not responsible for the issue we have. Will I somehow end up more responsible for the problem?

Ignore the reality of fears such as those identified above and plans for change will either never leave the starting gate or drag on and on without any attainable value, leaving you to potentially deal with "see, I told you that would never work" type of criticism. Acknowledgment and handling of the prospective fears will enable a smooth course to the development and roll out of a change.

So how do you handle the diffusion of the fears? The simplest means to a minimally fear filled, maximally beneficial change practice is "Broad Involvement". Each individual's potential solution vector will have different magnitudes and phases for a specific problem. They all need to be as aligned as possible to maximize the effective magnitude and the only way to do that is to engage them, really engage them. Any problem to be addressed and the resulting change will have far reaching impact; therefore a strategy of far-reaching inclusion rather than exclusion of individuals will alleviate fears and tip the scales towards success. Consider that the problem you want to resolve is rarely contained within a given organizational silo, although it may appear as though that is the case due to a narrow view of the project execution landscape.