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.

Image from the Archives Center of the National Museum of American History

When I was about ten years old, growing up in Concord, North Carolina, there was an activity that I really enjoyed each week.  It was watching the “Baseball Game of the Week.” 

Now you have to understand that baseball on television then was very different from baseball on TV today.  There was no WGN in Chicago to carry the Cubs games.  There was no TBS in Atlanta to carry the Braves games.  There was no ESPN to analyze the game of baseball from forty different angles.

There was simply one station–CBS–that carried whichever game it chose to cover, usually from the northeast and, most often, from Yankee Stadium featuring the New York Yankees.  Go figure!!!!

Every Saturday,  I was so excited for the 1:00 PM broadcast that I was actually seated in front of the television, with my favorite sandwich and beverage, at 12:30 PM waiting for the game. 

As a result, I started watching a weekly series sponsored by the National Association of Manufacturers (NAM), entitled “Industry on Parade“, that preceded the baseball game.   The series was a showcase of the latest manufacturing technologies and new approaches to emerging industries, like plastics, after World War II. 

Although they did not emphasize its importance in the weekly shows, “Industry on Parade” was a great introductory course in PROCESS.  In fact, it was probably the best “course” I ever took in PROCESS, as defined by the traditional Michael Hammer definition of  “an organized group of related activities that together create customer value”.  That includes my coursework while earning my undergraduate and graduate degrees in science, engineering, and business.

What “Industry on Parade” did for me was to “imprint” on my mind a visual image of a specific set of activities which together led to a finished product, service, or goal.  The experience had such a profound effect on me that my approach to almost any situation from that point forward was to “look for” the PROCESS behind the actual description of the event.

And so it was that, when I learned about the discipline of project management, my first reaction was to think of it as a PROCESS.  Project management, by description, had a “baseline” or “as is” state.  Any improvements to the way that the project management “state” was planned and delivered then became a PROCESS IMPROVEMENT to an established or “baseline” practice or discipline.

As I observe the way we try to add complexity and more competencies to today’s project management practices, I wonder whether, in our haste to advance the practices of project management, we have forgotten the basic understanding that a project management “baseline” is first and foremost a PROCESS.  In other words, it is set of activities which, when carried out in a specific sequence, yields a planned result that can be forecasted, measured, and made repeatable and consistent.  (See Hammer’s book Beyond Reengineering, for example.)

Understanding a PROCESS is easy when the process is tangible, especially for visual and kinesthetic learners.  Yet, practitioners of project management often seem to fail to see “the forest through the trees”–they fail to grasp that project management is, at its core, the implementation of a PROCESS.  I truly believe that we should return to something similar to “Industry on Parade” for the training and guidance of our next generation of project managers. 

Today, PMBOK characterizes itself as being a process or a series of processes which when taken together constitute “good project management practice.”  But it’s not PROCESS in the purest sense. 

Those who cite PMBOK as the process by which project management plays out are missing the key point that every PROCESS must have an objective, must have controls, and must be measured to ensure that it meets objectives and goals.

Those who develop the next iteration in the project management discipline should look back at “Industry on Parade” as a benchmark in creating long lasting, instructive visual images that illustrated project management as a PROCESS. 

Click here to view a clip from “Industry on Parade”.

 (in the very last section of this clip, the NAM inserted a public-service announcement in which references are made to Communism and Democracy, suggesting that “inflation” is akin to Communism)

Thank you.

I just finished a new book by Seth Godin entitled Linchpin.  It was a very thought provoking book about the realities of today’s job market and worldwide industry outlook. 

In this book, Seth defines a “linchpin” as a person who is “indispensable” to an organization.  A “linchpin” is a person who acts as an “artist” by:

 (1) creating and sharing new organizational knowledge;

 (2) facilitating effective connections among colleagues;

 (3) helping develop creative responses to sustain the organization going forward; and

 (4) facilitating the organization by dealing with complex and often nonlinear system dynamics issues that, if unaddressed, may hinder sustained growth. 

While Seth did not specifically address whether this concept could be successfully applied to project managers, there is no reason why these basic concepts would not apply.  The only difference might be the very nature of projects, which are themselves defined by specific timetables, with start and finish dates.  In applying the lessons of Linchpin to the discipline of project managerment, it is more effective to focus on the project manager’s contributions to the overall corporate environment, rather than his or her contribution to an individual project. 

When I read the book, it reminded me of a scenario I experienced about twenty five years ago, when I had just been promoted to Manager, Manufacturing Performance Reporting and Analysis, in the Controller’s staff of ARCO Products Company in Los Angeles.  One day at lunch, the Controller (who was my Manager’s boss) stopped by my office for a brief chat.  We had not had much time together since the promotion, and he wanted to provide his insights as to how I could “be recognized” in the organization. 

His advice to me was to do something “extraordinary” that would use my unique talents and would be recognized and applauded by ARCO Management.  He told a short story about how, a short time earlier, he had himself been recognized.  At that time, ARCO was in the process of building a new natural gas fired cogeneration facility at the ARCO Los Angeles Refinery.  The Controller was on the finance staff, and offered a creative financing idea for the new cogeneration facility based upon his previous work with the financial community.  Management had endorsed his initiative, and it had saved the Company quite a bit in total financing costs, as well as put the Company in a better position to pursue a joint venture with the local electric utility in Southern California. 

