Our podcast on this topic is available here (Podcast No. 229).

I have worked in this field for many years, during which time I worked with several major project organizations.  I feel that now is the time for increased emphasis on Lessons Learned. 

Early in 2011, I predicted that more companies would seek to close projects successfully and to capture project lessons learned.  In fact, I stated that those companies who successfully documented and shared lessons learned would gain a decided competitive advantage with regard to competition.

Today, I see a trend toward being more open in organizations with regard to “project failures” and poor performance of projects.  However, it is still a “culture” phenomenon, and much work must still be done with organizations to help them gain an appreciation for the full value of lessons learned.

Our BOT International work has shown that how project and PMO organizations embrace “change” is very much related to how they embrace lessons learned.  The discipline of lessons learned is all about change. 

To quote John C. Maxwell:  “Real change occurs as the result of either inspiration or desperation.” 

Project and PMO organizations that are “business driven” and proactive take a decidedly different approach to that of project and PMO organizations that are on the “compliant” end of the spectrum.  This difference between “commitment” and “compliance” when addressing change is important.

Our BOT International consulting offerings in the Project Closeout and Lessons Learned Advisory Practice take these CHANGE, CULTURE, and PMO MATURITY issues into account in their planning and execution.

All of our consulting offerings approach project lessons learned from a Framework which contributes to a continuous process improvement environment for the organization.

We have four basic consulting offerings from BOT International regarding Project Closeout and Lessons Learned.  I would like to review each one and provide the following information:  type of engagement, length of engagement, participants, focus, and outcomes.

First, we have a culture and change initiative (PCOLL010).  This is a three to five day on site intensive culture initiative to instill an appreciation for project lessons learned and the value to be gained by sharing information.

The second offering is a three day intensive workshop (PCOLL020) aimed at groups of 20 or less to discuss tactical aspects of documenting lessons learned. 

The third offering is a five day on site engagement (PCOLL030) which combines the three day workshop with intensive discussion of project culture and importance of lessons learned in a continuous process Improvement framework.

The fourth offering is an intensive one day on site workshop (PCOLL040) whose participants will become “mentors” to others in the organization with regard to capturing, documenting and sharing project lessons learned.  The selection of these “mentors” is a collaborative effort with the project organization.

Obviously, these four offerings can be modified to meet the needs of specific organizations based on their individual project and business contexts, project organization maturity or Management’s desire to change the culture.  I would be happy to work with any Managers who wish to emphasize a specific aspect of Project Lessons Learned or Knowledge Management in our consulting work.

Please contact me at mbost@botinternational.com to discuss how BOT International can assist you with Project Closeout and Lessons Learned or any other aspects of PMO Setup and Maturity.

This team recently assembled in Orlando, Florida at the 2011 PMO Symposium to demonstrate their process assets “Processes on Demand” to Symposium participants and to discuss their expertise in any field of PMO maturity and development.

The principal subject matter experts and their fields are:

Mark Price Perry:  PMO Setup and Maturity

Terry Doerscher:  Project and Portfolio Management (PPM)

Steve Romero:  Governance

and me, Mel Bost:  Project Closeout and Lessons Learned

Another BOT International consultant and facilitator, Cornelius Fichtner, interviewed the four subject matter experts during the 2011 PMO Symposium to provide his PM Podcast and PREPCAST listeners with the latest news on the BOT International talents.  Check out his podcast here.

BOT International is a global firm specializing in Project and Program Management Office (PMO) competencies.  Contact me to find out more about how BOT International can help you.

Here are some other factors that contribute to this trend:

1.  The need to include Risk Management in every aspect of Project Planning and Execution.  Risk can be included as a variable in the Project Lessons Learned framework, especially if applied in a Project Lessons Learned schedule that calls for a review at each of the Phase Gates of the project process.

2.  Web-based tools such as the Microsoft Project 2010 client and server or Basecamp allow Project Lessons Learned to be easily recorded so that they will be treated as just another piece of performance reporting information for a project.

Project managers who fully experience the project process—including the use of Project Lessons Learned—learn and acquire truth, knowledge, decision-making skills, and good judgment. 

There are three primary methods by which project managers may learn these valuable lessons:

First, “reflecting” is the preferred method because it results in the highest value to the project manager.  “Reflection” means focusing attention on or studying an event or outcome to understand its origin and root causes as they apply to new project situations.

