• Skip to main content
  • Skip to secondary menu
  • Skip to primary sidebar
  • Skip to footer
  • Home
  • About Mel Bost
  • About the Book

Mel Bost - PMO Expert

PMO Expert

  • PMO
    • PMO Leadership
    • PMO Maturity
    • PMO Benchmarking
    • PMO Execution
  • Risk Management
  • SMART Goals
  • Project Information
    • Project Lessons Learned
    • Project Business Requirements
    • Project Communications
    • Project Community
    • Project Environment
    • Project Manager Qualities
  • Knowledge Management
  • Practices
    • Next Practices
    • Best Practices

What Do I Do if My PMO Can’t Execute?

February 15, 2010 by Mel Bost 2 Comments

A number of years ago, the Los Angeles Dodgers and the Cincinnati Reds played a baseball game in which the Dodgers did nothing right and the Reds did nothing wrong.  The final score was 10-0 in favor of the Reds.  In a post game press conference, the Dodger Manager Tommy Lasorda was asked this question by a reporter, ” How do you feel about your team’s execution today?”  Tommy thought a minute and then replied, “I am highly in favor of it.”

Execution.  Getting things done–consistent, coordinated, controlled execution.  It’s the road to success in today’s competitive global marketplace.  But how do you optimize that execution?  How do you correct your PMO’s execution when you’re not getting the expected results?

I would like to provide one perspective to this question based on my experience working in a PMO and observing the changes in its performance and the actions that we undertook to optimize that performance. 

As evidenced in the baseball game mentioned above, execution includes “actions” and “behaviors” and “decisions” on the part of both teams that lead to “results.”  In a sense, we all develop or forecast “expectations” for those results before they occur, and then we measure the difference between the actual results and the expected results. 

That gap can be very elusive because it contains not only team or group performance items but also individual performance items.  It includes day-to-day decisions and judgments based on information we gather at or near the time of the actions.  It also brings the business context into play.

So optimizing the results from the execution means understanding the “gap” between expectation and actual  and then providing feedback to change the execution.   Sounds like a process lurking in their somewhere!!

Let’s look at an actual example.  Some years ago I was a member of a PMO following the merger of two major corporations.  I had participated in the development of the processes, standards and procedures for the PMO so I understood the “structure” of the PMO quite well. 

During the first year of actual operation following the merger, this PMO was engaged mainly in systems integration and applications/systems rationalization projects as the two merged organizations combined their business systems and in most cases developed a single system going forward where each had had a system before.  An example would be the Credit Card networks of each company being merged into a single credit card system as a result of a PMO project. 

The PMO delivered a number of projects during that first year so that, on a graph of number of projects completed versus time, the upward trend was along about a 45 degree angle.  That performance defined the “expectation” for the PMO.  Nobody stated that expectation as such, but everyone had the idea that the project teams were performing such that they could predict over time how many projects would be completed in the next incremental timeframe.

After about one year in this mode, the emphasis shifted over to the PMO conducting projects for the “business functional” groups in the new merged organization.  During the first year of the merged corporation, those groups had been forming and organizing, and not focused on systems projects addressing business needs.  Over the next year of operation, the curve of projects completed versus time began to flatten out and tended toward some asymptotic level.  The PMO was no longer completing projects at a 45 degree clip. 

What had happened?

A number of us formed a small group to study the structure and execution of the PMO at that point.  We were very aware that there had been a shift from mainly systems integration to new business functional group projects. 

What we found was that there were two basic reasons why projects were lagging in execution. 

First, the PMO had limited financial consulting resources for consulting with the business functional groups on their business case economic analysis.  Such financial consulting was a basic requirement for a complete business case and subsequent funding approval of the project. 

Second, we found that the PMO project coordinators and analysts were having difficulty translating the business functional area business requirements into project scope and business requirements for the projects.  In other words, we were having difficulty “framing” the projects correctly to answer the question “What problem am I trying to solve with this project?”  Subsequently, there were a number of false starts and “reframing” of the projects which led to less total projects completed over time versus those in the systems integration phase of work.

Now the first finding was easily addressed.  The PMO added additional resources to assist with the financial analysis and in many cases partnered with Financial Services to coop those consulting resources. 

Solving the second condition was a little more complex.  When we examined it more closely, we found that the PMO project coordinators and analysts were not holding effective dialogues with the business functional groups to define the project business requirements.  We immediately enlisted the help of “Crucial Conversations” training coordinators to teach effective dialogue within the PMO and business functional groups.  Very rapidly, we began to “frame” the projects correctly the first time leading to good and timely execution.