The Controller’s advice to me was to look for something similar that would leverage my unique talents in “engineering” and “venture development.”  You might say it was an early “linchpin” pep talk.

That was extremely good advice.  And it is advice that applies equally well to project managers in their day-to-day project work.  Look for those contributions that are unique to your talents and which will be recognized for their value to the entire organization, and not just to the single project on which you are focusing at that time.  While that may seem like a tall order if you are a project manager who is “up to his rear in alligators” everyday,  today’s market requires that you invest in making yourself “indispensable.” 

How does that saying go?  “The markets may be strong or weak but strong people will endure.”

Nurture the four abilities of a linchpin that I summarized from Seth’s book in the introductory paragraph.  You have the ability to become an  “artist” and to “share” your gifts with the rest of the organization. 

I would like some feedback on this post from those who have experienced similar scnarios.  Are there “linchpins” around you whom everyone recognizes as being “indispensable” to the organization, and yet no one really stops to acknowledge or applaud them?   While they may be the unsung heroes of our project ventures today, they will be the glue that sustains the organization going forward.

Thanks for your support!!!!!

If you are a project manager, you should be working everyday to develop a quality or capability known as “resiliency.”  Resiliency is the ability to spring back or rebound from emotional setbacks.  Resiliency is “mental toughness.”  In this context, “mental toughness” or tenacity is the ability to lock-on to an end-result, goal, or project and to successfully handle all the temporary setbacks that might occur without giving up on the goal.

How many times in your projects have you seen repeated setbacks, either in deliverables not being completed on time or on budget, resources not being available or competent to complete the task at hand, or “dependencies” from other projects in the form of “gives” and “get” not being available when needed to support your project goals.  Often, these temporary setbacks occur in bunches, and we have all said at times “My, what an awful day!!”  

But in order to focus on the end result and achieve all the value from the project, you must put aside these emotions and feelings, and deal with these temporary setbacks. 

The project manager who can address these setbacks successfully and still accomplishes his end objectives will be sought-after over and over again for future project work.  

Oftentimes we hear the word “ambiguity” in today’s organization because so many seemingly-aligned initiatives often are really oblique to the direction in which the organization is moving, and creating “ambiguity” in direction, motivations, goals and objectives.  The project manager who can address this “ambiguity” with its associated setbacks and still achieve the end value from his project is extremely valuable to the organization and to himself

So, how should a project manager proceed to develop “resiliency” in his work ethic, practices, and day to day activities? 

Louis Tice is a coach and counselor who helps men and women achieve their potential in whatever field or discipline they have chosen to participate.  He and his wife Diane started The Pacific Institute for the purpose of using research about cognitive skills and self-image to enable high achievement in individuals.  Louis Tice has coached business professionals, and both professional and collegiate athletes in the area of development of “resiliency.” 

Using affirmation and visualization techniques, he has coached athletes to develop the mental toughness to overcome temporary setbacks in athletics to achieve the end result in their selected sport.  Lou instructs, for example, college football running backs to visualize themselves running through the forest at night when they are headed in a general direction but cannot see any of the trees and limbs in the forest.  As the athlete starts to run in his selected direction, he may run into a limb and it will smart and hurt.  It is painful but, instead of sitting down, he keeps running.  And when he strikes the next tree, it hurts but he just slides to the side and keeps running in the selected direction.  Then when he runs out of the forest, trees stop striking him–he has reached the end goal and never wavered from the end result he wanted to achieve. 

Another exercise might be to picture yourself in a well and you cannot get out.  As you reach your hand upward, something strikes your hand and you have to pull back.  You do it over and over again and eventually the striking stops and you come up out of the well. 

Now, as a project manager, visualize yourself running through a maze which represents your project plan or schedule. When you reach an impasse or an unexpected setback, just slide to the side and keep going.  It may be painful but you just keep running through the maze.  Eventually, after you have overcome all the setbacks, you will realize that your end goal is right in front of you.  And you reach out and grasp it!!! 

Of course, this has applications in other parts of life as well.  Suppose you are actively involved in a job search and your most recent interview for a Program Manager position went very well.  But then you receive a call saying that you were not selected for any further interviews because they have selected others with industry experience which more directly aligns with the Program Manager job description.  It’s just a “no” and not a “forever” although, at the time, it may seem like a huge setback.  So you slide to the side and keep looking. 

Developing resiliency in your project manager career will allow you to handle temporary setbacks with less stress and greater confidence.  You can begin the road today toward being a more resilient project manager.  It is a quality that is essential in today’s marketplace and in future project organizations.

In Part I of this post, we discussed two communication mechanisms–Situational and Empathic Communication–that project managers can use to ensure that stakeholders hear and understand key project issues. 

In my experiences working with many project managers in a PMO environment, Situational and Empathic Communication–along with Resonance and Metaphorical Communication, the two communications mechanisms that I will discuss in this Part–have been used widely by successful project managers. 

RESONANCE COMMUNICATION