Second, “imitating” other project managers’ documented, shared experiences is the easiest method by which project managers may improve their skills.  “Imitation” means to behave in a manner which mirrors the actions or behavior of others.

Third, “repeating” his or her own bad experiences and unplanned or poor outcomes may also result in the project manager developing his or her skills, although this method causes the most pain and, in most cases, creates the least value addition.

These concepts paraphrase Confucius’ fifth-century B.C. quotation concerning “wisdom” and “lessons learned.”  They relate concepts of “behavior,” “actions,” “outcomes,” “experiences,” “pain,” “ease,” “value addition” and “knowledge.” 

Why is it that project managers refuse to accept the reality that it is more painful to keep repeating the same mistakes in their projects, rather than to learn and benefit from the experiences of others? 

Lou Tice teaches us two principles of personal growth and development:

1.  People act in accordance with the “truth” as they perceive it to be.

2.  People move toward and become like that which they think about.

As Lou Tice suggested, project managers who act as if Project Lessons Learned can have no positive impact on their future success, act in accordance with their perceived “truth” that Project Lessons Learned aren’t valuable.  Similarly, many organizations have been reluctant to require their project managers to take the time required to reflect upon their completed projects and to document their Project Lessons Learned—despite the fact that most PMBOK practices suggest that project managers properly close-out projects with an after-action review and documentation of Project Lessons Learned. 

Today, however, I believe that this reality is finally beginning to change.  Many companies have begun to take Project Lessons Learned more seriously, and they are now  interested in closing-out projects with documentation preserving the “knowledge” created by the project, and the “experiences” of the project’s participants.

On the other hand, what do project managers want to do more than anything else when they successfully complete a project?  Those of us who have observed this behavior over time can tell you that overwhelmingly project managers want to get on to that next great assignment, that next great challenge, that next great project.  Rarely do they want to pause and reflect upon what they have just accomplished, or what the organization could gain if they documented and shared their project management experiences. 

So, what should be the driving force for properly documenting and sharing project lessons learned?

We all know that most organizations now recognize that there are certain Best Practices—in both their project management processes and in their business context—that they employ over and over again.  This is to be expected; when an organization experiences a successful outcome using a key Best Practice, the organization is likely to have successful outcomes in the future if it employs that same Best Practice again.  Often these Best Practices are specific to that organization’s culture, and they fit into the project process naturally in the course of executing projects.  Indeed, many organizations are now employing Best Practice intuitively.  Few companies, however, are adept at recognizing and employing their own Best Practices.     

Just like Best Practices have become—no pun intended—Best Practices within many companies, shouldn’t PMOs look upon Project Lessons Learned as having the same potential to lead to “success” in their project work? 

Here is a “process” and ”framework” for looking at Project Lessons Learned that will allow the project lessons learned process to become a Best Practice in your PMO. 

What would constitute a “capability based system” for capturing and sharing Project Lessons Learned?

1.  There must be some process or mechanism for sorting out the FACTS in stories, experiences, and anecdotes, versus the ASSUMPTIONS and PERSPECTIVES contained therein.

2.  There must be a recognized “review” process to identify SIGNIFICANT EVENTS and CANDIDATES for Project Lessons Learned. 

3. There must be willingness on the part of project managers and project team members to speak directly, concisely, and with conviction about project events and lessons.  This involves a risk-taking attitude that only comes from developing an internal capability in the organization to acknowledge that Project Lessons Learned add lasting value.

4.  There must be a “review” process which addresses the following questions:

        –What were the Expected Results from the action or behavior of the project team?

        –What were the Actual Results from the action or behavior of the project team?

         –What is the gap between Actual and Expected?

         –What are the Lessons Learned to be captured, shared, and documented?

5.  There must be an internal knowledge-management system (such as, as mentioned above, Microsoft Project 2010 or Basecamp) devoted to storing Project Lessons Learned documentation so that project managers may easily retrieve and apply the lessons contained therein to new projects.

6.  There must be a single person who is the coordinator or caretaker of the Project Lessons Learned process and the knowledge-management system, so that he or she can analyze the documented lessons learned in order to identify any broader lessons learned that may be applied to the policies, processes, and procedures governing the organization’s project management processes.

Once you have mastered these basic elements and gain some experience in applying the process to a number of projects, you can begin to add some sensitivities. 

