Mel Bost – PMO Expert

Those of you who follow my blog site know that I have written recently about the fact that Lessons Learned are all about us.  They occur in every discipline and field of endeavor we might pursue.  They arise as the result of actions of the participants and consequences of those actions or what is commonly referred to in project jargon as “outcomes.”

Everyone can participate in gathering, sharing, documenting, and capitalizing on lessons learned, no matter what their individual backgrounds might be or what field they may be interested in.

I am particularly interested these days in “innovative” techniques and methods for capturing lessons learned and the various ways that they are used to improve processes in daily life.

This morning I heard about a new venture that Marlo Thomas is pursuing on Broadway.  You will remember that Marlo Thomas is the daughter of Danny Thomas of early TV fame and a staunch supporter of St. Jude’s Children’s Hospital in Memphis.  Marlo herself starred in the TV show THAT GIRL with her steady boyfriend Donald.  I am not sure we ever heard what Donald’s last name was.

Marlo Thomas is appearing on Broadway in Relatively Speaking, three one-act plays by Woody Allen, Elaine May, and Ethan Coen that ”explore the often outrageous reality of relatives.”  When she discussed the specific details of the performances on TV this morning, one thing particularly interested me.  The playwrights for each play attend a play each week to see firsthand how the performers interact, how the plot unfolds, how the emotion runs, what the audience reaction is to various actions of the actors, etc.  In other words, the playwrights are getting an “in process” look at their own work each week.  They use this insight to change certain aspects of the play for the upcoming stage productions of the plays.

What an innovative approach!!!!   Reminds me a little of our discussion of project managers identifying lessons learned at the end of each major stage of a project which we have discussed several times in this blog.  This method also gives the actors insight into how their performances are being perceived and received by the audience so that they can adjust their actions accordingly.

If you are a project manager looking for ideas about how to improve your project, why don’t you try to “observe” the actions of your actors in their natural setting at least once a week.  How do they interact?  How do they interpret their lines and deliver the outcomes?  How does the entire project “play” out under your direction and initial charge to the group about what was the desired outcome of the project.

I will bet that many of you project managers have never attended a project review for another project in progress.  Try that sometime to see how others are approaching similar situations and how the various project actors are playing out their parts.

You will be very happy when you do this for the insight will rush over you like a wave on the beach.

Let me hear about your successes.  Good luck.

Sometimes project managers are as much informed by their projects, as they inform their projects.  And sometimes the lessons they learn are as valuable to the broader scheme of life, as they are to their projects going forward.

What does that mean?

It means that the total experience of carrying out and managing  a project sometimes adds a richness to a project manager’s experience that no training, no development course, no experiential modeling, no simulation, and no textbook could ever provide.

It is these experiences that project managers should reflect upon in order to draw out some real lessons when dealing with the physical, mental, social, and emotional states of project management.

This is the story of one such encounter from my experience.  I hope it provides you with some insights, and I hope  that you share your own similar experiences in projects so that others in the project community may benefit.

In 1996, while working for UNOCAL 76 Products Company as a Marketing Operations Analysis project manager, I was pressed into service opening convenience stores under our “Fastbreak Format” program.  This was an initiative to construct and operate convenience stores ranging from 1500 square feet in interior size to 2500 square feet interior size.  Many of these convenience stores also included fast food sections that featured Carl’s Jr., Subway, or another food brand.

As a project manager, it was my job to take the site from the Construction group, and then implement a plan for completion of store’s interior layout (including fixtures for the display of soft drinks, candies, and snacks) while also completing the store’s exterior layout (including underground fuel storage tanks, fuel dispensers at the islands, and other features).  Systems in the store included Point of Sale equipment that was sourced by major suppliers and installed by a special UNOCAL systems group. 

Obviously, coordination and timing were of the essence in such an operation.  I had at least ten bosses from various groups who always wanted to make sure that their portion of the exercises was completed on time, on budget, and fully operational.

There were two C-stores in particular that I remember from this experience. 

One was located in an inner city area of Los Angeles.  It was a 1500 square foot interior C-store that was to be franchised by a couple in the local area. 