So, from a prescriptive point of view, what would I suggest you do if your PMO is not executing as expected?

First, look for alignment issues.   Stephen Covey once said “Every organization is perfectly aligned to get the results it gets.”  (See Stephen Covey, “Principle Centered Leadership.”)  Alignment means that business processes, jobs, people, systems, rewards and values and beliefs are aligned so that they support each other in the accomplishment of goals and objectives.  

In the case in which business processes are changed, the other alignment variables must be addressed in order for results to be consistent with expectations.  For example, if a business process is changed which involves a change in jobs and people, then systems and rewards as well as values and beliefs must also be addressed.  Too often in the past companies or smaller organizations within companies have changed business processes and the associated jobs and people without really addressing the systems, rewards, values and beliefs that must support those process changes.  (See Michael Hammer’s Beyond Reengineering for the business model.)  Also look at the Organizational Effectiveness (OE) work by Booz & Company on this subject.

Second, look for changes in objectives or goals or direction.  In the example, the PMO shifted its emphasis from systems integration projects to business functional group projects, which meant a new set of competencies might was necessary to continue with execution as it was expected.

Third, apply some systems thinking to the situation.  (Here, systems thinking can be thought of as in the context of Peter Senge’s Fifth Discipline or Daniel Kim’s work.)

In systems thinking, the organization can be looked upon as a system which refers to organizational structure, culture, processes, procedures, feedback, human interactions, policies and the structure we use to manage the process. 

In systems thinking, we can see organizational processes as either reinforcing processes or as feedback processes.  Reinforcing processes are those in which more is gained as we push harder on the variable defining the process.  Balancing processes are those that tend to retard reinforcing processes.

As a general rule in systems thinking, if a growth scenario appears to be reaching a “limits to growth” situation, then look for the balancing loop that is tending to retard to the growth of the reinforcing loop.  Rather than continuing to push harder on the reinforcing loop, solutions can be more easily found in examining the balancing loop. 

That is why solutions to the PMO scenario in which the project completions were slowing were to be found in the balancing loop which contained the financial/economic analysis as it contributed to the business case and the lack of effective dialogue promoting proper “framing” of the problem and poor business requirements definition.

Fourth, make sure that any major initiative or project which the PMO pursues has a robust Organizational Change Management (OCM) plan to ensure that all the stakeholders of the initiative or the project are addressed according to what is expected of them after the initiative or project is implemented.  If you see results different from expectations following a major internal PMO initiative, look at the associated OCM plan to see how well it performed.

There may certainly be other perspectives on analyzing Execution of the PMO and I invite others to comment on specific situations they have been involved in with PMO activity.  We can all recall a myriad of  interventions we have pursued within organizations to realign expectations and results.   It is a never ending job to continually examine alignment but it is the only method for ensuring lasting, consistent EXECUTION.

Filed Under: PMO Execution

Reader Interactions

Trackbacks

  1. "Next Practices" Initiatives And PMO Formation says:
    April 20, 2010 at 4:06 pm

    […] o  “Reframing” project scenarios to ensure we are tackling the right problem with a project… […]

  2. Application of “Design Thinking” Principles to the Complete Definition of Project Business Requirements | Mel Bost - PMO Expert says:
    November 14, 2010 at 4:41 pm

    […] 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 […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Search The Site

About Mel Bost

Mel Bost is a project management consultant specializing in project closeout and lessons learned, as well as process improvement, best practices, and benchmarking. For the past several years, he has been teaching “Project Management for Research” to postgraduate students at Arizona State University, as well as developing new approaches to the research process. Read More

Project Management Lessons Learned: A Continuous Process Improvement Framework

The NERS department congratulates C. Melvin Bost, Jr., on the publication of his new book.

Categories

Footer

Recent Posts

  • To My Project Community Readers:  Please Support the Fastest Path to Zero Initiative
  • The Role of Cognitive Sciences in Project Management and PMO Performance
  • A Tribute to Louis Tice: What He Contributed to my Thoughts about Project Management
  • How Can Project Managers Use the “Scientific Method” to Finesse Projects?
  • When is Project Management Much More Than Just Cost, Schedule, Scope and Quality?
  • The Importance of Perception in Capturing and Documenting Project Lessons Learned

Read the Book

Search the Site

© 2025 · Mel Bost, PMO Expert · Customized by Element Associates