For example, you could relate Project Lessons Learned to the risks existing when you are developing a new technology concurrent with the project within which the new technology is being applied.  At the outset of such a technology-driven project, you can establish a plan to prove-out the technology as the project progresses.  A lesson learned could then be documented in terms of the risk of the new technology being proved-out successfully during the project.  Such a scheme could introduce concepts such as “controllable” and “uncontrollable” risk.  “Controllable risk” could be associated with those portions of the technology prove-out where there is a high probability of success.

Likewise, you could look at Project Lessons Learned at the end of each major phase of your project, and apply some “integrative thinking” principles.  This allows a reexamination of original “assumptions” for the project and sets the tone for good project planning for future project phases.

Does your organization have a capabilities-based strategy for making project lessons learned a Best Practice?

As a Principal Consultant with BOT International, we are interested in assisting PMOs and project groups with PMO Setup, Project and Portfolio Management (PPM), Governance and Project Closeout and Lessons Learned.  Call on me or email me if you would like more information about our consulting services.

On the first day of class, I let the class set the schedule based upon their normal working hours.  They chose to have the class run from 7:30 AM to 4:30 PM with a one hour lunch break from noon to 1:00 PM.  So, my day was set early!  I was up at 5:30 AM every day, I ate breakfast at 6:30 AM, my taxi left the hotel at 7:00 AM, I arrived in the classroom 7:20 AM, and the class started at 7:30 AM.  After a few days, I began to realize that my best, most energetic time of the day was between 6:00 AM and noon.  So, I tried to plan my interaction with the class around that same energy level.  Since returning from Panama, I have maintained that 5:30 AM awakening, and have had my most energetic and productive time between 6:00 AM and noon.  This self awareness of energy level and corresponding times of the day has been very productive in planning work cycles and downtime for rest.

The first day of classes, I was uncertain whether “language” differences might be an issue.  In our contract, it specified that the course would be offered in English.  As it turned out, I had to spend a great deal of energy and time covering the introductory material because of language-related issues.  When it came time for our lunch break, I was uncertain as to what to do about lunch.  Several people had told me there were small restaurants within walking distance of the facility.  But I really felt that I needed to prepare for the afternoon session.  I had brought a box of granola bars with me for snacks in case I needed extra energy.

As a result of this “lunch dilemma,” I ate a granola bar everyday at lunch in my classroom and prepared for the afternoon session.  This resulted in a much smoother class than if I had tried to find a local restaurant with time constraints and not knowing how my stomach might react to the cuisine.   This self awareness of integrating food intake with the needs of the class was very important.

One area that I have been studying lately is “risk analysis.”  For example, on my taxi ride to the training facility on the Monday of the second week of training, I began to think of the “risks” I might encounter that week.  One risk was that my classroom location might have been changed from the location of the first week’s training.  This was highly likely due to the way the second week of training had been scheduled at the last minute.  Similarly, during the first week, I had to acclimate myself to the audio and video equipment and my laptop computer connections so that the class would run smoothly.  One thing I thought I might have to my advantage was the fact that most of the training rooms seemed to be set up with the same equipment and tables/chairs, whiteboards, and visual equipment.

When I arrived, my HR/Training contact informed me that I would, in fact, be in a different training room that week.  I requested his assistance in helping set up the equipment so the course would proceed smoothly.  My experience during the first week helped me to identify and plan for “controllable” and “uncontrollable” risks.  Risk analysis is a very valuable tool to keep close at hand because it deals with not only the likelihood of the possible event, but also the possible impacts if such an event occurs.

So, here are the big takeaways in terms of personal awareness and the big challenges:

1.  It is easy to plan for the major activities associated with a big challenge, but it is difficult to plan in advance for personal aspects such as food, rest, relaxation, energy level maintenance, language differences, etc.  These personal aspects, however, also contribute to your ability to tackle a challenge.  Take the time to plan for these personal aspects, and you will see your successes grow exponentially.

2.  Work to match your energy level characteristics with the scheduling of your big challenge.  If you can identify the times during which you have maximum energy and can sustain maximum concentration, you will be more productive and your stakeholders will, in turn, be rewarded.

3.  Utilize risk analysis and risk management techniques both to plan your big challenge, and to monitor your progress during the big challenge.  You will want to conduct your own “lessons learned” analysis of your big challenge, so, remember, the Significant Events that you identify in your lessons learned analysis frequently become the risks that you identify when conducting a Risk Analysis for your next big challenge.