The other was a 2500 square foot interior C-store that was to be a company-operated store on a freeway location just north of San Diego. 

The larger C-store was equipped with several islands for gasoline dispensing, while the smaller C-store had only two islands for gasoline dispensing due to the small lot at the inner city location.  The smaller C-store was equipped with a bulletproof glass partition that separated the operator from the customers after certain hours of the evening.  The larger C-store, on the other hand, had an open and spacious layout with extensive coolers for a variety of cool drinks and beverages.

The larger C-store had a company-employed manager who was already a manager at a nearby C-store about ten miles from the new location.  Although it was his responsibility to manage the store upon opening and to assist me prior to opening, it was solely my responsibility to manage the project, interface with all the suppliers and vendors, work with all the company systems groups for installation of systems, and determine when the store was ready for operation. 

In the case of the smaller, franchised C-store, my principal responsibility as project manager was to complete the project, interface effectively with the couple who would operate the store upon opening, and determine when the store was ready for opening.

The couple who had franchised the store had two children under age ten, and a grandmother who was always with them during the construction, installation of equipment, training, and opening of the store.   Although the manager of the larger C-store was extremely helpful in carrying out routine tasks in getting the store ready to open, he was also very impatient to “get his hands on the reins” and drive the stagecoach.

These two stores were going up concurrently, and I lived about half way between the two stores.  I divided my time each week between each location as I managed the various project tasks that had to be staged to bring each store to a ready state.

Occasionally during the work, a representative from another UNOCAL group would appear on-site to talk to either the franchisee or the company store manager.  These discussions, of course, always involved me as a principal participant in the preparation of the site. 

There were always issues in the opening process that required my liaison with another UNOCAL or supplier group.  For example, we encountered systems problems with installation of the Point of Sale equipment in the smaller C-store because the satellite communication equipment for credit card authorizations was not working properly.  So, a supplier from the network systems vendor was on-site much of the time during that phase of the setup, diagnosing and troubleshooting the satellite communications.   This meant that I had to describe the problem, the planned solution, and the timeline for fixing it to the franchisees.  Although nothing in the project plans called for informing them about how this interface with going, I felt an obligation to let them know exactly what problems we were encountering since they seemed to be at the site 24 hours a day.

As the two stores slowly took shape, my drive from my home to each location each day provided a good time to reflect and plan and digest and understand the C-store operators’ different agendas.  My obligation was to provide an open C-store, free of any systems issues, and ready for steady state operation. 

The smaller C-store was ready first even though we had been delayed with systems problems several times during the project.  I began to think of the training that the franchisee couple had received as the store neared completion and wondered if they were really prepared for what was to come.  They would have control over when the whole C-store would be open to the public and when customers could interface with the manager only through the bulletproof glass partition.  This was in stark contrast to the freeway location for the larger C-store where hours were almost unrestricted.  Although 24 hour operation was not common at that point in time, the store was open from 6 AM to 10 PM.

On the last night when I drove away from the smaller C-store, I was assured that the couple had sufficient training to see the store’s opening through.  I made sure that company personnel and vendors/suppliers had called on them enough that they had phone numbers and contact information with backup numbers if necessary.  The wife asked “does this mean we will not see you again?”

I wasn’t sure how to react.  All I could say was “yes, I had completed my project and felt they were prepared to operate the store successfully.”  But that is when I realized that this was more than just a project; it was their livelihood, and lives were dedicated to making this venture work.

As I drove away that evening, I questioned whether I had done my best to prepare them for the days ahead.  Had I coached them enough on the credit card system?  Had I helped them enough to understand the dispensers and the card readers?  Had I really treated them like they were going to be successful in this endeavor?  Only time would tell.

Meanwhile, the larger C-store was nearing completion.  More corporate people were appearing everyday to question the store manager and his staff on their particular areas of influence and control.  As we neared completion, I participated in the training of the staff to handle every aspect of the store.

