ppmp20014 complex in project management

Sarath

aspects-of-complexity.pdf

Home >Engineering homework help >Civil Engineering homework help >ppmp20014 complex in project management

Project Management Institute

Aspects of complexity: mAnAging projects in A

complex World

Editor in Chief Terry Cooke-Davies, PhD

Contributing Editors Lynn Crawford, DBA, John R. Patton, PMP,

Chris Stevens, PhD, and Terry M. Williams, PhD

Library of Congress Cataloging-in-Publication Data

Aspects of complexity : managing projects in a complex world / editor in chief, Terry Cooke-Davies ; contributing editors, Lynn Crawford ... [et al.]. p. cm. ISBN 978-1-935589-30-3 (pbk. : alk. paper) 1. Project management. I. Cooke-Davies, Terry, 1941- II. Crawford, Lynn. HD69.P75A77 2011 658.4’04—dc23

2011024450

Published by: Project Management Institute, Inc. 14 Campus Boulevard Newtown Square, Pennsylvania 19073-3299 USA Phone: 1610-356-4600 Fax: 1610-356-4647 Email: [email protected] Internet: www.PMI.org

“PMI”, the PMI logo, “PMP”, the PMP logo, “PMBOK”, “PgMP”, “Project Management Journal”, “PM Network”, and the PMI Today logo are registered marks of Project Management Institute, Inc. The Quarter Globe Design is a trademark of the Project Management Institute, Inc. For a comprehensive list of PMI marks, contact the PMI Legal Department.

PMI Publications welcomes corrections and comments on its books. Please feel free to send comments on typographical, formatting, or other errors. Simply make a copy of the relevant page of the book, mark the error, and send it to: Book Editor, PMI Publications, 14 Campus Boulevard, Newtown Square, PA 19073-3299 USA.

To inquire about discounts for resale or educational purposes, please contact the PMI Book Service Center. PMI Book Service Center P.O. Box 932683, Atlanta, GA 31193-2683 USA Phone: 1-866-276-4764 (within the U.S. or Canada)

or 11-770-280-4129 (globally) Fax: 11-770-280-4113 Email: [email protected]

Printed in the United States of America. No part of this work may be reproduced or transmitted in any form or by any means, electronic, manual, photocopying, recording, or by any information storage and retrieval system, without prior written permission of the publisher.

The paper used in this book complies with the Permanent Paper Standard issued by the National Information Standards Organization (Z39.48—1984).

10 9 8 7 6 5 4 3 2 1

iii

Table of Contents

Acknowledgments .................................................................................................. v

Introduction: Managing Projects in a Complex World .......................................vii Chris Stevens, John Patton, and Terry Cooke-Davies

Chapter 1: Complexity in Project Management and the Management of Complex Projects ................................................................................. 1

Terry Cooke-Davies

Part 1 – With Practitioners and Their Managers in Mind ................ 15 Chapter 2: Managing Projects With High Complexity ....................................... 17 Stephen Hayes and Daniel Bennett

Chapter 3: Tools for Complex Projects ............................................................... 29 Kaye Remington and Julien Pollack

Chapter 4: Strategic Management: Developing Policies and Strategies ............ 41 Christoph Loch and Frederick C. Payne

Chapter 5: Fear of Flying ...................................................................................... 57 Stephen Carver and Harvey Maylor

Chapter 6: The Impact of Complexity on Project Cost and Schedule Estimates ..................................................................... 73

Dale Shermon

Chapter 7: Beyond Competence: Developing Managers of Complex Projects ............................................................................... 87

Lynn Crawford and Ed Hoffman

Part 2 – With Researchers and Students in Mind ............................. 99 Chapter 8: Human Behavior and Complexity ................................................... 101 Terry Cooke-Davies

Chapter 9: Controlling Chaos? The Value and the Challenges of Applying Complexity Theory to Project Management ................................. 115

Kaye Remington and Roxanne Zolin

Chapter 10: Systems Thinking and the Systems Movement ........................... 135 Peter Checkland and Terry Williams

Chapter 11: Systems Engineering and Project Management ............................ 149 Andrew Daw

Aspects of complexity: mAnAging projects in A complex World

Summary .......................................................................................... 169 Chapter 12: Toward a Coherent Research Agenda ........................................... 171 Terry Williams

Chapter 13: Toward Project Management 2.0 ................................................... 179 Terry Cooke-Davies

Contributors ........................................................................................................ 189

Acknowledgments

This book owes a great deal to many people.

The presenters at each of the Research Open Working Sessions, who so gener- ously provided their experience and insights, and the participants who made the conversations so lively. The contributors who have provided such stimulating chap- ters. The contributing editors, whose wise advice and ready support helped to give the book both shape and substance. And finally, of course Project Management Institute for funding this project and its many staff who have made this publication possible.

My grateful thanks to you all. It has been a privilege and a pleasure to work with you on this project.

vii

Introduction

Managing Projects in a Complex World

Chris Stevens, John Patton, and Terry Cooke-Davies

�And�when�it�comes�to�solutions,�simple�is�better.�Elegant�is�better�still.�� Elegance�is�the�simplicity�found�on�the�far�side�of�complexity.�

Matthew May, 2007, p. 3

This book has been written with three different audiences in mind: people who manage programs and projects (practitioners), line managers in organizations to which programs and projects make a substantial contribution (managers), and members of the academic research community who have an interest in how com- plexity shapes and influences the practice of program and project management (re- searchers).

Chapter 1 will be of interest to all three audiences, because it summarizes a se- ries of dialogues between practitioners, managers, and researchers. These dialogues provided this book with its shape and led to the choice of topics in the remaining chapters of the book.

Increasingly in the world of business today, practitioners and managers find themselves potentially overwhelmed by the amount of complexity that they en- counter. Successful project and program managers in these situations have had a natural or learned proactive perspective of what needs to be done. For many, obtain- ing this valuable skill of thinking and acting holistically can be accelerated, but not substituted, by exogenous learning. However, for most, such skills are obtained through years of experience. This experience is given another “C” designation, meaning Craftsmanship rather than Complexity. Chapters 2 to 7 (Part 1 of this book) will focus primarily on the experiential learning of experts, often labeled the “practical” application of the topics covered from a research point of view in Chap- ters 8 to 11 (Part 2). Finally, in the two concluding chapters, the first 11 chapters will be mined for “nuggets” of insight that are then used to outline the implica- tions of the book as a whole for research (Chapter 12) and for management practice (Chapter 13).

Project managers in early documented achievements, such as the construction of monuments or biblical narratives, had to both think and practice their leader- ship systemically to be successful. Systems engineering has in the past 100 years evolved from a “hard” systems perspective to a professional discipline based on sys- tems thinking and practice. Project management is an important relation based on

viii

Aspects of complexity: mAnAging projects in A complex World

similar ideas, even though success is generally based on the “soft” systems aspects of managing people. All projects at some level can be viewed as complex, but for most project managers it is not only their understanding of the “how it will be de- livered” but “how they can manage it” that can be, and is often seen as “complex.”

Of “complex” projects and “complexity” as a term, it is clear that for most peo- ple when confronted with something they don’t understand, it will be considered as complicated. Where there are exponentially “complicated relationships” making up the whole, they may see it as complex.

Breaking programs or portfolios of work down into parts to be managed better has been a common and important practice for handling complicated situations. However, from a systemic perspective, this practice ignores all of the important relationships between those parts. As more parts such as subprojects are added, the relationships between them continue to expand exponentially, so perceived com- plexity rises.

During many large and long projects, change is ongoing and normal. Manag- ers need to be more holistic in the way they view changes and current situations, as today’s solutions have the potential to be tomorrow’s problems. For many to understand a situation with a systemic and holistic discipline, as a means for both perceiving and understanding, it becomes possible to manage around the adverse aspects of change, and indeed leverage the positive.

Now, let’s move from the consideration of the complicated to that of the truly complex. Part 1 brings together some of the practical perspectives of utilizing sys- tems theory and practice in the context of complex projects and their management.

Progress during the history of the human race has always been fraught with challenges. For many, there was little or no precedent to build upon. For many centuries, humans have wondered about and studied from earth what the rest of the universe contains, and how it came about. Progress and understanding were not initially the results of pure study and contemplation. The real adventures in space started through the development of weapons of war. They then progressed to putting astronauts into low earth orbit, then reaching out to the moon and finally deep space.

These achievements may be seen as progressive advancement of knowledge and application. The unknown and new complexities of each stage were better under- stood because they were based on the experience gained from earlier projects. In addition, in the most successful cases, each stage was preceded by a strategic focus (for example, the mission to the moon spearheaded by President John F. Kennedy). Using previous experience, plans were established for the moon landing and they became operational, resulting in a final achievement of the goal (Apollo 11 landed on the moon on 16 July 1969).

As Doctor Jon Whitty explained during the March 2008 PMI Research Working Session in Sydney, Australia, the “C” word for describing the unknown and new challenges should not be seen in the context of complexity. Rather, to achieve an outcome in such situations, we should consider them in the context of challenges of craftsmanship.

introduction

Other presenters, at the same event, used complexity to refer to what appeared to be simple tasks, such as the refurbishment project of a local hotel, in contrast with building a large power station: (1) in another country on the other side of the world; (2) in the middle of an earthquake zone; and (3) using contractors from yet another distant country.

In another example, shoeing a horse was compared to building three advanced warships. In each case, one can learn some skills through an apprenticeship or ex- perimentation. In the case of the larger projects, one can contract in those skills, and use one’s experience in the leadership and dealing with large numbers of peo- ple, together with the experience gathered previously on similar projects.

Each one of the complex aspects of the simple projects was seen as such because they involved people, or, in the case of shoeing a horse, a large animal. The mutual conclusion was that it is the interaction with living sentient beings, rather than the technical issues of projects, which make a project complex. “It’s all about people,” said one of the leaders present.

Let us support this point by reflecting on NASA and their space projects. They suffered three very disastrous and public failures. It was determined that these failures were not just technical, even though the technology was admittedly com- plex. The failures were caused by failures in communications and interpersonal relationships.

Pellerin (2009, p. 11) stated that a Congressional investigation determined that between 80% and 95% of project failures are a result of either human or miscom- munication (which is still human) issues. People can clearly be seen as a, or the, critical component in the difference between ‘complicated’ and ‘complex’ projects. Furthermore, history has shown that irrespective of how those projects have been labeled, their success or failure will be due to the behavior of the people in the teams, as well as how they are managed and led.

Good leadership is common across all successful organizations. The ability to communicate and negotiate, to have integrity and people skills, and to be a proac- tive and systemic problem solver are all considered to be essential tributes to man- age projects.

Where Part 2 will provide the systemic foundation for consideration, Part 1 con- centrates on the context and practice of dealing with project complexity. As with all endeavors, albeit a program or a project, one needs to understand where we are going or what we want to achieve. What is the goal?

In the terms of that quote from Alice�in�Wonderland, as long as Alice didn’t care where she was going, but as long as she was going somewhere, then the Cheshire Cat’s answer was appropriate in that she would get somewhere, if she was to walk long enough (Carroll, 1865).

A similarly focused approach is not acceptable for most organizations. In any discipline or sector, commercial/not-for-profit, or public/private or government, there clearly needs to be a focus and strategy. This strategy must cascade down through portfolios, programs, projects, and knowing what tools are appropriate to help those who manage them with a high degree of complexity.

Aspects of complexity: mAnAging projects in A complex World

Part 1 addresses the pragmatic aspects of these issues. Within the context of de- veloping strategies, there are many considerations. These include risk and financial and resource allocations. However, one issue that needs the most focus is that of the “do-ability” of the goal. Can an outlined endeavor or strategy be achieved given the right management structure, adequate financial support, appropriate risk analysis (for all the stakeholders involved), along with the required skills and time?

This has to be considered in the context of the organization as it aligns with its overall ability to run a larger portfolio of short-, medium- and other longer-term projects and programs that need to be collectively managed. Their interactions and relationships, including time, finance, and risks (and shortages of appropriate levels and numbers of resources with the required skills to deliver) make up a portfolio of considered deliverables. Considered individually, the projects would be seen as simple or even routine. Yet, when the parts are brought together, and the relation- ships between them are considered as in a portfolio or large program of work, the situation often becomes complex.

For organizations to manage the potential conflicts within the portfolio(s), un- derstanding the interaction among projects and programs can require both simple and sophisticated tools. Without making the management of complex work more difficult, one must not fall into the trap of assuming that expensive and large com- puterized management applications for project/programs/portfolios will help. They will only help if the fundamental and simple concepts of their foundations and needs are clearly understood. If they are not understood, sophisticated, expensive, and inappropriate tools will certainly overcomplicate the situation, accelerating the journey to project and program failure.

For Part 1, at some level, every project can be seen as complex, especially if it is not understood by those who either sponsor or deliver it. In the past, by splitting a project into small subprojects has been a way of simplifying or reducing project complexity. However, within the systemic view, it is clearly the interaction be- tween the elements (subprojects, tracks, and deliverables) that is more important to manage than the larger projects. Such interaction invariably involves people; it was clearly agreed by academics and practitioners alike, during the PMI-ROWS sessions in that this point was a significant component in defining the difference between complicated and complexity.

In Part 2 of this book—Chapters 8 through 11—the topic of complexity will be explored from the point of view of researchers in different fields, each of whom has something to contribute to our understanding of complexity.

Much has been written in this introduction and in the first seven chapters of this book about the contribution that human behavior makes to complexity in proj- ects. So Part 2 opens with Chapter 8 with a review of research into some prominent aspects of human behavior, judgment, and decision making, which are so important to the fields of project and program management, and which are explored from a variety of behavioral and cognitive aspects.

Reference has also been made to the multiple fields of study, arising from the systems movement in the natural and life sciences and that have been grouped together initially as “chaos theory,” and later as “complexity theory.” Chapter 9

introduction

explores how these theories apply to the management of projects, and acknowledge the conceptual challenges that they present to both researchers and practitioners.

The 1950s and 1960s saw, at least in the popular imagination, a confluence of the fields of science, technology, and management such that the U.K. Prime Minister-to-be Harold Wilson could campaign in 1963 with a slogan promising the “white heat of the technological revolution” (Pearce & Stewart, 2001). It seemed as if approaches such as systems engineering, management science, and the study of systems in the natural sciences were all broadly aligned with one another and that they were leading toward the achievement of common goals, with the control of both organizations and technological systems lying within reach. It was in this mi- lieu that modern project management first flourished, and that the seeds were sown of what is now known as complexity science, or complexity thinking. In terms of understanding project management, complexity, and the relationship between them, it is necessary to understand the systems movement.

The systems movement as a whole is multifaceted, and through studies of both natural and artificial systems, has developed in a myriad of ways since the early days of project management. Chapter 10, presents an overview of this development, with special reference to soft systems methodology and to system dynamics, each of which provides a different research window through which we can catch glimpses of the causes of complexity in projects.

That part of the systems movement, out of which project management grew, included systems engineering, cybernetics, and management systems. It has been argued (Johnson, 2002) that it was this approach that distinguished the success of the U.S. space program culminating in the moon landing of 1969 from the failure of the European space program at the same time. This relationship between modern project management, management systems, and systems engineering remains an important one. Chapter 11 highlights recent perspectives on systems engineering and explores the respective contributions made by systems engineers and project managers to the challenges of complex projects that attempt to provide valuable solutions to “wicked” problems. In so doing, he makes the case both for new tools to be adopted by project managers, and for the kinds of behavioral skills and compe- tencies that are necessary to bring about success in such environments.

These four perspectives (systems thinking, systems engineering, complexity science, and cognitive studies) may not, on their own, be sufficient to reach a com- prehensive understanding of the nature of complexity on projects, but each one of them is most certainly necessary, and each of the chapters in Part 2 provides deeper insights into topics that were introduced in Chapter 1. Although they are written primarily with an eye on the research community, it is our intention that they will hold many insights that are of value to practitioners and managers.

Although Chapter 1 serves as an overview of the whole field, Part 1 has been written mainly with practitioners and managers in mind and Part 2 mainly for the research community, the final two chapters show very clearly how interwoven the interests of the three audiences really are. Chapter 12, written for the research com- munity, contains many issues and topics drawn from Part 1, whilst Chapter 13 finds many insights for practitioners and managers in Part 2. Indeed, the careful reader

xii

Aspects of complexity: mAnAging projects in A complex World

who is pressed for time may well wish to start with one of these closing chapters, depending upon which audience they belong to, and then allow these summaries to direct their attention to the chapters that are most of interest to them.

References Carroll, L. (1865). Alice’s�adventures�in�wonderland. London, England: Macmillan. May, M. E. (2007). The�elegant�solution:�Toyota’s�formula�for�mastering�innovation.�

New York, NY: Free Press. Johnson, S. B. (2002). The�secret�of�Apollo:�Systems�management�in�American�and�

European�space�programs. Baltimore, MD: The Johns Hopkins University Press. Pearce, M., & Stewart, G. (2001). British�political�history,�1867–2001:�Democracy�

and�decline. London, England: Routledge. Pellerin, C. J. ( 2009). How�NASA�builds�teams:�Mission�critical�soft�skills�for�sci-

entists,�engineers,�and�project�teams.�Hoboken, NJ: John Wiley.

Chapter 1

Complexity in Project Management and the Management

of Complex Projects Terry Cooke-Davies

In some ways, complexity is rather like love: Everybody has experiences of it and knows what it is, but ask them to define precisely what they mean by it and you will end up with a broad range of definitions. In the realm of project management, the terms “complex” and “complexity” have been cropping up extensively during the past few years.

In order to shed some light on the topic, Project Management Institute hosted a series of four Academic-Business Roundtable Discussions and Workshops on the topic of “Complexity in Project Management and the Management of Complex Projects.” These sessions were held in Atlanta, GA, Sydney, Australia, St. George’s, Malta, and São Paulo, Brazil. Nearly 100 attendees at each location, heard from a panel of six invited presenters. The participants were then invited to take part in an open discussion and workshop session. The presenters were composed of business- people, project management practitioners, academics, and consultants.