4.  Remember, your stakeholders and clients are expecting you to produce a memorable “experience”.  To achieve that goal, you will have to closely monitor other people and processes that will impact your challenge.  Be sure your analysis accounts for these people and processes and plan accordingly.

Your personal growth and awareness during and after conquering your next big challenge is very important to everyone with a stake in the outcome.  Do everything you can to make this challenge a great experience and produce an excellent work product for both your stakeholders and yourself.

Those were the words of my former manager in an IT Project Office (a predecessor to the modern PMO).  It is an often-repeated statement, but one which does not get much scrutiny from a root cause analysis format.

Here was the scenario:

A major energy company acquired the downstream assets of another energy company, and integrated the functional groups, including the Information Technology groups.  At the start of this scenario, I was a Project and Planning Consultant in the IT Planning Group.  The Information Technology group decided to form an IT Project Office (ITPO), and it hired an experienced manager from a major Fortune 500 Company whose expertise was in forming and maturing PMO-type organizations.  Prior to that point, each IT Applications Development, Systems, and Infrastructure Group had planned and executed projects within their own groups with limited collaboration across groups.

A major consulting firm had facilitated the merger of the two energy companies, and Management of the merged company strongly recommended that the Information Technology group use the consulting firm as a “guide” in forming the IT Project Office.  The consulting firm had an excellent reputation for internal project management capability, and it utilized a methodology which I will refer to here as “THE METHOD.”  So, Information Technology Management was pleased at the outset that they not only had an experienced PMO-type Manager, but also a strong consulting group direction.

The “vision” and directions given by the IT Project Office Management to the consulting firm were that the ITPO wanted to instill its own “trademark” and “business context” in the new project group. 

While the consulting firm heard this “firm” direction,” it internally recognized that the firm had made a great investment in “THE METHOD” and that it would exploit “THE METHOD” at every opportunity.

The IT Project Office utilized the SEI Capability Maturity Model as a framework for planning its path of evolution to a mature state.  However, whenever a new process or procedure was developed in concert with the consulting group, the outcome had a strong flavor of “THE METHOD.”  So, whenever the IT Project Office mapped its systems projects to follow the business processes with which it was trying to align, it conveniently left the consulting group out of the process until some redefinition of an omitted process was imminent.

This recurring pattern of behavior was subtle but highly visible to those of us living the daily ITPO experience.

This is an example of a “systems archetype” at work. 

Peter Senge has written extensively about organizational dynamics and behavior and systems archetypes identifiable from events and patterns of behavior.

William Braun has also written extensively about systems archetypes.  System Archetypes are highly effective tools for gaining insight into patterns of behavior, themselves reflective of the underlying “structure” of the system being studied. The archetypes can be applied in two ways – diagnostically and prospectively.

Diagnostically, archetypes help managers recognize patterns of behavior that are already present in their organizations. They serve as the means for gaining insight into the underlying systems structures from which the archetypal behavior emerges. This is the most common use of the archetype.

Archetypes are effective tools for beginning to answer the question, “Why do we keep seeing the same problems recur over time?”

Prospectively, archetypes are useful for planning. As managers formulate the means by which they expect to accomplish their organizational ends, the archetypes can be applied to test whether policies and structures under consideration may be altering the organizational structure in such manner as to produce the archetypal behavior. If managers find this to be the case, they can take remedial action before the changes are adopted and embedded in the organization’s structure. 

From my experience, archetypes can be highly effective when examining PMO and IT Project Office organizational structure.

The particular ”systems archetype” described above is called “accidental adversaries” because it explains how groups of people who ought to be in partnership with each other, and who want to be in partnership with each other (or at least state that they do), end up bitterly opposed.  It applies to teams working across functions, to joint ventures between organizations, to union-management battles, to suppliers and manufacturers, to family disputes, and even to civil wars.

The classic case where this “accidental adversaries” structure was first articulated and  recognized was a scenario involving Procter and Gamble (P&G) and Walmart.  Both had the same goals–improving the effectiveness and profitability of their production/distribution system–but they each felt that the other was acting in self-serving ways that damaged the industry. 