It was solely my call whether the store was ready for operation.  As project manager for this C-store opening project, I weighed all the evidence and decided that we needed one more day to be sure that everything was in working order.   My store manager disagreed and voiced his disapproval to the Business Development Manager for the region.  Although the BDM was concerned, he recognized that I was the only person who had been on-site every day, knew every piece of ground, had talked with every vendor, had questioned each systems development specialist, had operated each dispenser, and each card reader.

As it turned out, we did have a minor systems problem on that last day before officially opening—a problem that no one, not even me, could have foreseen.  It took several hours to resolve, but I knew better at that point than to make a big issue of why we needed one more day.

As we opened the larger C-store, I thought of the smaller C-store and the vast differences between the two….the differences in location, market, operations, and especially the challenges for each.  Had I done my best to prepare each one to succeed?  I learned so much from the experience that I am sure it affected my approach to future projects and the people involved.

John C. Maxwell can be a mesmerizing speaker.   When he exhorts you to give your best, you give your best.  When he beckons you to take on a great challenge, you say “How soon can I start?”

I just listened to his audio CD lesson on ”Conquering Life’s Great Challenges” for the fifth time, and every time I felt like he was speaking directly to me.  Maxwell’s theme is that everyone is faced with great challenges in their life, and those who successfully conquer these challenges are enormously enriched, and better equipped and prepared for the even greater challenges that await them later in their lives.

Preparation is a key ingredient.  Keeping a positive outlook about the end result is essential.  Keeping the drive going when obstacles seem formidable is essential.  But you can do it.

Maxwell says that there are SIX great “ADD-VANTAGES” that one gains from conquering a great challenge:

1.  Adds Self Awareness And Understanding Of Self:    Conquering a challenge makes you more aware of what your real capabilities are, and helps you solidify your thinking about what you have to contribute.

2.  Adds And Builds Confidence:  Conquering a challenge gives a person great confidence to proceed to the next challenge with the knowledge that you have a process for facing and conquering that next challenge.

3.  Adds Personal Growth And Stretch:  Expands your capabilities to handle key issues.

4.  Adds Momentum:  Creates the drive to move forward proactively with other key challenges.

5.  Adds New Territory and Growth into New Activities.

6.  Adds Great Value To Others, Their Lives, And The World In General.

Maxwell goes on to say that, before an individual attempts the challenge, an individual’s world is filled with questioning, intimidation, fear, and uncertainty about his own ability to meet the challenge.  But completing the challenge creates a sense of breakthrough, encouragement, strength, purpose, and value.  What a difference completing a challenge can have on the willingness and proactive behavior of an individual.

In my case, my most recent great challenge was to develop and facilitate a new Project Closeout and Lessons Learned training for an organization that specifically requested the training because it desired to fill a void in its current project process.  The organization also wanted to instill a culture that valued the discipline.  The organization was itself faced with a great challenge in the form of a major super-project that was taking place over a number of years.

While Project Closeout and Lessons Learned is one of my favorite topics, and one I had been preparing to tackle for many years, my work for this organization spurred me to focus in-depth on the area for a sustained period of time, leading to my own personal development in each of the six Add-Vantages mentioned by Maxwell in his lesson.

At first, like many of us when faced with a new project, I faced all of Maxwell’s classic roadblocks.  I felt fear and uncertainty that I would be able to deliverm, but I forced myself to overcome this fear.  After I prepared a training manual and a well-choreographed presentation, I still had to travel to the organization and present the final product.  As I was leaving, one of my closest friends said “Just think how much you will be contributing to their capability… continuous improvement and lessons learned will be invaluable to this organization in creating overall project and program success.”

Once there, I knew that preparation would be the key to overcoming any remaining fear.  I surveyed the training facilities carefully and I was committed to make the training times as compatible with the participants’ normal workdays as possible.  Since everyone agreed the 7:30 AM to 4:30 PM were their normal working hours, we adopted that timeframe.

I disciplined myself to be ready to fire on all cylinders at 7:30 AM each morning, to have a working lunch prepared for the lunch break, and to be ready to answer the participants’ questions and to rephrase any concepts necessary to make sure they understood.