These events, and the lively discussions that took place during them, were the inspiration for this book. Presenters and delegates offered insights that were as var- ied in their topics as they were well grounded in practice, in theory or in both. In the course of the dialogue, it emerged that managing projects in an increasingly complex world is both a growing challenge, and one for which no easy solutions exist. The field itself is multifaceted, continually evolving and in pressing need of expert practitioners, supportive organizational environments, and well-grounded research to support both.

This first chapter provides an understanding of complexity in project manage- ment as it emerged from the presentations and discussions at each of the four events. Made up, as it is, of the insights from 19 distinguished practitioners, managers, consultants, and academics, it inevitably has something of the “scatter gun” about it. It also does not include references and citations, since the points it is making all emerged during the events themselves from one of the participants. For ease of reading, a single “voice” has been adopted for the narrative, to present the breadth

Aspects of complexity: mAnAging projects in A complex World

of ideas as coherently as possible. Subsequent chapters, which each elaborate on a particular theme introduced during the discussions, have the added depth and un- derstanding of the expert authors and refer to the source of the information.

What Do People Mean When They Talk About Complexity? As far as projects are concerned, there is a difference between “complex” and “com- plicated.” It doesn’t help to look up the dictionary definitions of the words, since each tends to be defined in terms of the other. If sense is to be made of the topic, then it is important to understand the concepts that people tend to have in mind when they use the terms, rather than educate them in one or the other particular dictionary definitions.

Similarly, although the term “complex” has a technical meaning (or, to be pre- cise, several different ones) when it is applied to “complex systems” in the worlds of science and technology, these technical definitions (which will be explored in Chapter 4) should also be distinguished from the everyday sense in which people speak about complex projects. Furthermore, they should seek to assess the degree of “complexity” that any particular project or program can be said to possess.

You could describe a system or a project as “complicated” if it has a large num- ber of interconnected and interdependent parts, whereas complex means something more. The Latin roots of the word imply “woven together,” so that changes in one part have an impact on the others. If this “woven togetherness” is combined with changes that can occur within individual elements, then a project can be said to be complex if it consists of many interdependent parts, each of which can change in ways that are not totally predictable, and which can then have unpredictable im- pacts on other elements that are themselves capable of change.

You could say that a modern saloon car or a laptop is complicated, whereas a Formula 1 racing car or the human brain is complex. As one of the contributors said, “If you don’t understand what will happen when you kick it—that’s complex.”

Aside from being a memorable way of describing complexity, this particular description also introduces a second important concept alongside the interaction of multiple parts—that of human “understanding.” Many activities or fields of knowl- edge appear to be complex when they are first encountered, but as understanding and experience grow, they appear much less complex to the accomplished practitio- ner. To many beginner drivers or people with no knowledge of the workings of an internal combustion engine, a saloon car is daunting in its complexity, whereas it holds few mysteries for the drivers and engineers in a Formula 1 racing team. Thus, a single project might appear to be more or less complex to different people associ- ated with it, such as the project sponsor or the project manager.

Complexity, then, is relative to an individual’s understanding. But what about collective understanding? There are limits to the understanding of groups of people, organizations, professions, and even of humanity itself. This would suggest that complexity is a characteristic that is always encountered in endeavors or activities at the frontier of the knowledge or technology of the people who are undertaking the activity. Projects to build ancient wonders of the world such as the Pyramids

complexity in project mAnAgement And the mAnAgement of complex projects

or Stonehenge must have appeared complex in their time, but look very simple in contrast with NASA’s programs leading to human flight to the moon, or some of the intricate and complex building and infrastructure projects that have been un- dertaken in the modern era.

On the other hand, the different components that make up the global economy are themselves complex elements that change unpredictably and then interact in unpredictable ways. As a result, in the postindustrial global world, apparently sim- ple concepts such as a single integrated business appear to be increasingly complex, difficult to manage, and prone to failure.

The tools and techniques of modern project management were developed to help people and organizations reduce the amount of complexity in projects by breaking complex activities down into simpler ones wherever possible—thereby designing complexity out of the project as far as possible and leaving the resulting activity simply complicated. Removing complexity remains a laudable goal, and it should be the first resort for many project managers. However, a combination of the am- bition that keeps humanity constantly pressing onward to new frontiers, coupled with increasing complexity in the global economy, ensures that there will always be projects that present their promoters and implementers with a high degree of complexity.

If projects with a substantial amount of complexity are also likely to have as- pects that need to be managed in ways that extend the traditional tools and tech- niques of project management, then just what factors can be identified that cause a particular project to be “complex” in this common sense use of the term? And what challenges do these pose for project managers?

What Causes Complexity, and Why Is It a Problem? Many organizations have developed their own means of assessing how complex a project is for varied reasons, such as assisting with the appointment of appropriate management or governance resources or positioning it within a portfolio of projects that are being considered for funding. Typically, such assessment schemes consider factors such as technology, size and scale, supply chain, geography, time pressure, stakeholders, and so on. The lists are long and varied.

Research into categorization systems has shown that organizations typically rate a project using, on average, 5 attributes, although the number of attributes can vary from as few as 2 to as many as 12. Factors assessed may include project scope, technical complexity, number of functions and skills involved, organizational in- volvement, level of ambiguity/uncertainty, number of sites locations or countries, organizational impact, clarity of goals and objectives, or source and location of risks.

Some organizations, recognizing that complexity depends on understanding, consider how familiar it is with the particular type, scale, or technology of the project.

It is worth looking into the different factors in this long and varied list and that can be said to cause complexity, and consequently, problems for project managers.

Aspects of complexity: mAnAging projects in A complex World

Unhelpful Behavior

There is widespread agreement among practitioners that one factor that makes projects complex is the interaction of human beings who are faced with making complex decisions. Complexity occurs when people with different interests, loyal- ties, cultures, and interactions with one another are put together to deliver a par- ticular project or program. This can be seen as variants on “organizational politics,” but it is actually more widespread than that.

All but the simplest projects involve teams of people coming together to ac- complish goals, and when physical teams come together, unpredictable behavior emerges. The larger the team, and the larger the number of teams involved, the more complex the project. People are not always rational in their decision making, and tribal instincts are deeply rooted in humankind, which makes the behavior of individual teams liable to evolve and be difficult to predict. In addition, the interac- tions between different teams are themselves unpredictable, especially if there are differences in national, organizational, or professional culture.

These differences are often magnified by the different perspectives of the people involved: Those who are implementing the projects, those who will use the prod- ucts or services that result from the project, those who stand to benefit from the success of the project, or those who establish the regulatory environment for the project.

Complexities like these in human behavior can reveal themselves in many dif- ferent ways, for example: Clients of projects can cause changes to project scope, delay important decisions, interfere with the project implementation team, or com- plicate actions and decisions through a lack of trust; the workforce that is imple- menting the project can become disincentivized through poor morale or exhausted through excessive schedule pressure; and managers can react inappropriately to cost, schedule, scope, or quality pressures. Indeed, in projects with a high degree of complexity, communication can be a significant cause of failure. This is perhaps not surprising, since the need to communicate, relate, and interact is a basic human need. Such processes of relating are complex and responsive, because interaction among humans is always unpredictable to some extent.

Anyone who has ever been involved in large-scale organizational change will most likely have experienced for himself or herself what happens when the rumor begins to circulate that reorganization is imminent. The complex human system begins to evolve, to react in unpredictable ways, and to develop its own response in anticipation of the announcement. On the other hand, when a fleet of contractors’ vehicles rolls up to start a major roadwork scheme with an inanimate system such as a road network, the roads don’t react!

Project managers can expect to be faced with such behavioral complexity, but their own response can create additional complexity of its own. Responding to dis- ruption by taking decisions that seek to recover the original planned schedule can lead to feedback loops, with unintended consequences and even, on occasions, cata- strophic failure. This response is a particular manifestation of a phenomenon that is well understood in the systems view of the world, and one that is a major cause of complexity in projects: systemicity.

complexity in project mAnAgement And the mAnAgement of complex projects

Failure to Appreciate Systemicity

When people talk about projects being complex, as we have seen, they are talk- ing about not only the number of separate elements in the project but also about how these interact. In other words, about the behavior of the project as a “whole system”—what could be called the “systemicity” of the project.

When project managers look at projects, they are used to breaking them down into their constituent parts (e.g., using work breakdown structures). However, when feedback loops begin to develop, quite simple behaviors in each element can combine and cause complex behavior to emerge for the system as a whole. Per- haps the easiest of these effects to imagine is positive reinforcing loops, or “vicious circles.” It is frequently encountered in amateur events making somewhat inexpert use of public address systems. The voice of the announcer is amplified through the loudspeakers, and this louder voice is picked up by the microphone and amplified further, and so on until the familiar ear-splitting “howl” results.

Similar effects can be experienced on complex projects, as unintended conse- quences from well-intended decisions result in the magnification and escalation of the original problems, until catastrophic failure results.

A pattern can be detected: project risks or perturbations create interactions that feed on themselves causing vicious circles; project managers respond to the disrup- tion by making decisions that seek to retain planned delivery and planned quality, usually by accelerating certain actions; these actions are also disruptions that, in turn, must be contained within a shorter time scale, therefore, increasing the power of the vicious circles.

Models

Each of us interacts with the world as we understand it to be, based on our own mental “models” of what reality is and how it works. Most commonly, these models are more implicit than explicit, and they are likely to differ in important respects from other people’s models. This diversity of models can be a major factor in causing complexity in projects.

Arising out of our models, we use symbols that are created, reproduced, and transformed by our interactions, and out of these symbols, we create and re-create meaning. That meaning in turn informs and directs what we do, so if our models are left intuitive and unexamined, they are likely to lead to unforeseen systemic effects at interfaces within the project.

Here, creating explicit shared models throughout the project team can help to improve understanding of the complexity inherent in the project. Conversely, hav- ing inadequate models that, for example, fail to recognize the extent of complexity in the project makes dealing with it that much harder.

Simplistic Project Management

One mental model that most project managers bring with them to the man- agement of complex projects and programs is their understanding of the tools and techniques of project management. Where these are incomplete or inappropriate,

Aspects of complexity: mAnAging projects in A complex World

they can add to project complexity. For example, a simplistic model of project risk management that fails to recognize systemic risks caused by the interactions be- tween individual risks, or that fails to identify the significant risks, can contribute directly to a need for the kind of decision making and behavior that causes the kind of issues with systemicity that have already been described.

Complexity can also arise because of assumptions that are inherent in tradi- tional models of project management and that are incompatible with actual systems and practices in the organizational environment of the specific project or program. For example, project managers may lack the authority necessary to manage the project effectively.

None of this, of course, is any excuse for failing to implement the “basics” of project management and use the tools and techniques in an appropriate manner to reduce avoidable complexity.

Over-Ambitious Strategic Management

A number of factors lead to increased complexity in projects in business and government. At least in the Western economies, the work force is aging while si- multaneously the number and value of projects being undertaken are increasing.

Against this background, projects are managed and governed within a context created by the management and governance systems of the promoting and imple- menting organizations, and the resulting “system of systems” adds a further dimen- sion to the systemicity that has already been discussed.

So too does the number of interactions (or “ripple effects”) between projects undertaken within a project portfolio aimed to accomplish strategic business objec- tives, particularly when a number of projects independently are each intended to create business change that has to be managed and integrated at the point of deliv- ery by the same business unit’s operational staff.

Other Factors

The foregoing may be five of the most prominent factors that come to mind when seeking to understand the causes of complexity, but there are many others as well.

For example, project management training that reduces all the tasks of a project manager to a simple and straightforward rational, linear, and deterministic set of predefined processes and activities, tends to increase the challenges of systemicity by developing project personnel who are not on the lookout for the project’s inter- connectedness.

In the global marketplace today, supply chains frequently consist of people and organizations from very different geographical and ethnic cultures, which place great challenges on the social systems that need to be created within a complex project. In addition, the same forces that lead to such culturally diverse supply chains place great pressure on the expectations of superior project results, creating what often turns out to be unrealistic stakeholder expectations and can lead to time pressure and resultant systemic problems and/or stress on members of the project team with a consequential increase in unhelpful behavior.

complexity in project mAnAgement And the mAnAgement of complex projects

In general terms, insights from the study of complexity in the life sciences sug- gests that there is a natural tendency for all organisms (including humankind and its “social” organisms such as project teams) to evolve complex responses to chal- lenges that they encounter in their environment. Which, taken together with the causes we have just examined, provide a compelling argument for why there is a pressing need for a coherent research agenda to understand both the causes of complexity, and what can be done to prevent it resulting in problems, waste, and economic and social failure. That is why Chapter 12 of this book is so important.

In the meantime, however, it appears that many of the factors that contribute to complexity can cause consequential problems for practitioners of project manage- ment are also the factors that hold out the promise of both mining the benefits from it and minimizing its harmful consequences.

How Can Practitioners and Organizations Best Respond To Complexity in Projects? Perhaps the most important observation about responding positively to complexity in projects is that the response should come from both the organization and from individual practitioners. To respond positively, there is a need for transformational leadership of the complex project or program, collective creativity to develop the system that is right for the particular project, shared knowledge among all those involved in the project, and processes that are adapted and adaptive to the project needs.

This kind of organizational and personal leadership is the measure by which one can engage, embrace, and drive to effect positive influences in delivering on strategy in the face of complexity. It is a leadership that recognizes that wherever possible, simplicity is the preferred option—possibly even elegance.

A great deal can be achieved by the rigorous and adaptive application of project management such that the fundamentals of a project manager who is skilled in leadership, a project controls system that is systemically sound, team members who know how they fit in and what they have to do, and well-conducted commu- nication and people skills. But doing so in a way that doesn’t create unwelcome complexity requires the first of the factors that are critical to success in managing complexity in projects, developing sufficient practitioners with the right competen- cies to deliver the whole portfolio of strategic projects.

Developing Practitioners

There is general agreement that good managers of complex projects are not born with skills they need, but rather that they learn them and perfect them over time. They develop a tacit sense of what needs to be done and become proactive in doing it. These skills are learned over time, much as a craft is learned, through the acquisi- tion of experience with the help of mentorship. It is appropriate to talk about crafts- manship—the old system of mentoring or apprenticeship where the tacit knowledge of an elder can be passed on to the pupil. A craft skill is a memory embedded in your very being. It takes guidance and time to acquire the skill. Therefore, it is not a mat- ter of training people how to do something; rather it is the repetitive and improving nature of honing practices to perfection.

Aspects of complexity: mAnAging projects in A complex World

As has been discussed, there is a shortage of people who are capable of leading large, complex projects and programs. With this in mind, Australian, U.K., and U.S. governments and senior representatives of the defense industry have supported an initiative to improve the international community’s capability to deliver very complex projects across all industry sectors. It includes not only a competency standard for use as a framework for assessing and developing managers of complex projects but also an executive master’s degree and continuing professional develop- ment in complex project management. This program allows people to think about what they do (as project managers) for an entire year. It provides employers with valuable experience and credentials, not one or the other; allows project manag- ers an opportunity to develop a language for complex project management; and provides project managers with a credential that can develop a positive correlation with competent practice over time through the ongoing evaluation of the perfor- mance of credential holders.

The program acknowledges that too often industry expects engineers to go to college for their degree but they are not given a complex project to manage as soon as they qualify. However, all too often there comes a time when overnight they are given one to manage. That can be harmful for both the individual and the organi- zation, whereas what is needed is awareness that people’s experiences in this field should be developed only when they are ready to accept more difficult (complex) projects. After all, in the medical profession, a new doctor may have knowledge but is not going to be allowed to do surgery on someone until he or she has gone through a residency program for the specialty.

Not every organization will be in a position to support such a master’s degree program, which, in any case, can reach only a finite number of candidates each year. There is a real need to recognize that developing a workforce capable of delivering a portfolio of complex projects requires more than acquiring a set of technical skills and competencies from a mentor over time. Many of the attributes required to man- age complex projects successfully are directly connected to emotional intelligence and interpersonal abilities. For example, one factor that seems to be important is something called “ego resilience.” Project managers need big egos if they are to believe that they can get the project done, yet need small egos to get out of the way and let people do what they need to do to get the project done. Therefore, the development program needs to contain elements such as this ego resilience. It is also a question of the project managers’ comfort zone—they need to be comfortable managing up and around in the environment rather than just managing technical aspects of a project.

Other development needs include understanding cultural differences on a deep level to bring out the best from multicultural teams; focusing on how to organize teams, which people should be put together to deal with such cultural develop- ments; and understanding all the commercial and risk management techniques that are necessary to deal with complex projects.

Finally, it is important to understand not only the skills that are needed, but also how they can be acquired. How do practitioners get better at learning skills? Learning from experience on projects presents a difficult challenge. The difficult part is mapping out what happened and what went wrong and learning the com-

complexity in project mAnAgement And the mAnAgement of complex projects

plex lessons, and yet unless this is done, any lessons learned are likely to be trivial or mistaken.

Appropriate Project Management

Perhaps not surprisingly, since modern project management had its birth in the ambitious and (then) complex projects of the post–World War II technology systems development, project management itself is seen as a powerful antidote to complex- ity. After all, the modular design of a project management system, together with the modular design of the system that was the project’s output, was explicitly developed to reduce complexity to manageable proportions.

Not all projects are equal, of course, and allowances need to be made to ac- knowledge that different types of projects have different characteristics. For ex- ample, in R&D projects, initial estimates of cost are far more difficult to make than in (say) refurbishment projects.

There are also some organizational practices in the implementation of proj- ect management processes that can help to combat unwelcome complexity. Proj- ect management offices (PMOs), for example, can reduce unintentional complexity in project management implementation if they are responsible for implementing standards in portfolio management and program management as well as project management. Similarly, careful attention to the relative authority of line managers and project managers can help. The aim is to strike the right balance between those processes that need to be tightly controlled and rigorously followed, and those that are better applied flexibly.