Wal-Mart learned throughout the 1970′s and 1980′s that heavy discounting and price promotion of goods could boost market share, value, and improve profits.  But price promotions created extra costs and difficulties for distributors like P&G.  The Wal-Mart practice undermined P&G manufacturing, creating great swings in P&G’s manufacturing volumes.  The practices of each firm were intended to meet each firm’s internal objectives but, as a partnership, each was always pointing a finger at the other claiming undermining practices.  In responding more attentively to their internal objectives, the partnership fell short of optimizing its combined operational effectiveness.

While this pattern of behavior continued for years, attempts to reconcile and elaborate exactly what was happening was a difficult, if not impossible, order.

And so, this same pattern existed in the newly formed and maturing IT Project Office, among seemingly cooperative and optimization-oriented managers, who did not recognize the future implications of their antagonistic conduct.  It is often not easy to discern or to admit that these behaviors take place among rational and intelligent groups who join their efforts to make a better condition within their groups.

But, as William Braun has suggested, the potential exists for  archetypes to be applied to test whether the policies and structures under consideration may be altering the organizational structure in such manner as to produce the archetypal behavior. If PMO managers find this to be the case, they can take remedial action before the changes are adopted and embedded in the organization’s structure. 

Have you identified some recurring behaviors in relationships between your key PMO suppliers, vendors, partners, or other support groups which can be limiting your attainment of PMO Excellence?  

Here are some prescriptive actions and seven action steps from William Braun in case you find candidates for “Accidental Adversaries”:

Prescriptive Action

• Revisit the original opportunity that brought the PMO parties together into a collaborative relationship.

• Use the archetype to identify the origins of adversarial attitudes.

• Renew the Shared Vision of the collaborative effort and commit to Team Learning.

Seven Action Steps

• Reconstruct the conditions that were the catalyst for collaboration and PMO success.

• Review the original understandings and expected mutual benefits.

• Identify conflicting incentives that may be driving adversarial behavior.

• Map the unintended side effects of each party’s actions.

• Develop overarching PMO goals that align the efforts of the parties.

• Establish metrics to monitor collaborative behavior.

• Establish routine communication.

I don’t want to leave you with the impression that this IT Project Office archetype produced a highly dysfunctional organization as it matured.  Over a two or three year period, the management of the IT Project Office and the consulting firm realized and recognized the internal objectives of the other party, and actually began to discuss how they could support their own internal objectives while creating the fully functional IT Project Office that everyone envisioned at the beginning.   Dialogue and continual realignment of values and vision were effective over time.

Audience response to this post was extremely positive, so I recently collaborated with Wayne Thompson, the author of the very popular blog “Project Management War Stories” to develop a two-part podcast on his blog site about the “Design Thinking” topic.

Part One of the podcast covers background material on why project teams often fail to define complete business requirements for projects and are forced to rework and redo much of their planning. 

Part Two of the podcast covers the use of “Design Thinking” and other innovation principles to better define project business requirements. 

I hope all PMO practitioners, project managers, and project team members find these podcasts interesting and enlightening.  I have certainly enjoyed working with Wayne Thompson on these topics, and we are planning a new podcast for later this month on Project Lessons Learned.  Stay tuned for that next podcast and thanks for your support.

First, “reflecting” is the preferred method because it results in the highest value to the project manager.  “Reflection” means focusing attention on or studying an event or outcome to understand its origin and root causes as they apply to new project situations.

Second, “imitating” other project managers’ documented, shared experiences is the easiest method by which project managers may improve their skills.  “Imitation” means to behave in a manner which mirrors the actions or behavior of others.

Third, “repeating” his or her own bad experiences and unplanned or poor outcomes may also result in the project manager developing his or her skills, although this method causes the most pain and, in most cases, creates the least value addition.

These concepts paraphrase Confucius’ fifth-century B.C. quote concerning “wisdom” and “lessons learned”, which many of you will recognize from previous posts on this site.  They relate concepts of “behavior,” “actions,” “outcomes,” “experiences,” “pain,” “ease,” “value addition” and “knowledge.” 

Why is it that project managers refuse to accept the reality that it is more painful to keep repeating the same mistakes in their projects, rather than learn and benefit from the experiences of others? 

Lou Tice teaches us two principles of personal growth and development:

1.  People act in accordance with the “truth” as they perceive it to be.

2.  People move toward and become like that which they think about.

As Lou Tice suggested, project managers who act as if project lessons learned can have no positive impact on their future success, act in accordance with their perceived “truth” that project lessons learned aren’t valuable.  Similarly, many organizations have been reluctant to require their project managers to take the time required to reflect upon their completed projects and document their project lessons learned, despite the fact that most PMBOK practices suggest that project managers properly close-out projects with an after-action review and documentation of project lessons learned. 

