Mel Bost – PMO Expert

My recent PMO blog posts have consistently addressed some of the prerequisites for an “actionable” Project Closeout and Lessons Learned Process for the PMO or project organization.  In general, these have been activities or competencies or capabilities that the organization needs to nurture in order to really make Project Lessons Learned an active contributor to the overall Project Process.

In the course of this review of critical success competencies, we must also ask what skills and capabilities are required of project managers or project facilitators to enable the full development of project lessons learned? 

As we all know, people are what really make a difference in the deployment of corporate resources.  To make a real difference, and to stand out versus other organizations’ implementations of the project lessons learned process, your organization needs to ask what skills and capabilities it must develop and nurture in its project managers to fully realize the benefits of Project Closeout and Lessons Learned.

It is the combination of Process, People, Tools, and Capabilities that really make a successful package for Project Closeout and Lessons Learned.

So, what skills do your project managers need to develop to enable the full development of project lessons learned?

First, the project manager must be a good “facilitator” of the Perspectives, Facts, and Deliverables that are key to defining Significant Events for Lessons Learned.  The project manager or coordinator must be able to work with different Perspectives as to what actually happened in key project situations, sort through the various Perspectives, and then “reconcile” if necessary those Perspectives that would hinder gaining consensus on key Significant Events.

Second, the project manager or coordinator must be a good “reframer” if necessary to hold the dialogue with key project participants who might see situations differently but, in actuality, just need a “reframing” of the facts of the situation to be brought on board.

Third, the project manager or coordinator needs to be a leader of the discussion, at all levels, during which it is important to convert Significant Events, to Candidates for Lessons Learned, and finally, to the identification of Lessons Learned themselves.

Fourth, the project manager or coordinator needs to be a good documenter of the process using the Lessons Learned Template as a key documentation tool.

Fifth, the project manager or coordinator needs to be able to explain, and put into context, why certain lessons learned led to improvements in process, and how those improvements were actually realized.

In my experience, even the most experienced project managers have trouble working with the Framework at first and must develop some experience with using it effectively.  In most cases, it is these capabilities or competency areas that are being developed while the project manager or coordinator grapples with the details of Project Closeout and Lessons Learned.

I have also found in my work with PMOs that oral presentations of Lessons Learned by project managers to their peer group is a very effective way of building these capabilities, and also to build project leadership.  In a major PMO with which I worked, those project managers who consistently stepped forward and volunteered to lead this discussion of project lessons learned eventually became the leaders of the PMO.  Why was that?  Project managers who embrace change, who believe that Risk Management is a friend, and who want to be “curators” of the project knowledge in their own project communities are often the very ones who step forward and lead in the Project Closeout and Lessons Learned arena, as well as in their own PMO development and maturity.

So, please keep in mind that it is not enough to espouse good Project Lessons Learned documentation.  You must first look to how your organization is nurturing those Process, People, Capabilities, and Tools for Project Closeout and Lessons Learned.  You can start this journey in your own organization by volunteering to speak to other project managers about your own project experiences and by beginning to examine Facts, Perspectives, and Deliverables for your recent projects in anticipation of capturing Lessons Learned.  Integrate this zeal with a good Project Risk Management Plan and see how it contributes to the success of your PMO or project organization in upgrading the entire project process.

Those of you who have read my blog consistently know that I am interested in two cases in which Project Lessons Learned can be identified from projects.  I call these the Single Project Case and the Multiple Project Case. 

The Single Project Case involves a project manager and his team who wish to identify, document, and share project lessons learned at the completion of a project, usually during the project close process. 

The Multiple Project Case is the case in which several projects are subject to the same “project environment” and, therefore, may exhibit patterns of behavior that are the result of the structure of the project environment.  The “structure” of the project environment is the policies, procedures, standards, and working processes that the project organization establishes to govern the way that the project will be conducted.

As we have discussed previously, the real leverage in looking at patterns of behavior from several projects that are subject to the same project environment is that a single change to the structure could potentially improve the performance of all the projects in the environment.  This is because the structure has dictated some behavior or action on the part of project teams of others associated with the project that have contributed to suboptimized performance.

The purpose of this blog post is to provide a simple “analogy” to further explain the power and leverage associated with looking at patterns of behavior among projects, and tracing these patterns to some action or process in the project environment that contributed to those patterns. 

The simple analogy is the story of a breakfast buffet at a hotel.  From six AM to nine AM each morning, the hotel offers a breakfast buffet to its guests consisting of the usual breakfast foods:  eggs, sausage, oatmeal, coffee, orange juice, muffins, bagels, cereal, etc.  Guests usually serve themselves from a buffet and then sit in a lobby designed with tables for use by the guests during breakfasts and other meeting occasions.  Guests usually serve themselves and then clean up at the end, which assists the breakfast staff in maintaining a continuous flow of breakfast guests.

On one particular morning, as each table completed its breakfast and vacated the area, a member of the breakfast staff wiped the table clean with a damp cloth in preparation for the next guests.  Several breakfast staff noted that there was a sticky substance on each of the tables that resisted the usual wiping with a damp cloth, so that additional cleaning was required.  The incident continued throughout the morning. 

At about 8:50 AM, the manager, who had been informed by the breakfast staff of the sticky substance, observed several guests as they ate and completed their breakfasts.  He approached several tables, and asked if the breakfast staff could examine the tables while the cups, plates, and utensils were still on the table.  It was found that the sticky substance had been deposited on the table by the plastic orange juice cups. 

 A “pattern of behavior” had been identified.  A sticky substance had been identified with each table where an orange juice cup had been place by a guest.  The sticky substance appeared to be the same in each case.

The manager and several breakfast staff proceeded to the orange juice dispenser and observed the following process.  Guests would pick up a juice cup from a stack of empty juice cups and place the cup on a specific spot in the juice dispenser.  The guest would then push a button to dispense the juice into the juice cup.

The manager and the breakfast staff examined the single spot where each empty juice cup was placed by guests.  On that spot there was a sticky substance.

A process that had been put in place to facilitate ease of juice dispensing had caused a bad outcome at the customer environment location.  The process supported the overall structure of breakfast for guests during the time period six to nine AM. 

If the breakfast staff had not acted to identify the incident and its resulting pattern of behavior, the impact on customer satisfaction might have been negative.  At the very least, it might have contributed to the sticky substance being spread to other equipment and guest utensils.

Because the breakfast staff and the manager reacted quickly, however, the sticky substance was removed from the orange juice dispenser.

This analogy is far from being too simple.  It points out that “patterns of behavior” are so important in a project or customer environment that project groups should be attentive to them and act with haste to correct them.

Many such patterns of behavior occur in project environments every day.  Do you take the time to think through incidents and events in your own project environment which can be “patterns of behavior?”

The quick action of the breakfast staff and the manager in identifying the patterns of behavior were a significant step in making the improvement to the process which kept the structure working as planned.

In your own project environment, look for “patterns of behavior” and the underlying root causes for their occurrence.  The leverage you can apply in your business context is enormous.

And the next time you drink a cup of orange juice, think of this example.  You will be glad you did.

In recent blog posts,  I have discussed how individual project and program managers can improve their capabilities and performance through some simple, yet very tangible and actionable, everyday tasks in the project process. 

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!