How project scope is defined has a big impact on how complex the project ulti- mately is. Some organizations have reported taking the stance that anything that can affect a project should be considered as part of the project, so there is no “macro” environment. In other words, as many external influences as possible are brought within the scope of the project. However, since there is considerable evidence that smaller projects of shorter duration are significantly easier to control than larger projects of longer duration, than this suggests that program management, combin- ing as it does a single integrated program with a succession of shorter more tightly defined projects, is an important weapon in the armory used to combat unwelcome complexity.

A second implication of this increased scope is that the design of processes for projects that affect a large public and use public funds will need to be established using highly visible independent bodies for such roles as conducting risk evaluation publicly and accountably.

Complexity in projects probably has its greatest impact in the sphere of risk management. What is called for is a shift toward “impact risk analysis.” This in- volves asking questions such as, “What is the effect if it continues? What is the effect of multiplicities of this?” Risk mapping, looking at overall pictures, can help and may help to scale up for larger, more complex projects, for which traditional risk analysis is often useless. Risk has to be monitored and tiered in a complex project or program, balancing threats with opportunity management and creating wealth not only for the business but also on individual projects. It can often be beneficial for all

Aspects of complexity: mAnAging projects in A complex World

potential stakeholders to be involved in the risk management process by identify- ing the risks that they are most conscious of and allowing proactive management to mitigate external problems.

Unfortunately, the current state of knowledge about projects that are late and overspend, does not distinguish clearly between projects that are well estimated and poorly managed, and those that have the opposite problems. It is clear, how- ever, that getting the estimate right in the first place is important for success, and the more complex the project, the more challenging this task becomes.

Constructive Behavior

In examining the causes of complexity, people’s behavior and the nature of hu- man beings were well highlighted. The good news is that just as we collectively have the capacity to create unwelcome complexity, people are also capable of pos- sessing competencies that provide the antidote to complexity.

Competencies that can mitigate complexity include:

• Passive empathy. The level of consciousness in anticipating and predicting situations and taking control of them before they become problems.

• Active empathy. The ability to quickly and accurately act on or communicate the situation. Ability to get to the core of problems through analysis and to develop and present solutions.

• Persuasiveness. Ability to influence others by listening, assimilating, and communicating information. Ability to negotiate and be flexible yet provide accurate information to key stakeholders.

Project managers accomplish their work only through other people—it is the members of the project team that actually deliver the end product. Therefore, it is particularly important to look for and develop those behaviors that encourage and build up the team. For example, it is important to give team members hope, so that they are motivated both to plan well and prepare for implementation and to carry out the actual implementation.

Especially on complex projects, it is a good idea to be prepared for things not to go according to plan, and if project managers find things getting over their heads, they need to be prepared to ask for help. It is crucial and important to ask for help in those situations. To that end, the project manager needs to manage and collaborate with all stakeholder groups.

It is perhaps a truism to say that managing complexity in projects is all about managing people, both upward (through upper management and influential ex- ternal groups) as well as downward. What that implies, however, is that it would strongly benefit the project management profession if it had a stronger theoretical foundation for understanding why people behave the way they do where projects are concerned.

The effective manager of complex projects also needs to be able to “turn things around” when the project gets into difficulties, and this can often involve making some fundamental changes to the culture that has developed within the project team. They need the ability to step outside the culture . . . to start evolutionary

complexity in project mAnAgement And the mAnAgement of complex projects

change processes that are more adaptive; to look at change processes to enable the team to progress; to articulate visions, embody values and create the environment within each team member, where things can be accomplished; and last but not least, to get the team involved in the values of creating an environment where the project can succeed.

If it is appropriate, project managers today can call on many advanced com- munication technologies including not only information and communications technology (ICT) but also advanced tools such as social networking capabilities or products such as Second Life, which can transform the experience of working vir- tually. Used unwisely, such tools can add to the complexity of projects, and that is where the project manager needs to demonstrate not only sound judgment, but also leadership ability.

The task of managing a complex project combines project management with leadership. To that extent, it is at least as much about who you are as a project man- ager as it is about what you do. People that successfully manage complex projects have creativity, imagination, openness, and flexibility, and they go with the flow. On the one hand, it is a good thing to schedule, but when the project is complex, it is important to let the creative juices come forward. Speak with successful manag- ers of complex projects and you will discover that they constantly have to have the big picture in mind, are willing to go into detail, and ask those burning, penetrating questions that cause people to see when they are off track.

It is only human to take setbacks personally when managing complex projects, and there are techniques for cooling down when you are emotionally upset. For ex- ample, trying to look beyond somebody who is antagonistic and responding neutrally to him or her. Teams can be extremely defensive because they got the project in trouble and if you get people really tired doing worthwhile work, it breaks down some of their defensiveness. This is not manipulative, but it helps people open their minds.

Like all effective leaders, the project manager needs to focus on the end goal of the project and manage all elements to that end, rather than managing the indi- vidual (technical) parts. It is in that context, that the effective manager of complex projects is able to understand the systemic implications of what is happening in different parts of the project.

Appropriate Response to Systemicity

Just as interactions between different elements of a project can have unintended consequences such as vicious circles, as we have seen, so understanding the sys- temicity of a complex project (the inter-relationships between the different ele- ments of the project) is central to a project manager’s ability to manage the project efficiently and effectively. It is this understanding of “the whole” rather than “the sum of the parts” that enables the effective integration of processes, knowledge, and leadership.

This is an area where a skilled project manager can add value to an organization by connecting all the dots to help the successful delivery of complex projects.

Reference has already been made to the consequences of not having appropriate shared models of complexity, but in a positive sense, mapping techniques and dia-

Aspects of complexity: mAnAging projects in A complex World

grams can aid in simplifying complex projects and demonstrating how the different parts combine. Feedback loops need to be understood, recognized, and evaluated for mitigating actions. Soft issues such as culture, language, leadership, and personal relationship management all contribute to a project’s complexity, so visual means of expressing them help with understanding and management. Indeed, if a complex project is understood as a complex system, then the activity of managing the project through taking informed decisions and the like is inseparable from the activity of learning about the project.

Understanding this systemicity is important when making upfront decisions with what inevitably turns out to be inadequate information, and so is building up that understanding as the project progresses and more information becomes avail- able. Sometimes actions or risks do not have the effect that was expected; in partic- ular, as we have seen, feedback loops must be recognized, analyzed, and controlled. For this to happen, the systemicity needs to be understood and modeled.

Frequently, such systemic interactions bring the project’s own systems and pro- cesses into direct contact with those of the promoting and implementing organi- zations, and this can bring many if not all of these different ways of mitigating complexity together in the form of the organizations’ strategic management.

Focused Strategic Management

The ripple effects caused by interactions between multiple projects have already been mentioned earlier in this chapter, as has the “system of systems” created by the interface between the project’s systems and those of its promoting and imple- menting organizations.

In a more positive light, however, the recognition by an organization of the stra- tegic importance of managing its complex projects effectively and efficiently can lead to a significant mitigation of unwelcome complexity. A major defense contractor, for example, can have as many as 15,000 projects being undertaken at any given time, and it is far from certain whether all of their project managers understand their proj- ect’s strategic intent and how it relates to the whole organization. This quantity of projects creates its own form of complexity, as has already been discussed, but it also creates the opportunity to create a “roadmap” of how the projects fit into the overall picture from a stakeholder perspective, showing how the outcomes from each proj- ects contribute to the overall strategic success of the enterprise.

Similarly, the creation of an effective means of identifying the complexity of projects, and matching that to the competencies and skills of project managers is a significant help in the strategic leadership of an organization’s most critical proj- ects. Indeed, to deliver strategy effectively, an organization needs the following: leadership in the form of supportive and appropriate behaviors within policies and applications processes; information that has integrity and meshes systemically; knowledge in the forms of appropriate interventions and experiential opportunities for people as was seen in the discussion of “behavior”; and processes that are not restrictive but rather, policies that are adaptive processes.

With this in place, there is a systemic and dynamic link between mission, man- agement of programs and projects, information, knowledge, learning, and under- standing in a given context and under given conditions.

complexity in project mAnAgement And the mAnAgement of complex projects

Other Considerations

These five groups of actions that can be taken by either individuals or organiza- tions to exploit any opportunities presented by complexity, or to mitigate its unwel- come threats, will have the effect of linking more closely a complex project to the organizations that collectively provide its environment.

It is also good practice to have a C-level project manager to represent key proj- ects to the executive level of the organization, to further the connection. It also has the effect of educating business leadership in issues around the delivery of strategy, while educating project management to the complexities and pressures of business leadership.

In the course of such dialogue, it is likely that there will be an increase in evidence-based measurement of outcomes, which is surely desirable.

Is Complexity in Projects a “Friend” or a “Foe”? It is easy to form the opinion from reading much of the literature on complexity in project management that it is somehow undesirable—something to be resisted and overcome wherever possible.

That is, at best, a partial picture of reality. Some complexity is the inevitable consequence of changes in society, technology, and the global economy. As such, it is neither a friend nor a foe, but simply a feature of the environment within which the art and science of project management are practiced. Some complexity, as we have seen, is the result of humankind continually striving for goals that are more ambitious and as such, if the goals are well formed, they are surely to be embraced as a friend and welcomed for the benefits it can bring. What remains are those un- welcome aspects of complexity that are not properly understood, are not responded to sensitively and appropriately, or are the result of misguided management deci- sions in the first place.

The remainder of this book is a serious attempt both to pull together what is currently known and understood about the topic, to help practitioners and their managers improve future practice, and to guide researchers into answering those questions that will best help to improve our understanding of this multifaceted topic. If it is successful in these goals, it will support the profession of project management as it seeks to adapt to inevitable complexity, to turn desirable com- plexity into tangible benefits, and to minimize the harmful effects of unwelcome complexity.

Part 1

With Practitioners and Their Managers in Mind

Chapter 2

Managing Projects With High Complexity

Stephen Hayes and Daniel Bennett

Introduction During 2009, the International Centre for Complex Project Management (ICCPM) hosted its first international roundtable series on complex project management in the United States and Australia. The roundtable series was titled “The Conspiracy of Optimism—Why Mega Projects Fail.” The conspiracy of optimism is a term used in areas as diverse as economics, environmental change, and complex project manage- ment. It describes a situation where a number of stakeholders, each with their own priorities and unique worldviews, tacitly ignore the reality of a situation in order to gain approval to proceed with a venture no one would sanction if the true outcome was known. The roundtable series provided the opportunity for senior government and industry officials from Australia, the United Kingdom, the United States, and Canada to analyze the issue, reach consensus on some of the drivers, and propose a future course of action. A position paper and findings paper have subsequently been written and an international task force has been established to help improve the in- ternational community’s knowledge and ability to better deliver complex projects.

This chapter examines the findings from the 2009 roundtable series and con- siders the implications for program managers when dealing with complex projects, both from a public and private sector perspective. How does the presence of a high degree of complexity influence the behavior and practice of a project manager? What does it feel like to be a program manager in a complex project? From an existing good practice perspective what has been found to work or not to work? What are the key elements that help or hinder a program manager? How does a project manager influence his or her environment to better manage the affects of complexity?

Complexity In situating this chapter, it is also necessary to frame what makes a project complex while noting the contextualization of complexity ultimately depends on an indi- vidual or organizational “lens.” In 2007, the ICCPM led an international meeting that described complex projects as those that:

• can be characterized by uncertainty, ambiguity, with emergent dynamic in- terfaces, influenced by significant political or external changes;

Aspects of complexity: mAnAging projects in A complex World

• run over a period which exceeds the product life cycles of the technologies involved or where significant integration issues exist;

• defined by effect (benefit and value) but not by solution (product) at inception.

Key Issues as Highlighted by ICCPM Roundtables The following paragraphs highlight a range of issues that complex project manage- ment practitioners, from both the public and private sectors, believe have a signifi- cant impact on the success of complex projects.

Unaccommodated or misaligned stakeholder views of success. The view of success is driven by divergent stakeholder expectations of project success that is derived by assuming each other’s interests to be aligned. As the number of stake- holders increase, there is an increase in risk associated with attributes such as out- come, control, ownership, and schedule.

Tension between product success and project success. The tension arises from, and encompasses the clash of paradigms associated with stakeholder interests—pri- vate versus public, product versus project outcome. The purchase of a new defense capability, such as an airborne early warning aircraft (product), without consider- ation for its role in a much larger network-centric environment (outcome) is a use- ful example.

Political and public relations pressure militating against doing the right thing. How often do we fail to see the timely cancellation of multibillion dollar projects due to the implications for political and corporate image? To resist pressures of this kind, and to improve timely/difficult decision making, requires clear situational awareness and a comprehensive understanding of the facts coupled with personal and organizational courage supported by effective senior leadership.

Lack of understanding or acknowledgment of nontechnical risk. Traditional or classical project management focuses on hard system theories such as systems engineering that fully account for technical aspects of project risks. However, com- plex projects need to be viewed as organic systems of systems and should include soft systems issues such as politics and more often than not a significant number of external stakeholders. Consider planning risks (and opportunities) associated with the global financial crisis. Few of these relate to technical risk and, as with the po- tential policy changes and implications following a change of government, result in the need for a paradigm shift for many programs in the approach to understanding and managing risk.

Use of competition as a weapon. Competition within an open environment promotes effective and efficient use of resources. However, within monopsonis- tic environments, the use of artificially created competition has the potential to drive a misperception of competition, resulting in relative ineffective and ineffi- cient outcomes such as driving the contract price below an achievable level. This is analogous to perceived economic free markets that employ the use of tariffs to enable artificial competition. In a monopsonistic environment, both the customer and supplier have a responsibility to ensure they have a rational understanding of the real cost for capability through the implementation of systems to de-risk cost uncertainty.

mAnAging projects With high complexity

Institutionalized procurement practices. Classical project management re- sponds well to institutionalization of procurement practices and standardized methodologies. Within complex project environments, adhering to rigid procure- ment processes and procedures can limit the agility and ability of an organization to respond to complexity and therefore avoid the realization of unknown risk.

Few project managers are equipped to be project delivery leaders. It is becom- ing sufficiently evident that a project manager’s skill base needs to be multidis- ciplinary, encompassing source knowledge from discrete disciplines such as law, economics, engineering, and human resources. In the future, managers of complex projects need to be developed and selected based on a range of leadership skills that enables them to operate in uncertain and ambiguous environments. With global- ization and greater complexity, we are increasingly moving into an environment of globally interconnected organizations focused on strategic benefits realization. In this environment where outcomes are being managed using both operations and projects, project delivery leaders need to look and operate beyond the existing paradigms of project process and controls. Procedural compliance and engineering management are necessary but not sufficient for complex projects. In addition to the process and engineering of project management, our future complex project de- livery leaders need to be developed and selected with consideration to the “art and strategy” of program leadership that incorporate aspects such as systems thinking.

Lack of opportunity for engagement between government and industry. IC- CPM’s 2009 roundtable series provided an opportunity for senior government and industry officials from around the world to have a safe and nonattributable dis- cussion around the key issues causing complex project failure. Enabling this sort of activity through organizations such as ICCPM, Project Management Institute (PMI), and Aviation Week allows development of a shared understanding and agreed on definition of the issues we face in the project management community. More importantly, the engagement provides the starting point and a vehicle to begin to address these issues.

Future capability (projects) is predicated on attaining rational estimates. There is a need to improve project planning and estimation to be “realistic” and “afford- able.” Improvement in cost estimation tools as well as benchmarking cost of capa- bility are important aspects of reining in the often overly optimistic view of cost of capability. Failure to do so will result in unaffordable long-term government capa- bility or corporate investment plans.

Current tools and decision processes unsuitable for analyzing uncertainty. In an increasingly complex and ambiguous world, the inability of current tools, pro- cesses, and the human mind to analyze uncertainty poses a significant problem. Research investment is required to develop tools that focus on project relationships and interconnectedness of those parts of the “system” that cause uncertainty and thus complexity.

Complex Project Management in Practice Perhaps the first question to consider in a discussion about complex project man- agement is why would anyone ever contemplate a complex undertaking? Given his-

Aspects of complexity: mAnAging projects in A complex World

torical issues with performance and risk of massive and intricate projects, reason might suggest that complexity should be avoided or reduced whenever possible. In most ordinary situations, that approach is entirely appropriate. Nonetheless, there is a powerful and compelling reason for accepting the challenge and risk of a com- plex project—the potential for greater benefits than would be possible by resorting to a more conventional and simplistic approach. Complexity in any situation must be characterized in terms of not only its principle context-specific attributes but also in terms of what it means from the standpoint of risks and rewards, and to whom both risks and rewards accrue.

So, how do organizations decide to take on the challenge of a complex project? And, once they decide to do so, how do they manage complexity to achieve benefits that make the endeavor worthwhile? Let’s examine the nature of what organiza- tions do and how they think about complexity in order to begin to answer these questions.

Stakeholder benefits and the measures of success and failure. One key attribute of nearly all complex projects is that they typically involve a large number of di- verse stakeholder communities with a broad range of interests, issues, and levels of activism. In many cases, very powerful and influential stakeholders have no direct involvement in or, in some cases, no real awareness of what is happening within the project. Furthermore, and rather interestingly, we find that quite often the com- plex project manager has no direct responsibility to key high-level stakeholders, nor do they have any formal accountability (credit or blame) for achieving the desired stakeholder benefits.

For example, in the 1960s U.S. space program, the American public, as stake- holders, was advised by national leaders of the imperative for manned lunar explora- tion. However, the public had little need or desire for access to information about what was actually being done by NASA project management. Nonetheless, public support was vital to sustain the effort. Generally, however, although NASA leaders and managers had a keen sense of the national will and the high stakes involved, their direct accountabilities were for execution of the manned space project only. They had little or no responsibility for the stakeholder benefits that were to derive from successful project management.