Today, however, I believe that this reality is beginning to change.  Many companies have begun to take project lessons learned more seriously, and are interested in closing-out projects with documentation preserving the “knowledge” created by the project, and the “experiences” of project participants.

On the other hand, what do project managers want to do more than anything else when they successfully complete a project?  Those of us who have observed this behavior over time can tell you that overwhelmingly project managers want to get on to that next great assignment, that next great challenge, that next great project.  Rarely do they want to pause and reflect upon what they have just accomplished, or what the organization could gain if they documented and shared their project management experiences. 

So, what should be the driving force for properly documenting and sharing project lessons learned?

We all know that most organizations now recognize that there are certain Best Practices—in both their project management processes and their business context—which they employ over and over again.  This is to be expected; when an organization experiences a successful outcome using a key Best Practice, the organization is likely to have a successful outcomes in the future if it employs that same Best Practice again.  Often these Best Practices are specific to that organization’s culture, and they fit into the project process naturally in the course of executing projects.  Indeed, many organizations are employing Best Practices now intuitively.  Few companies, however, are adept at recognizing and employing their own Best Practices.     

Just like Best Practices have become—no pun intended—Best Practices within many companies, shouldn’t PMOs look upon Project Lessons Learned as having the same potential to lead to “success” in their project work? 

Here is a “process” and ”framework” for looking at Project Lessons Learned that will allow the project lessons learned process to become a Best Practice in your PMO: 

In my last blog, I talked about building capabilities as a prerequisite for successful PMO execution. 

What would constitute a “capability based system” for capturing and sharing project lessons learned?

1.  There must be some process or mechanism for sorting out the FACTS in stories, experiences, and anecdotes versus the ASSUMPTIONS.

2.  There must be a recognized “review” process to identify candidates for project lessons learned. 

3. There must be a willingness on the part of project managers and project team members to speak directly, concisely, and with conviction about project events and lessons.  This involves a risk-taking attitude that only comes from developing an internal capability in the organization to acknowledge that project lessons learned add lasting value.

4.  There must be a “review” process which addresses the following questions:

        –What were the Expected Results from the action or behavior of the project team?

        –What were the Actual Results from the action or behavior of the project team?

         –What is the gap between Actual and Expected?

         –What are the Lessons Learned to be captured, shared, and documented?

5.  There must be an internal knowledge-management system devoted to storing project lessons learned documentation so that project managers may easily retrieve and apply the lessons contained therein to new projects.

6.  There must be a single person who is the coordinator or caretaker of the project lessons learned process and knowledge-management system, so that he or she can analyze the documented lessons learned in order to identify any broader lessons learned which may be applied to the policies, processes, and procedures governing the organization’s project management processes.

Once you have mastered these basic elements and gain some experience in applying the process to a number of projects, you can begin to add some sensitivities.  For example, you can relate project lessons learned to the risk of developing a new technology concurrent with the project within which the new technology is being applied.  At the outset of the project, you can establish a plan to prove-out the technology as the project progresses.  A lesson learned can then be documented in terms of the risk of the new technology being proved-out successfully during the project.  Such a scheme could introduce concepts such as “controllable” and “uncontrollable” risk.  “Controllable risk” could be associated with those portions of the technology prove-out where there is a high probability of success.

Likewise, you can look at project lessons learned at the end of each major phase of your project and apply some “integrative thinking” principles, as I have outlined in another blog post.  This allows a reexamination of original “assumptions” for the project and sets the tone for good project planning for future project phases.

Where does your PMO stand on closing out projects?

A.G. Lafley, in his book, The Game Changer:  How You Can Drive Revenue and Profit Growth with Innovation, defines innovation as “the process of converting or turning new ideas into revenue and profit.”  Similarly, many authors in the PMO field have defined the PMO as a distinct organizational structure which can be used to drive innovation through project management and product development.

A recent article in the Winter 2010 issue of Strategy + Business magazine, entitled “The Global Innovation 1000:  How the Top Innovator’s Keep Winning”, was based on an ongoing Booz & Co. study of innovation in the most successful companies in the innovation game today.  The goal of the study was “to examine the capabilities needed to maximize the impact of the company’s innovation efforts in good times and bad, and to highlight the benefits both of focusing on the short list of capabilities that generate differential advantage and of clearly linking the specific decisions within innovations to the company’s overall capabilities system and strategy.”

