Mel Bost – PMO Expert

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 more organizations are seeking to close out projects in a more formal, systematic, and documented manner, and that 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.

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.

Several project managers have asked me to expound on my blog post about conquering the great challenges in life, and the six “ADD-vantages” one gains by this effort.  In this post, I want to share about the self awareness that I gained as a result of developing and facilitating Lessons Learned classes for the Panama Canal Authority.

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.

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.

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.

Do you think that you can snap your fingers whenever you need some vital information? 

Do you think that your LinkedIn connections or your Facebook or Twitter friends will come running to your aid whenever you need help?

If it was late at night, and you were sitting in front of your laptop, in a foreign country, several thousand miles from most of your network, with a useless cell phone because you provider had no network, and you needed help, what would you do?

When this happened to me just a few weeks ago, I was thrilled by the responsiveness of my network, and I just had to share this fantastic networking experience with my readers.

Most of you know that I was in Panama recently facilitating two three-day courses on Project Lessons Learned for the Panama Canal Authority’s Construction Division. 

At the end of the second day of the second session, the division’s manager requested that, the next day, I speak to the class about some specific project lessons learned success factors and barriers experienced by other organizations.  He also wanted to know how these success factors and barriers fit into a cohesive project lessons learned system.  He requested this information because he wanted to impress upon the class that Project (and Contract) Lessons Learned would (and should) be an ongoing part of their daily activity.

I left the building that day worried because, while I had many examples, anecdotes, and ideas about project lessons learned success factors and barriers, I was not aware of any single document or study that would address his request.  Since I unfortunately hadn’t anticipated his request, after dinner that evening, I sat myself down in front of my laptop, and began to brainstorm about who in my network might be able to efficiently guide me in the right direction–time was of the essence since I had to be back in the classroom about eight hours later!

During my brainstorming, I remembered that Michael Guidry’s Northwest Arkansas PMI Chapter recently featured Deborah Grassi, a Senior Manager in SAP Change, Training, and Communication at WalMart.  Deborah spoke about lessons learned from a significant WalMart project.  So, I dashed off a quick email to Michael explaining my conundrum.

I sent another quick email to Dan Ranta, a Director of Knowledge Sharing with whom I had worked at ConocoPhillips. 

I also wrote to Wayne Thompson, my frequent collaborator on podcasts for his popular blog “Project Management War Stories.” 

I also recalled that Lisa Austin , a manager of Knowledge Management at Williams Midstream, had recently spoken to the PMI Tulsa Chapter about Knowledge Management at Williams.  While I had unfortunately missed her presentation, I thought contacting her was worth a shot since she and I are connected on LinkedIn.  Lisa quickly replied that, if I had not already seen the website and blog on Knowledge Management in the United Kingdom operated by Nick Milton, Director of Knoco, Ltd., I should check it out. 

Nick Milton was formerly a knowledge management executive with BP.  Now, is a knowledge management consultant who consults with corporations worldwide on knowledge management issues.

I quickly accessed Nick’s website, and found a section on Lessons Learned that included a survey that he had conducted in 2009 of companies in many different industries.  The survey discussed these companies’ varying Lessons Learned practices, which factors had been barriers in establishing Lessons Learned, and which factors had led to success in Lessons Learned and lasting change within the organization.

BINGO!!!

I immediately messaged Nick on LinkedIn and introduced myself.  I explained that we had common interests in Project Lessons Learned, that I was in the midst of teaching a course on the subject, that I had been referred to his website, and that I was very impressed by survey.  I requested that we connect on LinkedIn.  Almost immediately, Nick approved by connection request and explained that he was with a client in China, but that he would love to talk about our common interests in Project Lessons Learned. 

Nick and I emailed a few more times that evening, and Nick was kind enough to permit me to present his survey and discuss its findings with the course participants.

The survey had 74 responses from individuals in such varied industries as oil and gas, engineering and construction, consulting, mining, industrial products and services, etc.  It mainly focused on project groups, and it covered success factors, barriers, key systems components, and other enabling factors. 

As I read through the survey, I was pleased that it supported many of my recommendations, including the use of the After Action Review (AAR) as the preferred basis for a project lessons learned framework, as well as the inclusion of Risk Management when identifying candidates for lessons learned.

The next day, I distributed the survey to the course participants, and we discussed its findings within the context of the Construction Division’s business and project/contract environment. 

Throughout the day, similarly helpful information flooded in from my network.  In fact, nearly one hundred percent of the people that I contacted responded with useful information.

I learned two valuable lessons from this experience: (1) when training, listen—and be responsive to—your audience, as it often provides valuable insight as to how you can develop and improve your materials; and (2) believe in the power of your network!

Remember–the responsiveness of your network is entirely up to you.

As Robert Cialdini has stated in his work on INFLUENCE,  RECIPROCITY is a powerful motivator.   Always do what you can for others before asking a significant favor in return. 

Your network will only be as responsive to you, as you have been in fulfilling its needs.

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.

I have always thought that summer was a time for “renewal.”

