Mel Bost – PMO Expert

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

Last week on “The Tonight Show with Jay Leno,” Paul Reiser was a guest.

You may remember Paul as the male lead in the sitcom “Mad About You” which starred Helen Hunt as his wife.  The madcap comedy of this twosome kept me in stitches for many evenings.

Paul was appearing on “The Tonight Show” to promote his new sitcom “The Paul Reiser Show.”  However, as luck often has it in the TV business, Paul’s show was canceled after just two shows on air. 

The way he said the TV executives pitched the cancellation to him was “Well, you have some viewers and then you have not so many viewers.  Your show fell in the latter category.”

So he was a “lame duck” in a sense but, since he was already scheduled for Jay Leno’s show, he showed up to provide some laughs and a look a reality in the wacky world of TV sitcoms.

Jay asked Paul about his two sons, who I believe are seven and ten years of age.  Apparently, the last time Paul and Jay spoke, Jay recalled that the two boys had requested a 3-D TV for their home.

Paul explained that one of his sons had exclaimed “Dad, didn’t you see that last jungle picture in 3-D.  The trees were slapping me in the face as the animals swung through the trees.  It was so real.” 

Paul explained that he had always been a 2-D person himself and, in fact, throughout his life, he had tried to avoid being slapped in the face by anything resembling tree limbs as he navigated the world. 

But, of course, the boys were different.  They really enjoyed the idea that they could actually experience being slapped by something unreal and yet so lifelike in appearance.

To all you project managers reading this blog, how do you treat your projects?  Do you go through the motions, treating your projects like 2-D, always hoping that something won’t leap out and slap you in an unexpected manner? 

Or do you approach you projects with a 3-D mentality, relishing the idea that every slap in the face represents a new opportunity to lead?

If you are experienced enough to have managed several projects, you know that 3-D is the only flavor for projects in today’s fast-paced project environment. 

So why avoid being slapped in the face by treating projects as 2-D?  Take a risk and embrace new experiences and new opportunities to lead–you will be glad that you did.

I genuinely want to share my experiences developing several Program Management Offices (PMO) and an IT Project Office with others who may be facing the same issues and similar situations.  I believe that I have valuable insights about the behavior of project teams, project managers, stakeholders and project organizations that are worthy of sharing with others.   The comments that I have received on my posts from the “project community” have supported my belief.

What do I mean by the word “community” and the phrase “project community”? 

In my mind, a “community” is a loosely connected group of people who have common interests in a field or discipline.  They are all interested in the growth and well-being of that field or discipline. 

A “community” need not be all in the same organization or in the same geographical area.  It does, however, need some framework for sharing information and collaboration.  Such a framework allows the community to benefit from the work of its members, from the input of outsiders whose ideas impinge on the community environment, from academics, and other researchers. 

Social Media and Social Technology facilitate such a community environment.

Rich Maltzman, who writes “Scope Crepe“, first alerted me to the importance of a “project community.”   We were talking about the evolution of PMOs–from strictly IT PMOs, or Shared Services PMOs with a particular “mindset,” to Enterprise PMOs (EPMO), and to PMOs designed to serve specific targeted project goals and objectives or requirements (such as Smart Grid with some utilities). 

Rich said that regardless of how many PMOs there were in an organization, it was important to maintain a sense of “project community” across the PMOs.  “Communities” contribute to the well being and ongoing growth of the members of the community.

In her book Open Leadership, Charlene Li presents an excellent model of “engagement” that could apply to either an organization or an individual engaging a community.  The hierarchy of increasing engagement proceeds as follows:

1.  Watching

2.  Sharing

3.  Commenting

4.  Producing

5.  Curating

The evolution of this blog has followed this model. 

First, I watched as the “project community” embraced the PMBOK, and the literature surrounding the progress of projects in a corporation from early simple executions to large scale executions of tremendous strategic importance to the corporation.  At this point, the PMI and its chapters engaged with the “project community” via publications, on-line web sites, and periodic meetings throughout the world. 

As I progressed through the stages of Sharing and Commenting, I was reacting to the written and spoken words of others in the “project community” who were contributing to the processes, standards, and methods by which good Project Management Practice was being spread throughout the community. 

Now with the stage of Producing, I am contributing to the literature and culture of the “project community” with my own unique observations, analysis and insights.  

I feel that the Curating stage lies ahead because I am still a “youngster” when it comes to “contributing.”  Social mediums, such as blogging, have certainly furthered this journey–and, yes, it is a “journey” of growth and awakening and finding out how much I don’t know about things I should know.

