Showing posts with label profile. Show all posts
Showing posts with label profile. Show all posts

Tuesday, May 13, 2014

“Any fool can know. The point is to understand.” Albert Einstein



 “Any fool can know. The point is to understand.”

Understanding a project is absolutely critical to developing and executing an appropriate project plan. Project Managers spend significant time in defining client’s expectations, defining deliverables for the project and developing the data that we need to be able to develop a project charter in a project scope. We have developed tools and processes for gathering this information in articulating the information in different documents that become the foundation for developing a project plan. From these tools we gather a great deal of knowledge.
Sometimes knowledge is not enough. Developing an understanding of our project requires more than just gathering the data and collating the data into meaningful documents. Understanding requires seeing the interplay between the different components of our project and developing an understanding of how these different aspects come together to form a picture of a project. To understand our projects we need to think about the about the interplay between the different parts of the project, to process our knowledge of the project and develop a holistic view of our project.
The more complex[1] our project, the more difficult the task of understanding and developing this larger or more holistic view. The more complex our project, the greater the difficulty in developing a good understanding of our project. PMI has recently developed a tool for better understand the complexity of our project. In March of this year, PMI published Navigating Complexity: A Practice Guide online, hard copy is now available. Worth taking a look at.
Russ


[1]   Complexity can be understood as the number of parts and their degree of differentiation
                                                                Dan McShea,
                             Santa Fe Institute for the Study of Complexity

Thursday, May 8, 2014



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 50th 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.

Wednesday, April 30, 2014

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