As the class days advanced, my confidence was building–I was very assured that my Project Closeout Framework was sound.  Our group discussions yielded some great insights.

In my experience during this training session, I gained a great deal of insight into my strengths.  My best times for action are between 6 AM and Noon.  So, it is best for me to capitalize on that timeframe for my most significant work of the day.   I also learned that I have a tremendous network of willing colleagues in the project community who can be counted on at a moment’s notice.  I also learned that my Framework applies equally well to contract closeout and to project closeout.  I learned that a simple feedback diagram showing “Process,” “Result,” “Lessons Learned,” and the feedback to continuous improvement of the “Process” can apply generically to just about any process an organization wants to pursue.  What a grand revelation and one that would not have been recognized without the assistance of a flip chart and an attentive class that demanded the very best of my efforts.

So what is my next great challenge?  Writing my book on Project Closeout and Lessons Learned.  The Framework, which once graced a few napkins on a lunch table, will now be immortalized for everyone to use.  The application of this Framework will be a leverage tool for project groups and PMOs to succeed and to produce significant results in their work.  This book will also complement BOT International’s new Advisory Services for Project Closeout and Lessons Learned Consulting.  As Practice Head for this new Advisory Services area, I will be responsible for assisting companies in instilling a new Project Lessons Learned culture that will enable project practitioners to “master” lessons learned as a continuous process improvement discipline.

So Mr. PMO–when you are faced with your next challenge, take heed to John C. Maxwell’s words on conquering great challenges.  Not only will you prepare yourself to willingly take on those challenges, you will also add tremendous value to your PMO in your ability to tackle ventures and projects that Management dictates.  It will also build “resilience”–a leadership trait that is highly valuable in this risky economic and political climate.

Step up to the plate–you have the ability to innovate, to meet any Challenge, to conquer any language barrier, to overcome any cultural conflicts…if you will only focus on the task, and keep a positive attitude in the face of any setbacks.

Let me know what great project challenges you are tackling.

Everyone is talking about “Lessons Learned.”  With the wrath of hurricane Irene being felt up and down the east coast this week, David Gregory asked the FEMA Director on “Meet the Press” Sunday what lessons had been learned from Katrina that positively impacted the response to Irene.  Governor Christie of New Jersey declared that there would be an after action (review) of the response in his State to Irene.  “”Lessons Learned” became a buzzword in the press again.

What is my definition of a “Lesson Learned?” 

A “Lesson Learned” is an EXPERIENCE or EVENT that can be used to improve a process.  Lessons Learned arise from many different activities in life.  They can arise from car accidents, military conflicts, weather related events or just about any activity in which an ACTION leads to a RESULT or OUTCOME.  “Lessons Learned,” if captured and shared can lead to an improvement in the way these ACTION processes are handled in the future.

My experience lies in the area of Project Lessons Learned.

I have written extensively over the past two years in this blog and also through the podcasts with Wayne Thompson of “Project Management War Stories” that Lessons Learned are here to stay.  Companies and clients of many companies are demanding better mechanisms to guide their continuous improvement activities.

So, get with it!!!!    Lessons Learned for many daily processes and activities are here to stay.

Why is “Success” magazine so successful? 

Is it because the articles are so skillfully written that readers feel compelled to read the magazine cover to cover? 

Is it because the insights are so insightful that no reader can resist the articles?

Is it because John C. Maxwell always seems to grace their pages with his deep insights into Leadership?

No.

It’s because everybody, no matter what their chosen field, or discipline, or career path, wants to “get better” and to “improve” their performance and their happiness in their chosen field.  People are searching every day for that bit of wisdom that will give them a clue about their own lives and their own happiness.

And you as a reader of this blog are no exception. 

It’s why you have accessed this website.  If you are a seasoned project manager, an aspiring young project manager, or a practitioner from another discipline or field, the idea that something “learned” may contribute to your achievement and happiness is important. 

And “project lessons learned” is even more important because everyone takes on “projects” large and small, formal and informal, approved and unapproved, budgeted and unbudgeted, every single day.

