Browsing Posts in Best Practices

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

A.G. Lafley, in his book, The Game Changer:  How You Can Drive Revenue and Profit Growth with Innovation, defines innovation as “the process of converting or turning new ideas into revenue and profit.”  Similarly, many authors in the PMO field have defined the PMO as a distinct organizational structure which can be used to drive innovation through project management and product development.

A recent article in the Winter 2010 issue of Strategy + Business magazine, entitled “The Global Innovation 1000:  How the Top Innovator’s Keep Winning”, was based on an ongoing Booz & Co. study of innovation in the most successful companies in the innovation game today.  The goal of the study was “to examine the capabilities needed to maximize the impact of the company’s innovation efforts in good times and bad, and to highlight the benefits both of focusing on the short list of capabilities that generate differential advantage and of clearly linking the specific decisions within innovations to the company’s overall capabilities system and strategy.”

Their premise was that “innovation capabilities enable companies to perform specific functions at all the stages of the R&D value chain–ideation, project selection, product development and commercialization.”  The consultants asked the respondents in the Global Innovation 1000 survey which capabilities were most important in achieving and sustaining success in innovation.

Surprisingly, the study found that “all the successful companies surveyed depended on a common set of critical innovation capabilities.  These include the ability to gain insight into customer needs and to understand the potential relevance of emerging technologies at the ideation stage, to engage actively with customers to prove the validity of concepts during product development, and to work with pilot users to roll out products carefully during commercialization.”  The study’s authors also found important the ongoing assessment of market potential during the project selection phase.

Exhibit 1--The Most Important Innovation Capabilities

You will recall that in other blog posts, I have discussed the rise of PMOs for specific purposes in organizations which recognize the special value-added by having an organization focused on project management capabilities as a means of converting strategy into action.  For example, some utilities have formed Smart Grid PMOs to handle Smart Grid projects.  In an organization that is determined to succeed and grow in its industry, with best-in-class products, services, or both, why not consider creating an entity called the Innovation PMO?  What would the characteristics of such an entity be?

First, since feedback and research from consumers, users, and other stakeholders is critical to understanding “what to innovate for,” the Innovation PMO would establish its own unique source of feedback research within the context of its own industry or consumer setting.  This is a key element of success.  Unfortunately, very few PMOs are currently doing a good job in this area, but to become an Innovation PMO, they must.

Second, the Innovation PMO has leveraged its key supplier and vendor relationships.  It knows that frequently, the unsolicited feedback provided by suppliers and vendors provides a fresh look as to where the market is headed, especially in innovation scenarios.

Third, the Innovation PMO has tailored the critical innovation capabilities discussed in the Booz & Co. study to the internal business context of the organization.  This tailoring process is analogous to the benchmarking process, discussed in a previous blog post, which is used by leading PMO organizations, such as American Express and Procter & Gamble, to establish best practices.  Like best practices, to be successful, innovation capabilities can’t be lifted verbatim without being tailored to the organization’s business context.

Margo Visitacion of Forrester has also written about the expansion of the PMO concept to innovation in organizations in her recent Forrester paper “Involve Your PMO to Find the Right Match for Innovation Opportunities.”  I would recommend you read her analysis as well.

Innovation is certain to be a topic embraced by more and more organizations looking for successful growth-promoting projects in their industries.  Your role as a PMO practitioner is to find a spot where you can contribute to that success.  Remember–”Change Creates Opportunity.”  Now, go find that opportunity.

“Pay Me Now or Pay Me Later”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In recent blog posts,  I have discussed how individual project and program managers can improve their capabilities and performance through some simple, yet very tangible and actionable, everyday tasks in the project process. 

I want to turn now to “benchmarking”, an area which can be applied to improve performance on several “scales”, whether it be overall performance of a PMO group, of an individual group within a PMO, or a single person’s performance.

Benchmarking is the comparison of a known state or condition of a group or process to another “defined standard” group or process which, in the eyes of  the benchmarker, represents a level of performance or activity that is desired in one’s own group, process or person. 

Benchmarking also introduces “innovation” into your organization.

Now what does this really mean?

In order to have a meaningful “benchmarking” exercise, you must first define an “as is” base case that describes the current situation with regard to a process, group, or person, and which adequately describes the level of performance.

Next, you must seek another “reference” group which, in your eyes, represents a “to be” state of performance which you seek to emulate within your own group  or process.

