Complexity

Below is come materiel I developed on Complexity and Project Management.  I thought it might be useful.
Russ

Although the Project Management Institute’s definition of a project is generally accepted, the definition of complexity is much less clear. PMI defines a project in terms of its distinctive characteristics – a project is a temporary endeavor undertaken to create a unique product or service. [1] This definition highlights two distinctive aspects of a project: every project is executed within a defined time frame and every project is unique. 

Complexity; When is a project complex? Not an easy question but if we look at generally accepted complexity models we begin to see a trend that is useful for defining complex projects.  In biology the simplest plant is composed of one cell. As the cellular structure increases in number and number of connections to other cells increase the plant life is seen as more complex. In the animal kingdom, the single cell ameba is the simplest animal and life gets more complex as the number of cells combine to form muscles and organs, leading to the brain, which may be the most complex of all known possibilities, especially my daughter’s.

The complexity of a system is usually construed as number of parts or activities and their degree of differentiation or the structure of their arrangement. Thus, heterogeneous or irregularly configured systems are complex, such as organisms, airplanes, and junkyards. Order is the opposite of complexity. Ordered systems are homogeneous and redundant, like an interstate tollbooth or a production line in a factory. Complex systems have multiple interacting components whose collective behavior cannot be simply inferred from the behavior of the components.

Complexity has morphological and functional aspects. A junk heap (to use a favored example used by McShea and Thomas) may be morphologically very complex (in consisting of so many highly varied and independent parts) but is functionally quiet simple (just a glob for a landfill). On the other hand, what is functionally simple for us might be quiet complex to other users – in this case a seagull that must distinguish all the little bits while searching for morsels of food. [2]

In addition to the number of parts, the degree of differentiation, morphological and functional aspects of complexity, the number, type and strength of relationships between parts or activities also influences the degree of complexity. Typically, as the number of activities increase and the number of relationships between activities increase the project becomes more complex.

Complexity is also context-dependent. A project is more complex or less complex than some reference point, typically another project. The Manhattan Project, building the first nuclear bomb, was more complex than design and production of the F-15 Fighter. Project complexity is therefore better evaluated on a continuous scale than on a discrete measure.

Projects are complex adaptive systems. A complex system is a system consisting of a large number of parts or activities that interact with each other numerous or various ways. A complex system is adaptive if their activities adjust or react to events or the environment. Successful adaptive systems adjust activities in a way that allows the system or project to achieve its purpose.

The dependence of the project on the activities, the interdependence of the activities and the specialization of the activities underscore the relationship dependence of complex adaptive systems and projects. The nature of complex systems can be probed by investigating how the impacts of changes in one activity affect other activities and the behavior of the whole. Activities must be studied and understood as an interrelated, connected part of the whole. If you remove a computer chip form a laptop and the computer powers down, don’t assume that the purpose of the chip was to provide power to the computer. If you remove a project kickoff activity and the schedule indicates a shorter project duration, don’t assume that the project will finish earlier.

Complex adaptive systems have three characteristics that are also reflected in complex projects:

1.      Complex adaptive systems tend to self organize. Formal organizational charts aren’t very effective. Projects organize around the work, the phases or activities. The organization of the project reacts to the nature of the work at any given phase.

2.       Complex Adaptive Systems reflect evolutionary trajectories. The future can not be predicted by knowing the current or present state. Too many possible outcomes exist. If we ran an identical project three different times, we would deliver three different outcomes. We try scenario planning, Monocarlo simulations etc. to develop the most likely outcome but a change in when someone takes a vacation or a small change in delivery of an important deliverable can change the entire personality of a project.

3.       Complex Adaptive Systems co-evolve with environmental agents who themselves are reacting and changing. Projects apply technology that is evolving or developing. Projects interact with people who grow and change. Projects deal with companies who are seldom in a fixed state.

Projects have significantly different characteristics. The Darnall Project Complexity Index, DPCI, is a tool to evaluate various characteristics of a project and to develop a comprehensive understanding of the total project.

Each of these characteristics or elements is evaluated separately, relative to the industry standard for this type of project. A one hundred million dollar project to develop a prototype jet fighter or to construct a new highway maybe considered a small or medium size project in their respective industries but a one hundred million dollar medical drug research project may be considered very large.  The relative size of the project becomes one element in evaluating the project’s complexity level.

Complexity, within this index, refers to the number of cells in the project times the number of connections between cells.[3] As the project size increases and the duration shortens the complexity of the project increases. The technological complexity, cultural complexity, legal complexity and other indicators measured in the Index reflect the complexity of the environment in which the project will be executed.

Measuring the level of project complexity is an important first step in understanding the impact of increasing complexity. Managing more complex projects requires a different project management approach and a different set of management skills, tools and techniques than managing less complex projects.