It would be a mistake to discount those stakeholders or to ignore project ben- efits that should accrue to them. One lesson learned from experience in managing complex projects is to pay attention to the entire stakeholder set and their expected benefits. More stakeholders generally make the effort more difficult to manage, but the reason for giving them voice and consideration is tied to the value proposition of what it means to realize stakeholder benefits. In essence, the more a complex proj- ect manager can be accountable to deliver benefits to stakeholders at all levels, the more likely the project will be successful. In this sense, complex project managers draw within the project some of those accountabilities to stakeholders that would ordinarily be external to the project.

The organizational capacity for managing complexity. Ross Ashby, in his pio- neering work on cybernetics and systems thinking, contributed what is called the Law of Requisite Variety, which essentially states that the controller of an activity

mAnAging projects With high complexity

must have the capacity to deal with at least as much variety as is presented within the activity being controlled. Though seemingly simple, this law has far-reaching implications for complex adaptive systems and the organizations that propose to manage them. One fundamental issue in this regard relates to the choices a man- agement team makes in determining the project’s internal scope, and thus the va- riety within the project system.

As noted in the previous section, for highly complex undertakings where suc- cess or failure may hinge upon risks and benefits as seen and experienced by ex- ternal stakeholders, the organization must often adapt to bring direct or at least indirect responsibility for those requirements into the project domain. For example, the F-35 Joint Strike Fighter program, a U.S. Department of Defense mega-project of unprecedented proportions, affects and is dependent upon many factors that are normally a matter of national or international policies and diplomacy. Although program leaders do not engage directly in international politics, they have in some ways adapted the project organization and its capacity for internalizing and influenc- ing things, such as economic and industrial policies in relation to F-35 worldwide industrial participation. Similarly, some effort has been expended to help ensure alignment of international financial institution expectations in relation to provi- sion of financial support to industries participating in the program. In this latter case, financial institutions benefitted from a better understanding of the nuances of U.S. defense procurement and how limiting factors, such as annual contracts versus single longer-term contracts, affect the risk and profitability of participating international companies. The program has adapted to provide industry engagement that, to a degree, has influenced changes in long-standing practices that would have proven to be overly restrictive if left unaddressed.

The organization as a hierarchy, or a network, or both? Many complexity theo- rists and researchers are occupied with the study of how complex projects are orga- nized, and how they conduct business in response to a constant demand from the environment for rapid self-directed reorganization. According to complexity leader- ship theory, complex projects require a balance between administrative, adaptive, and enabling leadership. In this model, administrative leadership implements and manages administrative or bureaucratic policies, procedures, and practices that are essential for any successful operation. Adaptive leadership produces effective and timely responses to the changing business environment and embodies the most innovative and Agile behaviors within the organization. The key contrast here is that administrative leadership generally follows hierarchical lines of authority and positional power structures, whereas adaptive leadership adheres to more of a neu- ral network form of organization and operation that many traditionalists may have difficulty understanding.

A critical truth, however, is that most work in every organization is done with- out engaging the formal hierarchy. People within even strong hierarchical orga- nizations learn the rules of engagement and then interact with each other with some degree of autonomy to get the job done. The difference in the most capable of complex project organizations is that they possess a strong enabling leadership function that moderates between administrative and adaptive leadership functions to purposefully enhance the adaptive neural network capacities for speed, agility,

Aspects of complexity: mAnAging projects in A complex World

and innovation, even while maintaining essential discipline and control through- out the business.

Enabling leadership achieves these outcomes by fostering one-to-one and one- to-many employee engagement and other forms of networking and self-organizing behaviors, while using values- and principles-based leadership techniques to guide the network toward self-control. As one example, Google is well known not only for its innovation, but also for its internal self-control within an environment that is notably unrestrictive except for a simple mantra of “do no evil.” It is interesting to note that individuals and work teams at Google usually determine for themselves what is good and what is evil; they do not need the organization to dictate that in- formation to them.

People and discipline. Within the framework of what complexity leadership theory suggests, our real focus is on what people need and how they respond within the work environment to produce outcomes that, in turn, drive value in the form of stakeholder benefits. Although complex situations clearly present new challenges requiring seemingly radically different management approaches, the notion of ad- ministrative leadership correctly establishes the need for stability, order, and clarity in organization, processes, and procedures. In essence, a well-formulated organiza- tional context establishes values, boundaries, and operating principles that serve as a stabilizing and guiding reference frame that helps people to accurately interpret meaning from their environment, to make sound judgments, and to maintain effec- tive relationships with one another.

It is vitally important for individuals to maintain very high standards in the practice of their respective disciplines, as lapses in those disciplines, even under or- dinary circumstances, can lead to catastrophic consequences. In complex projects, lapses in discipline initiate slow and steadily building erosion affecting the capacity of the organization to hold its ground, eventually leading to failure that is meta- phorically akin to a landslide. Thus, although there are certainly some detrimental mindsets created by many traditional forms of education and training, it is vitally important for people to possess a compelling drive for rigor and discipline within their fields of practice.

At this point, it becomes clear that effective organizations give attention to two critical networks that must be developed and maintained. First, leaders support and direct their energy to the building of core disciplines and professional connec- tions that might best be described as communities of practice, where individuals guide and strengthen one another—formally and informally—to drive standards and continuous improvement into their professional practice. Second, leaders also build each project team network by linking nodes in and between the communities of practice networks. That is, they select team members from the communities of practice to participate in the project, where a key communicated objective for each individual is to contribute value not only from their personal skills and efforts, but also by leveraging value from their professional network.

Systems thinking and paradoxical leadership. As noted previously, one of the key contradictions facing complex project managers is the tendency for formal training in any field to produce closed or narrow-minded perspectives. Almost every business

mAnAging projects With high complexity

enterprise or government organization is confronted with this problem, and its im- pact is more serious as complexity increases. Although the professional disciplines are critical, how those disciplines are taught and practiced is also very important.

Because complexity presents us with nonlinear and counterintuitive interac- tions and effects, we need holistic perspectives and systems views of projects and the problems they seek to resolve. For example, traditional teaching, beginning with elementary grade mathematics, science, and even language, gives us insight into the tremendously powerful concept of reductionism—the breaking down of problems into smaller, more manageable parts. This learned practice, though im- mensely valuable, produces an almost automatic and habitual response to virtually all problems. We become blind to the assumptions inherent in the approaches and tools we choose to apply, and we fail to appreciate how much error those assump- tions have introduced. Is reductionism bad? No. It is very good and effective in a wide variety of circumstances, as long as we recognize the limitations of reduction- ist thinking and where super-position principles—that is, the recombination of the solved parts of a problem—are not valid.

Systems thinking raises our awareness of these limitations and contradictions. A good example of this kind of systems level, holistic thinking is to consider the treatment of physiological problems in the human body. We would find it ridiculous to physically take the body apart, try to fix the individual parts, and then hope to reassemble them into something that would resume normal function. We all know the patient would die. Think about heart transplant surgery and what it takes to keep the body alive and functioning during the operation. In this illustration, we can see that a doctor must consider the whole, even while treating a discrete part, and that there are serious impacts to the whole because of any intervention.

Some of our more complex projects are beginning to resemble the kinds of sys- tems interactions and integrative designs that connect with this example. We are finding many more situations where constituent subsystems and parts have little meaning or verifiable function until assembled into the whole system or a com- puter-based simulation of that system. Examples might include the most advanced concepts in satellites, unpiloted airplanes, or computer networks that have high degrees of automation and artificial intelligence, even to the point of autonomous decision making and operation.

The complex project manager adopts a different kind of thought process that involves disciplined systems thinking with an acute awareness and sensitivity to the underlying assumptions that are presented within a specific problem or proj- ect. There are many valuable techniques that can be employed to discern those assumptions, to assess their implications, and to identify alternative definitions of the problem, assumptions, and possible solutions. Tony Proctor among many others, provides an excellent summary of creative problem solving techniques, in- cluding methods for lateral thinking that facilitate the challenging of constraints, paradigms, and assumptions. These are important tools and techniques for all team members to employ.

Using such techniques, a skilled complex project management team directs their focus on a deeper issue. For at the root of many incorrect or misapplied as-

Aspects of complexity: mAnAging projects in A complex World

sumptions, there are fundamental contradictions or paradoxes that cannot be over- come by conventional reductionist thinking. Many assumptions are planted at what appears to be the boundary of conflict between two or more contradictions. Fred Smith and FedEx saw an unchallenged assumption, a paradigm that constrained a whole world of intelligent people. FedEx chose to reverse the assumption with a twist of integrative, holistic thinking that said there is a viable business case for shipping a package from any one place in the United States to any other place in the United States and doing it overnight. They saw the paradox. They took an assumed “either-or” constraint, inserted “and” instead, and with some hard work along the way they created a new industry. Complex project managers understand the nature and need for the practice of paradoxical leadership—seeking and finding the para- doxes—those contradictions that serve as signposts to important breakthroughs. The breakthrough is initiated by challenging the contradiction, and fulfilled in finding a creative way to simultaneously satisfy what once appeared to be mutu- ally exclusive constraints. Solving a riddle that poses an apparent contradiction is a metaphor for this type of thinking.

Leadership through values, vision, and principles. In his book Principle-Cen- tered Leadership, Stephen Covey discussed the idea that much of true leadership is exercised by communicating a vision and a plan that appeals to the values of people through principles. Principle-based leadership provides a solidly anchored reference frame that serves as both a sure foundation and a navigation aid for decision mak- ing. As a foundation, guiding principles communicate security and confidence to team members, much like a handrail or ladder might do on a steep mountain trail. As a navigation aid, guiding principles give clarity to position and heading, just as the earth’s magnetic field would convey through a compass and as the constella- tions would reveal through a sextant. The latter metaphor is useful by extension to point out that truly sound principles are transcendent; they hold true no matter where you are or whom you are with. This metaphor further illustrates that prin- ciples have within them what is needed, such as a stable magnetic field, where some form of tool or technique or understanding may also be required, such as a compass, in order to derive something of value.

In complex environments, we are often faced with one of those paradigms that need to be broken. Many project managers think as if every problem has a solution for which there is a paved road or high-speed rail that will get them there. To the informed complex project manager, there is a whole new set of perspectives and skills, and a clear realization that much of what is required involves exploration and “living off the land”—that is, creating what is needed from what the local environ- ment provides at that moment.

Correspondingly, much of traditional project management training provides the equivalent of a driver’s license, with an emphasis on how to do many things that have been done many times before and for which a lot of standards and road signs are in place. Complex project management training, on the other hand, amounts to something equivalent to multi-climate survival training, where a lot of knowl- edge is required, but where wisdom, discernment, and good judgment are most im- portant. Complex project managers read the environment, regard the terrain, and understand how to eat, breathe, and live on the move through the unknown and

mAnAging projects With high complexity

unexplored territory to the next waypoint on their journey. They do not know all that they know through book knowledge or formal directed learning, but through knowing the principles of where to find water, food, and shelter, and how to deter- mine what direction to head in and how to navigate along the way. Complex project managers guide and are guided by principles because principles give them both a firm foundation of reliable knowledge and the ability to adapt that knowledge read- ily to changing or radically different circumstances. Principles equip, enable, and empower leaders to handle the unknown.

Sense-making leaders makes sense. In maintaining the connection with the model of principle-based leadership and the explorer metaphor, another key attribute of effective complex project managers is their multi-paradigm adaptive leadership style. They recognize that some circumstances call for a conventional ready-aim- fire approach. What sets them apart is that they also know that under completely different circumstances, a fire-ready-aim approach is needed and is much more ef- fective. Conventional thinkers are smirking and mocking in response to that idea. However, researchers such as Kurtz and Snowden, Snowden and Boone, and Palmer, Dunford, and Akin have long studied and validated that leaders who adapt their behaviors, styles, and modes of leadership to the situation at hand are much more effective than leaders who expect those being led to adapt to their dominant style of leadership.

Consider a disaster response team that is dealing with a disaster they never trained to handle. Disasters do not allow time to think or coordinate. Either re- sponders know what to do or they are paralyzed with inaction. Under those circum- stances, the only effective approach is for the responders to do what they know to do, react to what they sense, and then identify the next course of action: fire, ready, aim. Leaders in radically complex environments sometimes need to take action first, and make sense of the situation afterward.

Even in less challenging and risky environments, the notion of floating trial balloons or surveying a population for what they might prefer or find acceptable is common practice. A study of how the Japanese auto industry achieved traction in the U.S. market reveals that it was accomplished mostly through trial and error. Japanese automakers, most notably Honda, explored options, made small but well considered investments, and identified by way of exploration the right path and approach for action. Interestingly, as a tangential point, this was a strategy imple- mented to perfection; however, some highly regarded experts on strategy thought it was not “real” strategy at all. Those individuals were blind to the strategy that defeated them because their internal definition and paradigm held that strategy involved a predetermined destiny directed from an all-knowing supreme leader and carried out faithfully by motivated subordinates. A strategy enacted by a leader who embraces an explorer mindset and leads a team accordingly is indeed a strategy, and one that is likely prevail under many circumstances, particularly those dominated by ambiguity and uncertainty.

Systems and processes to facilitate the discipline of business. In closing, it seems an appropriate time and place to address some other fundamental and often overlooked aspects of management that, because of being overlooked, become ob- stacles to success in managing complexity. Every business has systems, processes,

Aspects of complexity: mAnAging projects in A complex World

and a way of doing things that are part of the formula for its success. These systems and processes should rightly represent a framework for business execution that in- herently includes standards for behavior and action that contribute stability and predictability to the enterprise. For the same reasons, though, all business systems and processes can over-constrain or under-constrain the behaviors and actions they are intended to control. Even in high performing organizations, there are likely to be some business processes that need to be refined, modified, or replaced. The orga- nizations in today’s volatile business environment need to know that the leap into the domain of complexity is extraordinarily risky for those who are not adequately prepared.

For example, an organization that has loose or ambiguous controls in place for financial or schedule management is inviting disaster. Undisciplined manage- ment controls lead to unclear expectations, inaccurate reports on performance and current position, and inadequate advanced warning mechanisms that protect the business from critical failure. Similarly, the introduction of new and unfamiliar systems, such as S.A.P., can produce significant temporary disruption and confu- sion, particularly if combined with the ambiguities noted above. When these fun- damental systems and processes fail or falter, the organization loses its ability to sense and see what’s happening. Furthermore, when cost and schedule are impor- tant to external stakeholders, poor management controls cause them to lose confi- dence quickly. Complexity makes these problems worse, and sometimes fatal to the project or business. For all involved, life is better if the organization is constantly maintaining or improving its business systems and processes, and ensuring that there is adequate rigor, discipline, and quality in them.

This dilemma becomes even more difficult to deal with where partnering is required. The fundamental issue here is within the premise for selecting a business for collaboration. Companies choose partners who have demonstrated that they have unique skills, tools, and capabilities along with their own company-unique systems and processes to manage themselves effectively and successfully. To ask that organization to change significantly toward becoming at best a second-class copy of another means that they are being asked to change the formula that made them successful. That doesn’t sound like a good idea, but neither does operating in partnership with a company that has substantially different systems and processes that make planning, scheduling, budgeting, and performance reporting trouble- some, thus jeopardizing the project. Both options have the potential to negatively affect the value contribution of the partner. This is another of those paradoxes that complex project managers must recognize and mitigate based on the specific con- text of the business situation.

References P20, line 43. Ashby, W. R. (1956). An introduction to cybernetics. London, England:

Chapman & Hall. P21, line 30. Uhl-Bien, M., Marion, R., & McKelvey, B. (2007). Complexity leader-

ship theory: Shifting leadership from the industrial age to the knowledge era. The Leadership Quarterly, 18(4), 298–318.

P22, line 6. Hamel, G. (2006, April 26). Management a la Google. The Wall Street Journal, p. A16.

mAnAging projects With high complexity

P23, line 39. Proctor, T. (2005). Creative problem solving for managers (2nd ed.). London, England: Routledge.

P24, line 18. Covey, S. R. (1991). Principle-centered leadership. New York, NY: Simon and Schuster.

P25, line 16. Kurtz, C. F., & Snowden, D. J. (2003). The new dynamics of strat- egy: Sense-making in a complex and complicated world. IBM Systems Journal, 42(3), 462–483. and Snowden, D. J., & Boone, M. E. (2007). A leader’s framework for decision-making. Harvard Business Review, 85(11), 68–76. and Palmer, I., Dunford, R., & Akin, G. (2009). Managing organizational change: A multiple perspectives approach (2nd ed.). New York, NY: McGraw-Hill/Irwin.

Chapter 3

Tools for Complex Projects Kaye Remington and Julien Pollack

If the only tool you have is a hammer, you tend to see every problem as a nail.

—Abraham Maslow

This chapter first defines the differences between a tool or technique, a method-ology, and a theory. It then describes the results of some of the research carried out by the author and her colleagues by focusing on the tools, techniques, or ap- proaches developed by senior project managers specifically to address highly com- plex projects. Selected tools are discussed in more detail. The chapter concludes with a discussion of tools in application.

A Case for Thinking Outside the Tool Box Maslow’s comment is entirely relevant to projects that we might define as complex. It preempts one of the most important findings from our research. That is, manag- ing a complex project successfully requires unconstrained thinking: thinking that embraces more than the standard textbook approaches to project management or the standard tools and methods. We asked senior project managers, who were se- lected because they had managed high risk, complex projects (judged as such by their key stakeholders), to list the key attributes that enabled their success. With- out exception all respondents cited phrases like the ability to “think outside the box”; “flexible approach to management”; “not being constrained by rules”; and ability to “think creatively.”

Most standard project management methodologies carry the implicit assump- tion that the practitioner will use a particular set of tools in a defined order, and that all or most of the tools in the methodology will apply. Complex projects can rarely be managed by applying a standard methodology that has been designed to be used unvaryingly in all contexts. Our research data reveal that tools, techniques, and approaches—and we bracket these three terms together in this context—were selected by experienced project managers as and when the situation demanded, and, if no appropriate tools were available, one was created to fit the purpose. Based on this research data, and supported by mounting anecdotal evidence, the project manager who successfully manages high risk and complex projects appears to be someone who can select from a vast range of tools, methods, and approaches, to ap-