In the sciences, we study a phenomenon called “resonance.”  Resonance is the state of a system in which an abnormally large response is produced by the system, as compared to a standard external stimulus.  Once again, it is we are most interested in the “cause” and “effect” relationship.  Resonances are observed in many physical systems.  In nuclear physics, resonance occurs when there is a high probability of a certain type of action or reaction occurring if the conditions are right.  For example, if a neutron of a certain energy comes in close range to an nucleus which has a high resonance cross section for absorption at that energy, then there is a high probability of absorption of that neutron by that atom.

There is an analogous situation in behavioral or emotional systems in which an external stimulus causes some form of a larger than expected response on the part of the person affected by the stimulus.  Certain music, for example, is known to cause an emotional reaction.  For example, the songs of Paul McCartney or Sting cause a “resonance” in the emotional behavior of many of their fans.  This emotional response can be built upon to form a “market” for that particular music.  The same can be said of certain foods.  Pizza or Mexican food can, for example, cause a “resonance” response in some people who have a “taste” for that type of cuisine.

Perhaps you have never thought of markets in this way before.  How can you estimate the market size for a new song by a particular group?   

Now, how can an understanding of “resonance” help project managers communicate with project teams and stakeholders?   

When I worked in a PMO for ConocoPhillips, we developed a number of SAP ERP projects for the organization during the merger of Conoco and Phillips Petroleum.  After the first three or four of these projects were completed, we noticed that one aspect of the project which created longer actuals in terms of both budget and schedule, was a phase known as “data conversion.”  “Data conversion” was a very general term that often included such competencies as “data scrubbing,” “data interpretation,” “data cleansing,” as well as other related activities.  We asked ourselves the question “Why does data conversion create such problems for project teams?”

What we found was that project teams, no matter how exerienced in SAP projects, inevitably underestimate what it will take to convert the data from the original system, into fully compatible and useable data for the SAP application.  Typically, the number of resources would be underestimated, or the point in the project where data conversion would have to be initiated was miscalculated, or the “data conversion” team might be missing some key component of expertise. 

How could we correct this situation and learn from past project mistakes in such a way that future project managers on SAP projects could fully anticipate the scope and resources required for an on budget, on schedule completion of “data conversion”?

We wrote a Project Lessons Learned document that would strike a “resonance” in any qualified project team.  The project manager only had to discuss the Project Lesson with his team and his project planners in order to effect a full and complete understanding of the problem, so that the team could understand and successfully act during the  project’s execution.  By covering all the topics of data conversion, timing, competencies, special expertise, inclusion of all known types of data shortcomings, the project manager was able to address any question that the project team might have regarding data.

Striking this “resonance” was essential to future on budget, on schedule performance in the SAP ERP arena.

So, as a forward thinking project manager, look for those topics that will strike a “resonance” in each of your stakeholders, topics which you can call upon time and again to elicit a greater than expected response to your message.  You will find that these topics are numerous, and can be counted upon to reach project team members, sponsors, and steering committee members of business functional groups.  Some of these topics might be Organizational Change Management (OCM) plans, Risk Analysis and Vendor Management.

METAPHORICAL COMMUNICATION

Metaphors are an effective way to put a situation or an issue into a context that another person or group can better understand.  A metaphor is a figure of speech , symbol, or image that can help illustrate a point and connect similar or dissimilar items. 

When people are able to see how to apply familiar processes and behaviors and attach their prior knowledge to various situations, it makes it easier for them to come up with action plans.  It also enhances esteem and gives them confidence.

A number of years ago, after very successful runs in London and New York, Phantom of the Opera came to one of the performing arts centers of southern California.  My family was very excited but, when I went to the box office to buy tickets, the earliest tickets I could get were for a performance four months in the future.

I had heard so many great things about the music of Andrew Lloyd Webber and the performances of his leading actors Michael Crawford and Sarah Brighton.  So, I thought I would prepare myself for the upcoming performance by listening t0 the soundtrack on cassette tape.  I had an expectation that I would be able to enjoy the “atmosphere” of the performance by listening to the music and the interaction of the characters on the soundtrack.

What happened?  Without seeing how the perfomers interacted or how their roles  were related, I really could not understand the context of the music or how it enabled the action.  My understanding of the entire performance was incomplete.  Many key things were missing.  It was not until I saw the production with action, music, interaction, themes, and a plot that I realized what a fine “tapestry” that Andrew Lloyd Webber had woven.

Such is often the case with project teams.  They may not see the full context of a project.  Someone must communicate to them the “big picture”–the subtleties of the interaction among their roles, communicated messages and feedback about the project, various decisions that had been made, etc.  That is where metaphors can be so valuable and effective.

On the Sunday, March 14, 2010 episode of “Meet the Press,” Tom Friedman of The New York Times ,and Tom Brokaw, the guest moderator, were discussing the United States’ role in the Middle East, and the perception of the U.S. in the eyes of many of its residents.  This exchange ensued:

MR. FRIEDMAN:  Yeah.  I mean, look, everyone in the Middle East is watching. You know, Tom, we both grew up in the Midwest.  You remember, we used to talk about the Minnesota State Fair.

