Mel Bost – PMO Expert

I recently had the opportunity to discuss BOT International’s  Project Closeout and Lessons Learned Advisory Services with Mark Price Perry, BOT International’s founder. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Under the leadership of founder Mark Price Perry, BOT International, the company in which I am a Principal, PMO Practice, has assembled subject matter experts in PMO Setup, Project/Portfolio Management (PPM), Governance, and Project Closeout/Lessons Learned to create an integrated project and program management consulting group.

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

The principal subject matter experts and their fields are:

Mark Price Perry:  PMO Setup and Maturity

Terry Doerscher:  Project and Portfolio Management (PPM)

Steve Romero:  Governance

and me, Mel Bost:  Project Closeout and Lessons Learned

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

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

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.

“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.

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.

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 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!

“The mastery of risk is the foundation of modern life, from insurance to the stock market to engineering, science, and medicine.  We cannot see the future, but by calculating probabilities, we can do the next best thing:  make intelligent decisions–and take control of our lives–on the basis of scientific forecasts.”  Peter Bernstein, Against the Gods:  The Remarkable Story of Risk.

“I am used to thinking three or four months in advance about what I must do, and I calculate on the worst.  If I take so many precautions, it is because it is my custom to leave nothing to chance.”  Napoleon I, in a conversation with Marshall Murat, March 14, 1808. 

With the current deepwater oil spill crisis in the Gulf of Mexico occupying much of the news lately, we have heard a lot of rhetoric about “risk” and how BP and the United States should have developed a risk management plan as a contingency in case such an event were to occur.  It is obvious that many people feel that the principal parties involved in the exploration, drilling, and production had no risk management plan in place. 

I suspect that is far from the truth. 

Modern project management practices include risk analysis and risk management as key and integral components of any operating and business plan involving assets and resources. 

Deepwater Horizon Fire--courtesy of the U.S. Coast Guard

Every operational move in the portfolio of projects has key risk management activities that are focused on the two key aspects of risk:

1.  The probability of an event occurring.

2.  The impact of that event if it should occur.

These aspects are then analyzed based on prior information, other incidents, and events, in order to determine a four-quadrant layout of potential risk outcomes.  Typically, companies place the most emphasis on the quadrant of high probability of occurrence and high impact when developing their mitigation and contingency plans. 

The truth is that most mitigation plans and contingency plans are never revealed to the public by project teams unless an event sparks a response.  But that does not mean that the mitigation and contingency plans don’t exist.

Even prior to the project being initiated, most larger companies employ a risk analysis in their overall Internal Audit plan in order to identify risks involving the geopolitical climate for projects, the resource risk, the technology risk, etc.  The Audit universe of projects is then subject to scrutiny as to which possible risks present the greatest exposure to the company.  In other words, which possible risks represent the greatest adverse implications for revenue and profit generation (and possibly, environmental outcomes). 

This analysis, in turn, identifies whether the company should focus additional key resources on areas of high potential for risk events.   For example, if software or hardware development or new technology is considered a high-risk component of a project, then the Internal Audit staff usually provides key IT or other technology resources to guide the project team development in that area.

At the planning stage of major projects, risk is analyzed as an integral part of the Project Charter and Business Case development to alert the Authorizing Leadership Group of potential upside and downsides from project activities.  Indeed, a key and integral part of the decision to pursue the project often focuses on “risk.”

Throughout the project, risk is monitored closely.  Adjustments are made when new risks emerge, and some risks are moderated by project activities.  For example, if the project involves the proveout of new technology during the course of the project, the new technology development is monitored throughout the project so that mitigation plans can be employed at a moment’s notice. 

As part of the Lessons Learned exercise at the completion of a project, the risk management plan is reviewed for its completeness and accuracy of depiction of the events of the project.

So far my discussion has been somewhat “textbook” in nature following the usual Planning, Execution, Close and Lessons Learned aspects of any well defined process.

But, if we examine the reality of the risk management process with actual practice, you will see that there are two aspects of risk analysis and risk management that we have not introduced to this point–the concepts of interpretation and judgment. 

These concepts are concerned with the Leadership aspects of projects.  The actual application of interpretation and judgment to real life risk cases can vary all over the board based on the corporate culture and the context and climate within which risk is defined and managed. 