Aspects of complexity: mAnAging projects in A complex World

ply what is needed, when it is needed. In some cases, this means engaging others who are more experienced with a tool or approach, in other situations, it means be- ing familiar enough with a range of tools and approaches to be able to “move with the moment.”

One Size Does Not Fit All: Traditional Approaches versus “Systemic Pluralism” Differences between individual projects have been recognized for some time. In addition, management research in this field has expanded in the recognition that traditional approaches were not always delivering the best results. Our research suggests that project managers who manage complex project successfully tend to develop their own methodologies and vary these considerably from project to proj- ect. The most productive methods appear to be based on the concept of systemic pluralism. “How do we handle it? Well it’s difficult …There isn’t one single answer.” Systemic pluralism requires two things from practitioners: that project managers recognize the systemic nature of projects and that they adopt a pluralist approach to the tools and methods they apply. That means applying many different tools and approaches and being alert to the need to change tools and approaches as the project complexity develops or changes.

The idea of systemic pluralism was developed as part of the systems field, under the banner of critical systems thinking, a branch of systems thinking which em- phasizes theoretical and methodological pluralism. Authors such as Midgley, Min- gers, and Flood & Jackson all discuss the development of critical systems thinking and pluralist ideas in the systems, operational research, and management science fields. Discussed in more detail in other chapters of this book, most projects can be more readily described as complex adaptive systems than as simple systems. Complex projects vary dramatically in form and character, exhibiting many differ- ent characteristics and aspects of systemicity. A single complex project may even demonstrate multiple kinds of systemicity, with various parts of the project show- ing markedly dissimilar characteristics and behavior. Differences in systemicity will almost certainly vary considerably within any program or group of interrelated projects.

For those projects that can be described effectively as simple systems, where the outcomes of the project can be so well defined that fully predetermined con- trol is possible, standard or traditional project management tools and processes are very efficient. However, in more complex contexts, where ambiguity, uncertainty, or lack of trust prevail, there will be aspects of the project for which control, in the sense of total predetermination of outcomes, is unlikely or even impossible to achieve. These parts of a project, or subprojects, may benefit much more from approaches based on both systems thinking and multidimensional approaches. In fact, faced with the pluralistic nature of the projects themselves, project managers have no choice but to adopt a pluralistic approach to practice that means drawing flexibly and dynamically from a range of tools and approaches in order to deliver satisfactory outcomes. When implementing a systemic and pluralistic approach the manager must first identify the nature of the complexity; then like an artist, select

tools for complex projects

from the palette of tools, those tools that will provide a variety of perspectives, re- veal the layers of complexity, and make the project manageable.

Defining Tools, Methodology, and Theory Defining tools, methodology, and theory is problematic because these words are used in different ways and in different contexts. Therefore, for the purpose of this chapter, functional definitions will be used. From a purely functional perspective, philosophy and theory can be seen as providing a formal conceptual framework for examining the world, an explicit perspective through which the world can be viewed. Likewise, paradigm is broadly defined as ”...a world view, spanning ontol- ogy, epistemology, and methodology...,” “…based on a set of fundamental philo- sophical assumptions that define the nature of possible research and intervention.” Readers interested in a more thorough exploration of the ontology of paradigms should refer to Kuhn. Complexity theory itself comprises a broad group of ideas, models, and predictive descriptions about how complex systems behave.

Also from a functional viewpoint, a methodology can be seen as a structured set of guidelines for the improvement of the effectiveness of a system or project. It develops within a particular paradigm and embodies particular philosophical and theoretical principles. However, methodology differs from theory and philosophy in that it contains practical guidelines. Checkland placed methodology as the middle ground between philosophy and technique, containing elements of both, while ”...a technique tells you ‘how’ and a philosophy tells you ‘what’, a methodology will con- tain elements of both ‘how’ and ‘what.’” Here, methodology is considered to be ”... the logos of method....” It provides the principles on which the method is based, and can be considered ”...a higher-order term than method and, indeed, than procedures, models, tools, and techniques, the use of all of which can be facilitated, organized and reflected upon in methodology.”

Tools, approaches, and techniques are the most practical part of the hier- archy, and they tend to make little direct reference to theory or philosophy. However, they are often created under, or associated with, particular theories or philosophies. For instance, PERT and Gantt charts are both associated with the way of thinking embodied in project management and can be linked to positiv- ist and realist philosophies. Tools, approaches, and techniques generally involve a series of clearly delineated steps. Because of this, it is possible to create clear standards for their use, while this is significantly more difficult for methodolo- gies. According to Mingers and Mingers and Brocklesby, tools are specific activi- ties with well-defined purposes. A tool can also be an artifact, such as computer software, that can be used to perform a particular technique. Use of tools can ”... lead to an end point without the need for reflective intervention...,” however, re- flection on tools, in relation to theory and methodology, can be useful in learn- ing from past mistakes and improving future performance.

The Relationship Between Tools, Methodology, and Theory One popular way of looking at the relationship between tools, methodology, and theory, is to think of them as a hierarchy. In this kind of hierarchy, theory is usu- ally thought of as sitting at the top, with methodology below that, with tools sitting at the bottom of the hierarchy (see Figure 3-1). In this kind of hierarchy, the upper

Aspects of complexity: mAnAging projects in A complex World

layers can be thought of as more philosophical or theoretical and distanced from the mess of practical application. By contrast, the lower levels are never as “clean,” re- quiring actual engagement with pragmatic necessity and providing a context where theoretical claims can be tested. Many different practitioners and researchers have found it useful to view this relationship as a hierarchy with different levels of ab- straction.

The upper levels in this hierarchy constitute the conceptual basis and intel- lectual context for the increasing practicalities in the lower layers. The upper lay- ers provide a basis against which consistency can be judged. These philosophical and theoretical aspects provide the “why” for methodology. Methodology can be thought of as specifying “what,” while tools and techniques specify “how.” We can ”...learn more about these tools by reflecting on their links to methodologies, or about methodologies by reflecting on their links to theory.”

The practical world of the lower layers plays a different role in this hierarchy. A theory that bears no relationship to the real world of practice is not of much practical value. For theory to be valuable it must enable action, it has to be applied and tested in the real world. Testing the real-world efficacy of the practice provides justification for statements made in the realms of theory and philosophy. Practical application of the lower layers can be used to test the validity of claims made in the upper layers, resulting in either validation of claims or the need to reassess and rework statements about the nature of the world. The lower layers can be thought of as a feedback system for the upper layers.

For Midgley, thinking of this relationship as a hierarchy suggests that theory and philosophy are given special value and thought of as incontestable. He argues that such a hierarchical relationship precludes the idea that practice itself ‘…may signal a philosophical inadequacy.’ However, it is clear that in practice theory and philosophy are often challenged based on practical experience. Midgley argued that philosophy, methodology, and tools should be viewed as mutually supportive.

Figure 3-1: A hierarchical relationship between the theoreti- cal and practical

Why

What

How

Methodology

Tools and Techniques

Theory Philosophy

tools for complex projects

Methods can generally be thought of as an interrelated series of tools, used in practice to achieve a specific purpose. Methods may include representational guide- lines, such as modeling techniques, and procedural guidelines, which describe how work is to be conducted. To Paton a method is constructed to deal with an individ- ual situation. It is particular and individual. Methodologies “…provide us with logic to help us construct a method from a given set of tools and techniques.” Methods can be thought of as the practical output of the combination of methodologies and tools (see Figure 3-2).

Finding Tools that Suit the Nature of the Project Complexity Although we found many different tools in use, it was apparent that only some were relevant to complex projects, some were only relevant at particular times in the project life cycle, and some were relevant to one type of projects but not others. One of the tasks we set for ourselves, was to try to discover which tools were relevant, to what kinds of complex projects and when. However, we first needed a frame to define a complex project. As other writers in this book demonstrate, definition of a complex project is highly problematic. The definition is influenced by perception and context. Perception of the complexity of a project is influenced by prior experi- ence, personal capabilities, and the key stakeholders who are involved in making the judgment—their political agendas, cultural needs, and their own abilities to perceive an issue as complex. For example, in earlier research, we found that many sponsors did not perceive the complexity of the project in the same way that the project managers understood it. Some project managers felt they had to simplify the complexity in order to facilitate communication with a sponsor.

From our interviews with senior project managers, we collated a range of tools and approaches used, most of which differed from standard tools and meth- ods found in project management textbooks. We then analyzed the tools and approaches to discover the characteristics of the perceived complexity each tool or approach addressed and the stage of the project to which they were relevant. This, coupled with an extensive literature search, led to a classification of com- plexity types for projects, based on the source of complexity. With the exception of the fourth category, which we included to account for a particular source of complexity associated with time, this work extended the works of several other authors. The four categories or dimensions, which are based on the source of

Figure 3-2: The derivation and design of methods

Methodology

Tools

Method

to create a situation specific and contextually relevant

Enables us to design a process to select, combine, and use particular

Aspects of complexity: mAnAging projects in A complex World

complexity and may constitute a tool to assist stakeholders in identifying the nature of complexity, are as follows:

Structural complexity—derives from a classical view of complexity based on the structure of information pathways. The source of structural complexity is many interrelated and interdependent activities. Complexity, particularly in the form of non-linear feedback, can arise due to complicated organiza- tional and approval pathways as well as in huge work breakdown structures with myriads of activities that might interact.

Technical complexity—derives from technical or design challenges that are more severe than anticipated and in particular, problems that might not yield a solution within the time available.

Directional complexity—was viewed as a type of complexity that arose from unclear or unshared goals or goal-paths. Although this is most common at the beginning of a project, it can arise at any time due to changes of direction resulting from technical or environmental change.

Temporal complexity—was coined in response to projects that appeared to be unduly sensitive to unpredictable changes over time, due to the volatile nature of the internal or external environment. Even if the nature of the change could be anticipated, knowing when the environmental or organiza- tional impact might occur, what form it might take and its potential impact on the project can be hard to predict. Temporal complexity increases with the duration of a project.

The classification proved to be a very useful tool because it can assist project managers and other key stakeholder to identify or anticipate the source of complex- ity and the approaches that might best address the complexity. Some tools and ap- proaches apply to the whole of the project, others to specific phases, and others to specific dimensions of complexity.

It should be noted that although other classification systems include attributes such as uncertainty, we argue that categories or dimensions of complexity can have behavioral consequences, such as uncertainty, ambiguity, and loss of trust, which exacerbate perceptions of complexity. Thus, with the exception of directional com- plexity, uncertainty is treated as a consequence in this model, rather than a cause.

Whole of Project Tools and Approaches Tool for Mapping the Complexity

A tool emerging from our classification project has proved to be useful in help- ing key stakeholders recognize when a project is more than just complicated. Based on this knowledge, choices can be offered to key stakeholders about whether to proceed, how to proceed, and what tools and approaches might be useful and when they can best be used. An example provided by the authors was a remote area medi- cal facility. Being able to identify and agree upon the nature of the complexity and the expected level of complexity at the beginning of each phase of the project en- couraged key stakeholders to monitor and control the project based on the nature of the expected complexity. It enabled them to make appropriate adjustments to the

tools for complex projects

project’s organizational structure, key role definitions, and procurement systems as the project progressed through a temporally unstable landscape. As the assessment of complexity is based on perception, it is important that any tool captures the combined perception of the stakeholders. This in itself helps to stimulate dialogue about what contributes to the complexity of the project that, without such a tool, might not occur. As mentioned previously, earlier research revealed that although many project managers understood that the project was more than just difficult, their key stakeholders, such as owners and sponsors did not. This tool assists in structuring the kind of dialogue that is necessary if the project manager is to be given the kind of support needed for a complex project.

System Anatomy Tool

One project approach that stood out in the research was the “system anatomy,” which is now referred to as the integration centric development (ICD) approach, and was developed by the team at Ericcson, for a telecommunications rollout that spanned many countries. The challenge was integrating implementation in vastly different cultural settings by geographically distributed and often isolated teams, with different local work practices. The solution was to contain the master planning and communication documents to a one-page “anatomy” diagram that is constructed by key stakeholders. This document became the focus of all communication, control, and monitoring. Essentially the approach allowed central control of key elements and local control of work practices that could be developed locally to suit the particular context; including availability of labor and resources and cultural and political needs.

Time-Linked Semi-Structures

Another project tool, titled Jazz or time-linked semi-structures was derived from observation of projects managed in the entertainment and design industries where time to performance (or market) is often the critical driver in an atmosphere of highly interlinked creative team activity. Particularly in the theatrical world, there are also very tight economic drivers and high levels of competition for those all-important opening night reviews. More of a theoretical model than a tool, as such, this approach supports maintenance of a dynamic balance between a more formal structure at one extreme and the more chaotic environment needed to op- timize creativity. The reference to Jazz derives from the improvisational nature of jazz music, which is created “on the spot” without a prescribed score or plan. However, jazz, as a musical form, is guided by a non-negotiable framework that constrains what the soloist can play at any time. As the bassist Charles Mingus said “You can’t improvise on nothin.’ You gotta have something.’” The structure in the projects we observed was provided by a schedule, highlighting nodal points only, such as design or production meetings, and very clear role definitions that were well communicated and respected by all concerned. Around that structural spine or “time-linked semi-structure” the projects hovered near “the edge of chaos”—the hypothetical point where creativity and associated learning are like to be greatest.

Aspects of complexity: mAnAging projects in A complex World

Tools to Address Specific Aspects of Complexity Earned Value

One tool that addresses complexity is earned value management. Although this tool is part of the mainstream of project management tradition, our research sug- gests that it is still under-utilized as a tool. Earned value management is particu- larly useful in projects exhibiting high structural complexity and is indeed often applied in large engineering and defense procurement projects. Where high-level structural and technical complexity exist the most effective procurement options may be in the form of alliances or partnerships. However, successful alliances or partnerships depend on maintaining high levels of trust. For an alliance or partner- ship to work, all transactions must be completely transparent to all partners in the alliance. Transparency requires demonstration of rigorous monitoring and control. Earned value management assists in communicating transparency and maintain- ing trust in alliances or partnerships. If sensibly applied, it is one of the most effec- tive ways of keeping track of the value of what has been delivered within a specified time frame compared with projected delivery and expenditure.

Problem Structuring and Soft Systems Thinking Tools

Unclear or unshared goals or goal paths may exist in the absence of technical barriers or may exist before technical barriers have been discovered. Particularly, if the relationships are conflicted or where political agendas are unstated, high levels of complexity may result. Associated with this can occur a loss of trust and willing- ness to cooperate or work together. What is referred to as directional complexity oc- curs most frequently at the beginning of a project. If it is not addressed fully at the beginning, lack of clarity breeds loss of trust. Often larger goals are shared, for ex- ample, “we want to reduce customer complaints,” but the goal paths to achieve the overarching goal are unclear or unshared by the various levels of the organization charged with delivering the goal. Our research in the defense industries indicated that more often than not senior management understood the goals but the project personnel or industry partners, either did not understand, or had a different inter- pretation, of the goal or goal paths. Although directional complexity is probably the easiest to address given experienced facilitators using a raft of problem structuring and soft systems thinking tools, it is often not addressed adequately because people either do not recognize its presence or tend to ignore it in favor of leaping into what they believe is the meaning of the project. A number of soft systems thinking tools can be applied with great effect to clarify and share goals and goal-paths.

Summary of Tools for Complex Projects

The table below summarizes some of the tools and approaches used by expert practitioners to address different dimensions of project complexity.

Complexity in Combination and Tools The reality is that when a project is complex it exhibits several dimensions of com- plexity over time, if not all at once. Each dimension of complexity requires different tools and in some projects, a vast range of tools must be used in parallel. Even an apparently simple project can go very wrong if the nature of the complexity is not

tools for complex projects

recognized. In addition, the nature of the complexity can change over time, as in the case of the area medical facility discussed above. It is also important to note the potential impact of one dimension of project complexity on another and the ef- fect that intersection has on choice of tools and approaches. A project that initially presents few technical challenges can become highly problematic with a change of goal path when client requirements change. A structurally complex project might suggest the use of high level project control tools, however if there are technical challenges control needs to exercised in such a way that solution finding is not stifled too early in the project. This kind of situation requires a phased use of tool with approaches, like Jazz, that encourage rich communication, rather than overt control. If directional complexity is also present, enough time must be allowed to achieve understanding and alignment using soft systems thinking tools.

In reality, however, particularly with mega projects, such as large construction and engineering projects, a myriad of projects and interests intersect, each at dif- ferent stages and exhibiting different dimensions of complexity. In an intercity rail upgrade project, for example, temporal complexity was expected due to the duration of the project (over 10 years), the possibility during that time of a change of govern- ment (which might mean cancellation of the project), and the probability of signifi- cant advances in technology during the project life cycle. This is coupled with high structural complexity due to the size of the project, the number of railway stations involved, limited access to tracks and stations, the complicated approval pathways involving government and commercial entities and the potential for bottlenecks due to shortage of specialist expertise. Technological challenges also abound, as- sociated with how to address the number of bridges, tunnels, and stations that have existing heritage orders when few alternative tracks are available. However, the most challenging aspects relate to the directional complexity involved in aligning goals, addressing and monitoring conflicting requirements of the many stakeholder

Source of Complexity Tools to be ConsideredDimension

Structural

Technical

Directional

Temporal

High levels of interconnectedness and codependency between activities or organizational complicacy, resulting in unclear or redundant communication and approval pathways.

Design or technical challenges that are extreme or for which no solution is apparent within the time available

Unclear or unshared goals and goal paths; covert or conflicted objectives; cultural barriers, language and communication barriers; covert agendas

Shifting and unpredictable landscape over time; uncontrollable scope changes; uncertain political, regulatory, technical environments over the life cycle of the project

High level monitoring and control tools, including earned value management, procurement via partnerships, flexible procurement options, program management tools, OR tools, complex systems-based risk tools.