MR. BROKAW:  Right.

MR. FRIEDMAN:  I used to go the state fair as a kid.  There was a guy at the Minnesota State Fair who could guess your weight.  I was fascinated with that as a five, 10-year-old.  How does he get–and if he didn’t get it right, you won a Kewpie doll or whatever.  In the Middle East, people can guess your power from a hundred paces.  They have to.  That’s how, how they survive.  And if we look weak, vis-a-vis our closest ally in the region, that will have regional implications.

Tom Friedman used a terrific metaphor at that spot in the interview.  Each television viewer was given a picture, indelibly etched in their mind, of a man in the State Fair sizing up the power of someone he barely knows.  And all for the sake of survival!!!

If you are a project manager, the next time you send one of your project team members to talk to someone in the business functional area about a potential change in project scope that the business functional group may be considering, why don’t you use a metaphor when suggesting to your team member how the interaction should go?  For example, if your project team member is a baseball fan, consider this approach:

 “During this interview, why don’t you approach Jim as if he is the starting pitcher in a baseball game, and he has loaded the bases in the bottom of the ninth inning, with your visiting team ahead 6 to 5 with two outs.  It’s crunch time!  Let him know that you understand that he is upset for letting those batters get on base.  But be forceful, and let him know that, if he allows a run or two to score, it’s a whole new ballgame with your project.  More scope means more dollars and inevitably missing the Job #1 date.  Which is it going to be?  Let him know that the project team and the sponsor would rather that he pitch a strike out, and that, together, you can still achieve that goal and win the game.  If you frame it in such terms, he will deliver his best and, more than likely, you both will emerge with a win-win.”

I hope this discussion of four communication mechanisms has been informative, and that it will enable you to communicate effectively with all stakeholders.  I would be interested in learning more about your experiences using effective communication tools in the Comments section.

If you have been following my project related posts on this Blog, you know that one of my themes has been effective communication with all project stakeholders.  Of course, this means using different types of communication, with different types of stakeholders,  in different types of situations. 

It has often been said that, if you want someone to talk with you in a meaningful way and to listen to what you have to say, you first have to say something of importance and value to the other person so that he will feel that you value  his “stake” and continued involvement in the conversation. 

Communication has several components.  The simplest characterization is that something is conveyed by one party to another,  and the “something” is received and understood by the other party.  Without this sending and receiving, we do not have effective communication.

Four communication mechanisms are:

1.  Situational Communication

2.  Empathic Communication

3.  Resonance Communication

4.  Metaphorical Communication

I will discuss the first two of these communication mechanisms heren, and the last two in Part II.

While you won’t find these discussed in any standard project management texts or in the PMBOK section on “Communication“, these four approaches to communication have been cropping up in my experiences with successful projects time and again.  They seem to dominate the landscape of “real” project management.  And in my experience, those project managers who are able to master these four “methods” of communication have flourished.

SITUATIONAL COMMUNICATION

Ken Blanchard’s consulting group made famous a discipline known as “Situational Leadership.”  In essence, it meant defining the types of situations in which a leader finds himself, and then adjusting leadership “styles” to the task at hand. 

Communication in projects is much the same way.  The project manager must recognize and be constantly aware of the situation and business context facing the project team and then adjust his leadership and communication approach accordingly.

In graduate school at The University of Michigan, Ann Arbor, studying nuclear science and engineering, I had a chance to work with a famous researcher, Dr. Ziya Akcasu, in his discipline of nuclear reactor control theory .  Dr. Akcasu and I developed a research paper which I presented at the American Nuclear Society (ANS) Annual Meeting in Boston in June 1971.  While I was attending the Boston meeting, Dr. Akcasu was on the west coast attending another meeting.

On the morning of my presentation, I was second on the agenda to speak and, as I entered the lecture room, I noted that there were about one hundred people in attendance, which was a good size group for the topics we would be covering.  After the first speaker finished and answered questions, I walked to the podium and introduced myself and the paper topic.  Most of the one hundred patrons had maintained their seats and, in fact, a few others had entered and lined the back walls of the lecture room. 

Before I had a chance to continue, from the back of the room, someone asked, “Will Professor Akcasu be presenting today?”  Although I was a little taken aback by the question, I replied that Dr. Akcasu was on the west coast attending another conference and that I (“the designated graduate student and co-author”) would be presenting our results. 

Suddenly at least three quarters of the room rose from their seats and left somewhat boisterously.  After the dust settled, the remaining twenty five or so people looked at me and I looked at them.  Then, without really thinking about what I was saying, these words came forth, “Well, now we have a smaller group who is really interested in the results of this groundbreaking work.  We should be able to have a good open discussion of the details.”

As people left the room that day, they thanked me for the “intimate” atmosphere I had created.  I have often thought about what the lesson learned from that presentation might be.  My answer:  “Fame ensures millions of patrons but only the true scholars command the dedicated few.”

Of course, my methods of communicating with the twenty five or so remaining observors was quite different from the methods I might have employed with an audience of one hundred.   This was a good example of Situational Communication in which a person adjusts his style to accommodate the change in situation, circumstance or context.  Pure lecture was certainly not called for with this intimate group.