I also write this blog because it has restored some sense of “identity” to me.  When my manager at Exterran Corporation informed me in October 2009 that my company position or job had been eliminated in a budget cut, that my services were no longer required, and that I should clean out my desk and leave the building, I was amazed by my own loss of “identity.”  Like many other people, I largely associated myself, my work life, and my accomplishments with a “Corporation.” 

If you have seen the movie “Up in the Air“, this experience was very much like sitting across the desk from George Clooney and listening to him say, in his monotone voice:

“You are being terminated from the Company and I will need your access badge.  Please be prepared to leave the building as soon as possible with your personal belongings in this box.  And don’t worry.  All  your questions will be answered if you read what’s in this small packet.”

Authoring this blog has renewed my sense that I have something worth saying, something worth contributing, something worth reading and assimilating into the day-to-day “project environment” that the “project community” lives every day. 

The “Journey” has not been without its setbacks though.

Recently I sat across the desk from a manager at a major energy company who said to me  ”You know what your problem is?  You have no ‘brand.’  You come to me with no ‘brand’ that you can identify yourself with.  That means you are really unknown.” 

How untrue.  My brand–and my mission–is to give the “Project Community” the substance that it needs when it most needs it.

The head of a major executive search firm recently said to me “You know what your problem is?  You are like so many other people out there right now with too much time on your hands.   So you write this junk and think others will care about it.” 

The project community does care about these issues.  The proof lies in the comments to this blog and the constant positive feedback that I have received.

What I have to say is directly related to events in our world today.  The BP crisis in the Gulf points to the fact that we really have not learned our lessons from previous mishaps.  Someone needs to keep reminding us.

The Social Media revolution is an event that we cannot deny.  People are relying on other people–through social media–to satisfy their wants and needs; needs they once satisfied by going to established stores, banks, or other institutions.   Charlene Li referred to this phenomenon as a “groundswell“–a social trend whereby people use technologies to get the things they need from each other, rather than from traditional institutions such as corporations.

So, why do I write this blog?  To “connect” to the “project community” and hopefully, to give that community back as much as it has given me over the past twenty or thirty years. 

If everyone were to approach their interactions in a similar manner, they could find the “self direction,” “mastery,” and “Purpose” that Daniel Pink writes about in Drive.

I urge you to consider how you can contribute and give to the “project community.”  What skills, experience, ideas, innovations and specifics can you contribute to everyone who wants to grow and nurture the project discipline in the same manner?  What project lessons can you share with another project manager who is facing a similar situation or scenario?  What project analysis did you perform which led to successful completion of some very difficult phase of a project that you could share with your “project community?”

If you are watching, sharing and commenting to the work of others in some fashion, I urge you to consider “Contributing” through your writing, observations and insights about projects and programs.  Your reward in returns of new information, insights and knowledge will be amazing.

As usual, your comments are welcome.  Thank you for your readership.

Every project manager has been faced at one time or another with capturing, documenting and sharing lessons learned from projects. Besides being a PMBOK Best Practice, it is also a recognized activity by most larger project management organizations and communities in modern project work.

The focus of most project lessons learned activities is on the project itself. What did the project team learn about its project behavior and actions that could be captured for future project managers to benefit from in the project community? Very little work has been done on the other major contributing factor in project lessons learned however. This is of course the “project environment.” Every project is subject to a project environment created by the organization and the external environment in which people function everyday. The neglect of the project environment as a major factor in driving team behavior and influencing outcomes and project lessons learned means that the focus on continuous improvement in the project community has been almost exclusively on the lessons learned from individual completed projects.

However, the potential exists for far reaching leveraging actions to be taken regarding the project environment and the “structure” of that environment that could benefit all future projects as well as provide meaningful insights into project team behavior. And the resulting implications for Knowledge Management are just as great. Knowledge focused on the project environment can provide insights into how we design future project communities which are robust, productive, team inspiring and which lead to greater success for all projects.

This was the subject of my paper presentation at the 3rd Knowledge and Project Management Symposium (KPM) in Tulsa in August 2008. Using some “systemic thinking” principles from Peter Senge and Daniel Kim, I looked at several projects in a corporate environment that were “playing in the same space.” In other words, they were subject to the same project environmental “structure,” policies and procedures. The project team behavior in each case was driven by that “structure” or by the policies in place. So the leveraging factor in improving the performance of those project teams and the projects resided in an examination of the project environment.