The aspects of “good interpretation” and “good judgment” should be emphasized more in our understanding of risk in projects.  Noel Tichy and Warren Bennis in their book “Judgment:  How Winning Leaders Make Great Calls” emphasize that judgment is the core–the nucleus–of Leadership.  With good judgment, little else matters.   Without it, nothing else matters.  Risk analysis and risk management without good interpretation and good judgment are devoid of the key elements of Project Leadership.

In your PMO, do you have a well defined risk analysis and risk management plan in place for your programs?  How are the concepts of interpretation and judgment carried out?  Who carries them out?  Top management?  Or the engineers and planners at the heart of the project details? 

If your overall approach to “risk” in your PMO needs examination and updating, take this opportunity to boldly propose new approaches and new viewpoints.  The value addition from such exercises can be enormous.

As usual, your comments are welcome.

Recently I collaborated on a podcast with Wayne Thompson, the host of the very popular blog “Project Management War Stories.” 

Wayne wanted a topic that would continue the theme of PMO structure, organization, and function within a larger enterprise.  We decided to revisit the topic of building a PMO from the “grass roots level”, which many of you will recognize from my previous posts as taking a clean sheet of paper as the starting point.

In this podcast, you’ll learn about:

1.  The importance of  “commitment” vs. “compliance” in the design and success of a PMO.

2.  Issues of  “accountability” vs. “authority” in PMO organizations.

3.  Designing a PMO for a small entrepreneurial organization vs. designing a PMO for a larger, more disciplined, bureaucratic organization.

4.  The importance of including all Stakeholder voices to the design and success of a PMO.

5.  Building “capability” as a critical success factor in the design of a PMO.

Thanks to Wayne for directing this effort–the resulting podcast is now ready for your listening enjoyment on the “Project Management War Stories” blog site.   

Thanks so much for your attention.  As always, your comments are welcome.

There seems to be an abundance of recent research and published information on leadership in organizations these days.  Ironically, however, during the same time that the old method of listing and evaluating “attributes” of leadership has yielded to the critical examination of actual behavior in significant leadership scenarios, there have been fundamental breakdowns in basic leadership in some highly respected public and private organizations.  Much of the recent research and writing has focused on these breakdowns and their underlying causes.

Many of us have observed both good and bad leadership in evolving PMO settings and I am sure we have stopped to think “Now, what could have caused that particular outcome……especially when it seemed that everything was moving according to plan for that project or program?”  In order to avoid such breakdowns in your PMO, let’s consider which criterion contribute to the emergence of key leaders in the Program Management Office (PMO).  In particular, in this blog I want to address how, in the evolutionary stages of your PMO, you can identify the leaders who will ensure the success of the PMO at steady state. 

Now, please understand that achieving a ”steady state“, in the sense of systems and process, may be an ideal situation that each of us hopes to achieve for their PMO.  In actual fact, “change” will always be the norm and leaders will have to respond to “change” in innovative and insightful ways.

In my experience working in an IT Project Office, and in a PMO and helping develop several other PMOs from “grass roots,” I have had the opportunity to work with some remarkable Project Managers and PMO Infrastructure Managers at the inception stage, the developing stage, at partial maturity, and at full blown maturity.  As a result, I have had a chance to compare my observations with the emerging leadership literature.  Make no mistake….these observations are not intended to be exhaustive and complete.  But they should help us to develop a PMO Leadership Model which we can continue to build on as we collectively view more behaviors in PMO settings.

Here is a list of characteristics for emerging leaders in a PMO:

1.  Calculated Risk Taking Attitude:  In my experience working with PMOs, those project managers and project team members who displayed a risk-taking attitude in two key areas were most often the individuals who rose to leadership positions.  First, those project managers who volunteered for the high risk projects because of a “can do” attitude were often the emerging leaders.  Second, when I was directing the development of project lessons learned for a Breakfast Forum in which the project manager addressed the PMO project community about some key lessons from his or her project, those project managers who stepped forward and volunteered for the Breakfast Forums were most likely the ones to rise to leadership positions.  In fact, the first five project manager volunteers became leaders and formal group managers.  So, if you are a PMO developer, look for the “risk takers,” while recognizing that I am talking exclusively about calculated risk taking.