Where can you locate such a “reference” group?  Outside organization such as Gartner, Forrester, or the Corporate Executive Board  can provide a good starting point in terms of processes, the expected behavior and activities of these processes, and ways in which you could measure the performance of these processes.

If you are examining actual PMO processes, look at the standard-bearer companies like American Express, Marriott and Eli Lilly & Company   for your reference group benchmark.  Similarly,  if you want to benchmark in other processes, such as Purchasing and Supply Chain Management, look at the titans–Motorola, HP, and Deere & Co.

You can readily see the power of this approach–it can be applied at the total PMO organization level, an individual internal PMO group level, or even at the individual person contributor level within the PMO.

Benchmarking has been successfully employed by thousands of organizations, even when they had little benchmarking experience when they began the process.  The key to a successful benchmarking exercise is a desire to improve.  Once an individual or a group decides to get better at whatever the process or task of the group might be, the wheels of successful benchmarking are put in place.

You can be a leader in the benchmarking effort of your PMO.  It takes a desire to contribute to the improved performance of the group and a “capability” to perform.  As we have seen in previous blog posts, capability is enhanced with “education and training.”  You should seek out knowledgeable references on “benchmarking”, and other companies in the PMO field who exhibit good PMO performance characteristics.  Talk to your local PMI Chapter, or to a local PMOSIG group.  They can assist in your selection of appropriate PMO performance measures.

Good luck–I look forward to your feedback!

I once worked with a college professor whose reference books on his desk had notations in the margins which consisted of columns of scribbled, handwritten dates such as “8/25/1982.”   When I questioned him about the notations, some of which consisted of five or six dates in a column in the margin, he said that many of the “topics” and “subjects” were really recurring themes in his research work.  The only difference was the social or environmental or technical ”context” at the particular time he reexamined the topic.   So to remind himself of those “contexts,” he placed dates in the columns as documentation of the different perspectives he had experienced.

When I thought back on this situation, it occurred to me that a topic I had written about during my days in the ConocoPhillips Program Management Office (PMO), and which was published in the company’s newsletter several years ago, had even more significance to the project community now than it did when I originally wrote it.  So, I decided to resurrect this topic, which roughly can be termed “Change Creates Opportunity.”

You see, in the turbulent times in which we find ourselves today, with uncertainty at every turn, and no assurance that a well-intended decision-based action will, in fact, create the significant long-lasting result that were intended at the outset or at the decision point, we need a “theme” around which to rally our efforts.

I have worked for five major petroleum companies over a twenty-five year period, and I was involved in at least three major mergers.  Accordingly, I often have thought that my middle name is “transition.”

Here are some resources that I used to adapt to the changed, post-merger environment during those transitions. 

These concepts were introduced by William Bridges in his book JobShift: How to Prosper in a Workplace without Jobs. You may also be familiar with Bridges as the author of Transitions: Making Sense of Life’s Changes, a highly acclaimed book which discusses how people respond physically, emotionally and intellectually to the transitions and changes in their lives.

The approach set out by Bridges takes advantage of your unique skill set and competencies; tools that you can use to contribute to your PMO’s success.

Bridges’ main theme is that “change creates opportunity.”  While change does tend to destroy old opportunities, the bigger implication for you, personally, is that change creates new “needs” within an organization. Many of these needs go unmet until someone recognizes them and takes action. Change relocates the opportunity by changing internal customer needs and the terms under which success is possible. 

What does this mean?

 An employee should consider the workplace as a “market” with supply and demand forces at work.  By looking at the “supply of” and “demand for” services and needs on a continual basis, you can determine what roles and skills are necessary and act accordingly.

In this type of market environment, you must learn to find the needs that are not being effectively or economically met by others–both inside and outside the organizational boundary (because external contractors and vendors can and often do meet these very same needs). This shift in thinking replaces the idea that job roles are restricted to only their formal definitions, and allows an employee more autonomy and ownership of their contributions to the PMO.

Change also creates new interfaces. These interfaces may be a face-off between two organizations, between a business and its environment, between two patterns of experience and expectations, or between new technologies and users of old technologies. 

Because interfaces juxtapose value systems, assumptions, needs, and languages, they create “unmet” needs. They demand workers who are good at brokering, translating, interpreting, training, linking, facilitating, negotiating, and servicing. These activities bridge the gap in comprehension and familiarity created by the interface. For example, your group may need assistance from the Global Internal Audit group to assess standards and processes in your work area or your project, but no one may be assigned to provide this linkage. The first step would be recognizing the need.  The second would be assessing what type of skill or competency is required to fill the gap. The third would be effectively closing the gap.