I recall a Project Lessons Learned Breakfast Forum that I facilitated in my PMO work with ConocoPhillips.  A very experienced financial systems project manager told the group that his greatest challenge in completing a major SAP ERP Financials project on time was that the project was dependent upon several other projects that were scheduled to complete just before his project’s deadline.  In order to meet his own deadline, he spent a good deal of time in the last days of his own project ensuring that the other project managers successfully managed their own projects so that his project would not suffer any delays.

Such an endeavor is hard to delegate to others.  It takes foresight and experience that cannot be easily conveyed to others.  His management–and on-time completion–of the  SAP ERP Financials project was another form of Situational Communication.

EMPATHIC COMMUNICATION

At the University of Michigan, Ann Arbor, I was a PhD candidate in Nuclear Engineering.  One requirement for obtaining the PhD was passing a written and oral preliminary exam (called “prelims”), after which I could proceed to the research phase of my candidacy. 

I had heard numerous worrisome reports from students who had failed the prelims three or four times before finally passing. 

The prospect of failing the prelims terrified me., so I developed a strategy that defined two possible courses of action:

(1) I could spend all my waking hours studying every resource on nuclear science and engineeering that I could get my hands on; or

(2) I could align myself with a professor who was doing research in a field of my interest and go into the prelims with a certain amount of research already behind me along with the endorsement of that professor. 

I chose option two. 

On the day of the oral examination, I had already taken the written portion of the prelims.  While the written examination had been particularly difficult, I thought that I had done well and had a chance of passing the prelims on my first attempt. 

At the oral exam, I nervously answered the questions (in a way that I thought was somewhat incomplete).  After answering the questions, I then had a chance to describe some of the research on which I was working.  At the end of the oral exam, I asked the assembled group of professors if I could say a word to them before leaving.  I told the group that while I knew my opinion didn’t really count, I did not think I had done as well as I had expected, and that I knew I understood the field of nuclear engineering much better than had been conveyed during the oral exam. 

The professors listened and then one well known professor said “Mel, just remember this: No one has ever passed this test who should have failed, and no one has ever failed this test who should have passed.” 

To this day, I am uncertain exactly what he meant, but since I did end up passing the prelims, I think that it was his way of communicating with me that there was nothing else that I could have done in that oral exam that would have mattered to the final outcome.   He was sensitive to how helpless the prelim exam process had made me feel, and he wanted me to know that, whatever the outcome, I had done everything I could do to prepare for the exam.

This was an example of Empathic Communication, in which one party is “sensitive” to the feelings and explicit or implicit needs of the other party.

Shortly after the merger of Conoco and Phillips Petroleum in 2002, the newly-merged corporation was faced with a dilemma–in some geographic regions of the world, there was operational overlap.  One such area was Canada, where there were three or four distinct organizations with similar oil and gas operations, and unique internal operational systems. 

The decision was made to consolidate these operations into one Canadian organization going forward, with SAP being the ERP standard for all systems.  This meant that business processes would be changing,  and as a result, jobs, roles, and the people occupying those roles would also be changing. 

A huge Organizational Change Management Plan (OCM) was implemented.  When they chose the project manager for the project, it was someone who had recently completed a similar project in Europe.  For the first two to three months of the project, the project manager and project spoonsor traveled to all of the major operational centers of the organizations that were being consolidated.  They held personal conversations with each employee to gain their input and to understand their current roles.  These communications were extremely empathic in nature because not only did they seek each employee’s buy-in, they also conveyed to each that they would play a very important ongoing  role in the transition from the old organization to the new.  Some employees would become “power users” of the new systems , some would become casual users,  and some would play a support role in providing key information for the systems.  In other words, the success of the project, and that of the new consolidated organization, was in the hands of the employees and not in the hands of the project managers and sponsors.

Is that how it is in your organization?  Do the users of the systems and the “supporting cast” feel like they have a real “stake” in the delivery and the outcomes of the key projects that will “make or break” the organization in the future?  Please provide your insight in the comments.

I will discuss the last two methods of communication in Part II.

Do you remember how Rod Serling started the “Twilight Zone” TV series each week?   He would say “For Your Consideration.”  That is exactly what I request of you in this blog entry.

An article entitled  “Case Study:  Design in Cost Reduction“, which was cited in one of the Group Discussions on LinkedIn, caught my eye the other day.  The article’s author discussed how Motorola University (MU) was working with engineers, designers, marketers, supply chain stakeholders and clients, in what they termed Design for Manufacture and Assembly (DFMA).  

Basically, Motorola University draws on the “Cause” and “Effect” principle that fewer parts in a design will lead to less material and less labor cost in the finished product.  A colloborated and integrated effort in the Design Process, followed by a Manufacturing Process which closely follows the Design, will result in lower product cost and lower overall manufacturing cost. 

The article cited an example in which a top electronic device manufacturer used the Design for Manufacture and Assembly (DFMA) process, enabling it to complete 12 product redesign projects over a four month period, resulting in savings of $6.8 million.

The key for us, as project managers, is to recognize that the same principles can be applied in project planning and execution. 