Clear role definition, procurement via partnerships and alliances, value management, “hands-off” management control approaches, creative thinking tools, integrating tools facilitating “rich” communication

Soft systems thinking tools, appreciative enquiry, trust building exercises, value management, problem- structuring tools.

Parallel processing tools (multidimensions in series), environmental scanning, problem structuring and problem analysis tools, change management tools focusing on team motivation.

Aspects of complexity: mAnAging projects in A complex World

groups. Tools are only helpful in these kinds of projects if they form part of a phi- losophy and methodology that support a systemic and pluralistic approach and if they are able to be used and applied in a timely manner, by people who are compe- tent in their usage.

Conclusion: Tools Are Just Tools It is important to recognize that managing a complex project is a higher order man- agement activity and should be treated and resourced accordingly. A discussion of tools is not complete without addressing organizational and individual capabilities. Tools in themselves are useless without the appropriate level of capability. Most im- portant is the capability of the governance team in identifying the nature of the com- plexity associated with a project, ability to identify the tools or approaches needed, ability to identify the skills and competences to apply the tools, and the willingness to ensure that the right people are engaged to deliver the project. Our data strongly suggests that the project managers who manage complex projects successfully are like artists, selecting the most appropriate tools and approaches from their very large palettes and working with those tools to produce the color, form and texture appro- priate to the work in hand. However, they also behave like scientists in their ability to select, analyze, and synthesize empirical data, and like politicians in their ability to influence and manage a network of relationships. Tools are, in the end, just tools.

Bibliography P29, line 9; P30, line 12; P33, line 23; P35, line 8. Helm, J., & Remington, K.

(2005a, May), Adaptive habitus: Project managers’ perceptions of the role of the project sponsor. Proceedings of EURAM Conference, Munich, Germany and Helm, J., & Remington, K. (2005b). Effective sponsorship, project manag- ers’ perceptions of the role of the project sponsor. Project Management Jour- nal, 36(3), 51–62.

P29, line 22. Crawford, L., & Pollack, J. (2004). Hard and soft projects: A frame- work for analysis. International Journal of Project Management, 22(8), 645– 653. and Pollack, J. (2007a). Multimethodology in series and parallel: Strategic planning using hard and soft OR. Journal of the Operational Research Society. 60, 156–167.

P30, line 7; P33, line 33. Turner, J. R., & Cochrane, R. A. (1993). Goals-and-methods matrix: Coping with projects with ill defined goals and/or methods of achieving them. International Journal of Project Management, 11(2), 93–102. and Payne, J. H., & Turner, J. R. (1999). Company-wide project management: The planning and control of programmes of projects of different type. International Journal of Project Management, 17(1), 55–59. and Shenhar, A. J. (2001). One size does not fit all projects: Exploring classical contingency domains. Management Studies, 47(3), 394–414.

P30, line 13. Remington, K., & Crawford, L. (2004, August). Illusions of control. Proceedings of IRNOP VI Project Research Conference, Turku, Finland. and Smith, C. (2007). Making sense of projects: Theory, practice and the pursuit of performance. Aldershot, UK: Gower Publishing, p. 22.

P30, line 21. Midgley, G. (1996). What is this thing called CST? In R. Flood & N. Romm (Eds.), Critical systems thinking: Current research and practice, (pp. 11–24). New York, NY: Plenum Publishers. and Midgley, G. (2000). Systemic

tools for complex projects

intervention: Philosophy, methodology, and practice. New York, NY: Plenum Publishers.

P30, line 22; P31, line 16. Mingers, J. (1997a). Multi-paradigm multimethodology. In J. Mingers & A. Gill (Eds.), Multimethodology: The theory and practice of combining management science methodologies (pp. 1–20). Chichester, UK: John Wiley & Sons. and Mingers, J. (2003). A classification of the philosophi- cal assumptions of management science methods. Journal of the Operational Research Society, 54, 559–570.

P30, line 22; P36, line 5. Flood, R., & Jackson, M. (1991). Creative problem solving: Total systems intervention. New York, NY: John Wiley & Sons.

P31, line 10. Healy, M., & Perry, C. (2000). Comprehensive criteria to judge the validity and reliability of qualitative research within the realism paradigm. Qualitative Market Research: An International Journal, 3(3), 121.

P31, lines 11, 18, 35; P32, line 11. Mingers, J. (1997b). Towards critical pluralism. In J. Mingers & A. Gill (Eds.), Multimethodology: The theory and practice of combining management science methodologies (pp. 407–440). Chichester, UK: John Wiley & Sons, p. 429–430.

P31, line 13. Kuhn, T. (1962). The structure of scientific revolutions. Chicago, IL: University of Chicago Press.

P31, lines 18, 35; P32, line 6. Mingers, J., & Brocklesby, J. (1997). Multimethodology: Towards a framework for mixing methodologies. Omega, International Journal of Management Science, 25(5), 489–509.

P31, line 19. Checkland, P. (1981). Systems thinking, systems practice. Chichester, UK: John Wiley & Sons, p. 162.

P31, line 23. Checkland, P. (1999). Soft systems methodology: A 30-year retrospec- tive. In P. Checkland & J. Scholes, (Eds.), Soft systems methodology in action (pp. A1–A65). Chichester, UK: John Wiley & Sons, p. S36. and Checkland, P. (2002). Thirty years in the systems movement: Disappointments I have known, and a way forward. Systemist, 24(2), 99–112.

P31, line 26; P36, line 35. Jackson, M. (2000). Systems approaches to management. New York, NY: Plenum Publishers, p. 11.

P31, line 38. Rosenhead, J. (1997). Foreword. In J. Mingers & A. Gill (Eds.), Mul- timethodology: The theory and practice of combining management science methodologies (pp. xii–xiv). Chichester, UK: John Wiley & Sons, p. xiii.

P32, line 6. Fitzgerald, B., & Howcroft, D. (1998). Towards dissolution of the IS re- search debate: From polarization to polarity. Journal of Information Technol- ogy, 13(4), 313–326. and Ragsdell, G. (2000). Engineering a paradigm shift? An holistic approach to organizational change management, Journal of Organiza- tional Change Management, 13(2), 104–120.

P32, line 13. Jackson, M. (1999). Towards coherent pluralism in management sci- ence. Journal of the Operational Research Society, 50 (1), 19.

P32, lines 23, 26; P36, line 35. Midgley, G. (2000). Systemic intervention: Philoso- phy, methodology, and practice. New York, NY: Plenum Publishers.

P33, line 2. Midgley, G., Munlo, I., & Brown, M. (1998). The theory and practice of boundary critique: Developing housing services for older people. Journal of the Operational Research Society, 49(5), 467–478.

P33, lines 4, 6. Paton, G. (2001). A systemic action learning cycle as the key element of an ongoing spiral of analyses. Systemic Practice and Action Research, 14(1), 95–111.

Aspects of complexity: mAnAging projects in A complex World

P33, line 12. Remington, K., & Pollack, J. (2006, December). Complex infrastruc- ture projects: a systemic model for management. Paper presented at ANZSYS Conference, Sydney, Australia. and Remington, K., & Pollack, J. (2007). Tools for complex projects. Aldershot, UK: Gower Publishing.

P33, line 12; P34, lines 27, 39; P35, line 24; P36, line 38. Remington, K., & Pollack, J. (2007). Tools for complex projects. Aldershot, UK: Gower Publishing.

P33, line 33. Baccarini, D. (1996). The concept of project complexity—A review. International Journal of Project Management, 14(4), 201–204. and Williams, T. (2002). Modelling complex projects. Sussex, UK: John Wiley & Sons.

P33, Figure 3-2. Paton, G. (2001). A systemic action learning cycle as the key ele- ment of an ongoing spiral of analyses. Systemic Practice and Action Research, 14(1), 99.

P35, line 15. Lilliesköld, J. (2003, November). Coordinating dependencies in com- plex system development projects. Proceedings of the IEEE Engineering Man- agement Conference, IEMC ’03, pp. 400–404. and Taxén, L., & Lilliesköld, J. (2005, March). Manifesting shared affordances in system development: The system anatomy. Proceedings of ALOIS, Second International Conference, Limerick, Ireland. Available at http:www.alois2005.ul.ie/. and Lilliesköld, J., & Taxén, L. (2006, October). Operationalizing coordination of megaprojects: A workpractice perspective. Proceedings of IRNOP VII Conference, Xi’an, China, pp. 574–587.

P36, line 10. Bjørkeng, K., Clegg, S., & Pitsis, T. (2009). Becoming (a) practice. Man- agement Learning, 40 (2), 145–159.

P36, line 12. Lendrum, T. (1998). The strategic partnering handbook (2nd ed.). Syd- ney, Australia: McGraw-Hill.

P36, line 42. Pollack, J. (2007b). The changing paradigms of project management. International Journal of Project Management, 25(3), 266–274.

Checkland, P., & Howell, S. (1998). Information, systems and information systems: Making sense of the field. West Sussex, UK: John Wiley & Sons.

Checkland, P., & Scholes, J. (1990). Soft systems methodology in action. Chichester, UK: John Wiley & Sons.

Midgley, G. (1990). Creative methodology design. Systemist, 12, 108–113. Midgley, G. (1997). Mixing methods: Developing systemic intervention. In J. Min-

gers & A. Gill (Eds.), Multimethodology: The theory and practice of combining management science methodologies (pp. 249–290). Chichester, UK: John Wiley & Sons.

?/Au/Ed: listed but not cited, ok?

Chapter 4

Strategic Management: Developing Policies and Strategies

Christoph Loch and Frederick C. Payne

What Is Complexity? We are adopting a strict definition of complexity, in order to focus our discussion on developing policies and strategies. Complex projects have many parameters and variables with many interactions, or, more formally, collections of components and activities that are “made up of a large number of parts that interact in non-simple ways...[such that] given the properties of the parts and…their interactions, it is not a trivial matter to infer the properties of the whole.”

In other words, complexity is not the same as size: a large project may not be complex if it can be divided into pieces that can be worked through separately without interacting with one another; in this case, one just puts many teams in parallel, who each proceed without having to take into account what the others do. The management challenge is still relatively simple. Second, complexity is not the same as uncertainty and project risk (stemming from novelty). If we know that an activity may take two days if the weather is good and up to five days if the weather is bad, we can prepare ourselves for it, for example, by having a buffer in the plan. Complexity fundamentally has to do with interactions.

It is well known that complexity may be caused by the technical system of many in- teracting physical components. However, complexity may come from multiple sources:

• Technical complexity: interactions of many system components cause inter- dependencies among many tasks in the project.

• Actor complexity: Many stakeholders are interested in the project, possibly emphasizing different dimensions and wanting contradictory outcomes, and the stakeholders may influence one another

• External complexity: The project may touch multiple market segments, be influenced by regulations in multiple regions or domains, be affected by stan- dard defining bodies such as ISO, or face multiple competitors.

There may be complexity on each of these dimensions separately, (such as mul- tiple mutually influencing stakeholders), but complexity may also arise from in- teractions across dimensions: technical features may win or antagonize, or even

Aspects of complexity: mAnAging projects in A complex World

solidarize, stakeholder groups, or actors may influence regulatory changes. This cross-domain complexity may be just as damaging as well-known types of com- plexity, but initially be overlooked by management.

Take implementing an Enterprise Resource Planning (ERP) tool as an example. The stakeholders come from every corner of the organization and are familiar with what they have today. They all legitimately want something better in the future, but are reluctant to give up anything that they currently have for the greater good of the organization (actor complexity). All dimensions of running a business must be blended into one ERP system; program delivery feeds accounts receivable/pay- able, which feeds payroll, and so on (technical complexity). The finance part needs to meet regulatory requirements and timekeeping needs to meet local employment laws for each business in each country implementing the ERP system (external complexity). In this example, the strategy needs to emphasize a single approach with enough flexibility but blueprinted and agreed upon early in the process, and the policy must be to achieve the blueprint without undue interruption.

How Complexity Makes Project Management Difficult Complexity causes two fundamental difficulties: First, it causes causal ambiguity, which means that that many different actions and parameters interact, so the effect of actions is difficult to assess: any action has multiple effects, and any observed ef- fect has multiple possible explanations. Even when, in principle, everything in the project is “deterministic” and COULD be foreseen, it is just impossible to consider all cause-and-effect relationships, which makes the project unpredictable: “It’s not difficult to anticipate the position of ONE tree, but you can’t map a million of them, so you are likely to run into one of them.”

Second, complexity causes interaction uncertainty, again even if in principle, every event might be deterministic and foreseeable. A typical feature of complex systems is that the overall problem has to be partitioned into pieces in order to be manageable. Thus, individuals or departments are assigned pieces of the problem, coordinated by a system architecture with defined interfaces. These individuals act locally to do the best they can with (“optimize”) the pieces of the problem for which they are responsible. However, because of the complex interactions among subproblems and variables, the individuals influence one another, and while they may be aware of the influences, they often cannot fully consider them in their local decisions. As the component designs evolve over time, ongoing problem choices in other groups make the requirements for a particular group inherently unstable. The interactions themselves cause uncertainty for the individual.

As an example, take the development engineer for the air intake of a car’s cli- mate control system. This engineer had been constructing a particular component for more than a year, based on design assumptions (such as the available space) that were formally written down and “frozen” at various design reviews. A combination of technical complexity across car projects (because the intake system was shared by several models) and actor complexity (because manufacturing and prototyping of the final plastic part was performed by a supplier) came from the strategic position- ing of the project. It was out of the control of the project engineer, but nevertheless it forced him to cope with 18 changes (each requiring him to negotiate design and

strAtegic mAnAgement: developing policies And strAtegies

tooling changes with the part supplier), many of them based on elements beyond his horizon, which thus had no obvious logic. As a result, he experienced severe stress and ultimately took an extended sick leave.

These two fundamental challenges caused by complexity make traditional proj- ect planning inadequate: planning, no matter how thorough, cannot hope to suc- cessfully anticipate all interactions and causal ambiguity. They force management to either strategically structure projects differently, or adopt more flexible methods of management policy.

What Project Management Can Do in Principle Reduce Complexity: Decouple and Modularize

The most radical response to complexity is to leave out a few features, or mar- ket segments, or countries with different regulatory regimes, in order to get (at least the first version of the project) under control. Reducing the variables reduces com- plexity. A less radical and widely discussed tool to reduce complexity is modularity. A modular system is one with few and well defined interfaces cutting across the modules (component groups) and functions of the product. For example, software modules are subroutines that have a clear interface for evoking them. In car de- velopment, modularization comes in the form of mechanical “chunks” with clear interfaces to the rest of the car. For example, a car engine is developed largely inde- pendently of the body.

Modularity, in effect, reduces complexity itself by dividing the complex system into several smaller subsystems, which do not, or barely, interact. Why does not ev- eryone build modular systems, if they are so helpful? The answer is that the design restrictions imposed by modularity reduce system performance and compactness, especially for products incorporating new technologies that are not yet fully un- derstood. In particular, modularization limits the search space of the design team, which may result in a suboptimal solution. Suffering these performance disadvan- tages may well make a product uncompetitive. Thus, modularity is not always an option.

Freeze Components

It is an important architectural choice as to what should be optimized for the system and what components and interfaces are less important. Such “secondary” system elements may be fixed at some point during the development process. Freez- ing specifications stops short of segmenting the design (or reducing complexity itself, as modularization does). It defines which optimizations across interfaces have pre- cedence over other optimizations. Holding some components and interfaces fixed reduces the size of the part of the design system that contributes to complexity.

Take the example of developing an integrated entertainment system (CD, radio, personal entertainment module, TV, GPS, and links to the phone) as part of a new car model. After a long “back and forth” about the best operating system (OS) for the software, the team had to settle on one (freeze the decision), although the choice was not the one with the highest performance (this was hotly contested). However,

Aspects of complexity: mAnAging projects in A complex World

without the freezing, the many other components of the project had no chance of converging to a design in a timely fashion.

Some luxury car manufacturers have traditionally given design and feature decisions more emphasis than decisions regarding production issues. As a result, feedback loops from production back to product elements of the design process are limited. This eliminates complexity, at the expense of production cost.

Experience plays an important role in freezing decisions. An organization de- veloping a next generation product, based on a well-known architecture and well- understood technologies, can predict many aspects of the system’s performance. The organization can strategically choose in advance ranges of design parameters that are likely to yield high performance. Thus, many parameters can be frozen (i.e., ranges do not need to be considered) without trading off performance. In contrast, when freezing is used in novel projects, it is often not understood what performance is sacrificed; rather, the freezing is defensive in order to get the project’s progress under control.

Control-and-Fast-Response

Control-and-fast-response is a useful and interesting approach to complexity that follows a different mind-set than established project management. Weick and Sutcliffe discussed what high-reliability organizations, such as a nuclear power plant or an aircraft carrier, must do to guarantee a reliable functioning of a very complex system. Reliable operation must be guaranteed (almost at all cost) because much is at stake. A striking example is the operation of an aircraft carrier:

. . . you have six thousand people crammed into tight spaces away from the shore on a 1,100-foot, 95,000-ton floating city run by an overburdened ‘city major.’ Within those tight spaces on a carrier, you also have people working with jet aircraft, jet fuel, nuclear reactors, nuclear weapons, an onboard air traffic control system, refueling and re-supply from adjacent ships that are moving, a surrounding battle group of seven to nine ships that are supposed to protect the carrier but that can themselves also be dangerous obstacles in fog or high seas and unpredictable weather.

People on a carrier cannot afford to be wrong, or lives will be lost. This is a huge challenge because the system is so complex—the different parts of the carrier are tightly coupled, and impact one another, and the individual components con- stantly change, because, for example, of human error, equipment failure, or chang- ing weather conditions. “Safety is elusive because it is a dynamic non-event—what produces the stable outcome is constant change rather than continuous repetition. To achieve this stability, a change in one system parameter must be compensated for by a change in other parameters.” Yet, accidents rarely happen.