So, what does this imply for your day-to-day activities within the PMO?

Continually scan the environment for these unmet needs that define the marketplace for your group.   Be aware of what skill sets and competencies exist in your group for satisfying a variety of these needs.  Act as a facilitator or provide the linkage (REMEMBER THE LINCHPIN?) whenever possible to close the supply and demand gap for services.

Remember: “Change Creates Opportunity.”

The market will continually change but, by developing skills to recognize, adapt to, and fill the market’s changed needs, you add value for yourself and the PMO.

Is your PMO ready to meet the “unmet” needs in the marketplace?  Is is ready to react to a change as large as a corporate takeover? 

The rate of change is increasing. 

Today, there is a ”groundswell” of needs being satisfied through social media by varied stakeholders (rather than the traditional supply route of institutions).  New external requirements, such as Smart Grid, or Sustainability, or Carbon Footprint, or “the Green Movement”,  are other examples of forces requiring a change response within the PMO organizational framework. 

I encourage you personally to think about the concept of “Change Creates Opportunity.”  It is a perspective that creates win-win solutions.

If you have other changes you have experienced in your PMO, please share them with our project community through the Comments.

Thank you!!!

I was in a group roundtable discussion at the last PMI Tulsa Chapter meeting in which we discussed the various “generations” that are presently in play in the workforce, and the implications that this wide variation of working styles has for project work.  One project manager brought up his work with virtual teams on projects.  While he had formed an opinion of his team members’ expertise through their virtual collaborations via email and instant messaging, he found that once he encountered his team members on Facebook, and understood their backgrounds and their interests, he formed a more “informed” opinion and a greater appreciation for their competencies.  His team members’ Facebook profiles allowed him to see them in the real context of their everyday lives, including their extended interests, passions, and purpose.  The combination of the virtual team’s collaboration, and the team’s interactions on Facebook, allowed a more complete picture of the team’s capabilities, which contributed to the team’s current and future project success.

Several other roundtable participants, however, chimed in that they believed that the interest in “social media” would die down and be less of an influence in project work.  There were about as many different opinions of the role of social media in project management and the modern Program Management Office (PMO) as there were people at the table.

I am certain all of us have had similar discussions in recent months because the project community cannot escape the fact that “openness” now rules the collaborative nature of our daily interactions and our lives.

The role of social media and “opennness” continues to unfold every day with new forms and branches of social media being utilized by the general public in a variety of ways.  To the extent that more and more of the public embrace and use social media, it will find its way into more facets of our everyday lives.  It will become a necessity just as “personal communications” using phones and blackberries will be an assumed vehicle of existence.

So, what will be the role of social media (and open L\leadership) in the modern PMO?  Well, it depends.

It depends on the mindset of your PMO’s leadership with regard to the use of any form of media to connect your PMO’s employees and processes with the external environment and the PMO’s stakeholders. 

Roger Martin, Dean of the Rotman School of Management at The University of Toronto, has stated the problem in this way: 

“The struggle in balancing openness and control is a universal human problem.  While most leaders agree that greater transparency and authenticity can lead to significant benefits, many remain paralyzed by the risks involved in opening up the lines of communication with their stakeholders.  Tapping into the power of social technologies isn’t about mastering the latest shiny technologies, but instead having a clear idea of the relationships you want to form with your stakeholders.”  (From the introductory pages of Open Leadership by Charlene Li.)

How the PMO’s leadership sees itself in this new social environment is very important to the types of decisions that the PMO makes as to how it will employ these new social technologies.  In fact, in her new book, Open Leadership, Charlene Li of the Altimeter Group has used the phrase “Social Leadership” to focus on how organizations will development to handle these new social technologies.

Social leadership is defined as having the confidence and humility to give up the need to be in control while inspiring commitments from people to accomplish goals. 

First, if your PMO is still in the mode of looking at itself as a “cost center”–as many IT PMOs generally see themselves these days–then your approach to social media will probably be to see it as a drag on employee productivity and a cost increase item due to the linkage with the external environment and stakeholders.

But, if your PMO sees itself as a strategic partner with the other business/functional groups in the organization, then you will probably approach social media as an “opportunistic” and “value” addition vehicle.

The fact is, the PMO is like any organization.  It develops a “culture” over time which, in essence, is “the way things get done here.”  Key processes constituting organizational culture are information and communication flow, decision making and authority flow, and human resources flow. 