A Design for Project Execution and Delivery (DFPED) could be developed whereby the “Cause” and “Effect” principle might read: 

Lower project cost, with increased quality of final deliverables, can be achieved by collaborated and integrated project planning and execution, which includes the project team, key designers, marketers, end user stakeholders and process/project engineers.

This is very similar to having a Balanced Scorecard concept for projects.  If you design the underlying organizational and human resource performance processes correctly, this will lead to improved overall project processes which will, in turn, lead to better customer satisfaction with the process and the deliverables, and which will ultimately lead to the project’s financial success.

Many of you will say “Yes, but.  It takes a very mature project management process and organization to fully collaborate and integrate these teams and processes such that they may fully realize this cause and effect result in the final project delivery.” 

While that may be the case, every project organization has the capability and the desire to do a better job than they are doing today in delivering projects and value to their organizations.  That desire should be enough to motivate the project organization to start an evaluation of their own Design for Manufacturing and Assembly process or, as I have defined it here,a  DFPED process.

I would like to hear some comments from some project organizations who have undertaken such process improvement initiatives, and may have even applied the DFMA framework.  Please comment if you have done so and let us know the results of such initiative.

If you have been following my blog posts, you know that I have used the term “framing” with regard to projects many times.  Some of you may be wondering just what is the significance of “framing” to the success of projects.

When I a was a member of the Shared Services PMO with ConocoPhillips, we had a framework for analysis known as DRA–Decision and Risk Analysis.  This framework (decision process) was applicable to both operational and project initiatives in the Corporation.

 One of the earliest and most important steps in the Decision and Risk Analysis framework was “framing.”  When “framing,” we asked “What problem am I trying to solve with this initiative?”

For projects, it is very important to understand the answer to the question: “What problem am I trying to solve with this project?” 

Answering the question  means understanding the situation and business context well enough that you can determine when a “problem” has occurred in the corporation, and then determine a course of action for solving the “problem.”

In order to understand the significance of proper “framing,” I would like to relate to you a situation from my own recent experience.  As I was driving from point A to point B the other day, I was also listening to a call-in show on the radio.  It involved a caller with a real life problem and a “telephone consultant” answering the caller’s question by providing a different perspective and suggesting various action plans that might alleviate the caller’s concerns. 

The caller told the consultant that he was despondent about a recent phone call that he had received.  He had been married for about ten years, and he and his wife had several children together.  He had recently received an anonymous phone call, however, in which he was told that four years ago, his wife had an affair.  The man said he believed the anonymous caller because of the details that he gave him about his wife, their family, and about his in-laws. 

The caller told the consultant that he had always believed that he had a good marriage, and that his wife had always “acted” as if she wanted to continue in their marriage, with no indication that she had been unhappy.  The caller was beside himself because he could not understand the situation.  He said that after he received the call, he confronted his wife and she said that she did have a short affair four years ago, and that it long over.  He confronted also his in-laws, who confirmed that they had known about the affair, but said that he would have to talk with his wife about any details.  The caller felt betrayed, even though his wife had tried to reassure him of her love and her devotion to their family. 

The consultant listened to this narrative very carefully and then said, “Sir, over the past four years, has your wife been devoted to your family as a loving wife?”  He replied that she had.  The consultant said, “Did it ever occur to you that she chose YOU, rather than the other person, to continue her life with?  Did it ever occur to you that your in-laws were actually trying to protect you from the truth because they knew the affair was short lived and that your wife had dedicated herself to your home?  Did it ever occur to you that the anonymous call was intended to hurt you and your wife because the caller knew he had lost any ability to influence the situation?”

The caller thought for a minute and then remarked, “No, I never thought of it that way.  I was so  hurt by that anonymous call that I had to lash out at someone.   And my wife was the closest thing to me.”

“She chose you,” said the consultant.  “Go home and thank her for being the kind of wife she is and the woman you love.”

Whether you agree with the consultant’s advice, she had effectively re-framed the caller’s problem.

How often do project managers get so caught up in the heat of planning a project, that they do not take time to “frame” the project correctly?  On the surface, they may see an immediate problem that the corporation is facing, and so they plan the project to alleviate that obvious problem.  But others may have a different perspective and bring different viewpoints to the table.  Examining the different viewpoints is essential to correctly “framing” the project.

Herb Cohen is a master negotiator and author of a number of books on negotiations.  His main theme in negotiations is that “an effective negotiator must care but not too much.”  What he means is that, if a negotiator brings too much emotion to a problem or is tied too closely to the emotional outcome of a particular negotiation, he may lose his impartiality.  He may incorrectly “frame” the negotiation.  He may develop a bias toward one party or the other.  He may render himself ineffective in the negotiation.

A project manager faces the same situation when “framing” a project.  The next time you plan a project, keep this caller/consultant story in mind.  Then sit back and ask yourself “Have I framed this project correctly?  Have I really described the problem that I am trying to solve?  Or is it being masked by my emotion or by some other circumstances in the organization that I must uncover?” 

Success lies in getting the “ingredients” of the pudding right and the right pudding ingredients lie in the “framing.”

Thank you.