I have been studying and writing about project lessons learned for a number of years.  I helped a major Fortune 500 company develop a robust project lessons learned process and framework for their PMO organization.  I have contributed to several podcasts on the subject that have been well received by the project community.

Dan Pink’s work on “drive” is also very relevant here.  In studying groups that are engaged in highly complex work with significant intellectual content, he has found that three major motivators are at work:

1.  Autonomy:  This is the need for self-direction, the need to determine what and when a person will pursue in order to reach his own goals and objectives.

2.  Mastery:  People want to master their chosen “discipline” or field.  In the case of project managers, mastery means project managers want to pursue project lessons learned as the culmination of a successful project, as the pinnacle of sharing experiences and insights with the project community.

3.  Purpose:  People engaged in highly complex and intellectual work seek a higher purpose than just the profit motive for their efforts.  They want to know that the larger community of which they are a part will benefit from their efforts.  In the case of project lessons learned, they want to know that the project community will benefit long-term from the capture, documentation, and sharing of lessons learned.

Early in 2011, I predicted that we would see more Program Management Offices (PMOs) focusing on Project Lessons Learned as a primary rather than a secondary focus (as has been the case in the recent past). 

My interactions with many PMOs have revealed that this prediction is becoming true–more organizations are seeking to close-out projects in a more formal, systematic, and documented manner.  Project Lessons Learned is an excellent framework to follow when closing-out projects.  

There is no doubt that those organizations who successfully “convert” Project Lessons Learned into process improvements will gain a competitive advantage.

I just got back from working with the Construction Division of the Panama Canal Authority.  They hired me to train them on a Framework for developing Project Lessons Learned.  I facilitated two, three-day Project Lessons Learned courses. 

The Construction Division Management was fully supportive of introducing a Framework that would add to the “capabilities” of its staff to identify and document Project Lessons Learned.  They were committed to creating a continuous improvement project management environment that would close-out projects and contracts with an “actionable” Framework.

This Project Lessons Learned Framework will help the Construction Division successfully complete the major projects that make up the Panama Canal Expansion Program.

Their commitment was indicative of what I am finding as I talk to more and more PMO groups.   They all want to “get better” at closing out projects and contracts in a manner which creates “actionable” results within a continuous process improvement context.

If you are interested in making that next step toward full commitment to capture, document, and share Project Lessons Learned with a simple but effective Framework that focuses on Risk Management and continuous process improvement, please contact me to schedule a similar course for your organization.

You will be glad that you followed through–as a Benchmark group within the wider context of your organization, you can set the example for others to follow.

“We had everything to gain by planning and working closely together to advance the development and maturity of our new IT Project Office, but it seemed that every time we would take a step together in the right direction, one of us would sideswipe the accomplishment by acting irrationally or in what seemed like an irrational manner.”

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.

Recently, I collaborated with Wayne Thompson, author and host of the very popular blog “Project Management War Stories,” to develop a podcast covering one of the topics that I have frequently written about in this blog–Project Lessons Learned. 

Part One is now ready for your listening. Part Two is also ready on the same site. 

As I alluded to in my last blog post, I believe that more companies are seeking to close out projects in a more documented manner and they are using a Project Lessons Learned Framework to do so.

Those of you who have followed my PMO Blog for some time know that I am very interested in Project Lessons Learned and their impact on future project team behavior and success.  

Among the themes that I have developed are:

1.  Why it is desirable to conduct Project Lessons Learned reviews at specific intervals in the project such as Phase Gates rather than waiting until the Project Close Process?

2.  What is the actual cost to the PMO for not developing and sharing Project Lessons Learned?

3.  How PMOs can make Project Lessons Learned a Best Practice in their organizational and business context.

In 2011, I predict that we will see PMOs focusing on Project Lessons Learned as a primary focus, rather than a secondary focus (as has been the case in the recent past).  More organizations are seeking to close out projects in a more formal and documented manner, and Project Lessons Learned is an excellent framework to follow. 

Here are some other items I see 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 the Phase Gates at the end of each project process.