The various complexity indicators can range from very low to very high within the indicator and when combined with other indicators can the increase the total impact on the project’s complexity. In addition to knowing the total project complexity rating, the implications of the interaction of the various indicators is better understood.

Developing relevant recommendations that will increase the potential for project success is a key next step for the DPCI. Understanding the level of project complexity and the implications of the interactions of the various indicators will allow experienced project management professionals to better customize the project execution plan. This information also allows project management to develop and allocate resources early in the project, in areas where the DPCI indicates potential problems. Understanding the potential problem areas also allows the project management team to better develop and allocate contingency in the project budget and schedule.

---

[1] A Guide To The Project Management Body of Knowledge, Project Management Institute, Standards Committee, 1996

[2] McShea, 1992,93,94 and Thomas 1993

Full House, The Spread of Excellence from Plato to Darwin, Stephen Jay Gould, 1996, Three Rivers Press, 201 East 50^th Street, NY, NY 10022

[3] A project cell is the smallest organizational unit of the project.  On large project this is typically a small team. On a smaller project a work unit or cell can be a person. The simplest arrangement is when a cell receives all the information needed to complete the unit’s work from only one other cell. The more cells that must interact for work to progress the more complex the project. This increase in complexity is impacted by many of the project characteristics measured by the Darnall Project Complexity Index.

What You Should Know About Megaprojects and Why: an Overview, in the April/ May 2014 Project Management Journal

What You Should Know About Megaprojects and Why: an Overview, in the April/ May 2014 Project Management Journal

I just finished reading the lead article, What You Should Know About Megaprojects and Why: an Overview, in the April/ May 2014 Project Management Journal. This was an invited article from PMI written by Bent Flyvbjerg from Oxford University.

Flyvbjerg presented the current state of megaprojects providing an overview of the current market and trends, a general conclusion that there are a huge number of problems with megaprojects, the source of these problems in a couple recommendations. A historical analysis of the development of your project was very interesting and included a number of statements that needed backup. For example, he said: “when projects of such as go wrong entire company’s national economies suffer.” This may be a logical conclusion but in a research oriented journal I would say he would need to present data to back up his point. He also included the stimulus package that was passed by Congress in response to the banking crisis as a project and the major acquisitions program portfolio of the United States Department of Defense. By including these programs within his discussion of projects he has blurred his arguments.

Flyvbjerg been listed a number of megaprojects that went wrong; over cost, late, not meeting the specifications and leading to a negative ROI. The list of projects that that one or more these criteria for an underperforming project was impressive. One of the most valuable parts of the article for me was a list of challenges that are inherent in megaprojects and are not typically dealt with in planning and executing megaprojects. In paraphrasing these challenges list included:

1.      megaprojects are risky

2.      planners and managers don’t have the appropriate skills

3.      stakeholders have conflicting interests

4.      technology is typically new and untested

5.      overcommitment to project without justifiable data

6.      optimism bias

7.      significant changes over time

8.      ignoring events that could cause risk for the project

9.      inadequate contingency

10.  misinformation about cost, schedule, benefits, and risk

Although I believe this list has a lot of validity, it would’ve been helpful to have some data that supported the belief. In a later section we also indicated that “front in planning this scant and bad projects are not stopped”. These types of conclusions cry out for citations.

Flyvbjerg quoted from the Standish Group research about the number of failed projects and I believe this detracted from his argument because of the flaws in this research that has been pointed out.

One of the more interesting parts of the paper was the discussion of the Hirschman’s Hiding Hand. In short, this is the intentional underestimate of a project in order to get approval. Flyvbjerg presented several situations where the original estimate of the project was intentionally at the level to be approved with knowledge that the estimate was significantly lower than the anticipated actual cost. In the construction industry recalled this “lowballing” an estimate. Companies would bid on projects at or below cost with the knowledge that there would be sufficient changes that could be created that will enable the company to make a profit. The art was estimating how you could go and how many changes could you create to have a successful project. I watch the original estimates for the new nuclear power plant proposal that went to the utilities commission in South Carolina. With my limited experience in this industry I estimated the cost to be at least double what was submitted to the utility commission. After initial approval, every update provided to the utility commission included at least a 10 to 15% increase in the estimate. I find it difficult to believe that the people making the estimate and probably the people accepting the estimate and making approval did not know that the true cost will probably be double.

Flyvbjerg suggested that there are number of drivers that lead to these intentional underestimates. He also recommended that companies and governments establish significant consequences for anyone or any organization that intentionally provides misinformation in these processes. He also gave several examples where countries are taking a step including the United Kingdom, Switzerland and Australia. It also appears that many private organizations are relying more on consultants to evaluate project bids more closely. Flyvbjerg suggest that we cannot solve problems that we do not talk about and cited Pres. Obama’s identification of costly overruns, fraud and abuse, and endless excuses as key policy problems, is one indication of a lease beginning to talk about these issues.