Organizational cultures tend to exist on a continuous spectrum between “closed” and “open” systems.  Once a culture is established, it is difficult to change.

This observation comes from experience.

When I worked for ConocoPhillips, the corporation was a “member company” of a group known as the Information Technology Research Institute (ITRI) of the Walton School of Business at The University of Arkansas.    Other typical “member companies” were Tyson Foods, Dillard’s, Walmart, Federal Express, J.B. Hunt , and Dell

The ITRI “member companies” sent representatives to meetings at U of A several times a year to discuss Information Technology and Project Management issues as they impacted the work of the various member companies.  I was often a participant in these discussions, and even facilitated a PMO Roundtable meeting. 

Each year, the ITRI identifies a “Top Ten List of IT Issues” which they believe will impact the member companies’ IT and business strategies in the near future.  It is always interesting to look back at how this list has changed over the last ten years to see what hot topics have risen to the top of the list.  Project Management and PMO operations, for example, have steadily risen on the list.  Innovation and Business Intelligence have appeared and moved up the list. 

During the 2008-2009 year, the Top Ten list was expanded to Twelve issues because of the emergence of two additional issues–Value Management and Social Networking.

The new ITRI Social Networking topic has the following description: 

“The explosive adoption of tools such as Twitter and Facebook have created new modes of personal and mass communication in the last 18 months, but business remains unsure of its benefit within the corporate walls.  Citing potential productivity decreases and the need to control corporate messaging, many companies have adopted a wait and see approach to this rapidly evolving phenomenon.”   (from the ITRI 2008-2009 Annual Report)

Now, keep in mind that this is a group made up of “member companies” who have embraced the evolution of the use of the Program Management Office (PMO) as a key delivery tool for project value to the organization. 

Professor Puneet Manchanda of the Ross School of Business at The University of Michigan conducts ongoing research in social interactions, social networking and social media.  

Manchanda recommends that companies pursue both “active” and “passive” strategies with regard to social media.  In the “passive” mode, organizations will gain valuable information about their particular subject by monitoring what others have to say about their day to day tools, methods, and practices. 

For example, evaluation of new tools, methods, and practices for Project and Portfolio Management will be played out in social media by those whose interests are in either (1) using the tools, methods and practices in their own business context or (2) those who wish to advance the use of such practices in the community at large.  A PMO can gain valuable insights by merely monitoring the ”conversations” taking place in that community and taking action accordingly.

Alternatively, an organization can take an “active” role in social media as it shapes the landscape for tools, methods, and practices of its discipline by taking particular positions that would advance its own particular way of doing business in its culture and context.  The various “stakeholders” which a PMO serves could then be kept in tune with the latest thoughts and actions of the PMO and, in many cases, could be asked to participate in the development of new tools, methods, and practices. 

This would be a powerful approach; it would build that all-important element of “commitment” which every PMO needs from all stakeholders.

Charlene Li in her book Open Leadership identifies four major themes in the transformation of an organization such as a PMO to an open, social media organization:

1.  Values drive the vision

2.  Leaders set the tone and the example for others to follow

3.  Extending the old culture into the new–if culture is made up of norms and values, the organization must define new processes to define how these relationships will work.

4.  Systems and structure sustain the transformation–supporting the new culture are new incentives and recognition systems, as well as revamped processes and procedures that govern interactions both internal and external to the organization.

Let’s take two examples of how this might operate in a PMO which “actively” uses social media. 

First, you may recall from a previous blog post that I advocated gathering project lessons learned at major break points in the project or, as some of you might say, at various stage gates.  The project manager could solicit project feedback from team members, sponsors and other stakeholders using social media such as Twitter.  A key to this change in the business process would be how this feedback is collected, reviewed for common themes, documented and shared with all project participants.

Second, let’s assume an example where a design point has been reached in a project where a potential scope change might occur depending on the tradeoffs and decisions that need to be made jointly between the project team and the stakeholders.  Once again, social media such as Twitter could be used to “inform,” “solicit feedback,” and “facilitate” the decision and sign off of the resulting scope change if necessary. 

You can see how both of these examples require certain norms, values, and beliefs to be supported by and in turn support the essential business processes. 

Trust and commitment are assumed ingredients supporting the scenario of Open Leadership.

Are there organizations that we can examine as case studies in how to structure processes, incentives, rewards, values, and beliefs in order to support the new open reality of collaboration? 