Weick and Sutcliffe recommended that the organization develop what they call “mindfulness.” This refers to “the combination of ongoing scrutiny of exist- ing expectations, continuous refinement and differentiation of expectations based on newer experiences, willingness and capability to invent new expectations that make sense of unprecedented events, [and] a more nuanced appreciation of context and ways to deal with it.”

strAtegic mAnAgement: developing policies And strAtegies

Mindfulness includes a number of “soft skills,” such as a policy of preoccupa- tion with failure, reluctance to simplify, sensitivity to operations, commitment to resilience, and deference to expertise. In our language of “systems,” mindfulness means the ability to know precisely what the “in control” target state of each com- ponent of the system is, to detect even small deviations from the target state, and to quickly react to them and contain them so that they do not spread to other com- ponents of the system, causing a major problem there. In other words, mindfulness represents control-and-fast-response: We prevent deviations if possible, and if one occurs, we need a policy to contain it immediately.

Control takes the form of preoccupation with failure, or ever paranoid and per- vasive monitoring. For example, aircraft carriers conduct foreign-object-damage walk-downs on deck several times a day to prevent small objects (such as bolts or trash) from being sucked into airplane engines. In the constant chatter of simulta- neous loops of conversation and verification, “seasoned personnel do not ‘listen’ so much as they monitor for deviations with a policy of reacting instantly to anything that does not fit their expectations of the correct routine.”

When a slight deviation is discovered, even if it seems inconsequential, correc- tive and, if necessary, drastic action is taken. For example, a seaman on a nuclear carrier reported the loss of a tool on the deck. All aircraft aloft were redirected to land bases until the tool was found, and the seaman was commended for his ac- tion—recognizing a potential danger—the next day at a formal ceremony. Com- mitment to resilience means the ability to have a policy that substantially deviates from established routines, and to modify those routines, in order to mitigate the deviations before they escalate out of control.

Control-and-fast-response embodies a different mentality from traditional proj- ect management: It admits that there is a wide “state space” of influence factor configurations out there, which contains many nasty surprises, and therefore we insulate the system from this state space and keep it iron-fisted at the state that we know works. Compared to traditional project management, the emphasis is not on planning contingencies but on mutual adjustment of the system elements (such as ground crew, pilots, and ship operations) to bad news that emanates from different system elements, in order to keep the system in the control state, or to minimize deviations from it before they escalate. This relies not only on planned routines but also critically on a willingness to improvise (resilience) if that particular combina- tion of circumstances has not been foreseen. Moreover, because of system complex- ity, it is not possible to anticipate all system constellations.

Control-and-fast-response in the way described by Weick and Sutcliffe differs from our topic because it is directed at ongoing processes. Projects are, by definition, directed at new activities (or at least activities having some novel aspects). Thus, it becomes more difficult to stay in the “green area of control.” However, control-and- fast-response and mindfulness are highly relevant to project management for two reasons. First, they provide a good discipline of knowing as much as possible and re- acting to deviations that are not required for learning about the path toward the goal. Second, mindfulness helps to alert us to the problems of complexity, the interactions among multiple system parts, as a major source of risks. Mutual adjustment and re- silience are highly applicable in project management. The lessons from control-and-

Aspects of complexity: mAnAging projects in A complex World

fast-response are to carefully assess what one knows, and where one can make system changes without being worried about catastrophic changes; venturing out of this safe traditional zone into unchartered waters should be done cautiously, expecting the worst, and with a fallback option. Thinking back to the ERP example, here a control- and-fast-response approach to what the project subteams are allowed to do makes sense with the project plan as a base line; any unilateral deviations from the plan may cause havoc spreading throughout the project because of the many interactions.

It takes a bit of personal risk to reputation to venture outside of an agreed upon and thus legitimized plan. If it does cause cascading problems, it may reflect reck- lessness, and the person taking the initiative is blamed. However, sometimes oppor- tunities for creativity do exist, so if done successfully, taking the initiative yields a positive result of “what can be done when thinking outside of the traditional proj- ect management box” or the “iron triangle of death—cost, time, and scope.” The challenge is the judgment of what risks are acceptable—it is fundamentally a judg- ment because complex systems are, by definition, difficult to predict. This is where project strategy can help, by diagnosing complexity as well as its justification, then helping the actors to make judgments with a holistic view.

Small Steps and Controlling Variability

There are two lessons from control-and-fast-response directly applicable to, in- deed often named in, project management: first enforce tight coordination among all parties, by forcing every actor to identify the other actors with whom they in- teract, and to regularly communicate and to consider their mutual effects on one another. Thus addressing the most critical interactions this way may be enough to reduce ambiguity and mutually imposed rework enough to make the project viable.

Second, large steps into the red out-of-control state are likely to not work out; it may be better to make small steps, control variability, and iterate yourself forward in quick cycles. Iteration and learning may be more promising than planning and control. Alternatively, one may undertake several parallel trials and see which one works best (if the trials are informative and van be performed cheaply).

The Role of Strategy

Strategy has a very important role to play in shaping the complexity of the projects that an organization undertakes. Strategic decisions determine what types of projects are chosen, and they affect the overall complexity of the organization’s tasks directly by influencing how much the projects themselves interact (for exam- ple, because one project is a proof of concept for another, or the market reputation of one influences another).

All too often, an inherent appetite for “more revenue” becomes the dominant determinant of project selection, or “What we bid upon is what we make.” The complexity of the resulting portfolio is rarely considered—but this is dangerous: In- viting the complexity of pursuing many projects in parallel may very well be appro- priate in a rich economy where increased market share is the predominant strategic goal, but does it really offer a strategic advantage over one’s competitors? Or should the organization reduce complexity by undertaking fewer projects?

strAtegic mAnAgement: developing policies And strAtegies

For example, General Motors Corporation in 2009 had 7 brands totaling 87 dif- ferent vehicles available in the United States alone, not to mention the Vauxhall, Opel, and Holden brands in Europe, Asia, and Australia. Was this self-created com- plexity generated around an increased market share strategy really necessary? Does consumer demand really require such a level of complexity? Marketing studies show that variant proliferation may be a symptom of an underlying weakness of the brand.

However, the extreme answer, “strategy should reduce, or at least limit, com- plexity” is too narrow and in many cases wrong. Complexity of a strategy makes it harder to copy it, and complex projects may have a better chance of achieving uniqueness, and thus differentiation and competitive advantage. Platform strategies with a modular design approach typically become feasible when the products in the category have become mature, and thus prone to cost competition. Complexity may well be the price to pay for having something novel to offer.

For example, the Joint Tactical Radio System (JTRS) is planned to be the next generation voice-and-data radio used by the U.S. military in field operations after 2010. Launched with a Mission Needs Statement in 1997, and a subsequent require- ments document in 1998 (which has been revised several times), JTRS is a software- defined radio that will work with many existing military and civilian radios and their associated waveforms. The Government Accounting Office reported, “Over the past decade, the Department of Defense (DOD) has undertaken a major trans- formation of its military operations—one that will rely on network centric com- munications to improve force information sharing, collaboration, and situational awareness and, thereby, enable more rapid and effective decision-making and speed of execution on the battlefield. The Joint Tactical Radio System (JTRS) program, initiated in 1997, is a key effort in this transformation. By capitalizing on emerging software-defined radio technology, the program plans to develop and procure hun- dreds of thousands of JTRS radios, which are expected to interoperate with existing radio systems and provide the warfighter with additional communications capabil- ity to access maps and other visual data, communicate via voice and video with other units and levels of command, and obtain information directly from battlefield sensors.”

In other words, this program is loaded with several types of complexity: techni- cal because thousands of radios will have to work together and with other commu- nication media in real time under varying circumstances. Actor complexity because having many users also means having many stakeholders. And external complexity because battlefield technology changes, budget availability changes with political tides, and external technology constraints change because consumer electronics change so fast (the time elapsed since the program’s start, 1997, is an eternity in electronics). All of this complexity has not been recklessly imposed but reflects the wide-ranging benefits that the JTRS program is hoped to bring.

Still, the question arises whether it could have been tackled in smaller sequen- tial and iterative portions in order to alleviate the daunting complexity, which cer- tainly has made itself felt in many symptoms of management difficulties. The GAO report continues,

Aspects of complexity: mAnAging projects in A complex World

Although JTRS offers the potential to address key communications shortfalls and significantly improve military capabilities, the program has encountered a number of problems, including unstable requirements, immature tech- nologies, and aggressive schedules, which have resulted in significant cost increases and delays. In August 2003, we reported that the lack of a strong, joint-management structure presented significant challenges to the program’s ability to control costs currently estimated to total about $37 billion. In re- sponse, Congress directed DOD to strengthen program management, and in February 2005, DOD established a Joint Program Executive Office (JPEO) to manage the JTRS program and its various components. Following JPEO’s as- sessment of the program, the Defense Acquisition Board directed JPEO to come up with a plan to restructure the JTRS development effort—a plan that DOD approved in March 2006. Given the criticality of JTRS to DOD’s force transformation, Congress directed GAO to continue its ongoing review of the JTRS program.

The recent restructuring of the JTRS program appears to put the program in a better position to succeed, by emphasizing an incremental, more mod- erate risk approach to developing and fielding capabilities. The incremental approach reflects the military services’ most urgent priorities for a mobile, flexible communications and networking capability and defers the devel- opment of some of the more challenging requirements to later increments. Deferring these requirements will allow more time to mature critical tech- nologies, integrate components, and test the radio system before committing to production. DOD expects that JTRS program management through the JPEO and other structural changes will improve oversight and coordination of standards and development of the radios. The centralized management struc- ture is also empowered to manage development costs, which are expected to total US$2.1 billion more than originally projected between fiscal years 2006 and 2011. In addition, the restructuring attempts to facilitate information- sharing and competition by ensuring government purpose rights to contrac- tor-developed products.

Over the longer term, the program faces several key management and techni- cal challenges. For example, although the new joint management structure for JTRS is a significant improvement over the previous fragmented program management structure, joint development efforts in DOD have often been hampered by an inability to sustain requirements commitments and funding support from the military services and other department stakeholders.

This discussion implies that determining the value of a project cannot be de- termined exclusively on margin, revenue, budget, and strategy, but on building a longer than one year growth path (possibly multiple paths) that will surmount competition and have a reasonable chance of success even if it does not retain the entire original strategic intent. Having a path of success includes external value generation potential as well as internal execution capability. Thus, strategy should determine the strategic portfolio on not only financial or market criteria alone but complexity, and the risks associated with it should be part of the selection criteria. This implies directly that the complexity of the projects, and the entire portfolio, should be tracked. Moreover, an operating strategy should ensure that the policies, capabilities, structure, and processes are put in place to deal with the complexity

strAtegic mAnAgement: developing policies And strAtegies

that the portfolio requires. In the following, we discuss both principles for the strat- egy of complex projects.

Traditional Project Selection Criteria Project selection criteria need to address portfolio balance as well as attractiveness and viability of the individual projects.

Balance refers to the holistic view of the portfolio as whole: Are the projects complementary in covering the company’s business needs, or are they excessively concentrated on one need? For example, is there a risk balance, are there mostly moderately safe projects and just a few high-risk undertakings, or is the portfolio too conservative or too risky? Is there a balance of market coverage—do all im- portant market segments receive project support or are projects too focused on one sector? Is there a balance between products and services? Other balance questions cannot be posed generically but must emerge from the strategic challenges of the organization.

Project attractiveness refers to the requirement that each project should be above a minimum attractiveness hurdle in its own right—no matter how good the strategic balance, a project portfolio composed of “dogs” cannot create value. Many useful criteria are used in companies; examples are listed in the following. Not all of them are weighted equally and in the end, some may be ignored completely. If they are all at least considered in the project selection process, everyone knows ex- actly where the project stands, the perceived benefits to be derived, and the ultimate priority of the project within the portfolio. The criteria are as follows:

• “Business case” criteria: Expected revenues, market share, financial returns, versus investments, time to market, usage of scarce resources, and risk (tech- nical as well as market).

• Other long-term consequences of the selection: Fit with the strategic direc- tion of the company, durability of the competitive advantage created, in- volvement of preferred suppliers, partners, government entities, etc., and thus strengthening of the organization network position.

• Interests of the employees • Impacts on community and environment • Desire to maintain high business standards and ethical guidelines

Widen the Set of Portfolio Criteria These balance and attractiveness criteria are well known and widely used. How- ever, all of these criteria are “business content” focused, but they neglect the proj- ect execution process (with the exception of the usage of scarce resources). Our discussion on the dangers of complexity suggests that complexity is a major risk item in the execution process, and thus should be monitored and mitigated ap- propriately. Therefore, project complexity should be incorporated in the portfolio dimensions at both levels.

Complexity at the portfolio level. How much complexity is introduced by the composition of the portfolio? Complexity has to do with the number of variables and their interactions. Thus, we can operationalize this criterion in the following

Aspects of complexity: mAnAging projects in A complex World

way: How many interactions are inherent in the portfolio? These correspond to the cross-domain complexity dimensions mentioned earlier:

• Technical interactions. Some interactions are positive, for example, a project acts as an enabler for others, perhaps by providing a common platform or by building components that are used by other projects. Other interactions are negative, for example, the technical solution developed because of the needs for one project degrades the functionality available in another project.

• Resource interactions. Projects compete for the same scarce resources (proj- ect personnel, specialists, management attention, building, marketing, chan- nel capacity, manufacturing, etc.), and so allocating resources to one project deprives other projects.

• Market interactions. Projects may be complementary, for example, strength- ening a common brand, or one building acceptance for the other. Projects may also cannibalize each other if they are directed toward similar needs and customer segments.

• External interactions. Projects may cannibalize each other in stakeholder “tolerance” (“we have allowed you to do project A, so now you can’t also do project B”), or compete for shared regulatory quotas.

The complexity implied by the entire portfolio should be, at a minimum, esti- mated by counting the interactions. Once the management team has a feeling for the potential for cross-project interactions, it can ask itself whether this portfolio is manageable, or whether it is so unwieldy that controlling the important interac- tions looks unfeasible or very management-heavy—in this case, it risks producing bad surprises and jeopardizes the success of individual projects. Think about this as “risk management at the portfolio level:” project level risk may “average out” over many projects, but complexity compounds itself over many projects. In this case, management might consider simplifying the portfolio in order to reduce com- plexity-induced risk. Conversely, if the complexity of the portfolio significantly en- hances its value potential, management might consciously decide to pay the price, which implies putting resources with the right competencies and capabilities in place to deal with the complexity at the project management level.

Problems result if the business management does not realize the burden that portfolio complexity places on the projects. In this case, aggregate strategic plans are de facto unrealistic and not explicit and project management may be blamed for interaction-caused execution problems that are really caused by complexity at the portfolio level and outside the control of the project managers.

Many years ago, one of the authors was working in a business that had a few portfolios; we will mention two here that describe interaction-caused execution problems. First, I was heading-up a portfolio that was focused on break-through novelty-based product development while another portfolio manager was dealing with derivative products coming off a huge “cash cow” base. My mission was to use advanced technology to achieve future cash cow products. The derivative oriented portfolio manager’s mission was to continue the cash cow business as long as possi- ble, introducing smaller size, adding capabilities, and so on. I hired a premier ASIC designer to work on our break-through projects. This designer was the envy of the derivative-oriented portfolio manager since the ASIC designer’s capabilities could

strAtegic mAnAgement: developing policies And strAtegies

make his projects smaller and more capable faster. You see where this is going. . . . The battle was on; both of us saw our portfolios as being of high priority for the company. I can admit now, that if it wasn’t for the cash cow business, I would not have had a portfolio to manage! The derivative-oriented portfolio manager would probably admit now that if we did not engage in novelty-based product develop- ment, that his portfolio would have been unsustainable over the years.

It was not until we collectively recognized that an aggregated view of our stra- tegic portfolio plans was not working and that we really needed to engage our in- teractions across the dimensions. Then it became evident as to how we needed to operate. As for the ASIC designer, I explained to the project manager within my portfolio the need to continue the cash cow business for the time being and we lent him out to the derivative oriented portfolio manager’s projects part time and as appropriate brought him into the novelty-based product development team on a full-time basis.

Portfolio balance is about not only the interactions inherent across portfolios but also the policy prescribed by the overall organization where the portfolios reside. The policy component of a project management system describes senior manage- ment’s perception of the strategic role of project management for the organization (the ultimate portfolio).

1. Strategic importance of project management 2. Organizational commitment to project management 3. Overall maturity of organizational project management

Complexity at the project level. Complexity is also caused at the project level, from technical, stakeholder, or external variables that interact. Again, this needs to be diagnosed at the outset in order to be prepared for problems that are not caused by management problems or classical project risk, but by the ambiguity stemming from overlooked or unexpected interactions. A diagnosis at the outset helps the project management team to prepare, proactively by putting communication and coordina- tion mechanisms in place, but also in a contingency spirit by agreeing on procedures that are triggered with conflicts and interaction related problems do occur.

A diagnosis can happen directly by identifying and counting the critical influence factors on the three domains of technology, actors, and external and constructing a design structure matrix that illustrates interactions among the influence factors. This is discussed further in the following. Another tool that allows identifying complexity is the Diamond Approach, which characterizes the prospective project on the dimensions of novelty (the amount of work that the organization has not done before), pace (the urgency and deadline tightness), com- plexity (the number of not only components but also subsystems), and technology (the amount of novel technologies that will be used). Complexity is an explicit element of the diamond approach, which helps to identify key project manage- ment challenges at the outset, and to monitor it throughout the project life cycle.

Integration With Project Execution Strategy sets the context and the tone. If complexity, and especially its roots stem- ming from the portfolio level, are not recognized and incorporated in project execu-

Aspects of complexity: mAnAging projects in A complex World

tion tools, then project and portfolio managers are sent into minefields studded with traps that they have not been warned about. It may certainly make sense to consciously engage in a complex project portfolio if the strategic benefits of the complexity are worthwhile. Then project execution must be equipped for dealing with the consequences.