As I’ve addressed in other post, I believe this is indicative of where we are in the project management profession in the issues addressed in this article are not exclusively related to megaprojects. One of my focuses the best several years has been to better understand our projects. I believe the tools and techniques for developing a good understanding of the project are not well developed and without a good understanding of the project it is difficult to develop an appropriate execution approach. See my other post on project profiling.

One of the things I’ve discussed in earlier posts has been the breaking up of large projects into smaller components. Most organizations have a project size and complexity comfort zone and when the project gets too far out of that zone is important to break the project down into smaller projects that can be managed independently and coordinated from a program point of view. This approach should have had some mention in Flyvbjerg’s article.

The article is worth reading and does provide a good overview of some of the issues surrounding megaprojects as well as some of our project execution as a whole. It is important to put on the table that much of this underestimating of project costs is intentional and that’s difficult for the project manager to address and project execution.

Russ

Stress and Project Management

Stress and Project Management

Stress is a natural biological response to perceived danger or threat. Our biological response is typically fight or flight. This makes sense because to understand that you are threatened and to take steps to reduce this threat is basic to survival.

What does this mean to your execution of a project? One of the things that we know is that increase stress reduces creativity. When we feel threatened, blood flows from the creative parts of our brain to the parts of our brain that focus on our physical survival. The adrenaline increases, blood flows from our stomach in our brain to our muscles. This is one of the reasons that we need to go for a run or ride our bikes after a stressful day. This exercise tends to neutralize the effects of the adrenaline and stress of the day. So stress has the impact of reducing our ability to respond creatively to problem.

As a project manager seeks to understand his project during the initiation phase, one of the things to explore is the stress level on the project. So how do we evaluate the stress level of a project? One of the ways to look at project stress is to understand the comfort zone. The comfort zone represents the area where we have the knowledge, skills and abilities to meet the requirements.

For example, if the project schedule indicates the project needs to be complete within two years and the preliminary estimate to complete the project is two and half years, then we created stress. If the project team truly perceives that they have insufficient time to complete all the necessary activities, then there will be a degree of stress. The level of stress will depend on the perceived consequences of not meeting the schedule and the perceived ability to develop an approach to either change the schedule requirements or accelerate the pace of the project to meet the requirements.

In a similar example, the project team does not believe they can perform the project within the allocated cost, then the team stress will increase. This can have a cumulative effect. The combined effect of an unrealistic schedule and budget will be greater than either one by itself. There are number of different aspects of your project making stress. There can be organizational issues, cultural issues, technological issues, clarity scope among their number of different issues that can impact the stress level in the project.

We have a number of methods for reducing stress in a project management tool box. For example, as we explore options for reducing the time it takes to complete the project we can the crashing the project schedule, executed activities in parallel other than sequence and decelerating procurement activities as if you the tools available. This is also true for many of the areas that carry stress on the project.

This project manager’s protest is to first understand the stress on your project and then develop an appropriate execution approach that will address the stress and maximize project performance. Sounds simple? Probably not, but this is what makes our job so interesting.

Russ

PMI Meeteing, Networking and Trust

PMI Meeting in Ashville

I attended the PMI chapter meeting in Asheville last night for a presentation by Teddy Burress. Teddy made a presentation on networking and focused on how to build a social network. The basic premise was networking was built on the foundation of relationships. Relationships begin with people you know and expand outward as the people you know help you find others with common interest and common concerns. The basis of this relationship focused on not how you can use the relationship to further your goals but how can use relationships to support people in achieving their goals. This foundational belief will lead to times when people see the opportunity to help you.

This presentation was not overtly related to project management but themes are consistent in building relationships with your clients, your team members and your project stakeholders. Relationships are also built on trust. Not in the sense of unconditional trust that you may share with people that you have a more intimate relationship but trust in the sense that you have shared goals and shared understanding and beliefs on how to achieve these goals.

Establishing trust with your client as well as your team and stakeholders is one of the critical skills they project manager. Without this trust communication suffers. Without this trust commitment to a common goal suffers. Without this trust is difficult to have fun on your project.

Trust comes from respect. It comes from shared values and it comes from a belief in a shared future. You developed this trust respecting your client, your team and your stakeholders. You developed this trust by sharing your values and living your values daily. And you develop a belief in a shared future through developing a common vision of success.

One of the critical aspects of the teambuilding meetings that occurred during project initiation is the development of trust. Depending on the project profile, the processes and the investment in developing this team will influence your ability as project manager to develop an appropriate project execution approach and address the various issues that arise during the life cycles of the project.

Russ