2.  Project Lessons Learned will eventually be captured and stored in new systems such as the Microsoft Project 2010 client and server, so that the information can be treated as just another piece of performance reporting information for a project.

I recently collaborated with Wayne Thompson, host of the very popular blog “Project Management War Stories,” to develop a two-part podcast on Project Lessons Learned.  I will post the first part of the podcast in late February, and the second part in early March.

I would be interested in some comments from those of you actively working with Project Lessons Learned in PMOs.  Please contribute, and I will continue to monitor and assess the increase in usage of Project Lessons Learned.

This past week was the fifth anniversary of Hurricane Katrina’s devastation of New Orleans.  The commentary on “Meet the Press” stated that it was the largest “man-made” disaster in U.S. history; not the largest “natural disaster.”  Why?  Because at some point in the past, a large (failed) project was undertaken to reinforce New Orleans’ levee system.  This project was supposed to reinforce the levees so that they could withstand the flood waters of anticipated hurricanes and storms.  Unfortunately, the levee system failed during Katrina. 

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.

In an earlier post to this PMO Blog (“What is the Impact of Project Environment on Project Lessons Learned and Knowledge Management” ), I talked about observations from my experiences working in a PMO setting about project lessons learned (observations which have been confirmed by others using systemic thinking principles). 

Project lessons learned can arise from two sources:

1.  From the individual project in question, usually by the project team’s analysis of their behaviors and actions leading to observed actual results. 

2.  From the project environment, usually by analysis of the “structure” of that environment and its effects on project team behavior.

Obviously, project lessons learned come from post-project completion analysis.  Project lessons learned are intended to inform and impact the future behavior of new and existing project managers in new future projects where similar project environments were considered the “as is” process state.  By using some systemic thinking principles, it is possible to effect the behavior and results of many projects “playing in the same space” by making changes in the project environment.  This is often termed as “leveraging actions” to the project portfolio.

Now what does that really mean? 

The project environment is composed of the external corporate environment and the internally created corporate environment.  Usually, the organizational and governance structures for a PMO group are defined and evolve over time as the organization evolves.  The structure put in place by the organization has a great deal to do with how people act, behave, and make decisions within that project environment.

We have often heard the expression that “structure influences behavior.”  The structure of the project environment is made up of the policies, standards, procedures, defined relationships, reporting linkages, etc, that constitute the working environment within the firm.  We are also aware that, in the dynamic complexity of project environments these days, well-intended actions can lead to unintended consequences.  John Sterman at MIT has studied this type of behavior extensively.  This is because the “cause and effect” are not close in space and time, and some nonlinearity may occur in which an action or decision on the part of a person or group may lead to unintended actions or behavior by others based upon their interpretations in their business context.

 Organizations and groups have the “ability” to anticipate and plan what effects their PMO structures will have on project behaviors.   Accordingly, they can take actions over time to react and adapt to unintended results that are occurring as a result of the structure of the project environment.   The project environment is a dynamic phenomenon–we can adjust structure in order to influence project behavior.  This approach to project management, however, is just in its infancy and requires some art along with the science.

For those of you who may have trouble visualizing how structure might influence behavior, let me offer an example from my experience.  Many years ago I worked as a Product Planner for a major domestic automotive manufacturer in the Detroit area. One of the benefits offered to top executives of the Division and the Company was a company automobile.  Each morning when the executive arrived at the building, he was met by a service technician who asked if the executive had encountered any problems or had any service items that needed attention.  At the end of the day, each executive drove away from the facility with a clean, serviced automobile.  At one time, a certain service problem was identified in the field and reported through the service warranty network to the company.  Reports and metrics summarizing the problem were reported through the ranks and eventually were highlighted to the executives in charge of product quality.  However, none of the executives had encountered the problem–or if they had encountered it, the problem was fixed with “same day service”.  The executives’ personal experiences led them to refuse to believe that the reports accurately identified the extent of the problem in the field.   The reported problems were not taken seriously.  In some cases, only one executive in twenty might have encountered the problem and, if he weren’t assigned to Product Quality, the problem was forgotten as just another ”minor” flaw.  As a result, the Division failed to react to a mounting service problem.  The structure of the executives’ benefits–the company car–had influenced behavior to such an extent that there was actually denial that such a problem existed.