This incorporates a diagnosis system, as described previously, and coordina- tion and risk management systems that can absorb and manage the cross-project interaction problems that complexity imposes. A key tool in representing and com- municating complexity is the design structure matrix (DSM). It was first proposed in engineering by Steward and further developed as a management tool by Eppinger, Whitney, Smith, and Gebala.

The DSM maps interactions among pieces of a project in matrix form, by listing which task needs input from which. Here, it can be adapted to represent the key sub-teams per project and list the interactions among parties across the projects (use a separate DSM to map complexity within a project).

Figure 4-1 presents a brief example of an application of this tool. Say, for sim- plicity of illustration, that each party listed (A through D) is one project. In the fig- ure, impacted projects are listed in the columns, and impacting projects along the rows. Crosses (x) mark dependencies. Project B is sequentially dependent on project A, as the impact goes only one way; for example, project A produces information that project B needs, or project A addresses a customer base that task B should not duplicate. Projects B and C are independent. Projects C and D impact each other— that is, they might require mutual information input, or rely on a common platform that is a compromise between them. Thus, they are coupled (interdependent). The matrix suggests an ordering of the project: A, then B in parallel with C and D, the latter two being performed in a closely coordinated way.

To see interactions across the system, actor, and external level, consider the fol- lowing example. A company that develops ink jet and laser technologies for offering total coding and printing solutions. Each solution combines multiple technologies, such as ink, laser, encoding, tracing, identification, or technologies in characters, letters, and graphs (technical complexity). In order to have any reusability and parts

A-B: Sequential

B-C: Independent

C-D: Coupled

A-D: Sequential

Project A

Project B

Project C

Project D

A B C D

X B

C X

X X D

Figure 4-1: Example of a design structure matrix, DSM

strAtegic mAnAgement: developing policies And strAtegies

commonality at all, solutions represent compromises of varying the business prac- tices of different customer industries, for example, a solution must work on differ- ent surfaces and materials that their products will print on, such as paper, plastic, metal, and fibers (actor complexity). Finally, the various customer industries may have standards and legal requirements that may cause conflicts, such as pharma- ceutical material requirements that clash with cost requirements in a different in- dustry (external complexity). The most important ones of these interactions can be represented in a portfolio DSM.

Using the DSM as a tool, senior management can put the following steps in place to ensure a systematically applied policy of managing complexity rather than simply suffer the consequences of “crept up” complexity. This needs to happen both at the portfolio level (steps 1-4) and the project level (step 5).

1. Diagnose portfolio complexity (ideally, complexity should be “designed” but this seems elusive at the outset, so start by diagnosing the complexity that is there). Graphically show the existing complexity in a DSM that represents the key interactions across projects.

2. Make the business case for complexity. Which interactions are fundamen- tally implied by the business or the technology, which are decisions (such as component sharing, projects addressing the same customers), and for these, what is the business case? What is the value offered by doing it this way?

3. Identify the correction loop. What can we do to eliminate or reduce interac- tions that are not sufficiently valuable (e.g., by modularization of the proj- ects, organizational reassignment of interacting projects to the same team)?

4. Communicate and explain the complexity, make the interacting parties public (e.g., DSMs with a focused representation of key interactions), so the teams are (a) prepared and informed and (b) are accountable for managing those interactions.

5. Put in place project management systems that enable the teams to deal with the complexity levels (within and across projects) that they face. Project level complexity and tools for managing it are discussed in Chapter 9.

Enabling the organization to manage complexity also involves leadership that is willing to make and support these diagnosis and decision tools (and the processes implied by them), for if it is not recognized as a top-down approach, the chances of success are minimized. Leadership should recognize that complexity is not a level but a continuum and should develop strategies that are nonconflicting and policies that can incorporate the full breadth of possibilities. If complexity is put on the agenda in its benefits and costs and managed as part of project portfolio decisions rather than just lamented over, project managers can become more effective.

The usual disclaimer applies: Diagnosis and decision tools do not replace judg- ment and courage to take (inevitably risky) decisions. The tools help to make deci- sions based on better information, but they will never make the decision because information is never complete and unambiguous. The critical management respon- sibility remains.

Aspects of complexity: mAnAging projects in A complex World

References P41, line 6; P42, line 19. Simon, H. A. (1969). The science of the artificial (2nd ed.).

Boston, MA: MIT Press, p. 195. P42, line 19. Kauffman, S. A. (1993). The origins of order: Self-organization and se-

lection in evolution. New York, NY: Oxford University Press, p. 42. P42, lines 22, 24. Loch, C. H., & Terwiesch, C. (2002). The Circored project A & B,

INSEAD case 06/2002-5040, Teaching Note. P42, lines 28, 35. Van Zandt, T. (1999). Decentralized information processing in the

theory of organizations. In M. Sertel, M. (Ed.), Contemporary economic issues (Vol. 4, pp. 125–160), London, England: MacMillan.

P42, line 28. Loch, C. H., & Terwiesch, C. (2007). Coordination and information exchange. In C. H. Loch & S. Kavadias (Eds.), Handbook of new product de- velopment management (pp. 315–345). Oxford, UK: Butterworth Heinemann/ Elsevier.

P42, line 35. Thomke, S. H. (1998). Managing experimentation in the design of new products. Management Science, 44(6), 743–762.

P43, line 16; P47, line 13. Ulrich, K. T. (1995). The role of product architecture in the manufacturing firm. Research Policy, 24(3), 419–440.

P43, line 27. Ethiraj, S. K., & Levinthal, D. (2004). Modularity and innovation in complex systems. Management Science, 50 (2), 159–173.

P43, line 28. Ulrich, K. T., & Ellison, D. J. (1999). Holistic customer requirements and the designselect decision. Management Science, 45(5), 641–658.

P44, lines 19, 30, 36, 42; P45, lines 16, 21, 37. Weick, K. E., & Sutcliffe, K. M. (2001). Managing the unexpected. San Francisco, CA: Jossey-Bass.

P46, line 29. Sommer, S. C., Loch, C. H., & Dong, J. (2009). Managing complexity and unforeseeable uncertainty in startup companies: An empirical study. Orga- nization Science, 20 (1), 118–133.

P47, line 7. Larreché, J.-C. (2008). The momentum effect. Boston, MA: Harvard Busi- ness School Press.

P47, line 10. Rivkin, J. W. (2000). Imitation of complex strategies. Management Sci- ence, 46(6), 824–844.

P47, line 11. Miller, R., & Lessard, D. L. (2000). The strategic management of large engineering projects. Boston, MA: MIT Press. and Shenhar, A., & Dvir, D. (2007). Reinventing project management: The diamond approach to successful growth & innovation. Boston, MA: Harvard Business School Press.

P47, line 20; P48, line 37. U. S. Government Accounting Office. (2006, September). Report to U.S. Congressional Committees. Defense acquisition, restructured JTRS program reduces risk, but significant challenges remain. (Publication No. GAO-06-955). Available from http://www.gao.gov/htext/d06955.html, p. 1.

P49, line 5. Cooper, R. G., Edgett, S. J., & Kleinschmidt, E. J. (2001). Portfolio man- agement for new products. Cambridge, MA: Perseus Publishing.

P49, line 14. Loch, C. H., & Kavadias, S. (2011). Implementing strategy through proj- ects. In P. W. G. Morris, J. K. Pinto, & J. Söderlund (Eds.), The Oxford handbook on the management of projects (pp. 224–251). Oxford, UK: Oxford University Press.

P51, line 16. Cooke-Davies, T. J., Crawford, L. H., and Lechler, T. G. (2009). Project management systems: Moving project management from an operational to a strategic discipline. Project Management Journal, 40 (1), 110–123.

strAtegic mAnAgement: developing policies And strAtegies

P51, line 35. Shenhar, A., & Dvir, D. (2007). Reinventing project management: The diamond approach to successful growth & innovation. Boston, MA: Harvard Business School Press.

P52, line 10. Steward, D. V. (1981). Systems analysis and management: Structure, strategy and design. New York, NY: Petrocelli Books.

P52, line 11. Eppinger, S. D., Whitney, D. E., Smith, R. P., & Gebala, D. A. (1994). A model-based method for organizing tasks in product development. Research in Engineering Design, 6(1), 1–13.

P52, line 16. Loch, C. H., & Terwiesch, C. (2000). Product Development and Con- current Engineering. In P. M. Swamidass (Ed.), Encyclopedia of production and manufacturing management (pp. 567–575). Dordrecht, Netherlands: Kluwer Academic Publishing.

Loch, C. H., De Meyer, A., & Pich, M. T. (2006). Managing the unknown: A new way of managing high uncertainty and risk in projects. New York, NY: John Wiley.

Mihm, J., & Loch, C. H. (2006). Spiraling out of control: Problem-solving dynam- ics in complex distributed engineering projects. In D. Braha, A. Minai, & Y. Bar-Yam (Eds.), Complex engineering systems (pp. 141–157). Cambridge, MA: Springer/NECSI.

Pich, M. T., Loch, C. H., & De Meyer, A. (2002). On uncertainty, complexity and ambiguity in project management. Management Science, 48(8), 1008–1023.

?/Au/Ed: listed but not cited

Chapter 5

Fear of Flying Stephen Carver and Harvey Maylor

Introduction Evidence from many studies has shown that the majority of programs and projects fail to meet one or more of their objectives. Indeed, the criticism of many levels of portfolio, program, and project management (PPPM), in many spheres of human activity, does lead to the question as to why anyone would want to take such a role with the prospect of failure so present.

This failure has been attributed to many causes. The analysis of one major program was typical in that the cause of “poor program management” was cited as the most influential. However, the report provided little by way of insight into precisely what aspects of program (or project or portfolio) management were poor. It was deemed enough to point in the general direction, and then walk away. Given the very particular nature of the challenges faced in this program, such analysis was clearly incomplete.

Such a generic consideration of PPPM is unlikely to be successful not least due to the lack of universality in practice as to what constitutes a portfolio, program, or project. Further, post-rethinking project management, the need to consider par- ticular characteristics of situations that would lead to an intelligent ‘fit to context’ approach has been established. In practice, this means that to achieve success, orga- nizations and individuals need to be able to appropriately respond to the challenges of each situation.

One way to describe the context for a particular activity is to consider its mana- gerial complexity or difficulty. If it is known then a suitable response in terms of process is required and the level of managerial effort could be established in prin- ciple, along with the selection of the task manager. However, matching to context does require that we are able to describe the landscape of challenge that each con- text brings.

This chapter charts our journey from the naïve question that formed our initial research efforts, “what makes projects difficult to manage?” We found manage- rial complexity to have both structural and dynamic elements, and there to be a large number of possible concepts or elements of complexity. Having determined our own grounded classification, re-visiting the literature demonstrated that these concepts or elements could easily be grouped in any number of ways. In terms of

Aspects of complexity: mAnAging projects in A complex World

progressing the discussion, an integrative classification is suggested. The classifica- tion provides a conceptualization of the experience and challenge of managers. In communicating this to senior managers, we have successfully used the analogy of flying to explore the requirements of portfolio, program, and project (PPP) manag- ers under different conditions of managerial complexity. The analogy raises some useful questions for both senior managers and researchers. Finally, and following from this, we note that while “pilot” still ranks as one of the more desirable profes- sions, the role of project, program, or portfolio manager currently doesn’t appear to have the same cachet, despite the growth in the number of people holding these important roles. This lack of inherent desirability of the PPPM profession is en- tirely reasonable given published project success rates. So, is there really a “fear of flying?” We examine the lessons for the PPPM profession(s) and senior managers of this challenge.

The Accidental Profession

“If your organization asks you to get involved in a project, best advice is run away, run away, run away!”

Adams

In the authors’ combined 50 years of teaching, consulting, and practice in the field of project management, it is a sad reflection that many students and prospec- tive practitioners approach the subject with high levels of negativity, confusion, and even suspicion. The response from many professionals in the area to the question, “How did you end up as a PPPM?” will often be along the lines of “I didn’t duck fast enough.” Indeed, if one considers the levels of success being experienced by projects in many sectors, this is understandable. The Standish Group reported appallingly low project success rates (32% in 2009, not significantly different from the first study in 1996). Avoidance of projects would seem to be a sensible career move.

With a global recession and tightened fiscal constraints, the fear of being in- volved in projects should be heightened. However, the popularity of project work is undiminished, with burgeoning membership of professional associations and the continued march of ‘projectification.’ For the future, if success levels were to im- prove, such negative mental associations could change. A key question then for professional bodies and educators then, is how such professionals should be devel- oped, so that positive and reinforcing cycles of better performance leading to better professional image, can be established. This was one of the key issues facing the rethinking project management network that ran from 2004–2006.

Rethinking Project (and Program and Portfolio) Management The starting point for the rethinking project management network was the con- sideration of the relationship between theory and practice. There were many chal- lenges to the theoretical basis for PPPM knowledge to accompany the litany of challenged project performance in both the national and professional press.

The network concluded that the development of twenty-first century practitio- ners would have to be different from twentieth-century practitioners. For instance, the network noted that twentieth-century project management was associated with

feAr of flying

the heavy-handed and unintelligent application of apparently omnipotent method- ologies and software. These viewed projects as hard, definite, and closed systems in which defined activities would take place with the objective of delivering an end product. This was inconsistent with the reality experienced by so many practitio- ners, often exacerbating feelings of helplessness rather than of self-actualization and control. In program management, the work of Pellegrinelli, et al. noted one manage- ment approach (Managing Successful Programmes, the UK Office of Government Commerce programme management standard) that led to a view that following its standard methodologies “was often more a matter of compliance than conviction.”

The change in the objective for the development of practitioners was identi- fied as being from “trained technicians” to “reflective professionals.” This echoed voices within the project management literature who encouraged a move away from standardized, process-driven methodologies, or “one size fits all,” to a more situational approach. This requires an understanding of the situational drivers that would require an approach to be amended or tailored to the specific needs of that particular portfolio, program, or project.

Understanding the Managerial Context Our starting point for providing A descriptor of the managerial context (not THE descriptor) was the recognition by a number of scholars that there was a lack of frameworks that could be used to describe key dimensions and characteristics of project complexity. Some had been defined a priori, but none had a grounded empiri- cal base.

Our study asked project managers the question, “What makes a project complex to manage?” One of the findings was that practitioners did not distinguish between complex and complicated or difficult. Of the aspects that practitioners defined as complex, we noted that academics are wont to discount these factors as “merely complicated.” Complexity science did not appear to have had an impact on the lan- guage of practice. Complexity as propagated within “complexity theories,” is about patterns of behavior of system of interrelated elements that are nonlinear, dynamic, emergent, etc. Such conceptualization is very different from the common usage of the term complexity by managers.

Once we describe the dimensions of complexity from this original study, we will show how these evolved by integration with the current literature into an ap- proach to describing not the complexity (as this is a contentious construct) but the complexities of a particular context. It is a small point but one that we have found to be very effective in moving from the generality of complexity, to a more specific discussion about a particular cause or type of complexity. Further, we demonstrate how this provides a useful conceptualization for managers. In particular, we show how there are two key complexities—structural and dynamic—and the categories of concepts that constitute each.

The analogy of flying is used to describe four different combinations of struc- tural and dynamic complexity and its application is demonstrated by the use of examples. This analogy has been found to be useful in working with practitioners and their organizations in creating greater clarity in the dissemination of project

Aspects of complexity: mAnAging projects in A complex World

complexity concepts. Finally, we explore the requirements of PPP managers under different conditions of managerial complexity.

Stage 1—Being MODeST The original paper was the result of an identified gap in the literature for a grounded framework of managerial complexity. A multistage empirical study was carried out to show how project/program managers perceived managerial complexity by asking, “What makes your project/program complex to manage?” The results established a grounded model of structural managerial complexity - the MODeST model (Figure 5-1), where the dimensions of Mission, Organization, Delivery, Stakeholders, and Team evolved as high-level headings for groups of characteristics. The groups again represented clusters of 132 identified concepts.

While the graphical representation shows these as apparently independent ele- ments, this is not the case. For instance, the organizational setting would have an impact on the resources available, and the objectives on the process used. However, as a starting point, this provided what we termed the structural elements of com- plexity—they could be captured at any point in time (typically before, during, or after a piece of work) as a perceptual measure or indicator of managerial complexity.

However, further analysis of the data from the study indicated that there was an additional dimension of complexity, as well as the structural, and that was the dynamic. The dynamic dimension resulted when the elements of structural com- plexity were not stable and changed over time. For example, when the organization is restructured during the lifetime of the project/program or the stakeholders un- derwent significant change and/or shifted their positions. This multidimensional framework not only leads to a multiplicative complexity effect but also further complicates the conceptualization of project complexity itself.

For each element, there are 20 or more questions to assess that element, and examples of each are shown in Table 5-1.

TeamStakeholdersDeliveryOrganizationMission

Managerial Complexity: MODeST Dimensions

Project StaffStakeholder Attributes ProcessTime and SpaceObjectives

Project Manager Inter-Stakeholder

RelationshipsResourcesOrganizational SettingScale

GroupUncertainty

Constraints

Figure 5-1: Dimensions of perceived structural managerial complexity

feAr of flying

Stage 2—Being Comprehensive The MODeST framework was a useful starting point for the discussion about com- plexity in project management. However, it was clear that this failed to integrate a significant body of work that had been undertaken elsewhere. The clustering pro- cess that had led to MODeST, would work just as well, with the already provided high-level categories. This held the potential of a much bigger prize—to be able to integrate elements of the literature into a framework that could be applied (and therefore used for comparative purposes) in both practice and research applications.

The most common high-level categorizations of complexity were identified as:

• Scale: how big is the task being undertaken; • Uncertainty: the level of unknowns in the task; • Pace: the time required for delivery compared to the ‘natural’ time that the

task would take; and • Socio-political: the interactions with and between different parties associ-

ated with the task.

Consistent with the earlier findings, each of these co