After all, isn’t that why there was no school in the summer, and why your parents sent you to those summer camp “enrichment” programs?  It was so you could relax and enjoy some subjects and activities that you were not exposed to during the remainder of the year.  And as you got older, perhaps you had a chance to attend a special summer program in a college or university setting, where other students like yourself could engage in debates and cultural activities that were “enriching.”

At some point in your life, you may have noticed that there was a transition away from those “renewal” activities that were planned by others, to renewal activities that you planned by yourself.  Maybe you didn’t notice this transition since you were caught up in the fast pace of growing up, but, as John C. Maxwell has said, “man has choices and the choices a man makes in turn make him.”

So–Summer is a time for renewal.  It’s up to you to grasp those opportunities for renewal wherever they might be in your life.

And, if you are part of a larger project community, or a member of a Program Management Office (PMO), it might be time for you to seek out some activities to renew your PMO as well.

What better time than the summer to pursue such renewal?

Give this some thought.  How can I as a project or PMO practitioner provide some renewal activities for my PMO?

Show some leadership and initiative to make this renewal something that lasts year-round in your PMO.

For example, look at some liason opportunities with a local PMI Chapter, or some special training that could be brought on-site to enrich your colleagues in the Best Practices of a PMO.

Renewal is up to you.  No one will plan for it any longer.  Summer is a great time to pursue it.  Get started today.

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.

In a recent blog post, I discussed using “Design Thinking” principles to define complete business requirements for projects. 

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.

Project managers who fully experience the project process learn and acquire truth, knowledge, decision-making skills, and good judgment.  There are three primary methods by which project managers may learn these 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. 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?

It has been difficult to pick up any literature on business strategy and business growth recently without seeing the word “innovation” splattered all over the headlines and content.  “Innovation” is such a catchy word these days because the idea inspires people; it connotes taking the innovator to a new height of success.  Likewise, there are some companies whose names seem to “drip” with the word “innovation” whenever you encounter the company’s name:  DuPont, Procter & Gamble, and Apple,  for instance.

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.

“Pay Me Now or Pay Me Later”

Sounds like a hit song or a cry that something may have gone wrong with the relationship at hand.  Turns out that “Pay Me Now or Pay Me Later” describes a number of consequences of project scenarios with which we all are familiar.  It was an expression I coined one time in response to a PMO Manager with whom I worked who wanted to proceed with a contract for services without adequately reviewing the risks in employing that vendor or the services requested.  “Expediency” was the name of the game.  Forget the requirements, just deliver the solution.  Sound familiar?

In this particular scenario, I used a “timeline” to lay out for that Manager the consequences for two scenarios–one in which the vendor did not deliver because the requirements were ill-defined and one in which we took time to evaluate and define the requirements carefully to “frame” the problem adequately.  Of course, this story would not be worth telling if the timeline for the redo and rework ended before the timeline for the complete requirements development.

The Manager signed the contract anyway despite my “drawings.”  And, sure enough, I refrained from saying “I told you so.”

If you survey project teams, project managers and key project stakeholders throughout the various industries that heavily employ project management as a discipline to add value to their respective organizations or to translate strategy into action, you will find that one of the principal problems encountered is the complete definition of project business requirements.  I have alluded to this problem in other blog posts, and in particular in the blog post on “Reframing” the project requirements to provide a more complete and accurate assessment of what problem is being addressed by the project.   Good business requirements are the key to a successful and compelling business case which, in most PMOs, is the basis for approval, rejection or deferral of a project. 

Among the many remedies for the lack of adequate business requirements definition which are found in project literature is the use of very disciplined approaches for defining business requirements by use of templates, coordinated facilitation of group meetings and very detailed descriptions of the “as is” and “to be” project environments.

Every year there is an enormous amount of rework, redo, and replanning of projects due to incomplete and inaccurate definition of business requirements by project teams.   What are some of the shortcomings of business requirement development that most project managers and PMO practitioners will recognize?

1.  Use of a “Once Through” Approach:  The “once and done” syndrome is rampant in business requirement development because of the desire to get on to the “execution” phase which is most often deemed by project teams as the most important phase.  Very little “iterative” approach and retesting of business requirements (and original project ASSUMPTIONS) takes place in actual project work.

2.  Abdication of Business Requirement Development by the Group most affected by the Project:  Usually a business-driven project will have functional and business representatives and stakeholders work with the IT group to develop business requirements.  In many cases, I have seen the business/functional group abdicate its position in the “dialogue” in favor of IT or another lead group taking over the entire process.  This has the effect of the development of business requirements from only one single point of view or perspective and leads to “interpretations ” and “judgments” which, if not tested appropriately, will result in poorly defined business requirements.

3.  Narrowly defined interface requirements between people/functional, functional/technology, and people/technology interfaces:  This results in technical feasibility and market viability often being ignored and the people/functional interface being treated with simplistic ideas for solutions.