2.  “Commitment” vs. “Compliance” Perspective:  In every PMO, and especially in those that are in the start-up mode, there is a range of attitudes toward the mission, vision, and values of the PMO organization.  At one end of the spectrum is “compliance,” the condition in which a person complies with the processes, standards, and procedures of the PMO, but doesn’t really buy into the overall mission.  These individuals most often come from “operationally” oriented positions which relied on “making a daily list of things to do”.  They often developed a work plan for a certain period of time which was rather inflexible in its components.  On the opposite extreme of the spectrum is “commitment,” a condition in which a person is totally committed to the mission, vision, and values of the PMO even though he or she might not be the most competent project manager in the organization, and even if the direction of the PMO has not yet been established with much certainty.  In my experience working with an IT Project Office and several PMOs, those persons who were “committed” and who demonstrated that “commitment” were most often the individuals who rose to leadership positions.

3.  Effectiveness Through Dialogue and Influence:  In every organization–at all levels of the organization–there are individuals who distinguish themselves by being extremely effective at getting things done through Dialogue and Influence.  These are exactly the people who were the object of research by VitalSmarts (which resulted in such books as Crucial Conversations, Crucial Confrontations and Influencer.)  They are the same people that William Bridges talked about in his book Job Shift who, when faced with rapid or unrelenting change in their organizations, developed the ability to successfully take on the roles requiring negotiations, brokering, translating, collaborating, facilitating, etc.

4.  Performance Focus:  In every organization, there are individuals at all levels whose attention to management of their own performance–and that of their teams–goes beyond what is required of their individual organization’s formal Performance Management Process.  These individuals typically set realistic goals and objectives and measure the outcomes at intervals, making course corrections where necessary based upon feedback and metrics.   These people are conspicuous and stick out in every organization.  They are “authentic” and “genuine” about their beliefs in performance management.  And they rise to leadership roles in a PMO setting.

5.  Formal vs. Informal:  We have all recognized for years that the most visible structures in organizations are those organization’s ”formal” structures.  Organizations are made up of organization charts, processes, standards, and procedures, as well as the underlying principles of efficiency, scalability, predictability, controlling influences; clear, disciplined, hierarchies; and rationality.  But some recent research by Jon Katzenbach and Zia Khan, entitled Leading Outside the Lines , has identified an “informal” character of organizations that may be just as powerful at influencing organizational performance as the “formal” aspects.   The ”informal” consists of loosely defined networks, communities of individuals with like interests.  These communication and information flow mechanisms are far from formal; rather, they are adaptable, local, innovative, ambiguous, spontaneous, collaborative, and emotional.  Individuals who know how to tap into the “informal” structures in the organizations can be leaders too.  In another blog post, I mentioned a very successful project manager of a very large SAP project who recognized that his project was “integrated” tightly with two or three other projects which were scheduled to complete just before his project.  He spent a considerable amount of time ensuring that those other projects had the resources and guidance necessary for their completion because he recognized the invaluable nature of their input and information  flow to his own project.  Now, he could have relied on formal Project Review Meetings to stress to all concerned the importance of their delivery, but he instead he focused on the “informal networks” of cooperation and collaboration to gain “commitment” from everyone that all projects would be successfully delivered.   That effort showed true leadership skills.

You will immediately notice that some of these characteristics pertain to project competency, and some pertain to business and personal competencies.  This is consistent with those Project Management Competency models such as the Boston University PM Competency Model, which stresses not only PMBOK competencies but also Personal and Business leadership attributes.

As you look around your PMO, notice the behaviors of project managers and team members who are  “authentic” and “genuine” and who live the values of the PMO every day.  Through good project experiences and difficult project experiences, there will be many who stand out in the crowd and become the ongoing leaders of the PMO. 

Your comments to this post are welcome.

The usual way that Program Management Offices (PMO) impact the firm’s strategy is through the execution of their “value proposition.”  The execution of projects yields tangible, concrete assets; new processes; or principles of operation that guide the firm and add long term value to the shareholders.  This blog post addresses how PMOs can more effectively deliver long term value and create a competitive advantage for the company. 