In my last post I promised to follow-up on the metaphor that I had developed comparing movies to projects.  Although project managers do not often think about themselves as “Directors,” they essentially play the same role in projects as “Directors” do in films.

I mentioned that the movie DVD “Pride and Prejudice” with its additional features had struck me over Valentine’s Day weekend as being particularly helpful in revealing some underlying lessons for project managers and their teams.  One of these lessons was my reaction to Director Joe Wright’s statement in his narrative of the film in which he said that “the experience of making this film informs the film itself.”

In this context, the verb “informs” means “to give evidence, substance, character or distinction to.”

How many of us as project managers would ever say that “the experience of managing this project informs the project itself?”  And yet, if you really think about it, every project manager adds substance, evidence, character and distinction to his or her project by managing the project everyday…from inception of first thought to the final close.

That is the key to successful projects.  To the extent that the PMO can pass along this type of ownership of the entire project experience to project managers whose experience will “inform” the projects, we will see more and more successful projects.

If you are reading this entry, chances are you are a project manager, a project team member, or someone who is interested in how projects are executed and how PMOs are implemented and maintained.  If that is the case, I am certain that you are probably tired of reading the same old lists of “What Contributes to Project Success?” or “Why Projects Fail.”

That is why I want to offer you another perspective on developing and leading successful projects, and the role of the PMO in those efforts.

Before Valentine’s Day, I was browsing through the Movie/DVD section of my local Barnes & Noble looking for nothing in particular.  A display of Valentine’s Day suggestions caught my eye.  One DVD stuck out because it seemed particularly well-priced, and the theme was one we all welcome at Valentine’s Day–a great love story between two seemingly very different people, Elizabeth Bennet and Mr. Darcy.

The DVD was “Pride and Prejudice,” starring Keira Knightley, Matthew MacFadyen, Donald Sutherland, and Dame Judi Dench.  This 2005 film was nominated for four Academy Awards and was called by many “the Best Film Of The Year.”  It is, of course, a love story based on the Jane Austen book “Pride and Prejudice.”

This particular DVD contained not only the movie but several additional features:  A Bennet Family Portrait; Jane Austen:  Ahead of Her Time; Behind the Scenes at the Ball; “Pride and Prejudice”  HBO First Look; and Commentary from Director Joe Wright.

As I watched the movie and several of the other features over Valentine’s Day weekend with my wife,  it struck me that the entire package created a tremendous value when viewed as a whole.  As I began to think about the plot of the movie and the way it unfolded, I could not help but think of some similarities with the way projects are planned and executed.

In our experience as project managers, it is too often the case that the project manager wants to finish a project as quickly as possible and then get on with the next project.  After all, that’s what project managers do, manage (and complete!) projects.  Too often in the past, the project manager was focused on the sponsor as the principal stakeholder in the project and often–unless a very robust Organizational Change Management plan was included–the project manager did not focus so much on the end users as “real” stakeholders.

This DVD package, however, considered all the stakeholders (i.e., the various possible viewers of the DVD).  The movie, when combined with the DVD “extras”, answered questions about how the love story unfolded, gave helpful background information, and additional information that showed viewers multiple ways that they could understand, or “frame” the story.  In doing so, the DVD anticipated and answered questions that the audience (the buyers of the DVD) probably had not considered until after having purchased and viewed the movie itself.  How many projects do the same thing?  Probably not many these days.

So, as you proceed with your next project, consider some of the following lessons in capturing all the value and satisfying all the stakeholders.  Pretend that you are the “Director” and charged with telling the story as well as creating all the “behind the scenes” explanations that stakeholders want both explicitly and implicitly:

1.  “Frame” the plot and the interactions of the characters correctly.  Look at the social or business context in which the action takes place and make that context real (i.e. come alive).

2.  Assemble the right cast  Obviously the cast members must complement the entire context of the project. 

3.   Train the cast in the “context” of the specific project and its tasks.  Each cast member brings some “raw talent” to the party but the Director’s task is to mold that talent in the context of the movie so that the value flows from the performances of each cast member as they interact, as they see and feel the action.

4.  Consider all the stakeholders, including the end-users,  and focus on the “needs” of the end-users; not just the “expressed” needs but the underlying needs.

6.  Consider not only the sponsor’s vision for the project, but also the “process” by which the project will be executed.  After all, a Director’s vision for a movie must not only follow the Screenwriter’s narrative but also the “process” for the movie production.  This is also where the PMO comes into play.  Having a defined process for all projects means all projects are initiated, justified, authorized, executed and closed by a process which can be repeatable and consistent.  That said, it does not mean that every project must conform exactly to the process, especially if there are situations where the process doesn’t exactly apply.  It means that there are “guidelines” for how to conduct the project (or to develop the movie) which have contributed to success over time.  The PMO is a guiding standard for reference and for consultation.

7.  Identify and address any risks to carrying out the plan for the project as originally conceived, and have adequate plans in place to address those risks.

The next time you view a motion picture, ask yourself if the Director fully accounted for all the Stakeholders’ wishes in its production.  And the next time you plan a project, think of the lessons we can learn from another art form such as a motion picture.

I will have more to say about this topic in my next post.