Cisco and Proctor and Gamble are two such organizations cited in Charlene Li’s book that Project Managers can study for clues our own PMO transformation. 

Make no mistake!!!  This does not have to be a major upheaval of existing processes and relationships.  But its success does rely on trust, authenticity and a willingness to approach control of key organizational processes in new ways.

This will certainly be a topic for discussion for many years to come as PMOs and social media tools and approaches advance. 

I would be interested in your insights about how you think PMOs will be impacted based on your experience working in a PMO environment.

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

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

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

I suspect that is far from the truth. 

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

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

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

1.  The probability of an event occurring.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

As usual, your comments are welcome.

In an earlier post to this PMO Blog (“What is the Impact of Project Environment on Project Lessons Learned and Knowledge Management” ), I talked about observations from my experiences working in a PMO setting about project lessons learned (observations which have been confirmed by others using systemic thinking principles). 

Project lessons learned can arise from two sources:

1.  From the individual project in question, usually by the project team’s analysis of their behaviors and actions leading to observed actual results. 

2.  From the project environment, usually by analysis of the “structure” of that environment and its effects on project team behavior.

Obviously, project lessons learned come from post-project completion analysis.  Project lessons learned are intended to inform and impact the future behavior of new and existing project managers in new future projects where similar project environments were considered the “as is” process state.  By using some systemic thinking principles, it is possible to effect the behavior and results of many projects “playing in the same space” by making changes in the project environment.  This is often termed as “leveraging actions” to the project portfolio.

Now what does that really mean? 

The project environment is composed of the external corporate environment and the internally created corporate environment.  Usually, the organizational and governance structures for a PMO group are defined and evolve over time as the organization evolves.  The structure put in place by the organization has a great deal to do with how people act, behave, and make decisions within that project environment.

We have often heard the expression that “structure influences behavior.”  The structure of the project environment is made up of the policies, standards, procedures, defined relationships, reporting linkages, etc, that constitute the working environment within the firm.  We are also aware that, in the dynamic complexity of project environments these days, well-intended actions can lead to unintended consequences.  John Sterman at MIT has studied this type of behavior extensively.  This is because the “cause and effect” are not close in space and time, and some nonlinearity may occur in which an action or decision on the part of a person or group may lead to unintended actions or behavior by others based upon their interpretations in their business context.

 Organizations and groups have the “ability” to anticipate and plan what effects their PMO structures will have on project behaviors.   Accordingly, they can take actions over time to react and adapt to unintended results that are occurring as a result of the structure of the project environment.   The project environment is a dynamic phenomenon–we can adjust structure in order to influence project behavior.  This approach to project management, however, is just in its infancy and requires some art along with the science.

For those of you who may have trouble visualizing how structure might influence behavior, let me offer an example from my experience.  Many years ago I worked as a Product Planner for a major domestic automotive manufacturer in the Detroit area. One of the benefits offered to top executives of the Division and the Company was a company automobile.  Each morning when the executive arrived at the building, he was met by a service technician who asked if the executive had encountered any problems or had any service items that needed attention.  At the end of the day, each executive drove away from the facility with a clean, serviced automobile.  At one time, a certain service problem was identified in the field and reported through the service warranty network to the company.  Reports and metrics summarizing the problem were reported through the ranks and eventually were highlighted to the executives in charge of product quality.  However, none of the executives had encountered the problem–or if they had encountered it, the problem was fixed with “same day service”.  The executives’ personal experiences led them to refuse to believe that the reports accurately identified the extent of the problem in the field.   The reported problems were not taken seriously.  In some cases, only one executive in twenty might have encountered the problem and, if he weren’t assigned to Product Quality, the problem was forgotten as just another ”minor” flaw.  As a result, the Division failed to react to a mounting service problem.  The structure of the executives’ benefits–the company car–had influenced behavior to such an extent that there was actually denial that such a problem existed.

Let’s examine another example a little closer to home in the PMO.  In the early days of defining new Program Management Office (PMO) processes and procedures for ConocoPhillips, we recognized the need to define some “rules” for Project Justification and Approval.  These rules called for the project teams to develop a Business Case to justify the project.  As in similar situations with other PMOs, we attempted to define some structure to answer the question “How extensive does the Business Case analysis need to be and who should be reviewing it for final signoff as an approved project?”  An early attempt to define this standard resulted in a “rule”  that every proposed project over $1 million total cost must have a full Business case with all economics and it must be signed off by the IT Authorization Board.  All projects under $1 million total cost must define a partial business case with limited economics and must be signed off by a subset of the IT Authorization Board.