4.  Requirements that are not truly “empathic” in their derivation:  Often the stakeholders’ real requirements are not surfaced in the “dialogue” because a singular perspective is applied by the IT group facilitating the dialogue with the business/functional group.  A real visceral understanding of the emotional, social, cognitive, and physical needs of the stakeholder are not defined.   “Empathy” requires looking at things from the users or stakeholders point of view without interpretation on the part of the dialogue facilitator about what the stakeholder or user really “wants.”

5.  Poor “dialogue sessions” between requirements gathering group and the stakeholders or sponsors of the project resulting in rework and redo to create a business case that truly reflects the business requirements being targeted.  I have written about this in another blog post about what to do if your PMO does not execute as expected.

You can certainly extend or expand this list from your own project experiences and I encourage you to write down your observations and test them with others in your project community who are subject to the same project environment.   You will be surprised at the recurring themes, many of which occur because of the similar approaches in building business requirements that are defined within the “structure” of your PMO organization and culture.

You may recognize that one reason for the rise in interest in other methodologies such as AGILE and JAD is specifically because these methodologies address some of the shortcomings in the previous ways in which business requirements were developed.  Utilizing iterative techniques, incorporating more than one point of view and prototyping have been accepted as very applicable to many project situations.

I would like to propose that we take a new approach to project business requirements definition based on principles of “design thinking.”  Design Thinking is an approach to innovation.  In fact, it has often been called “human centered innovation” because of the focus on physical, emotional, social and cognitive needs of the stakeholder or client.  Design thinking has been used successfully by consumer and industrial products companies as well as service providers to open up new markets, define new products, identify new partnerships and to solidify relationship management for parties involved.   Design thinking starts with “empathy” which means looking at things from the viewpoint of the stakeholder, user or sponsor.

Tim Brown, the CEO of IDEO, has written extensively about “Design Thinking” and his reference book on the subject is Change by Design.  And A.G. Lafley and Ram Charan have written about “design thinking” and its associated facilitating framework known as “integrative thinking” in their book Game Changer:  How You Can Drive Revenue and Profit Growth with Innovation.

In a WSJ article early in 2010, Estee Lauder CEO Fabrizio Freda, formerly an executive with Procter & Gamble and a leading advocate of “design thinking” in product development at P&G, said “We don’t want to just do the products that consumers want.  We want to be inspired by consumer desires and surprise them with products that they don’t expect.”  That takes a deep understanding of the cognitive, social, physical and emotional needs of the clients, consumers and customers.  But it also applies to project business requirements development.

Here are some specific actionable things you can do from a “design thinking” perspective to enhance your business requirements definition:

1.  Listen.  Employ “empathic communication” to understand the viewpoints of the stakeholders, users and sponsors.  Listen to the “stories” and “anecdotes” that your stakeholders tell each other.  Often they will reveal their anxieties, worries and fears along with other needs that are never mentioned in their straightforward conversations.  Engage them in “storytelling.”  Recall the account of the SAP project manager from one of my blogs who spoke to everyone who would potentially be affected by the changes introduced by his SAP program.  His method of “empathic communication” elicited many business requirements and business opportunities of a very detailed nature.  It also built “commitment” from the ground up for the program scope, issues and approach which the project manager wanted to pursue.

2.  Look for analogous situations or scenarios to develop deeper insights into the needs of the customers.  Tim Brown, CEO of IDEO, one of the pioneering companies in “design thinking” techniques often talks about some work they did in redesigning the processes for a hospital emergency room.  They talked to so many ER “experts” about what could be done that they decided to seek an analogous situation.  So they studied NASCAR pit crews.  Notice the similarities:  high pressure, high competency requirements, ability to work as a team and as individuals in  a time constrained , close quarters environment.  Often sharing the analogous scenario with your stakeholders can stir their innovative and creative instincts.  I mentioned in a previous post the analogy between project manager and movie director.  Look at the similarities between developing movie script, background, character and actor development and managing a project’s requirements.

3.  Prototype the business requirements situation as best you can.  This will provide additional insights into “real needs.”

4.  Expand your questioning of stakeholders to other than just “superusers” of the systems or new processes.  Tim Brown often tells the story of redesigning cooking utensils for the kitchen.  After continually using experienced cooks for requirements gathering, they brought in a group of children and asked them to put the utensils through their paces in some cooking classes.  The dexterity and handling requirements were immediately accentuated because the children had very few preconceived ideas about how the utensils were to be used.

5.  Read or view some background information on “design thinking” and “integrative thinking.”  Lectures by Time Brown of IDEO can be easily found on the internet.  Also, some business school curricula are now embracing “design thinking” as a basic tool for business strategy and requirements gathering.  See the work of Heather Fraser at DesignWorks which is the model school for design thinking at The Rotman School of Management at The University of Toronto.  Dean Roger Martin’s work on “integrative thinking” can be found in his book The Opposable Mind.

This is just the starting point for opening up a whole new panorama of requirements gathering techniques and validation.  Design Thinkers use the whole world experience in their designs.  Project managers should do the same.

Now, “Pay Me Now or Pay Me Later” should take on a whole new significance to you.  Give me some feedback about your most useful “design thinking” techniques and how you employed them.

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!