In recent blog posts, I have discussed:

o  “Best practices” in a project context

o  “Evolution” of PMOs from a “cost center” IT PMO perspective to enterprise PMOs to specialized PMOs to satisfy specific special business/functional needs in an organization

o  “Reframing” project scenarios to ensure we are tackling the right problem with a project; and

o  Design of PMO structures and functions using a “clean sheet of paper” approach

In this post, I want to leverage the insights of Professor C.K. Prahalad, a management and strategy guru who was recognized worldwide for his strategic intent, core competency and “bottom of the pyramid” theories, who died suddenly on April 16th.  He was a university professor in the Ross School of Business at The University of Michigan (which was my MBA program). 

In an April 2010 article/column entitled “Best Practices Get You Only So Far,” Prahalad discussed “innovation” in corporations from the perspective of looking beyond “best practices” to find what he termed ”next practices,” those cutting edge initiatives that will lead to sustained competitive advantage in a changing world and marketplace. 

This blog is in a sense a tribute to his contribution to strategy and management practice as I apply his principles to the Program Management Office (PMO).

Prahalad argued in this HBR column that today’s top management is too narrow in its focus to see “best practices” and must refocus their initiatives to uncover “next practices.”

He advocates that top management ask six questions in this search for “next practices:”

1.  Is the problem widely recognized?

2.  Does the problem affect other industries?

3.  Are radical innovations needed to tackle the problem?

4.  Can tackling the problem change the industry’s economics?

5.  Will addressing this issue give us a fresh source of competitive advantage?

6.  Would tackling this problem create a big opportunity for us?

In an earlier blog post, we cited the fact that Progress Energy–the utility that serves portions of North Carolina and Florida–had launched a Smart Grid Program Management Office (SGPMO). 

Why did they do this?

The logical answer was that they anticipated that the interest in Smart Grid would result in major project initiatives, not only for their own organization but for other contributing and supporting organizations such as General Electric.   Smart Grid would touch the lives of not only the electricity community but the customers and all stakeholders who have an interest in the application of SG technology.  Smart Grid would be an “evolving” concept because “the more you learn about what you don’t know about it, the more inclined you are to change direction with regard to subsequent actions.”

In other words, the six questions that Prahalad proposed we ask of a “problem” facing an industry and its stakeholders would surely lead to competitive advantage for someone–why not Progress Energy?

So defining a Smart Grid Program Management Office (PMO) was a very “smart” thing to do when faced with all the unknowns about how Smart Grid would play out.

The same could be said of Apple creating a PMO for its financial organization, reporting to its CFO.  The rapid product development that Apple has undertaken in recent years, including the recent introduction of the iPad, meant that the “problem” was how to mass produce sophisticated products that could still meet low cost requirements and a margin that would sustain Apple’s viability.

Many organizations engaging in a ”next practice” analysis will find that establishing a PMO will provide them with a long term competitive advantage.

So what are we saying here? 

Those of you who would seek to plan the next generation of PMO need to look to the six questions that Prahalad succinctly stated in his HBR column.  Finding that “NEXT PRACTICE” will become standard management practice if companies want to succeed.

Your comments are welcome.

While researching and writing this PMO blog, I have observed that, in the last several years, project-focused organizations have increasingly expanded the use of (or created) Program Management Offices within their organizations. 

Historically, the PMO concept first appeared in Information Technology or Information Services organizations, principally because those structures advocated and sponsored more disciplined and consistent/repeatable processes including change management, applications development, and project management processes.  From IT and IS organizations, the PMO then became more widespread in Shared Services organizations which served the larger corporate environment by handling common functions such as Procurement, Financial Services, Facilities Management, etc.  Next, the Enterprise Program Management Offices (EPMO) appeared to serve the entire business organization, or some major business/functional portion of a very large organization.

Most recently I have observed that:

1.  Both Home Depot and Lowe’s, two major Fortune 100 home building supply organizations, have formed IT PMOs.

2.  The Federal Reserve Bank of New York has expanded its IT organization to handle projects through a new IT PMO structure.

3.  Progress Energy, the electric utility serving portions of North Carolina and Florida, has recently introduced a Smart Grid Program Management Office (SG PMO) to handle all projects related to its Smart Grid business.