For those of you new to my blog by way of “Scope Crepe,” I want to thank Rich Maltzmann, PMP, for his link with my PMO Expert Blog.  My blog is intended to provide project managers and PMO leaders an in depth look at some issues and themes from my 15 years of experience in putting together several PMOs as well as an IT Project Office in the early days.  Here we examine PMO execution, how to form a PMO from first principles, project lessons learned and knowledge management and performance management for PMs.

Stay tuned for more exciting interpretation and thanks for tuning in.  Mel Bost

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.

In Session I, we talked about the PMO Author taking a clean sheet of paper and developing a Funding Authorization Statement or Summary for a project which would include information and details concerning supporting documentation for the justification and approval process. 

Here is the example we used:

“This funding authorization seeks $37.5 million (capital and expense) from the IT Executive Board to deliver the IT Marketing Apps Development Project for new Stores by December 2011. The Business Case is defined as follows…..The economics and payback are defined as follows….The risks to the project completion are defined as follows…..The proposed project team will consist of the following from IT and/or functional business units. The external consultants proposed for this project are ………Authorization of this project is part of a larger portfolio of projects which have been addressed by the IT Executive Board in its meeting of August 21, 2009.”

Every one of the Bolded Words (Information) in this Authorization statement need to be addressed including the following:

1.  Definition of the Bolded Word (Information).

2.  Location of the Bolded Word (Information), i.e. inside the PMO, supporting Corporate group, functional business group.  This detail will provide the PMO Author with decision points for various pieces of information. 

For example, the Business Case will contain financial/economic analyses which will need to be developed by someone or some group.  Wherever that someone or some group resides sets up a decision point for the PMO Author.

3.  At this point, I recommend that the PMO Author actually draw lines from the Bolded Word (Information) named in the Authorization Statement to a white space in the margin where the PMO Author will begin to fill in the details of what, where, when and how for each piece of information.

4.  It is important that every Bolded Word (Information) in the Authorization Statement be addressed by the PMO Author at this point so that the next stage of maturation in the process will flow smoothly.  Those of you familiar with David Allen’s Getting Things Done will recognize this as the next action.

5.  Once all the information and locations are defined for one project’s Authorization Statement, then additional Authorization Statements can be added for additional projects until a Portfolio of Projects is included.  At this point, an Information piece needs to be added to describe how the Portfolio will be handled.

6.  Obviously each Bolded Word (Information) will include human resource as well as physical and financial resource materials so that a Budget of human resources and physical and financial resources can be developed.

7.  Timing will also be a consideration after all Bolded Words (Information) and Resources have been defined.  Now the “process” is beginning to look like a  “Funding Authorization Process” and a flow of information to support the “Process.”

In the next Session, we will look at some other considerations such as ancillary or support processes for Control and Reporting.

You might want to revisit Session I again now that you have read Session II so that you get a complete picture of the “Process” and its inputs.  As we develop more detail and more information, we are beginning to define what is termed a “Well Define Process” which includes entry and exit information and flow as well as criteria for moving the process from one stage to the next in a controlled fashion.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Let’s take a simple example now. 

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

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

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

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

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

Suppose you are a member of a successful IT or other business functional group whose members have successfully delivered “value” to their larger organizations/corporations through successful project implementation. Inevitably, this success brings additional requirements from the corporation to deliver more “value” through more projects over time. You begin to feel the pressure because resources may not be readily available or accessible in the timeframe you are asked to deliver, teams may not be prepared and, in general, although you saw it coming, your best efforts just to deliver the last increment of “value” was enough to keep you occupied.

So what’s a body to do?

This is exactly what faces every organization who decides to ramp up to a Program Management Office (PMO). But the question remains “how do I define just what I need in the timeframe I have been given to be successful?”

My answer which I have leveraged in several situations before is to take a blank sheet of paper and write a “funding authorization statement” for a single project just as if you were seeking funding today.

An example:

“This funding authorization seeks $37.5 million (capital and expense) from the IT Executive Board to deliver the IT Marketing Apps Development Project for new Stores by December 2011. The Business Case is defined as follows…..The economics and payback are defined as follows….The risks to the project completion are defined as follows…..The proposed project team will consist of the following from IT and/or functional business units. The external consultants proposed for this project are ………Authorization of this project is part of a larger portfolio of projects which have been addressed by the IT Executive Board in its meeting of August 21, 2009.”

Now, such a simple statement defines many things. It defines what project, what funding group, what business case, what risks, etc.

Every one of these details must be provided by resources which reside in the PMO or functional business units interfacing with the PMO.

When the PMO has a number of these Authorization Statments, it can begin to decide if a Methodology of handliing the Portfolio of projects and the LifeCycle of the Project Management Process needs revamping to facilitate consistency in the way all the projects are evaluated and authorized.

What does your “clean sheet of paper” look like? Have you given it some thought lately? If you are an organization looking to move to that next level of superior project service and “value addition” to your Corporation, think about that “blank sheet of paper.” Your business context will determine what elements need a place in the PMO and what must come from the business functional areas and perhaps even what must come from external stakeholders.

Copy Protected by Tech Tips's CopyProtect Wordpress Blogs.