Their premise was that “innovation capabilities enable companies to perform specific functions at all the stages of the R&D value chain–ideation, project selection, product development and commercialization.”  The consultants asked the respondents in the Global Innovation 1000 survey which capabilities were most important in achieving and sustaining success in innovation.

Surprisingly, the study found that “all the successful companies surveyed depended on a common set of critical innovation capabilities.  These include the ability to gain insight into customer needs and to understand the potential relevance of emerging technologies at the ideation stage, to engage actively with customers to prove the validity of concepts during product development, and to work with pilot users to roll out products carefully during commercialization.”  The study’s authors also found important the ongoing assessment of market potential during the project selection phase.

Exhibit 1--The Most Important Innovation Capabilities

You will recall that in other blog posts, I have discussed the rise of PMOs for specific purposes in organizations which recognize the special value-added by having an organization focused on project management capabilities as a means of converting strategy into action.  For example, some utilities have formed Smart Grid PMOs to handle Smart Grid projects.  In an organization that is determined to succeed and grow in its industry, with best-in-class products, services, or both, why not consider creating an entity called the Innovation PMO?  What would the characteristics of such an entity be?

First, since feedback and research from consumers, users, and other stakeholders is critical to understanding “what to innovate for,” the Innovation PMO would establish its own unique source of feedback research within the context of its own industry or consumer setting.  This is a key element of success.  Unfortunately, very few PMOs are currently doing a good job in this area, but to become an Innovation PMO, they must.

Second, the Innovation PMO has leveraged its key supplier and vendor relationships.  It knows that frequently, the unsolicited feedback provided by suppliers and vendors provides a fresh look as to where the market is headed, especially in innovation scenarios.

Third, the Innovation PMO has tailored the critical innovation capabilities discussed in the Booz & Co. study to the internal business context of the organization.  This tailoring process is analogous to the benchmarking process, discussed in a previous blog post, which is used by leading PMO organizations, such as American Express and Procter & Gamble, to establish best practices.  Like best practices, to be successful, innovation capabilities can’t be lifted verbatim without being tailored to the organization’s business context.

Margo Visitacion of Forrester has also written about the expansion of the PMO concept to innovation in organizations in her recent Forrester paper “Involve Your PMO to Find the Right Match for Innovation Opportunities.”  I would recommend you read her analysis as well.

Innovation is certain to be a topic embraced by more and more organizations looking for successful growth-promoting projects in their industries.  Your role as a PMO practitioner is to find a spot where you can contribute to that success.  Remember–”Change Creates Opportunity.”  Now, go find that opportunity.

A new levee system is now being installed by the Army Corps of Engineers.  There are many lessons learned resulting from the previous levees’ failure during Katrina, as well as many years’ data from previous storms and from computer simulations.  These lessons learned are currently being addressed by the design of the new levee system.

What is the actual cost for failure to capture and share project lessons learned?  Aside from the human cost of storms like Katrina, what is the actual “project” cost that is incurred by not capturing, documenting, sharing, and institutionalizing project lessons learned?  How can we get a manageable and actionable handle on the real contribution of project lessons learned on “saving” future project cost?

The answer to this question obviously depends on many factors:  the complexity of the project, the number of systems impacted, the number of dependencies of project info with other like systems, etc.  How can we get a handle on this type of information, and of what value would it be if we were to understand and apply it?

I once studied with a professor whose favorite expression was “Analysis is the Essence.” 

It did not really dawn on me what that statement meant until I encountered some business situations where bad decisions resulted in a failure to meet objectives such as ”on time, on budget.”  In these cases, it seemed to me that the logical sequence of events should be “analysis” followed by “rational thought” followed by “decisions to proceed” followed by “actions.”

We all know that while it is easy to recommend to others courses of action, or specific rationale, or well-thought-out research findings, it is very difficult for others to actually follow-up, and to take the recommended courses of action. 

Why is that?  I believe that everyone has a tendency to believe that if they did not think of an idea themselves, then that idea is not of value to their ongoing, daily processes.  And they may also be biased, and emotionally involved in the decision, so that their “rationality” does not shine through.  As is often said, you can clearly lead a horse to water, but you can’t make him drink.  It takes motivation and capability.