4.  Apple has introduced a PMO in its financial operations, reporting to the CFO.

5.  Cisco, ADP, Sirius/XM, Microsoft, Time Warner Cable, BP, and many many other major firms have employed variations of PMOs to serve portions of their businesses.

The list goes on and on.

It would be very easy to say that this proliferation of PMOs is simply due to organizations “maturing” to recognizing the “value” added by the PMO structure to the organization.  But, my background in science and engineering led me to search for the underlying issues and ask several knowledgeable people who have studied PMOs from within and without for years.

I spoke with Rich Maltzman (who writes a great blog about project management entitled “Scope Crepe” and who also works in a PMO of a major telecom company) and asked him about his impressions of PMO proliferation.  Likewise, I asked Wayne Thompson (author of the well known Project Management War Stories blog) for input on this subject.  Over the last several years, Wayne has interviewed a number of successful PMO managers for a series of podcasts about the functioning of their PMOs in small to large corporate settings. 

Rich Maltzman said:  “From my Scope Crepe and consulting work, I see that PMOs have long been the bastion–not only of IT–but also of enterprise-level project organizations.  I think, in fact, there’s a danger in not trying to build a community that goes beyond the IT or customer-facing PMs in an enterprise.  The overriding PM discipline and the community of PMs in an enterprise should be respected as a community and there should – even MUST – be sharing between the IT PMs and those who run the enterprises’ projects with customers (i.e. deploying a network, introducing a new pharma product).  So, a PMO at the enterprise level has value in that it builds a strong sense of community for PMs, honors the discipline, shares artifacts, and allows for the career growth of project managers – including job paths that may intertwine between IT and other enterprise functions.”

Wayne Thompson remarked:  “PMOs originated in IT and since IT was traditionally looked upon as a ‘cost center,’ the same view of that role carried over to the IT PMO.  But clearly, moving to the enterprise level with the PMO, organizations have recognized that the real takeaway in employing a PMO at that level is that it clearly adds value (rather than merely incur cost) to the enterprise’s strategies and should be evaluated as such.  Enterprise PMOs deliver concrete results in a disciplined manner.  In my blog work, I have found that PMOs have been deployed for any number of reasons depending on the business and industry context for that company.   And their scope is still expanding.”

This same reasoning applies to organizations just entering the project management discipline area as well.  A recent article “Dechert Puts Every Project Manager Through Project Management Training” (from The Legal Intelligencer) outlined the fact that law firms are now embracing project management as well.  Traditionally, many law firms felt that they were different, and that the work they did was somewhat unique and could not be managed using a discipline such as project management.  Pamela Woldow, a lawyer with the legal management consultant firm, Altman Weil, gathered feedback from general counsels and in-house counsels that they wanted their law firms to operate more like businesses and deliver their services more efficiently and cost effectively.  Consequently, Pamela has been developing and delivering project management training to partners as well as to associates. 

More and more law firms are seeking training in basic project management principles, and Pamela believes this trend will continue as legal firms seek to satisfy the needs of their clients. 

Once again, ”value addition” from a consistent, repeatable process is the key–just as it has been in the ramp-up of PMO structures in major project-focused firms.

So what does this all mean?

In William Bridges’ ground breaking 1994 book Job Shift:  How to Prosper in a Workplace Without Jobs, in which he summarizes the evolution and transition taking place in the traditional notions of work, jobs, and careers, Bridges states that:

“The single organization pattern that is free from this built-in bias (toward maintaining the status quo in organizations) is the project cluster.  Project oriented structures offer the important advantages of tailor-made design to fit unique tasks, flexible resource commitments, defined termination points, and an absence of enduring commitment that encourages a resistance to innovation.”

In the years since this statement was made, I believe that these “project clusters” have taken on the new structure of PMOs, and that PMOs have been deployed in organizations wherever a “cluster” of projects has been the norm.  The expectation is that PMOs will add lasting and strategic value to the organization. 

We are going to see more and more specialized PMOs in organizational settings as time goes on.

I would welcome some comments on these observations as well as supporting or alternative reasoning for the sudden proliferation of PMO structures in organizations.  Your comments are welcome.