Let’s examine another example a little closer to home in the PMO.  In the early days of defining new Program Management Office (PMO) processes and procedures for ConocoPhillips, we recognized the need to define some “rules” for Project Justification and Approval.  These rules called for the project teams to develop a Business Case to justify the project.  As in similar situations with other PMOs, we attempted to define some structure to answer the question “How extensive does the Business Case analysis need to be and who should be reviewing it for final signoff as an approved project?”  An early attempt to define this standard resulted in a “rule”  that every proposed project over $1 million total cost must have a full Business case with all economics and it must be signed off by the IT Authorization Board.  All projects under $1 million total cost must define a partial business case with limited economics and must be signed off by a subset of the IT Authorization Board.

Now, what happened? You could probably guess that there were many projects proposed at $900,000 or two projects proposed at $800,000 and $850,000 that could easily have been combined into a more strategic and doable project.  Remember:  “Structure influences behavior.”  “Well meant or intended actions can often lead to unintended consequences.”

So, the bottom line for those of you who are designing new PMOs or are working with existing PMOs which have a set of policies, standards, and procedures in place to “guide” the planning and execution of projects is this…..follow some simple evaluation questions I present here to lessen the risk that you will introduce some unintended consequences from your project environment:

1.  Develop some scenarios to test out your policies, standards, processes, and procedures.  Take a typical project and follow it through the Project Management Process to see what the behavior of project managers, team members, sponsors, or other stakeholders might be.

2.  If your policies and processes have been in place for some length of time, test them to see if the thresholds for governance committee reviews are still valid.  In other words, over time your PMO projects may have taken on different characteristics which have increased costs.  The threshold values for review and signoff may no longer adequately cover the portfolio as you had originally planned.

3.  If new technology is introduced rapidly into your process, have a review process in place to determine at the earliest point possible in the process if the new technologies are compatible with current technologies and infrastructure.  Otherwise, you will very likely incur additional costs for these new technologies when they are evaluated.

4.  Check the hurdle rates for your economic/financial analysis in your business cases at intervals to ensure that they are set consistently with the business objectives and the types of projects that you are deploying.

5.  Survey your Project Authorization Governance Groups occasionally to make sure there is consistency in the way each member of the Group is viewing the mission and value proposition which projects present to the organization.

6.  Examine key reporting relationships for the project team within the PMO and understand how the overall structure of the PMO influences where decisions are made and who makes them.

7.  Identify and monitor any cultural or business context issues that might play a major role in the project environment for your organization or industry.  Since these variables are dynamic and change over time, make sure you are evaluating all projects on a consistent basis.  This is, of course, easier said than done.  It involves being a student of the project environment and touching base with others in the PMO to ensure all bases are covered.

8.  Continue to look at project lessons learned and use the information to feed back to the front end evaluation process we are describing at present.

There may always be some project environment variables that are elusive and for which you will not be able to easily identify unintended consequences of actions taken by the project manager, project team, sponsors or other stakeholders.  That does not mean that you should dismiss  this analysis as having no value. 

Remember:  The more you know and undestand about all the variables in the PMO and its organizational setting which can impact project team and stakeholder behavior, the quicker you can identify process improvements and achieve sustained project success.  That is a sign of MATURITY of your project process and is a goal worthy of striving for.

Your comments or feedback on real life situations involving the project environment are welcome.

Note that the question above says the “best time” and not the “most convenient” time. 

The “best time” should be that time which will allow for reflection, feedback and adjustment of any project assumptions or other parameters which would contribute to project success.  It should be that time which will allow win-win solutions to be identified from issues with different viewpoints, as opposed to the compromise solutions which often occur in projects when a full “look back” and “analysis” has not been conducted.

In the past, project lessons learned were often modeled after the “After Action Reviews (AAR)” from the military, in which a review session would be conducted after a military operation in order to capture lessons learned and positively impact the behavior of the team in future exercises.  This was a convenient time for such reviews. 