Now, what happened? You could probably guess that there were many projects proposed at $900,000 or two projects proposed at $800,000 and $850,000 that could easily have been combined into a more strategic and doable project.  Remember:  “Structure influences behavior.”  “Well meant or intended actions can often lead to unintended consequences.”

So, the bottom line for those of you who are designing new PMOs or are working with existing PMOs which have a set of policies, standards, and procedures in place to “guide” the planning and execution of projects is this…..follow some simple evaluation questions I present here to lessen the risk that you will introduce some unintended consequences from your project environment:

1.  Develop some scenarios to test out your policies, standards, processes, and procedures.  Take a typical project and follow it through the Project Management Process to see what the behavior of project managers, team members, sponsors, or other stakeholders might be.

2.  If your policies and processes have been in place for some length of time, test them to see if the thresholds for governance committee reviews are still valid.  In other words, over time your PMO projects may have taken on different characteristics which have increased costs.  The threshold values for review and signoff may no longer adequately cover the portfolio as you had originally planned.

3.  If new technology is introduced rapidly into your process, have a review process in place to determine at the earliest point possible in the process if the new technologies are compatible with current technologies and infrastructure.  Otherwise, you will very likely incur additional costs for these new technologies when they are evaluated.

4.  Check the hurdle rates for your economic/financial analysis in your business cases at intervals to ensure that they are set consistently with the business objectives and the types of projects that you are deploying.

5.  Survey your Project Authorization Governance Groups occasionally to make sure there is consistency in the way each member of the Group is viewing the mission and value proposition which projects present to the organization.

6.  Examine key reporting relationships for the project team within the PMO and understand how the overall structure of the PMO influences where decisions are made and who makes them.

7.  Identify and monitor any cultural or business context issues that might play a major role in the project environment for your organization or industry.  Since these variables are dynamic and change over time, make sure you are evaluating all projects on a consistent basis.  This is, of course, easier said than done.  It involves being a student of the project environment and touching base with others in the PMO to ensure all bases are covered.

8.  Continue to look at project lessons learned and use the information to feed back to the front end evaluation process we are describing at present.

There may always be some project environment variables that are elusive and for which you will not be able to easily identify unintended consequences of actions taken by the project manager, project team, sponsors or other stakeholders.  That does not mean that you should dismiss  this analysis as having no value. 

Remember:  The more you know and undestand about all the variables in the PMO and its organizational setting which can impact project team and stakeholder behavior, the quicker you can identify process improvements and achieve sustained project success.  That is a sign of MATURITY of your project process and is a goal worthy of striving for.

Your comments or feedback on real life situations involving the project environment 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.

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.

“Best Practices” is a term which is used very loosely in project as well as other business contexts. Often people use the term when they mean those practices which can be employed with high probability of success across organizational or company boundaries.

But the real context of the application of Best Practices is within a single organizational context itself. Harold Kerzner, a recognized project management authority around the world, has defined Best Practices as “those processes, procedures or practices which a company or project applies to other similar situations because they have proved to be valuable or successful in the past and they can be assumed to be successful again in the future.”

Let me give you an example from real life that may bring this meaning home. My wife and I usually divide up the laundry duties. She starts the washing machine and I dry and fold the clothes in the dryer. Our daily wash load usually consists of two or three bath towels, four hand towels, four wash clothes and various other white goods. Now, from my experience with folding the dryer load many times, I have developed a practice whereby I always fold the bath towels first. Why? Because, removing the largest load items from the dryer makes it easier and more productive to fold the remaining clothes. It is faster. I have established this as a Best Practice within my household context.

Now, if I were to tell my neighbor on our cul-de-sac that he could employ my “Best Practice” to speed up his laundry process, I may or may not be correct. My “Best Practice” may not apply equally across the board to others. Why? Because he has a different laundry context. He may have a different size or composition of laundry load which doesn’t yield a faster operation because of its unique context.

That is why we must be careful not to assume that one project’s or company’s Best Practices might be applied equally well to another context. It is only after repeated application of the “Best Practice” in a similar project or business context that we can define it as a true Best Practice.

Of course, some basic business practices like using a template for notes for a meeting might be applied across the board as a Best Practice because of the tried and true nature of using such a template in many contexts.

I hope this has cast a new light on project Best Practices for you.

Mel Bost

Copy Protected by Tech Tips's CopyProtect Wordpress Blogs.