Understanding and Surviving Project Complexity
The article Complexity is Often the Culprit in Cost Overruns and Delays was published last year in the MDCAdvisor® (March, 2014) and garnered much feedback. In today’s article we will revisit the Complexity and Systems Thinking topics and foster additional discussion of how and why project failures are driven by complexity. Complexity often arises to frustrate even the best efforts of Architects, Engineers and Contractors working to complete projects on time and budget.
Many of the comments generated addressed broader implications of the application of both Systems Thinking concepts and an understanding of complexity to problems in society in general and to government programs directed at solving specific problems. We have included these observations although our expertise at MDCSystems® is primarily focused on preventing, understanding and resolving Architectural, Engineering and Construction failures.
In order to provide a context for the observations, let me restate and re-emphasize the key points discussed and presented in the 2014 Complexity article. For our forensic analysis purposes, projects can be considered to be in four classes of control states. (See Snowden & Boone, Website – Ref D ).
(1) Simple: projects which are easily organized and managed using standard Project Management Body of Knowledge (PMBOK) principles known to all project managers;
(2) Complicated: projects requiring advanced project management skills and abilities. These are the situations where experience rules the day.
In these two categories all problems can be recognized and resolved by the application of advanced Project Management skills by team members or by an expert consultant/advisor. (Been There Done That).
(3) Complexity: projects that have serious structural challenges and/or interdependencies that do not always respond predictably to advanced PMBOK techniques. One characteristic that helps identify complex projects is that both structural and interactive relationships often change with each passing week and it can be difficult to predict their future effects. For these projects decentralized management is a valuable alternative to ‘centralized command and control’ techniques. Trial and error solutions can be implemented across the entire spectrum of the project to determine what works to pull the enterprise back into a manageable project state and condition.
(4) Chaos: Failing to restore the project inevitably results in moving to the fourth category – chaos. This domain is one of no return and nothing will work to salvage the enterprise and these projects are ultimately abandoned. Examples abound around the world. ‘Black Swan events (Ref 5), high impact/low frequency events, are at the genesis of many of these cases.
The intention of the original Complexity as Culprit article was to explain this approach to understanding the types of engineering and construction projects that MDCSystems® is called upon to advise/consult on and to show how Systems Thinking (Ackoff) could help provide insight to the three “functioning” project categories and assist in salvaging the project. Below are a sample of the insightful comments received from our readers in response to this article and our understanding of where — given the Simple, Complicated, Complex, and Chaos project categories — these examples and experiences are most instructive in solving future project challenges:
Comments received appear in italicized text.
Related to this, there are a number of heuristics I’ve developed for myself over time as a project professional:
• First, as the importance of a project goes up, so does the desire to control it.
• Second, as the desire to control a project goes up, the likelihood of its relative success goes down
• Third, as project participants begin to realize the likelihood of a projects relative success goes down, the desire to control it goes up
A self-perpetuating system…
I believe, much like Snowden describes in his Cynfin Framework, that complexity ought to be thought of as a phenomenon lying on a continuum. That is, when inquiring into a phenomenon, a practitioner can experience a simple level of complexity, a complicated level, a truly complex level or be faced with chaos.
Ackoff classifies Systems as Deterministic, Animated, Social or Ecological. The key distinguishing characteristic among these classifications is the notion of purposefulness. Most relevant to this discussion is the Social System. Regarding purposefulness, Ackoff describes Social Systems as those systems where both their parts as well as the system as a whole are characterized with purposefulness.
Ackoff goes on to describe purposefulness as the ability to control how to operate (choice) as well as what is produced (goal) after performing the operation.
With these operational definitions in place, it is safe to operate under the following premise:
Since project teams are comprised of people, people are purposeful, and project teams can alter their scope, project teams are purposeful. And, since project teams are purposeful, the levels of complexity they experience are, to quote myself,”truly complex.”
Ackoff also said “My point has been that when models of one type are applied to systems of a different type, the possibilities of effective choices is significantly reduced. This follows from the fact that the number and types of available choices perceived are significantly reduced when the system and the model applied to it do not match. The amount by which effectiveness is reduced is a function of the level of maturity of the system involved. Our society and the principle private and public organizations and institutions that it contains have reached a level of maturity that eliminates whatever effectiveness applying deterministic and animalistic models to social systems may once have had.”
That is, when applying a mechanical model to socially dynamic system, it does not work. Often, the application of a mechanical model to a socially dynamic system exacerbates what a project team is already experiencing – in other words, complexity increases.
Snowden suggests in his Cynfin framework that in the face of complexity the correct managerial response is emergence. That is, explore the environment to learn. Once the practitioner learns, he or she is better equipped to credibly act.
Therefore, project teams “ought” to cease using mechanical methods of control, and begin embracing emergence in the project execution space. Easier said than done I suspect.
The fact that Primavera scheduling programs commonly itemize and model thousands of activities and relationships for a typical construction project and in many cases add almost nothing to the effectiveness of the project teams efficiency shows how the ability to model misses the intention/point of preparing and implementing the model, which was to assist the PM team in managing the project. The ability to create the models many times exceeds the ability to use the model and the ability/practicality of getting useful information out of the model. On a macro scale the Donella Meadows article (Ref 4) provides a reality check on where modelers and their models sophistication exceed their grasp/understanding of the systems being modeled (interactivness) and therefore generate bogus information.
MDC’s experience with a Twenty Ship Coast Guard (CG) Modernization program provided a good example of this phenomena. The CG specifications required a program schedule for all the ships with activity durations of no more than seven days and a dollar value less than One million dollars for each activity. The schedules were produced by the contractor and delivered in the requested print-out format. A schedule up-date was prepared each month and CG comments were to be incorporated in the up-dates. CG personnel were still reviewing previous month’s schedules as new schedules were delivered. Each print-out was about one foot thick and schedules were arranged on the floor of the conference room around the entire room perimeter when we meet with the Project Manager concerning multi-year delays and a Three Hundred percent increase in the predicted final cost of the retrofit program. The very complete detailed model for the program exceeded the resources needed to manage and implement it resulting in misinformation and outdated corrupt data. We asked one question- why is there no summary schedule for each ship and roll-up for the program so that actual progress can be measured and understood? The Project Manager sighed and said, you consultants always ask the right questions after the fact! This program was in Chaos and was eventually revised (cancelled) renamed and refunded in a way that only government programs can be given new life. If Complex models are to be useful they need timely input, real progress data, constant maintenance and understandable output to justify their cost and provide the additional management insight expected of them.
Participants in this thread have mentioned project failure, delays, quality issue, cost overruns, and now aviation accidents due to overreliance on technology. Let me ad one more area to the mix where the lack of systemic approach, a too-narrow framing of the system, unadequate understanding of system dependencies, and the assumption of a controlable world hurt us — crisis and business continuity/disaster recovery planning. The plans my firm sees are usually brittle. They are based on mistaken assumptions such as: the people with a role in the plan will: find out in a timely manner about the anticipated events that trigger the plan, remember and understand their roles, successfully execute their tasks, and communicate with each other as needed to trigger and inform their colleague’s about new threats, task success, task completion failure and information required for situational awareness and decision making. When organizations with thousands of employees blindly assume that the right information will spontaneously flow to the right people at the right time — without validating that plan participants will communicate as needed – you have a recipe for failure.
MDC® agrees that “brittle” is a good term to keep in mind when reviewing all plans, and likely results from assumptions about future events. Consider the Black Swan events mentioned above, these events are rare, unpredictable and have huge impacts. Perhaps communications need more attention however much project correspondence and discussion (e-mails) that MDC® reviews are simply talking points and not exchanges of useful information at best and at worst are just deliberate mis-information to paper the file and prepare plausible excuses/arguments for future use!
One of the biggest common factors in all these programs is an across the board failure to try and envision what can go wrong and when; “design” risk management For example, I’ve managed several complex software/hardware integration projects and can tell you that writing software is almost all about predicting what won’t work or what will fail and then trying to head it off. But what’s frustrating is that these are issues that are repeated time and again, regardless of the project and it just seems like the developers never learn! I’m talking about dumb stuff like documentation that is outdated or misleading or data that isn’t in the right format or a spec that is ambiguous, or the tables that the processor uses has a known bug. These are known-knowns yet they are treated like unknowns.
Software projects provide excellent examples of Interactive complexity and unintended consequences of code gone wrong. Software development , as part of defense or control system projects (SCADA) have provided MDC® an opportunity to determine the following with some certainty: Software Modules although tested individually never work upon integration. Code development schedule/cost is underestimated at least by a factor of three. Assumptions such as; its going to be just like the last project, EXCEPT for a few changes are delusional. We will fix it in system acceptance testing fixes all problems, until acceptance testing!
My view is two-fold: For one, the complexity of a task is not appreciated at the estimation & selling phase of a project (why this is, needs fleshing out!) with a subsequent delay in communication, about that bit of complexity, when it is encountered at the work execution level, up the chain of command to somebody (PM?) who can do something about it. By then it’s too late. Secondly, I feel that with the three metrics to control projects time, money & quality of work, the two former are the easiest to measure (calendars & spreadsheets here we come!) with the quality being a bit more difficult to measure. Or, the measure, when it comes in the form of a user acceptance result, comes in too late to put in variations, change orders, etc. “The project’s going ‘live’ in two weeks!” they (PM) shout. An attitude of ‘make-do’ develops to honour the budget & time-line. The rest is history I’m afraid.
Trying to be systems minded myself, I have yet to come across a PM who thinks systemically, especially understanding the concept of ‘time delays in effects after certain causes have taken place.’
MDC® provides seminars and training in Systems Thinking concepts and the recognition and appreciation of Complexity and would agree that Project Managers are unfamiliar with and uneducated concerning these topics. They are not recognized at all in PMBOK and even at the Masters level in Universities it is rare to find an awareness. Dr. Pourdenand, at the University of Pennsylvania, and his association with the late Dr. Ackoff’s center for Systems Thinking is the rare exception. We have encountered many organizations that micro-manage elements of work that have little impact to the project success; one example occurred on a process plant where the spreadsheet approach to management had identified and counted and progressed one feature of the project brick-by-brick while ignoring the impact of events that were not on the schedule, which did control the success of the project! That which is identified and measured seems to get more attention from all; than that which is controlling the ultimate success or failure for the enterprise! Is this a failure of recognition/awareness or simply following a management edict to report on certain activities? Perhaps, this is really an example of a failure of organizational learning and adaption.
Having seen the high, on average about two thirds, rate of failure now in so many fields I’ve come to believe two things that we focus too much on trying to control things that cannot be controlled and the expectations of control are so high that information gets distorted to give the impression of being in control making failure even or likely.
This leads to two directions for solution, models that understand that solutions consist of elements that can be controlled, issues that can be solved others that can be influenced or resolved and yet others that can neither be controlled not influenced but just appreciated.
The other is to lower expectations of what can be known and controlled and design more dynamic approaches that learn to handle all three levels of power over project elements as the project evolves. Widely affected participants serve very different purposes through their project activities.
I learned this lesson in a dramatic way when evaluating the first social sector project for the World Bank. The first population project in Kenya was ranked an abject failure because it caused the population rate to increase rather than decrease. I revealed how in practice it had been transformed by the local Kenyans into an excellent maternal child health program. It served their purposes pretty well.
Systems Thinking concepts may have allowed for a pre-mortem evaluation of the program and identified the potential unintended consequences of the implementation of the program. Systems Thinking would likely have involved Kenyans to focus on and identify the real local needs rather than the social engineering goals of the World Bank. The interactions required to implement social programs likely give rise to unintended consequences of implementation. We leave to others the determination of implementation actions for these types of top down programs and their utility for the societal objectives.
Former President Clinton discussed a program designed to help lift the economy and welfare of Haitians some years ago. Observing the high price of rice in Haiti and being from a rice exporting state an obvious solution to this problem was to force the import of rice from the United States. Results were dramatic as the cost of rice in Haiti plummeted. Success was acknowledged, only later was it apparent that all local rice farmers were eliminated and the farms abandoned adding to the general poverty of Haiti. Unintended consequences that could have been foreseen, following the systems approach.
Many of the failures qualify as technical failures, or failures in name only, the result of choosing the wrong metrics to signify success. Biggest culprits: On Time, On Budget, On Spec, which might be reasonable targets when assembling physical things in time and space but devolve into the definitely delusional when applied out of that rather narrow context. I make the distinction between information intensive and ‘stuff’ intensive projects, my wife refers them as cat and dog projects. Dog projects enjoy obeying their master. Cat project are not manageable by dog projects.
MDC® generally applies a 10% rule when assessing project success or failure. If the project is over or under by 10% as regards cost and schedule we generally consider it a good project. That said we have consulted on projects that are exactly on time and budget but simply do not work for the intended purpose. This occurs in process type facilities and examples abound such as Trash to Steam, Sewage Sludge to Fertilizer Pellets and Recycling facilities. It is interesting to note that in the Sewage Sludge examples, first the EPA Ocean dumping ban provided the incentive to attempt the transformation coupled with the increasing cost of land disposal. Incentive and demonstration monies urged local governments to undertake the projects and the fixed compliance dates forced the technology into operation at production scale rather that demonstration scale to prove the technology. Water chemistry, solids content, compressibility, erosion and corrosion did the rest to prevent success for a number of undertakings, which increased litigation budgets for public entities and ultimately rate payers. A perfect storm of unintended consequences of implementation without Systems Thinking considerations as part of conceptual program planning.
Complexity definitely has a role to play in Project Overruns. The cause according to me is delay in decision making and trying to push the buck to others. When a delay occurs, decisions have to be taken fast- to mobilise additional resources at site, or to air freight a big vessel, and many other issues – the Owner invariably waits to take decisions to save costs – in the process, delays occur.I have seen this happen in too many projects in Middle East, India, Far East etc.
For those of us that are familiar with the cost structure of capital projects it is difficult to understand this owner perspective on saving money that costs more money in the future. On one very contentious hotel construction project MDC® was retained to replace the CM team and complete the work. As I was discussing the financial status of the project with the owner’s CFO, he was wondering out loud how the project got into financial trouble (50% Complete) and musing that until now he thought that the project was in great shape because they had so much of the budget still in the bank. My response was that the challenge on any capital project was to maintain spending at the predicted cost curve (spending plan) and to make sure that it coincided with the actual progress. He expressed some amazement at the relationship and I went on to point out that by not having a sufficient work force on site progress was lagging the spending curve and nothing could be done at that point in time to align the final completion and cost to the budget. (Delay and overtime costs would add at least $20 million to the cost with nothing new to show for it) This CFO was on his first construction project and was very experienced at managing budgets for ongoing enterprises, however construction is a batch process in engineering terms. Every dollar spent has to advance progress proportionately.
I like John’s comment “any promise necessary to win the bid”. In the full knowledge that the Project Team will be different later in the Project Life cycle so it’s someone else’s problem then. We can couple this with defective paradigms such as “win-win”. What matters only is that one party wins, the other party’s problems are theirs alone. Then there are PM Competencies.
Over the course of a number of years MDC investigated, analyzed and participated in dispute resolution of twenty projects for one client. Recognizing a pattern of similarities between the assignments MDC® developed and taught seminars using the client’s actual project examples and provided the tools necessary from bid submission to project management procedures that would eliminate the causation events recurring on their projects and provide defenses for the client. The implementation of the necessary steps by the client was never effectively carried out due to priorities being established by remote centralized corporate management and competing profit centers within the industrial organization. The series of projects were profitable on paper and this disguised the problems to some degree. These were all projects in the Complicated category and did require expert consulting intervention to preserve profitability at close-out.
This discussion is going in an interesting direction. I think in hindsight we often see an amazing outcome and forget how much of a failure it was at the time. Panama Canal, etc. Not to say we should settle for failure, but we would be smart to budget for it. Having said that I doubt it will happen. People are just to discount their passionate expectations for probable but nonspecific risks. The best I think we can hope for may be to structure and conduct complex projects in a way that exposes risk early and adapts to it well. I think that is the hope and promise of the Agile-like frameworks. Whether it pans out for complex projects, that remains to be seen. In business we seem to have a need for chaos even when we know it costs us dearly.
MDC® understands that this series of topics is technically dense and welcomes comments on this article and recommends that the cited references may help in the readers understanding of the underlying concepts and our recommended application to Project and Construction Management. For those who had the stamina and interest to make it to this point in the article, we have included references below to provide additional reading/research opportunities for inquisitive minds and/or sleepless nights. Comments and observations are welcomed and may form the basis for additional discussion in future Advisors.
MDC® has provided expert consulting services on a wide range of domestic and international projects for over fifty-years. If your organization could benefit from these types of timely, insightful and effective consulting services do not hesitate to call. Additional information on the Complexity topic is on our website at www.mdcsystems.com .
Reference Material and Websites:
•A Ackoff Collaboratory: http://www.acasa.upenn.edu
•B The Systems Thinker Newsletter: http://www.thesystemsthinker.com
•C The In 2 In Thinking Network: http://www.in2in.org
•D hbr.org | November 2007 | Harvard Business Review #69 Snowden and Boone
1. Fooled by Randomness, The Hidden Role of Chance in Life and in the Markets, Nassim Nicholas Taleb, 2004
2. Harnessing Complexity, Organizational Implications of a Scientific Frontier, Robert Axelrod & Michael D. Cohen, 2000
3. The Fifth Discipline, The Art & Practice of the Learning Organization, Peter M. Senge, 1990
4. Thinking in Systems, A Primer, Donella H. Meadows, 2008
5. The Black Swan, The Impact of the Highly Improbably, Nassim Nicholas Taleb, 2007
6. Thinking And Deciding, Fourth Edition, Jonathan Baron, 1988
7. The Fifth Discipline Fieldbook, Peter Senge, Richard Ross, Bryan Smith, Charlotte Roberts, Art Kleiner, 1994
8. Leadership and the New Science, Discovering Order In A Chaotic World, Margaret J. Wheatley, 2006
9. Complexity Leadership, Part I: Conceptual Foundations, Mary Uhl-Bien & Russ Marion, 2008
10. Business Dynamics, Systems Thinking and Modeling for a Complex World, John D. Sterman, 2000
11. Complex Systems Leadership Theory, New Perspectives from Complexity Science on Social and Organizational Effectiveness, James K. Hazy, Jeffrey A. Goldstein, Benyamin B. Lichtenstein, 2007