The “After Action Review” methodology was carried over to modern project management much as other practices are carried over from one discipline to another….without proper regard to what contributes the most to success in the future endeavors or in the current project at hand.

Instead of waiting until the end of your project, I suggest that you select intervals during the project for such reviews.  These could correspond to “stage gates” if your project is organized in such a way, or they could occur at natural or major breakpoints in activities in the project schedule.  

Documenting lessons learned at multiple points during a project allows a look back at the assumptions versus reality of the project, and affords the opportunity to define new assumptions for the remaining portions of the project.  Also, it allows time for “reframing” or asking the question “What problem are we trying to solve?” with this project. 

How many projects have you seen completed where the project team, in looking back at what was accomplished, realized that they had addressed or answered the wrong question?  “Framing” and “reframing” the major issues in the project is facilitated by conducting project lessons learned at intervals throughout the project.

Now that you’ve decided to conduct your project review at intervals throughout the project, the next question becomes “What framework should I use for conducting a project lessons learned session?” 

The usual questions asked in a Project Lessons Learned exercise are as follows:

1.  What was the expected result?
2. What was the actual result?
3. What is the deviation of actual from expected?
4. What is the Lesson Learned?

While this is a good starting point for capturing and documenting lessons learned, let’s take this one step further.

I would recommend you look at the work of Roger Martin, Dean of The Rotman School of Management at The University of Toronto, to find a good framework for examining project lessons learned during the course of the project. 

Over the course of about fifteen years, Roger Martin studied how successful leaders think.  Leaders from many different fields were interviewed and a thought pattern was discerned.  Roger Martin termed this “Integrative Thinking” because it differs from “Conventional Thinking.” 

Among the features of “Integrative Thinking” which makes it a good methodology for examining project lessons learned are the following:

1.  Examination of more salient features of  the project which might not have been considered when the original project was “framed.”
2. An integrative look at other issues which might impact the project so that a holistc view of the project, and its impact on all stakeholders and the environment is considered.
3. An attention to architecture of the project and its major issues which give a good overall view of the systems dynamics involved in the project.   This also provides clues to “dependencies” between your project’s deliverables and those of other projects, i.e. the fact that projects “give” and “get” information and deliverables during the course of the project life.
4. A consideration of opposing viewpoints which does not acquiesce or dominate other viewpoints but which takes into account the valuable features which contribute to a win-win situation rather than a compromise situation.

Let’s take a simple example now. 

Suppose your project has four distinct phases, each succeeding phase beginning at the completion of the previous phase in a linear fashion.  Also suppose you want to conduct a “project lessons learned” session at the end of phase one. 

The sequence of activities you might follow in conducting this lessons learned exercise might be as follows:

1.  Look at results from Phase One.  Are there any assumptions that require revision prior to going into Phase Two based on the results of Phase One?  Have you correctly “framed” the problem in this project based on the results from Phase One?  Are there any other salient features that should have been considered in the project during Phase One that were not considered?
2. From a holistic standpoint and anticipating activities in Phase Two, have we learned anything in Phase One which would impact how we handle Phase Two (or for that matter, any later Phase) activities?
3. Have we correctly planned the architecture of the project so that “cause” and “effect” of decisions and actions taken in Phase One can be clearly discerned in Phase Two and later Phases?  Are we certain of the “dependencies”  between project s and the key “gives” and “gets” between or among projects?
4. How are opposing viewpoints concerning decisions and actions in Phase One being addressed?  Are we taking the best features of opposing viewpoints to find the final solution or do we still seek compromise when opposing viewpoints clash?  How will we proceed to a win-win solution for the project outcomes so that stakeholders are satisfied with the project outcomes?

In conclusion, look for opportunities to conduct project lessons learned sessions and to document the lessons when it makes sense to conduct them.

  The real value of project management is when lessons learned are fed back into project schedules and plans, and positively impact project team behavior and resulting project decisions.  Success of projects is more assured if lessons learned are taken seriously and every team member takes ownership of both the identification and sharing of project lessons learned.