People decide to take courses of action based upon recommendations from others based on the credibility that they attach to the advice-giver, and the usefulness of previous directions from that person.  Leaders become leaders because they continually disallow their own thinking in favor of the more qualified thinking of their peers and associates; they have learned over time that their own thinking provides merely one perspective of a scenario that really demands many viewpoints to assess, understand, and take action upon. 

So, how do you get people to embrace project lessons learned–first, as a logical step in the project management process, and second, as a rational, thought-based process to provide information for future decisions about project work?

In the course of assisting project teams and PMOs with developing project lessons learned, I have often encountered a resistance to take the time to develop and capture lessons learned, and to share this information with others.  Emotional entanglement–as well as a lack of motivation in the sense that no immediate reward will be forthcoming (and perhaps that negative consequences may ensue)–often dictates the action or inaction.  And I am sure, if you are actively engaged in project work in a PMO, that you have encountered the same.

So let me suggest another tactic.

There is a cost to be borne by the PMO for not capturing and sharing project lessons learned. 

To get a simple model for this cost, let’s assume a model that is often used to get across the point that introducing changes at various key points in a project introduces additional cost to accommodate those changes.

If a project has, for example, four distinct phases, and if a change is introduced during the first phase that costs $10, that same change may cost $100 if introduced during the second phase, $1000 if introduced during the third phase, and $10,000 if introduced during the fourth phase. 

Now, suppose that a project lesson learned is identified in phase four, and that project lesson learned could impact a change at that point, so that the original change in phase one would cost 0.001 times as much. 

Suppose two or three project lessons learned could be identified for every project.   Thinking in an integrative manner to identify where projects could have been improved at previous project phases can deliver real cost savings.  The point here that you should grasp is not whether the savings is 0.001 times the final cost of the change but that this perspective can yield significant savings to any project, no matter how complex or simple.   Train yourself as a project manager to think in these terms and you will always be able to find significant “opportunities” in lessons learned.

Hard dollar reductions are the result of project lessons learned.

What is the situation in your PMO?  Are project managers willing to share project lessons learned?  Does the organization have a process for documenting and sharing project lessons learned to future project teams? 

I would like your feedback on this subject.  Thank you.

I want to turn now to “benchmarking”, an area which can be applied to improve performance on several “scales”, whether it be overall performance of a PMO group, of an individual group within a PMO, or a single person’s performance.

Benchmarking is the comparison of a known state or condition of a group or process to another “defined standard” group or process which, in the eyes of  the benchmarker, represents a level of performance or activity that is desired in one’s own group, process or person. 

Benchmarking also introduces “innovation” into your organization.

Now what does this really mean?

In order to have a meaningful “benchmarking” exercise, you must first define an “as is” base case that describes the current situation with regard to a process, group, or person, and which adequately describes the level of performance.

Next, you must seek another “reference” group which, in your eyes, represents a “to be” state of performance which you seek to emulate within your own group  or process.

Where can you locate such a “reference” group?  Outside organization such as Gartner, Forrester, or the Corporate Executive Board  can provide a good starting point in terms of processes, the expected behavior and activities of these processes, and ways in which you could measure the performance of these processes.

If you are examining actual PMO processes, look at the standard-bearer companies like American Express, Marriott and Eli Lilly & Company   for your reference group benchmark.  Similarly,  if you want to benchmark in other processes, such as Purchasing and Supply Chain Management, look at the titans–Motorola, HP, and Deere & Co.

You can readily see the power of this approach–it can be applied at the total PMO organization level, an individual internal PMO group level, or even at the individual person contributor level within the PMO.

Benchmarking has been successfully employed by thousands of organizations, even when they had little benchmarking experience when they began the process.  The key to a successful benchmarking exercise is a desire to improve.  Once an individual or a group decides to get better at whatever the process or task of the group might be, the wheels of successful benchmarking are put in place.

You can be a leader in the benchmarking effort of your PMO.  It takes a desire to contribute to the improved performance of the group and a “capability” to perform.  As we have seen in previous blog posts, capability is enhanced with “education and training.”  You should seek out knowledgeable references on “benchmarking”, and other companies in the PMO field who exhibit good PMO performance characteristics.  Talk to your local PMI Chapter, or to a local PMOSIG group.  They can assist in your selection of appropriate PMO performance measures.

Good luck–I look forward to your feedback!