How Can We Influence the Project Environment to Positively Impact all the Projects Subject to that Environment?

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.