conclusion
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
©2011 Project Management Institute, Inc. All rights reserved.
“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
iv
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
v
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.
ix
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.
x
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
xi
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.
1
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
2
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
3
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.
4
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.
5
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,
6
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.
7
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.
8
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-
9
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
10
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
11
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-
12
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.
13
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
17
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;
18
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.
19
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-
20
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
21
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,
22
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
23
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-
24
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
25
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,
26
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.
27
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.
29
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-
30
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
31
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
32
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
33
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
34
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
35
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.
36
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
37
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.
38
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
39
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.
40
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?
41
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
42
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
43
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,
44
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.”
45
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-
46
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?
47
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,
48
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
49
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
50
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
51
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-
52
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
A
X B
C X
X X D
Figure 4-1: Example of a design structure matrix, DSM
53
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.
54
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.
55
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
57
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
58
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
59
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
60
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
61
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 could be shown to have both structural (initial or snapshot conditions) and dynamic (changing) elements, though this dynamic element was the least well developed in the literature.
The change to categories is described in Geraldi, Maylor , and Williams. The 132 previously identified complexity concepts were successfully mapped to the new high-level categorizations and 8 new concepts from the literature were added. The result was a highly comprehensive instrument for assessing complexities, which comprised 140 questions.
However, while 140 elements ticked the box for comprehensive, it failed on use- fulness! The production of a reduced instrument is now complete and being used by a number of organizations at the outset and key checkpoints in their process for all PPP work, not just projects. In addition, one organization is in the process of re- vising its approach to risk to include the assessment of complexities as a key feeder
Structural Dimension Dynamic Dimension
Mission
Organization
Delivery
Stakeholders
Team
Are the requirements clear?
Is there a mismatch between the matrix structure of the project and the department structure of the organization?
How well does the project team understand the project management methodology?
How many stakeholders are there?
Are the team members motivated?
How frequently do the requirements change?
Is there ongoing organizational restructuring that affects the project?
Is a new project management methodology being introduced?
Are the stakeholders changing?
Is the level of motivation of team members changing?
Table 5-1: Examples of assessment questions for managerial complexity
62
Aspects of complexity: mAnAging projects in A complex World
to their risk management activities. This is the phase where, as identified by the rethinking work, the theory is intended to inform practice.
One strand that has progressed in parallel with the development of the complexi- ties instrument is the evaluation of the implications of certain complexities for man- agers—their skills and requirements—and is described in the following section.
Stage 3—Trying To Be Useful! The work that we describe here was undertaken with a firm belief that the first stage in helping to solve some of the challenges of delivery is to provide a concep- tualization for practitioners that assist in gaining a common language and under- standing. In this we have gone from the concrete (the experience of practice) and abstracted the key elements of what makes tasks complex to manage (structural and dynamic factors). This work has had some success in providing a set of attri- butes or complexities that can assist in that common language and understanding.
In order to progress the discussion, we first started with the main categories of complexity, structural and dynamic. Assessment of the overall level of each cat- egory allows the placing of a task within the matrix shown in Figure 5-2. We will return to the means of assessment later. For now, the approach allows tasks to be located according to their complexities and hence allow different approaches to their management to be situationally assessed.
Having created the model it can be used to discuss the complexity of various projects/programs.
As can be seen in Figure 5-3, Type A is a project exhibiting low levels of both structural and dynamic complexities. This is the well-bounded project, with well- defined requirements and understood route to delivery. The stakeholders are likely to be known and to operate within defined and understood structures. The level of change is low, discouraged, and actively managed where it does occur. Key issues
Increasing Structural
Complexities
Increasing Dynamic Complexities
Figure 5-2: Combination of structural and dynamic complexities
63
feAr of flying
here involve structured control in a largely stable environment. Traditional project management methodologies appear to be well suited to this type of activity.
Type B, while having high levels of structural complexity, exhibits low levels of dynamic complexity. An example of this type of project is the development of an oil field, where there are many projects (oil platform, oil pipeline, gas pipeline, oil/gas receiving facilities, etc.) that are linked together and form what might be considered to be a program or portfolio. While the combination of these projects is structur- ally very complex, each individual project can be seen to be a relatively “simple” element and be managed accordingly. The dynamic complexity of this combination of projects is low due to the extreme care taken to specify and plan early in their life cycles and then to impose very strict control regime on any changes. Key issues here involve structured coordination in a largely stable environment. Application of traditional program or portfolio management methodologies appears to be well suited to these types of tasks, and the use of traditional project management within the constituent projects.
Type C has high levels of dynamic complexity but relatively low structural complexity. These projects may not be particularly large in scale but are likely to have ill-defined or rapidly evolving requirements, stakeholders, underpinning tech- nologies, or political environments. Conventional project management methodolo- gies are increasingly unlikely to be applicable the higher the dynamic element of complexity becomes. In their place, faster and smaller incremental planning and action stages may be used, and more flexible resource structures and processes may be required.
Type D has the highest levels of both structural and dynamic complexities. Like type B it may be considered to be a program or portfolio of smaller linked projects with some but not necessarily all exhibiting type C characteristics. Within the overall environment for the program, there will be a much greater level and accep- tance of fundamental uncertainty and emergence (as for type C) may extend over a longer period of time and with greater levels of importance or impact for the organi-
Type B
Type A
Type D
Type C
Increasing Structural
Complexity
Increasing Dynamic Complexity
Figure 5-3: Tasks and complexities
64
Aspects of complexity: mAnAging projects in A complex World
zation. Key issues here involve fluid coordination in a dynamic environment. Type D tasks are currently challenging established and evolving project and program methodologies and paradigms.
The main implication of this very high-level classification is that it is possible to establish the location of a task, and then consider the implications for the orga- nizational and individual response to the particular level and type of complexity.
For example, the assessment of the managerial complexities of major pieces of work, puts DII1 in the top category of having very high structural and very high dynamic complexities. Other major projects (that had significant overruns) include Holyrood and Wembley Stadium, but these are not in the same league complexity wise. For type D, normal rules of planning and action don’t hold, and as a result, ex- pectations that projects would run like a much less complex piece of work are mis- guided. As the scale of a project grows, the number of interfaces between elements of the system increases exponentially. These elements themselves are changing and have an impact in unpredictable ways on other parts of the system. The impact of one change on the system will be disproportionate to the magnitude of this change.
Reflections on the Use of the Typology There is little that is totally predictable in PPP work, and complexity assessments should reflect this. For instance:
1. Shell’s Sakolin project: Initially, this was a project with a high level of struc- tural complexity but relatively little by way of dynamics (i.e., type B). How- ever, in 2004, the Russian government effectively seized control of the assets of the project. The result was a major increase in the dynamic complexity— effectively shifting this to type D. The result of this shift was a fundamental change in the requirements of the management of the project—from requir-
Apollo Concorde Channel Tunnel
Wembley Stadium Holyrood
Oresund Link
Structural Complexity
Dynamic Complexity
Figure 5-4: Placement of tasks in the complexity domain
1DII is one of the largest IT infrastructure programs undertaken in Europe, with the brief to integrate the U.K. Ministry of Defence’s 300+ legacy IT systems into one platform.
65
feAr of flying
ing people who could deal with scale, to requiring people who could deal with a broader range of complexities.
2. The launch of mobile phone texting in a major U.K. telecommunications company was seen as a type A project—well contained and presenting a new product that, it was believed, would make a limited impact on the phone market. The resulting uptake caused significant issues for network operators who struggled to provide the necessary bandwidth to deal with the volume of nonvoice traffic, and phone makers, who had only included limited texting capability in new phones. The resulting success took the project to type D, and required a fundamental rethink of the approach, governance, manage- ment and extent of the impacts.
Assessing the complexities, whether at this high level or using the four catego- ries of both structural and dynamic elements, requires consideration of TIPS:
Temporality—the assessment is only valid now, as demonstrated by both ex- amples.
Interactive—it is affected by the actions and inactions of the manager—it is not independent of what they do. For instance, imposing a rigid process on a situation where there was a high degree of dynamic complexity, is just likely to make the situation more difficult to manage.
Position in work breakdown structure is important—there will be different complexities at different levels. Tasks are not homogeneous and tasks within one level will exhibit different complexities.
Subjective—the assessment is entirely subjective – it is based on the judgment of an individual and can reflect both knowledge and ignorance of a situation (I know it is complex because I’ve done this before; I think this is complex because this is the first time I am attempting it).
Implications of Assessment of Complexities There are many areas where the assessment of complexities would assist in the discussion of how the task could be managed. These include:
1. The nature of the processes or systems required to run the task; 2. The amount of time and effort managing the task will take; 3. The requirements of the task manager.
The Nature of the Processes or Systems Required To Run the Task
In an attempt to define the implications of the complexities for practice, we have seen that Williams was among many who noted that current methodologies and processes have become largely trapped within the structural scale dimension. That is, they are reasonably good at handling anything large, but as soon as anything with pace, socio-political, uncertainty, or any dynamic challenge comes along, they are far less effective. This is just one of the insights from this work and provides some explanation as to the poor levels of success being achieved by organizations in the project work, despite the widespread application of current methodologies and processes.
66
Aspects of complexity: mAnAging projects in A complex World
The Amount of Time and Effort Managing the Task Will Take For example, we encountered a Nobel Prize winning scientist from one of Scandina- via’s top institutes. He had just been awarded millions of Euros from the European Union to conduct a research project involving more than 15 institutes and compa- nies from more than 10 countries. We asked this scientist, “How are you going to manage this as principal investigator?” His response was “I have a spare afternoon once a month to take care of this.” The communications and IP issues alone were going to take more time than this to manage, but when we were challenged as to how much time and effort we expected it to take, we had to rely on rough percent- ages, settling on “between 5% and 10% of the overall effort.” This figure had no calibration, and certainly nothing that was even vaguely acceptable to the scientific mind! An assessment of the complexities of the task would have at least provided a qualitative guide to the extent of the task of management.
The Requirements of the Task Manager The examples provided earlier illustrated that the notion of one size fits all applies just as poorly to the selection and development of the task manager as it does to the selection of the process. In exploring the requirements of the task manager, there have been some useful contributions to this (International Project Management As- sociation [IPMA], Global Alliance for Project Performance Standards [GAPPS]), but nothing that has engaged the conversation with senior managers as successfully as the analogy we are about to describe.
Flying
“I’ve never known an industry that can get into people’s blood the way avia- tion does.”
Robert Six, Founder and CEO Continental Airlines
As established at the beginning of this chapter, reports suggested that few proj- ects succeed completely, and if they arrive at all, they are often late and overbudget. Of those that are completed, many fail to deliver the benefits they promised. In short, if projects were civil aircraft we would be living in a world where jumbo jets regularly fall out of the skies. Airport runways would be strewn with wreckage and passengers waiting endlessly in lounges would be rightly terrified of the prospect of boarding the plane.
What if managing projects were rather more like flying commercial passenger airplanes? The requirements for each are immediately comparable; the flight (proj- ect) arriving safely (project delivered) on time (on schedule) and with the fuel load provided (resource or cost). In addition, the manner of its delivery is appropriate to consider, without surprises. Exciting delivery is not a requirement.
Similarly, the comparison between take-off and project initiation is relevant. Just about anyone can initiate a project, and data from pilot training simulators show that most people can get a plane off the ground. Landing the plane (project) is rather different. There is a saying among pilots that:
“A good landing is where everyone walks away unharmed. A really good landing is where we can use the plane again.”
67
feAr of flying
Projects can be delivered ‘at any cost’, but it is a really good manager that can ensure that the team wants to work together again. Further aspects of commercial flight and their project comparators are shown in Table 5-2.
No one would let an untrained pilot fly an aircraft full of passengers. Yet in many companies the selection and training of suitable project managers is still an assumed (rather than taught) professional skill. A good commercial airline pilot is a trained professional whose entire focus is to ensure that the flight is as well planned and executed as possible. They go to great lengths to ensure that the flight goes smoothly within a high reliability environment. In the project environment, methodologies/check lists and governance systems are utilized to ensure a similar modus operandi.
Pilots do not take off without doing the necessary preparation: planning (flight plan); reviewing checklists (preflight checks); conducting risk management (weather); and employing constant monitoring and control. They instill confidence in others by always appearing calm and in control and communicate clearly and factually. Their training is to plan and then have a back up the plan. They enhance their skills in flight simulators (project risk/contingency/scenario planning) and optimism (which might lead to optimism bias) is largely eliminated by their sys- tems of work.
While flying, an autopilot flies the plane leaving the pilot to intervene only if they choose or events occur that are outside certain established parameters (or the pilots need flying hours). The comparison with established organizational project and control systems is an interesting one. Here we see that ‘management by excep- tion’ is well established in flying, but less so in project work.
Like project managers, pilots are acutely aware that if the flight ends in disaster they will “arrive at the scene of the accident first…and at speed.” Similarly, many project disasters have reputational and/or financial consequences. Pilots have to sign off aircraft before take off (project launch/project charter) knowing that some
Aspect of Flight Project Comparator
Pilot Project manager
Airline Project organization
Cabin crew Project team
Passengers Stakeholders
Air traffic control Program/portfolio management
Instruments Performance indicators
Flight plan Plan
Fuel Budget
Flight time Timeline
Airspace Project environment/culture
Flying rules Systems/methodologies
Weather Risk
Accident investigation Post-project review
Table 5-2: Flight/project analogies
68
Aspects of complexity: mAnAging projects in A complex World
systems may not be fully functional. In extremis they can refuse to sign if they think that the level of risk is too high. In many organizations, project managers are not given any choice in the matter and are sometimes misled about the status of the project that they are expected to fly—small wonder then that in such cultures “smart people avoid projects.”
Air space is the environment in which projects fly, and it is divided into two types: controlled and uncontrolled.
Controlled. Here, all flights fly within strict air corridors controlled by air traf- fic control. It is known as instrument flight rules (IFR) and pilots are carefully tracked and monitored by controllers on the ground to ensure that flights are cor- rectly prioritized and collisions are avoided. An added advantage of IFR is that the pilots can ‘fly blind’ through clouds or at night relying on the controllers to keep them from harm’s way.
In our project analogy, these flights will be flown according to ‘rules’ which in organizations are the project procedures, methodologies, and governance (sponsors/ steering groups, etc.). These rules ensure that projects are controlled in a standard- ized way such that whole programs can safely be coordinated.
Uncontrolled. Here, the pilots are largely free to fly as they like but have to en- sure their own safety by “looking out the windows.” In the civil aviation world, this is known as visual flight rules (VFR). As long as pilots avoid the airspace controlled by IFR, they may largely make their own decisions as to how and where to fly.
In the project world, VFR applies to smaller projects (often run within a single department) where air traffic is light and complex tracking and coordination sys- tems are not required. It should be emphasized that the pilots (project managers) still need flying skills but they largely have to assess the risks for themselves and realize that flying blind is extremely hazardous. It is usual for pilots to submit a VFR flight plan that outlines their intended flight time, course, and destination. If they fail to arrive, their hope is that someone will come out to look for them and/ or clear up the wreckage.
Once structural complexity increases the more numerous and interrelated flights within the airspace lead to a requirement to prioritize and control them so accidents or collisions do not occur. In flying, air traffic control has this respon- sibility and in projects, portfolio, or program management. They will ensure that projects are only allowed to take off if the runway is clear (resources are available), and that they have a place to land (handover and deliver benefits).
It is important to note here a professional distinction: air traffic controllers are not required to be pilots. Rather, their task is to establish and control air corridors where projects can be tracked, given guidance, and prioritized for takeoff and land- ings. It is interesting to note that sometimes air traffic controllers look after several flights at once and similarly some managers will often find themselves members of several steering groups. The world’s air traffic control is made up of many integrated national systems, and likewise divisional/global organizations should have a com- mon project system/language that allows interdivisional programs of projects to be undertaken successfully.
69
feAr of flying
One of the greatest concerns for pilots is the weather—in project terms “risk.” They typically go to considerable trouble to study forecasts, and when flying, will often use radar or visual information to avoid turbulence or thunderstorms that could make the flight “eventful.” Likewise, project managers should use weather (risk) forecasting methods to ensure that risks are identified, avoided, or controlled thus ensuring as smooth a flight as possible. While forecasts and a weather eye can help avoid the worst weather conditions, there is always the possibility of other unforeseen events—in project terms “the unexpected.” Pilots must be capable of dealing with events that were neither planned nor forecasted. Like the pilot, project managers can only achieve this if they have the rest of the systems under control and they are correctly trimmed. Severe weather often leads commercial pilots to fly longer routes (using more valuable fuel) in order to ensure a smooth flight. Project managers do likewise but sometimes budget or time constraints mean that the flight has to fly through turbulence.
Finally, the analogy draws on the use of accident investigation in the develop- ment of more reliable and resilient processes, people, and technology when it does all go wrong. The world of commercial flight appears to have learned the lessons well of its accidents, with the results that today, it is safer to fly than to cross the road in most countries. While such learning is embedded successfully in systems of flight, project systems are far less successful at learning. One major U.K. gov- ernment department noted recently that “lessons learned review” were no longer carried out and had been replaced by “lessons identified reports.” The reason was simply, ‘we have realized we don’t learn.’
As with all analogies, flight has its limitations. As Winter and Sczepanek noted, this provides one view, not the only view. The focus has been on the development and role of the manager (civil pilot, fighter pilot, air traffic controller [ATC], or war- room commander). The analogy may extend and enlighten other roles, for instance, that of the crew (project team) or perhaps the most important individuals—the pas- sengers (stakeholders), without who the flight would have no objective.
Application of the Flying Analogy By combining the flying analogy with the task, it is now possible to create a tool for analyzing and teaching complexity within the project and program environment. It should be emphasized that this is a simplified model that only establishes high/low parameters; however, as a platform for initial conceptualization, it has been found to be valuable.
As can be seen in Figure 5-5, four generic types of management have been proposed.
Type A—the civil pilot. A commercial airline pilot model fits well with the es- tablished traditional project methods and mindset. Once a flight has been planned, dynamic change is positively managed out of the venture as far as possible. The objective is to arrive at the chosen destination, on time, on budget, and with as few deviations to the plan as possible. It is an environment of risk avoidance, planning, procedure, and compliance.
Type B—air traffic controller. The air traffic control model is applied to en- sure co-ordination of several projects. The objective is to orchestrate a system to
70
Aspects of complexity: mAnAging projects in A complex World
minimize any conflicts between flights and to maximize the utilization of given airspace. To enjoy the benefits of the system, all flights have to adhere to the pre- scribed systems or avoid the designated air lanes. It is an environment of risk avoid- ance procedure, coordination, and governance.
Type C—the fighter pilot. A fighter pilot needs all the planning skills of a com- mercial pilot but takes off on a mission with the expectation that the dynamic com- plexity of the flight will be high “a plan seldom survives the first contact with “the enemy.” The mission objective is clear but nothing is more important than the pilot retaining fluidity of thought and action. It is an environment of risk acceptance, frameworks, and tactical initiative.
Type D—the war-room commander. A fighter pilot alone is ineffective and soon dead. To maximize the strategic advantage of the fighter pilot, it is vital to have a system that not only identifies and coordinates “friendly” (internal) flights but can also track “enemy” (external) flights such that the system can adapt to the dynamically challenging environment. In this case, the focus is on looking outside the internal environment and predicting, expecting, and accepting high levels of change. It is an environment of risk acceptance, systems, and strategic initiative. In addition, the war room commander will have all the other types of activities ongoing.
Implications for Organizations We presented this analogy to many project managers and then asked, “So what kind of project manager are you—fighter pilot or airline pilot?” Over 80% responded as fighter pilot.2 Whether the perceived glamour of the fighter pilot or the reality of their work as having a high degree of dynamic complexity guides this view, is not clear. Either way, from an organizational perspective, this is a challenge, as the
Figure 5-5: Generic types of management
AT Controller
Civil Pilot
War Room
Fighter Pilot
Increasing Structural
Complexity
Increasing Dynamic Complexity
2We are not presenting this as scientific evidence, rather an observation that we found interesting and believe to be worth exploring further.
71
feAr of flying
preference for known or stable delivery in most organizations would suggest that it is more likely that 80% of projects would require the attributes of airline pilots. The implication for those organizations is clear: They need to provide the context (analogous to ATC) in which projects can work to be more like airline flight. The level of dynamic complexity can be assessed and should be managed. Further, the role of the civil pilot project manager needs to be encouraged and rewarded. As one senior manager recently commented, “We have too many fighter pilots who get rewarded for being fighter pilots in a war. The problem is that if there isn’t a war to fight, they go out and start one.”
For the other roles, while the application of program and portfolio management standards and processes may be effective for large-scale tasks, there are other com- plexities that need to be considered. For instance, where the high levels of complex- ity are due to socio-political challenges, pace, or fundamental uncertainties, the standards and generic process models appear ineffectual. The assumption that the adoption of standards will improve delivery is therefore to be challenged.
Lastly, the analogy of war room operations is most useful, and the practices of wartime leaders like Sir Keith Park in the Battle of Britain, do require some further exposition – there is much there that modern leaders could take from the way that both the structural and dynamic complexities were ‘managed.’
Conclusions At the beginning of this chapter, we noted that a rational mind would avoid taking the role of a project manager. However, the reality is that this has been a grow- ing arena for management activity and its popularity appears to be undiluted by published success rates. Using the flying analogy and reflecting on the growth of project management, perhaps we are now seeing the limits of visual flying rules; the skies are now so crowded with projects that a different kind of project manager (the commercial pilot) and rules for flight (IFR) need to be employed. The evidence of so many crashes surely requires this.
So, why would someone take on the role of a project manager? The personality profile for pilots, published by the Air Line Pilots Association International may give a clue. “Pilots are inclined to modify their environment rather than their own behavior. Pilots need excitement; a 9-5 job would drive most pilots to distraction.” Indeed, a participant at a recent project management workshop noted similarly that despite working in an environment where the customer didn’t know what they wanted and changed their mind frequently, their own senior managers undermined them at every opportunity and their team were demoralized and ready to quit, they wouldn’t change their job for the world. Fear of flying? Doesn’t look like it to us!
References P57, line 9. National Audit Office (NAO). (2009). Major projects report. London, UK:
National Audit Office. P57, line 16; P58, line 43. Winter, M., Smith, C., Cooke-Davies, T., & Cicmil, S.
(2006). Directions for future research in project management: The main find- ings of a UK government-funded research network. International Journal of Project Management, 24( 8), 650–662.
72
Aspects of complexity: mAnAging projects in A complex World
Heading, line 14. Davis, J. C. (1984). The accidental profession. Project Management Journal, 15( 3), 6.
P58, line 17. Adams, S. (1996). The Dilbert principle. New York, NY: HarperCollins. P58, line 25; P66, line 27. Standish Group. (2009). Chaos report (application project
and failure). Boston, MA: The Standish Group International Inc. P58, line 40. Koskela, L., & Howell, G. (2002). The underlying theory of project
management is obsolete. Proceedings of the 2002 PMI Conference, Seattle, WA. P59, lines 6, 9. Pellegrinelli, S., Partington, D., Hemingway, C., Mohdzain, Z., &
Mahmood, S. (2007). The importance of context in programme management: An empirical review of programme practices. International Journal of Project Management, 25(1), 41–52.
P59, lines 13, 21. Shenhar, A. J. (2001). One size does not fit all projects: Exploring classical contingency domains. Management Science, 47(3), 394–414.
P59, line 19. Xia, W., & Lee, G. (2004). Grasping the complexity of IS development projects. Communications of the ACM, 47(5).
P59, lines 23, 27; P60, line 27. Maylor, H., Vidgen, R., & Carver, S. (2008). Manage- rial complexity in project based operations: A grounded model and its implica- tions for practice. Project Management Journal, 39(S1), S15–S26.
P61, line 10. Baccarini, D. (1996). The concept of project complexity: A review. In- ternational Journal of Project Management, 14(4), 201–204.
P61, line 11. Williams, T. M. (1999). The need for new paradigms for complex proj- ects. International Journal of Project Management, 17(5), 269–273.
P61, line 13; P65, line 35. Williams, T. M. (2005). Assessing and building on project management theory in the light of badly over-run projects. IEEE Transactions in Engineering Management, 52(4), 497–508.
P61, line 15. Geraldi, J. G., & Adlbrecht, G. (2007). On faith, fact and interaction in projects. Project Management Journal, 38(1), 32–43.
P61, line 18. Xia, W., & Lee, G. (2005). Complexity of information systems develop- ment projects: Conceptualization and measurement development. Journal of Management Information Systems, 22(1), 45-83.
P61, line 19. Geraldi, Maylor, & Williams. 2011. P69, line 24. Winter and Sczepanek (2009) P71, line 32. ALPA (2010), Personality Profile of Airline Pilots, Washington, DC:
ALPA Int. – The American Union for Airline Pilots, p.1.
?/Au: Need full refs, pls. provide
73
Chapter 6
The Impact of Complexity on Project Cost and Schedule
Estimates Dale Shermon
Introduction This chapter provides advice for management and senior practitioners about how their projects’ complexity will influence their cost and schedule estimate. The thought that budgets need to be defined early with confidence is worthy of serious discussion, setting realistic, justified budgets earlier in a project’s life cycle will greatly ease the financial processes of the project. An attitude of “entry-ism”1 when establishing the cost and time budget at a politically acceptable level, rather than an appropriate level, will pave the way to financial problems which will emerge later in the life cycle. The estimating methodology of parametrics being a function of size, productivity, and complexity as independent variables and effort (and there- fore cost) as a dependent variable is discussed.
The top-down parametric estimating process involves a number of steps in- cluding data gathering, normalization, determining cost estimating relationships (CERs) using statistical analysis, testing a hypothesis, and finally applying the model. Historical trend analysis (HTA) is an application of parametric estimating in the context of business case (BC) approval including economic analysis (EA) in the form of investment appraisals (IA) and affordability. To exemplify these prin- ciples cost growth in defense programs is the topic and a case study for this chapter.
The Business Case Engineers and designers have had brilliant ideas; throughout history, they have created products and systems that have changed the world. Initially, hardware and more recently software systems have transformed our world and have even enabled us to travel beyond our world. However, none of these innovations would make it off the drawing board without the benefit of a business case. In early years, there was an informal understanding between people that investors would recover their
1The phenomena in projects of setting the budget low to get approval and then growing the budget once accepted.
74
Aspects of complexity: mAnAging projects in A complex World
capital or investment because of an innovation. Nevertheless, currently this busi- ness case is a more formal affair. Investors seek a business case that determines the return on investment (ROI), internal rate of return (IRR), net present value (NPV), cash flow, etc.
It is not just the private sector that requires this level of analysis. The public sector will also stipulate a number of hurdles, gates, or milestones through which a project must successfully navigate or cross before the program has a release of pub- lic funding. In some cases, these obstacles to funding will require a business case to be generated or a similar type of justification to precede the launch or kick-off of a project.
This can be mystifying for the engineer or designer who can see nothing more than the brilliant innovation or system that they have nurtured like a loving parent from an inspiration into a fully engineered design. It can be difficult to persuade some of these geniuses that their “baby” is not going to leave the drawing board until a business case has been established. They are so blinded by the brilliance of their creation that in some instances they never make it past the drawing board stage because they are unable to articulate the benefit and value to the wider popu- lation or at least to investors in such a way as to attract investment.
On the other side of the business case, the investors are rightfully skeptical about any or all cases that they review. Many investors fund projects, which prom- ise high returns, just to find that the project absorbs more and more funding with- out any sign of the return that was envisaged. Now this is not necessarily the fault of the engineers. Engineers, by their very nature are optimistic people. Engineers need to be optimists. They are challenged by difficult, tricky, complicated problems to solve; if they were easy, it would not require an engineer. Such people wake every morning and go to work with a “can do” attitude, no setback is going to stop them from solving the complex problems of the day.
It is also these optimists who are asked to estimate the cost and schedule of projects!
It is therefore little wonder that many projects are blighted with cost overruns and schedule slippages. The engineers’ optimism at the bidding stage will inevitably mean that they will consider all projects achievable and conceive a solution to the most difficult problems at the outset, which in reality will not be the final solution.
So how do project managers of complex project ensure that they do not suffer the frustrations of inadequate budgets and unrealistically short program durations?
Estimating and Parametrics There are three recognized estimating techniques: analogy, analytical, and para- metric. At different times in a project’s life cycle, these estimating techniques are appropriate. At the earliest point of the project’s life cycle, when the budgets are being set, the parametric estimate is the most appropriate methodology.
Parametric estimating provides an estimate of cost and schedule based upon a historical database of past projects, which have been normalized. This database has then been analyzed to determine the technical design and performance charac-
75
the impAct of complexity on project cost And schedule estimAtes
teristics that are cost and schedule drivers. From this point, a hypothesis needs to be tested, and a statistical analysis can be conducted to prove that hypothesis. The results of this testing is a set of algorithms known as cost estimating relationships (CER) and schedule estimating relationships (SER) that represent the database of past projects. To demonstrate accuracy of the estimating relationships they can be used to predict those historical projects based upon their historical parameter val- ues. These CER and SER can then be put to new usage with future projects param- eter values to determine the cost and schedule of future complex projects.
Typically, parametric models will contain hundreds if not thousands of CER algorithms. They are combinations of lower level models that are brought together to form the big picture. It is common for the core algorithm to consider independent variables of size (e.g., volume, weight, Software Source Lines of Code [SLOC]), pro- ductivity (e.g. variation from industry norm, tooling, labor skills), and complexity (e.g., technology, application, environment). The complexity aspect of a parametric model will be considered later in this chapter.
Why is this useful? A parametric model is not optimistic (or pessimistic); it is just a representation of the past which can be used to predict the future. Using a parametric model to set the budget for a complex project will ensure that the budget is adequate and the schedule realistic. Because it is a top-down methodology, noth- ing is omitted or duplicated. Figure 6-1 shows the difference between top-down and bottom-up estimating methodologies with the parametric advantage occurring when there is little information, which is generally the case at the start of a com- plex project. It is possible to estimate the cost of new complex projects without the need to ‘tease’ an estimate (staff hours, material, and other direct costs) out of a designer or engineer.
But, has the problem just been moved from one area to another? Although the estimate is not coming from the engineer or designer, we will need them to quan- tify the parametric inputs, which represent the likely solution to the complex prob- lem they have been set. We will require their view of the performance or design
Parametric Estimating
Detailed Estimating
High
High
Low
Parametric Advantage
Quality
Information
Figure 6-1: Parametric estimating advantage
76
Aspects of complexity: mAnAging projects in A complex World
parameters, which are the cost and schedule drivers. Again, these could be biased or optimistic.
So how does a project manager of a complex project ensure that the parameters are free from optimism?
Capability and Design There is often a misconception that it is possible to estimate the cost (and schedule) of a set of capabilities or requirements. Project sponsor’s often have a desired capa- bility that they wish to acquire often expressed in terms of a set of requirements and a need for an indication of the cost and delivery date. For example, I have a need to transport and contain a gin and tonic, what is the cost?
Now the problem here is that cost cannot be related directly to the capability or requirement. The requirement needs to be interpreted into a design, and it is the design which is given a cost and delivery date. In my example, the design envisaged could be a plastic cup and hence the cost would be less than one cent or penny. The naïve project manager would accept this as a realistic budget for the complex project.
A common problem is that the engineer’s optimism that a simple solution is sufficient does not become reality. The plastic cup becomes a lead crystal glass because the solution is always a glass of some description and the plastic cup was never going to be a satisfactory design. The cost consequences are many multiples of what the original budget was conceived to be, but by this time, nobody can re- member why the estimated cost (of the glass) and budget (of a plastic cup) are so far apart?
The problem is not requirements creep; this can be managed by a project man- ager by monitoring changes or alteration to the requirements. Here, the problem is conceiving an early immature design when only the requirements are articulated. Therefore, we toil for many days and nights to accurately predict the budget for the wrong design. This example is very simple, when the level of deviation between initial and final design is translated into complex real life projects there are serious financial consequences.
Advanced application of parametrics will include an extension to the cost and schedule parameters into the requirements space. It is possible to create a knowl- edge base or expert system, which will compare the capability and the proposed design early in a project life cycle, when a complex project is having its budget set. In a more practical example of a complex project, it would be possible to avoid the highly accurate cost and schedule estimate of a 20,000-ton aircraft carrier, which would be completely incapable of satisfying the requirement to fly 70 aircraft from its flight deck. An advanced parametric model would highlight the need either to increase the size (displacement) of the aircraft carrier, and thus the budgeted cost, or to reduce the capability or requirement (number of aircraft).
Parametric Estimating There is a number of commercial parametric cost estimating models available or it is possible to create and research your own. This section will consider the option to
77
the impAct of complexity on project cost And schedule estimAtes
build your own parametric model and then we will review a commercial system. As already stated a parametric model can contain thousands of variables or cost driv- ers. This example will be a multiple variable model that can be applied across many projects at a high level early in the project life cycle.
The steps in creating a parametric cost model are as follows;
1. Determine the requirements for a parametric cost model and the return on investment (ROI)
2. Determine the boundaries and assumptions 3. Gather historical data of past relevant projects including cost, schedule, tech-
nical and design data 4. Normalize those data for currency, economics, quantities, production rate,
units of measurements (metric or imperial) 5. Identify likely cost drivers (independent variables) 6. Formulate a hypothesis regarding the independent variables and the cost or
effort (dependent variable) 7. Test the hypothesis statistically to determine its significance 8. Document the cost estimating relationship for future usage.
In this simple parametric case study there has been a database created and nor- malized. In this example, aircraft data have been normalized to U.S. dollars ($) at constant 2006 year of economics and reduced to the theoretical first piece (T
1 ) of
the production run. The T 1 is theoretically the first item of a production quantity,
which exhibits the learning phenomenon and is therefore the most expensive. The first hypothesis considers the increase in cost with the increase in weight (see Fig- ure 6-2). This is a reasonably intuitive hypothesis, if something is larger then it will require more raw materials and more processing hence more labor content, there- fore “the more the system weights the more it costs.”
However, this simple hypothesis is not likely to satisfy all the historical data points or projects. These will be a level of ‘noise’ in the data, which means that the line of best fit does not go through all the historical projects. In statistical terms,
HighLow
High
Low
Positive Residual
Negative Residual
T1 Cost US$
2006
Weight
= Historical Normalized Data
Figure 6-2: Cost versus weight
78
Aspects of complexity: mAnAging projects in A complex World
this is considered a random error term, which can be represented as a positive or negative residual.
If these residual figures are plotted against another variable, for example a per- formance characteristic, then a second parameter becomes part of the cost estimat- ing relationships. In many systems, the residual can be plotted against a time axis (see Figure 6-3) and it becomes apparent that there is a relationship over time. This can be most likely explained as representing the technology influence isolated from the overall weight effect. As time passes, technology becomes more complex.
This addition to the CER can be justified with the hypothesis that as time passes the complexity of the systems increases. It now becomes apparent that newer systems will cost more than older systems, after their weight has been normalized out of the data. If you consider this hypothesis for many systems, it is true. For example, in the early days of aircraft, they were made from wood, canvas, and wire. This has evolved through to today when the technology is more advanced in term of materials and manufacturing processes adopting composites, electronics, and software.
Figure 6-3 in turn will have residuals, which can be calculated, plotted, and statistically analyzed and rationalized with hypothesis to develop the CER further. A parametric model does not need to be difficult to understand, but the number of CERs will grow to accommodate more hypotheses observed in the real world. These hypotheses are nominally the cause of residuals and explain why one simple CER will not completely model the cost of a complex project.
When a parametric cost model is used to normalize the cost there are a number of CERs that are applied. One of these submodels is the technology maturity model. Figure 6-4 shows graphically the theory behind this model based upon a constant industry or operating environment. Naturally, if the industry or operating environ- ment is changing the maturity of the technology will change.
The hypothesis behind this model predicts that as time progresses, technologies are assumed to mature. This is explained in terms of market forces. Due to market forces, immature technologies are expensive owing to the limited number of sup-
+
–
Residual US$
2006 ec
1940 1950 1960 1970 1980 1990 20102000
Figure 6-3: Residual cost versus time
79
the impAct of complexity on project cost And schedule estimAtes
pliers of the new material and providers of manufacturing processes. This lack of availability resulting in higher costs due to the demand and the model would gener- ate a positive cost penalty. As time progresses, more suppliers join the market and provide the material and skills. Competition ensures that the costs are reduced, resulting in the application of a cost benefit.
Part of the problem in complex defense projects is that mature technologies are seen as less capable. The services (navy, army, air force) constantly want to move to the next technology to ensure superiority on the battlefield. Equipment would be cheaper if the current generation of equipment were reordered with existing mature technology. However, the admirals, generals, and wing commanders desire the next generation of equipment not the present.
Accuracy Before there is too much excitement about our ability to predict the cost of a com- plex project, let us consider the obvious question. How accurate is a parametric model? To determine the relative accuracy, a data set was employed containing more than 90 fighter aircraft. The approach was to normalize the cost and techni- cal data. Costs were normalized against currency, economics, and quantity. The technical data were normalized for metric (kg) versus imperial (lbs) and other such anomalies.
After normalization, the fighter aircraft data were subjected to the analysis pro- cess and a simple parametric model was created. The historical projects then had their costs predicted based upon this parametric model. To assess the accuracy of this technique, the predictions were plotted against the historical data and the coef- ficient of determination (R2) calculated through a series of the graphs.
Figure 6-5 provides a graphical visualization of the fighter aircraft accuracy. A simple, core CER based upon just the weight of the systems provides a poor model (R2 = 0.23). There is an immediate increase in accuracy when the complexity of the systems, indicated by the time dependent residual, is added to the CER (R2 = 0.87). This complexity represented the increase in the level of technology introduced over
Cost
Time
Time Now
Lower Complexity Higher Complexity
Technology Maturity Dates
Mature Technology Usage Results in Lower Cost
+
–
Figure 6-4: Technology maturity model
80
Aspects of complexity: mAnAging projects in A complex World
time. Finally, the correlation of the historical costs and the prediction of the CER is refined further (R2 = 0.90) with the introduction of a performance variable, which will predict the cost most accurately. This model will be used as the basis of a case study at the end of this chapter.
Historical Trend Analysis There are a number of commercial parametric models on the market, which can be used to estimate cost. One of the oldest models has an independent variable term or cost driver called “manufacturing complexity” or complexity for short. The com- plexity occurs because of comprehensive normalization. The model has numerous submodels and CERs that result in a final representation of the core elements of the product. Complexity is a technology index and, if the technology is constant, it can indicate productivity. This complexity variable leads to many different applications of the parametric cost model including supplier assessment, cost as an independent variable (CAIV), predictive earned value management (P-EVM), and historical trend analysis (HTA). The latter application is useful in the context of predicting the cost of complex projects and setting the correct budget early in the project life cycle when little information is available.
Daryl Webb published a series of papers looking at complexity over time. Manu- facturing complexity of structure (MCPLXS) is the result of product calibration using the PRICE H model. Webb conducted a series of system level calibrations grouping the systems into product types and plotted the resulting complexity over time as seen (Figure 6-6). In the analysis, there was a consistent upward trend in military systems.
Historical Costs (US$)
True Concepts
Prediction (US$)
Accuracy
$250,000,000
$200,000,000
$150,000,000
$100,000,000
$50,000,000
$0
-$50,000,000
$0 $50,000,000 $100,000,000 $150,000,000 $200,000,000 $250,000,000
T1 Based on Weight Growth Curve Core + Technology + Performance Core + Technology
Linear (Core + Technology) Linear (T1 Based on Weight Growth Curve) Linear (Core + Technology + Performance)
R2 = 0.2311
R2 = 0.9052
R2 = 0.8758
Figure 6-5: Historical cost versus predicted cost
81
the impAct of complexity on project cost And schedule estimAtes
This approach was made easier with the introduction of the PRICE knowledge management systems, which enabled the consistent storage, retrieval, and analysis of system level programs, such as the future U.K. aircraft carrier.
However, although most systems demonstrate a trend, not all systems follow an upward trend. Commercial aircraft have become more complex as time has passed, but they have a flat or declining complexity over time when reviewed by aircraft type (Figure 6-7).
Technology Year (IOC)
Ztech = 1 Ztech = 0 Forecasts
Submarines Armored Tanks
1910 1920 1930 1940 1950 1960 1970 1980 19901930 1940 1950 1960 1970 1980 1990 2000 2010
Ztech = 1 Ztech = 0
Linear Slope = .035/yr n = 8, r 2 = .97
Linear Slope = .017/yr n = 9, r 2 = .80
C om
pl ex
it y
M C
PL X
6
5
4
3
2
7
6.5
6
5.5
5
4.5
4
Mk-VIII,UK FT (Fr)
M-4,US M-3,US
M-60A2,US M-48,US
XM-1,US Leopard,FRGSeawolf
Ohio Los Angeles
Lipscomb Permit
Lafayette Triton
Skipjack Halibut
Archerfish
Figure 6-6: Complexity over time
In-Service Date
Complexity
10
9
8
7
6
5
4
1980 1985 1990 1995 2000 2005 2010
Narrowbody Widebody High-Capacity Widebody
Linear (Widebody) Linear (Narrowbody) Linear (Widebody High-Capacity)
Figure 6-7: Commercial aircraft complexities by aircraft type
82
Aspects of complexity: mAnAging projects in A complex World
This picture changes when analyzed by manufacturer (see Figure 6-8) and pro- vides an indication of the possible reason for this lack of upwards trend. The duopoly achieved by supplier A and supplier B provides for very competitive environments, one in which productivity is key to survival. As the complexity parameter is an indication of both a technology index and productivity, it is possible to deduce that the productivity in the commercial aircraft environment is divergent to the tech- nology increase.
This phenomenon is not just limited to the commercial parametric model. Philip Pugh also observed a HTA. When considering the unit production cost (UPC) of a system, divide it by a size parameter, such as total unit weight (tons). This cost per unit weight exhibits a strong trend when considered over time. He plotted the historical UPC per unit weight of various complex projects on log-linear graph and observed a growth in system cost over time. Although the trend analysis appeared to be linear, they are curves due to the choice of axis.
This cost per unit weight versus time discovery was implemented by Pugh in the algorithms in the family of advanced cost estimating tools (FACET) model pro- duced by QinetiQ.
Why use the whole weight of a system in a complex project? It would seem logi- cal that any cost growth would be limited to certain subsystems, rather than the whole system? For example, in a destroyer, the significant weight is in the hull and super structure. Surely, this part of the ship, welded steel, has been the same for the last 50 years. If anything, the cost of this part of the system has reduced due to mod- ular construction and other manufacturing techniques. The real cost growth in a complex project has been in the radar, communication, propulsion, and navigation systems. Perhaps the focus should be on these rather than the overall cost density.
In-Service Date
Complexity
10
9
8
7
6
5
4
1980 1985 1990 1995 2000 2005 2010
Supplier 1 Supplier 2
Linear (Supplier 1) Linear (Supplier 2)
Figure 6-8: Commercial aircraft complexities by manufacturer
83
the impAct of complexity on project cost And schedule estimAtes
Case Study As an example of how parametrics cost estimating can be applied on a real complex project, a parametric estimate will be considered for the Lockheed Martin (F35) Lightning II or Joint Combat Aircraft (JCA).
The current assumptions2 for the F35 have been taken from public domain sources
• Empty weight = 13,300 kg • Length = 15.67 m • Height = 4.33 m • Wingspan = 10.7 m • Crew = 1 • Total installed power = 11,472 kw • Production quantity = 3,181 • In-service date = 2012
These technical and programmatic details have been used to estimate the pro- duction cost of the F35 aircraft, although the development and in-service cost could just as easily have been determined using parametrics. For production, the weight based CER for this parametric cost model is based on the following analysis (see Figure 6-9).
This follows the earlier hypothesis that the systems cost more due to their weight. The error in this relationship is the residual, which needs to be explained by some other independent variable. The relationship between the in-service date (ISD) and residual costs can be seen in Figure 6-10, which shows an influence with the passing of time.
2This case study was prepared in 2009.
Recurring T1 US$
$250,000,000
$200,000,000
$150,000,000
$100,000,000
$50,000,000
$0
0 5,000 10,000 15,000 20,000 25,000
y = 21.8719 x 1.4619
R2 = 0.3214
Mass Empty (kg)
Weight vs Historical T1
Figure 6-9: Aircraft weight versus time
84
Aspects of complexity: mAnAging projects in A complex World
If the F35 parameters are used in this parametric model, it is possible to derive a theoretical first piece (T
1 ) of US$147 million that will become a unit production
cost of US$135 million based on the 2010 economic conditions.
A recent General Accountability Office (GAO) report updated the F35 produc- tion cost and stated a figure of US$131 million in (out-turn) costs. As the majority of the program extends beyond 2010, this figure would be reduced when considered in constant 2010 economics.
In an alternative commercial parametric model, it is possible to determine the complexity parameter of fighter aircraft and extrapolate the HTA until the F35 ISD. This methodology is presumed more accurate due to the greater level of normaliza- tion, which is applied to the raw data. As discussed, there are a number of models within a parametric model such as technology maturity, schedule effects, quantity effects, etc., leading to increased normalization. When the resulting complexity is used to predict the cost, the F35 is predicted to be US$132 million at 2010 economic conditions.
The accuracy of the approach reflects the data that are required. It follows that more information is needed for the commercial parametric model. The complexity versus time approach required more data both when normalizing the cost to derive the historical complexity and when estimating. If this estimating technique is to be applied at the early, preconcept stages of a project this need for more programmatic and technical information should be considered.
Summary With the help of this chapter, it is possible to summarize the influence of paramet- ric estimating on complex projects. Not all complex projects experience an increase in complexity in parametrics terms. There are nondefense projects, for example commercial aircraft, which experience a neutral or reducing complexity. It is specu-
Residual
Residual vs ISD y = 5158.48 x -111758397.98 R2 = 0.66
In Service Date (ISD)
$250,000,000
$200,000,000
$150,000,000
$100,000,000
$50,000,000
$0
-$50,000,000
1900 1913 1927 1941 1954 1968 1982 1995 2009 2023
Figure 6-10: Residual versus time
85
the impAct of complexity on project cost And schedule estimAtes
lated that this is caused by the rate of productivity reduction exceeding the level of technology growth.
It would seem that the historical trend analysis (HTA) of a complexity param- eter could result in an increased degree of accuracy when applied to fighter aircraft. The results would indicate that utilizing a commercial parametric model is an effi- cient approach to normalizing raw cost data prior to extrapolation of the complexity into the future.
The assumptions for the F35 case study predict the UPC to be in the range of US $132 million to $135 million at 2010 economic conditions. At the early stage of a complex project, an accuracy of 20% is a good outcome and in this case in line with the current authority figures.
Finally, it is recognized that this initial case study demonstrates that paramet- rics has a place in the initial assessment of complex projects. However, this is only one project type, fighter aircraft, but it is equally applicable to other complex proj- ects in the space, land, and sea domains. Parametrics as an approach to set early complex project budgets is equally applicable in non-defense domains, if realistic budgets are desirable and business cases are going to be successful. Parametrics can be deployed to helping to set realistic budgets for complex projects and safeguarding the project manager.
References P77, line 4. Shermon, D. (2009). Systems cost engineering. Aldershot, UK: Gower.
ISBN: 978-0-566-08861-2. P77, line 5. International Society of Parametric Analysts. (2008). ISPA Parametric
Estimating Manual. Retrieved from http://www.ispa-cost.org/newbook.htm P80, line 7. PRICE Systems. (n.d.). PRICE H or TruePlanning for hardware from
PRICE systems. Retrieved from www.PRICESystems.com P80, line 18. Webb, D. (1990). Cost complexity forecasting historical trends of major
systems. Journal of Parametrics, 10 (4), 67–95. P81, line 3. Shermon, D. (2002). Knowledge management in parametrics. Cost En-
gineer, 40(3). P82, line 9. Pugh, P. G. (2007). Source book of defence equipment costs. ISBN: 978-
0-9556258-0-0. P82, line 17. Qineti, Q. (n.d.). Family of Advanced Cost Estimating Tools (FACET).
Retrieved from www.qinetiq.com/home/products/facet__the_family.html P83, line 5. F-35 Lightning II. (n.d.). In Wikepedia. Retrieved from http://
en.wikipedia.org/wiki/F-35_Lightning_II. and Lockheed Martin. (n.d.). F-35 Lightning II program update and fast facts. Retrieved from www.lockheedmar- tin.com/data/assets/aeronautics/products/f35/F-35FastFacts.pdf
P84, line 4. Government Accountability Office. (2010). Joint strike fighter: Signifi- cant challenges and decisions ahead. Publication no. GAO-10-478T. Washing- ton, DC: Government Accountability Office.
87
Chapter 7
Beyond Competence: Developing Managers of Complex Projects
Lynn Crawford and Ed Hoffman
Introduction Considerable attention and development activity has been devoted over the last 20 years to determining and codifying, in standards and certification programs, the knowledge and practices that are considered necessary for competent performance of project managers. Although not explicitly stated as such, these efforts are es- sentially geared toward threshold competence represented by minimum standards for project management knowledge and practice considered necessary for effective workplace performance. Further, they are primarily designed for management of single or stand-alone projects for which goals and methods can be well defined. On such projects, minimum standards for knowledge and practice can provide a shared vocabulary and assist in achieving a relatively consistent level of perfor- mance for a majority of project management practitioners. However, the adequacy of these mainstream practice standards, knowledge guides, methodologies, and rec- ommended best practices in addressing the experienced complexity of projects, has been increasingly questioned by both researchers and practitioners.
While the terms “complex” and “complexity” are now widely used to describe projects and the problems and challenges people experience in project environments, the actual meaning of the terms is rarely made explicit. Some organizations attempt to categorize the projects in their portfolios according to their degree of complexity but complexity is not a single construct so such categorization systems, in practice, are based on multiple attributes, such as scope, clarity of goals and objectives, and level of ambiguity and uncertainty.
Projects are inherently uncertain and unpredictable as they require decisions to be made in the present concerning events that are to occur in the future. Determi- nation of success or failure is often ambiguous as it is judged by stakeholders from different perspectives. While the level of uncertainty and ambiguity in projects contributes to perceptions of complexity, it is arguably people who introduce the complexity to projects, and on this basis, all projects are to some extent complex. As Snowdon said, “if you “walk up to an aircraft with a box of tools in your hand, nothing changes” but “when a rumour of reorganisation surfaces: the complex hu-
88
Aspects of complexity: mAnAging projects in A complex World
man system starts to mutate and change in unknowable ways; new patterns form in anticipation of the event.”
These challenges of projects have been exacerbated in recent times by ad- vances in communication technologies and evolving societal values that have pro- gressively eroded the illusions of command and control upon which standards for project management competence have been built. A fundamental premise of good project management has been the ability to plan, establish clear project boundaries, and exercise control to predictably achieve expected results. As pace, permeability, visibility, accountability, and stakeholder diversity increase, control becomes more elusive. It is hardly surprising, therefore, that mainstream standards and certifica- tions for project management are being challenged on the basis that they are linear, rational, and change averse and often either fail to reflect or are in direct conflict with the real dynamics of projects. Satisfaction of threshold or minimum standards for knowledge and practice in management of projects can be considered a hygiene factor for effective performance in project management roles. However, as the Engi- neering and Physical Sciences Research Council (EPSRC) funded Rethinking Proj- ect Management Network recognized, there is a need for a change of focus from trained technicians to reflective practitioners.
A number of factors have focused attention on the need to move beyond thresh- old performance to development of more dynamic competence especially for se- nior practitioners required to manage the more challenging projects or programs. One factor is that with advances in communications technology, both success and failure are far more visible and, especially in the case of public and high profile projects, subject to media scrutiny. Consequently, there is greater pressure on per- formance and less latitude for people to learn from their mistakes. Another factor is that organizations worldwide are realizing that their competent and experienced staff are retiring and leaving a vacuum because for the last forty years they have been failing to “develop their own.”
Until around 1970, organizations had taken much of the responsibility for de- veloping a skilled workforce through a tradition of on the job training, coaching, and mentoring. Those experienced employees who are currently on the verge of retirement, began work about 40 years ago, at the time when organizations, under the influence of economic rationalism, were reducing their workforce numbers and putting pressure on academic institutions to produce work ready graduates. Senior staff, at that time, were required to work harder and no longer had the time, or the responsibility, to coach and mentor new recruits. Therefore, current senior staff have not had the opportunity to learn through personal experience how to transfer their knowledge. Attempts to fill this gap through training in mentoring and coach- ing can only provide a partial solution.
So, while there is “significant growth in project work” resulting in a need for more managers of projects, organizations have not invested in succession planning and are facing the challenge of losing their most experienced employees. Hence, there is simultaneously increased demand for experienced senior project managers and reduced supply.
89
Beyond competence: developing mAnAgers of complex projects
It is, therefore, not surprising that a number of organizations are looking for ways to fast track the development of people capable of managing an increasing number of challenging and complex projects. To do this they need to look beyond project management competence as defined in current standards and certification programs, to ways of rapidly developing higher levels of expertise that will underpin superior performance.
Professional Competence and Beyond Competence is a term that “has different meanings, and … remains one of the most diffuse terms in the organizational and occupational literature.” Dictionary defini- tions of competence include “power, ability or capacity (to do, for a task etc.)” and “due qualification or capacity, adequacy or sufficiency” to do a task. According to Woodruffe, competency “seems to be used as an umbrella term to cover almost any- thing that might directly or indirectly affect job performance.” There are, however, more specific uses and meanings of the term.
The work of McClelland and McBer Associates in the United States, beginning in the 1970s and reported by Boyatzis in the early 1980s, established what may be referred to as the competency model approach. Followers of this attribute-based ap- proach define a competency as an “underlying characteristic of an individual that is causally related to criterion-referenced effective and/or superior performance in a job or situation.” This approach is primarily concerned with behavioral competence but according to Spencer and Spencer specifically encompasses knowledge, skill, and three core personality characteristics—motives, traits, and self-concept.
Inherent in the competency model approach, following in the tradition of McClelland, Boyatzis, and Spencer and Spencer, is the distinction between thresh- old and high performance or differentiating competencies. Threshold competencies are units of behavior that are essential to do a job, but which are not causally related to superior job performance. Schroder defined a high performance competency as “a relatively stable set of behaviors which produces significantly superior workgroup performance in more complex organizational environments.”
The competency model approach has become popular among human resource professionals, and most major institutions now have a corporate competency model that identifies behaviors that are considered to drive superior performance in their organization. The identified behaviors are highly contextual and do not easily form the basis for generic standards for workplace performance.
A far stronger candidate for development of generically applicable standards is the competency standards approach. This approach to competence is promoted in the standards and qualifications frameworks of the U.K. (National Vocational Qualifications [NVQ]), the Australian Qualifications Framework (AQF), and simi- lar frameworks in South Africa and New Zealand. While the competency model or attribute-based approach assumes that identifiable personal attributes will translate into competent performance in the workplace, the competency standards approach assumes that competence can be inferred from evidence of demonstrated perfor- mance at a predefined acceptable standard. Under the Australian Competency Stan- dards approach, based directly on the U.K. model, competence is defined as:“the
90
Aspects of complexity: mAnAging projects in A complex World
ability to perform the activities within an occupation or function to the standard expected in employment.”
Both of the approaches outlined involve assessment of a different aspect of competence. Each approach has both advantages and disadvantages. As Heywood, Gonczi, and Hager pointed out, a comprehensive consideration of both underlying enabling attributes and of performance “will be the most fruitful.”
The model in Figure 7-1 brings together the competency model or attribute based and competency standards (performance based) approaches to competence described earlier and relates it to existing standards and guides for competence in project management roles.
From Figure 7-1, it can be seen that mainstream project management standards and certifications address either or both of the input and output competencies iden- tified. The IPMA 4 level certification model which uses interviews and simulations in assessment and encompasses contextual, behavioral, and technical competences (International Project Management Association [IPMA) offers the most holistic ap- proach for assessment of project management competence currently available. It can still, however, be regarded as providing only a threshold or baseline for compe- tence at each level of certification. This highlights an ultimate limit to standards and certification. The standards development process requires focus on what is re- quired of most practitioners in most circumstances. Standards are inevitably based on the known, on codification of experience of the mainstream of practitioners.
Job Description
Competence
Personal Competencies
Input Competencies
Knowledge Qualifications and Experience
Output Competencies
Underlying Enabling Attitudes and
Behaviors
Demonstrable Performance
Knowledge Guides • PMBOK® Guide • APMBOK (UK) • IPMA Competence Baseline (ICB) • P2M Japan
Project Type Job Role
Resume or Curriculum Vitae
Instruments such as • OPQ, 16PF • Meyers Briggs • Caliper Profile • Competency Model • Assessment Center
Competency Standards • UK – ECITB • Australia – NCSPM • South Africa – SAQA • Global – GAPPS
Attribute-Based Inference of Competence
Performance-Based Inference of Competence
Context
Aspect
Unit of Assessment
Assessment Guide/Method
Figure 7-1: Integrated model of competence for project management roles
91
Beyond competence: developing mAnAgers of complex projects
They delineate the requirements for minimum rather than superior performance in work roles. They can be used to ensure that the foundations are in place but go no further. They do not provide guidance for assessment and development of abil- ity to operate in the largely uncharted and dangerous waters of very complex and unpredictable projects.
Dreyfus and Dreyfus developed a five-stage model, from novice to expert or mastery, that provides a useful basis for explaining the dilemma faced when en- deavoring to fast track development of practitioners towards capability to manage very complex projects. The five stages of this model are shown on the left side of Figure 7-2.
As in any profession, standards can only provide a basis for assessment and de- velopment to the level of competent performers. According to Dreyfus and Dreyfus, beyond competence is experientially based development of intuitive and holistic behaviors and responses that can be characterized as “expert.” Reflection in and upon action, highlighted by Schön, has become accepted as fundamental to higher levels of professional development. Cheetham and Chivers developed a model of professional competence that seeks to integrate reflective practice with compe- tence-based approaches by pointing out that reflection is fundamental to all com- petency development. Their model also includes meta-competencies, “which come into their own when managers and professionals deal with the complexity of mana- gerial and professional work” and “represent the range of perceptions that exist about an individual’s performance as well as focusing on the irrationality and un- predictability of personal feelings.” Meta- or trans-competencies exist ‘above’ other competencies, enabling and guiding their development. According to Cheetham
Experts Behavior is intuitive, holistic, and synchronic, understood in a way
that a given situation releases a picture of a problem, goal, plan, decision, and action in one instant.
Proficient Performers Identify problems, goals and plans intuitively from their own experientially
based perspective. Intuitive choice is checked by analytical evaluation before action.
Reflective Practitioners
Developing meta-competencies
Competent Performers Are characterized by the involved choice of goals and plans as the basis
for their actions. Goals and plans store both context-dependent and context-independent information.
Advanced Beginners Also use situational elements, which they learned to interpret on the
basis of their own experience from similar situations.
Novices Act on the basis of context-independent rules.
Trained Technicians
Developing and assessing
against PM standards
Figure 7-2: Summary of Dreyfus & Dreyfus model of skill acquisition as pre- sented and modified for application to project management
92
Aspects of complexity: mAnAging projects in A complex World
and Chivers, meta-competencies may include communication, creativity, problem solving, learning/self-development, mental agility, analysis and reflection. They are dynamic, interactive, and far less amenable to “standardization” than the basic pro- cesses and practices considered necessary for management of most projects most of the time. It is considered that meta-competencies are “innate and natural to human beings” and can be learned, but cannot be taught. It is in this realm of meta-com- petencies that cannot be taught that the challenge lies for fast-track development of managers of complex projects.
Developing Reflective Practitioners If the meta-competencies required for superior performance can be learned, but not taught, what can individuals and organizations do to fast-track development? The fundamental answer to this question can be traced back to the work of John Dewey who identified the centrality of experience to learning but pointed out that not “all experiences are genuinely or equally educative. Experience and education cannot be directly equated to each other. For some experiences are mis-educative. Any experi- ence is mis-educative that has the effect of arresting or distorting the growth of fur- ther experience.” For learning from experience to be effective, the learner must be self-aware and have a degree of humility that may be missing in some practitioners especially if they believe and have certifications to attest to their “competence” as project managers. The use of personal experience as a resource in adult learning is well established, but we need ways to “animate” useful learning from experience that will translate into the mastery required to manage challenging projects.
Managing Experiential Learning in the Workplace Traditionally, development of “expert” practitioners, in the workplace, took many years. In the engineering and construction industry, which has a long history of project-based work and views project managers as key value adding resources, research indicates that it takes 15 years to develop a project manager capable of managing a US$100 million contract, and 25 years for a US$1 billion contract. Po- tential project managers would be identified in their mid-twenties and developed through “spiral-staircase” career placements. Managers of major projects require both general and project management experience and expertise, so a spiral-stair- case development path involves alternating placements between functionally based management roles and management of projects of increasing levels of complexity.
Development is considered a partnership between the individual and the em- ploying organization. Career aspirations and development needs are regularly re- viewed and opportunities consciously sought for training, education, and work experiences. Providing structured developmental work experiences is not easy but several studies on staff retention have found employees cite opportunities for de- velopment through rotation through projects, functions, and company divisions as a key factor in their decisions about whether or not to stay with their employers. In response, companies like Booz Allen, Mobil, and Citibank were reported, some 10 years ago, as providing rotation opportunities in their career development plans.
Few organizations today have the luxury of confidently planning development of managers over two or more decades. As indicated earlier, the need for “expert” managers is urgent. But even if employers choose to begin now to develop managers for the future, “as a result of globalisation, increasing societal complexity and flex-
93
Beyond competence: developing mAnAgers of complex projects
ibility, careers have lost their linearity and predictability.” New recruits are likely to be Generation Y, who are predicted to switch jobs frequently; however, struc- tured work-based experiences remain central to development of expertise. It has never been easy but compressed timescales and changing societal values require innovative approaches.
Industry/University Alliances, Corporate Universities, and Project Academies As Dewey said, not all experience leads to beneficial learning. Learners need to be capable of critical reflection so they can interpret their experience and draw upon it selectively as a source of learning and change. Education can assist in developing meta-competencies that facilitate effective learning from experience.
Alliances between corporations and universities are a common feature of what is often today referred to as “talent management.” Such alliances take many forms, but typically involve the development, by an academic institution, of subjects or an entire degree, in partnership with one or more organizations, to provide tailored de- velopment programs that have academic support and credibility. This makes sense when aiming to develop higher order or meta-competencies.
Some organizations choose to establish “corporate universities.” These are owned and operated by companies as vehicles “for the education and development of employees . . . for disseminating an organization’s culture and fostering the de- velopment of not only job skills, but also such core workplace skills as learning- to-learn, leadership, creative thinking, and problem solving.” They do not usually award degrees. It has been suggested that the number of corporate universities in the United States may have exceeded 4,000 by 2010, including some of the earlier initiatives in companies such as Boeing, Motorola, and McDonalds.
Related to this is a trend towards development of what are referred to in some organizations as project academies. They may be stand alone, or part of wider cor- porate efforts to develop skills across multiple job families. They are not always called project academies, although this term is used by organizations such as Shell and NASA. Their mission is the development of talent to manage the organization’s portfolio of projects and programs and encompasses a range of responsibilities and activities including provision of courses, alliances with academic institutions, and structuring of work-based experiences. The importance of this imperative is illus- trated by an initiative that resulted in the coming together of representatives of twenty six organizations from Europe, North America, and Asia Pacific, to share their experiences in developing their “academies.” The next step was joint develop- ment of a process for gathering data to benchmark their development initiatives.
Benchmarking Project Academies: Methodology and Results Methodology
Data collection instruments were developed by representatives of six organiza- tions and they included 46 questions. These questions were scored 0–5 against a good practice model in terms of both approach and deployment. Eight companies were included in the first stage of data collection and benchmarking. A two-person team of experienced assessors worked with each of the eight companies to complete the
94
Aspects of complexity: mAnAging projects in A complex World
assessment, gathering detailed evidence to support conclusions, and returning the results to the organization for verification. Quantitative data collected included or- ganizational characteristics, services provided by the academy, and costs incurred.
Demographics
All companies in the sample are large. Each company employs more than 10,000 people and has annual revenue in excess of US$10 billion. For reasons of confidenti- ality, industry distribution cannot be detailed, but six different industries are repre- sented. One half of the companies participating consider themselves more than 75 percent project based while about a quarter of the sample consider themselves less than 10 percent project based.
Results
Annual cost of the academy varies across the sample from under US$1 million up to US$15 million. The main categories of expenditure are classroom training, e-learning, and in-role support or experiential learning but the patterns of spending and activity distribution vary by organization.
All but one of the organizations in the sample have clearly defined project re- lated career paths. Five have documented competency frameworks that relate to roles. The highest performing organization continually “scans” the horizon for the requisite levels and numbers of suitably qualified people, in terms of the compe- tencies they require. Most organizations have some form of talent management program including nurturing of graduate recruits and identification and fostering of “high flyers.” One organization regularly monitors the needs of the business and changes in the external environment and modifies their activities accordingly. They also use knowledge sharing forums to encourage continuous development of knowledge. Several of the organizations have one or more links or alliances with ac- ademic institutions and one specifically encourages two-way research placements.
Experiential Learning
Given the importance of experience to competence development, and particu- larly to the higher levels of proficiency and expertise, it is interesting that only one of the sample organizations plays a strong role in facilitating the process. Through a leadership development program across the organization, practitioners with high potential, and who are expected to lead higher level or more complex efforts in the near future are identified and provided with a comprehensive development agenda including specific work assignments, supported by technical and leadership train- ing, coaching and mentoring. A developmental program focuses on improving spe- cific leadership behaviors and technical capabilities. A competitive process ensures that the most qualified individuals are selected for this opportunity at the right time in their careers when the learning will have the greatest impact.
Roles and Responsibilities of Project Academies While the purposes and objectives of project academies differ according to organiza- tional needs and cultures, there are some common roles and responsibilities:
95
Beyond competence: developing mAnAgers of complex projects
Workforce development. The project academy’s foremost responsibility is pro- viding professional development training and experiences for the organization’s project workforce. This begins with the identification of competencies, and can include strategies for both formal and informal learning.
Advocacy for practitioners’ professional development needs. The project acad- emy can serve as a champion for the project workforce, and advocate for the leader- ship support and resources necessary to meet its specific professional development needs.
Common vocabulary. In decentralized global organizations, the project acad- emy is uniquely positioned to provide a common framework and standardized terminology for project management. Training courses can serve as vehicles for ed- ucating the workforce about the organization’s policies, procedures, requirements, and definitions related to project management.
Alignment with corporate strategy. Corporate strategy defines the context in which projects succeed or fail. The project academy is responsible for ensuring that competencies and associated activities are consistent with corporate strategy, goals, and policies.
Alignment with external stakeholders. As with corporate strategy, the proj- ect academy is responsible for understanding external stakeholder concerns and requirements (e.g., the standards or certification requirements of project manage- ment professional associations), and aligning competencies and associated activi- ties with them as necessary.
Promotion of continuous learning across the organization. By promoting learn- ing at all career stages, the project academy helps to create a community of prac- titioners who are reflective and understand the importance of learning in project success.
Promotion of institutional knowledge. As with continuous learning, the proj- ect academy plays an important role in building institutional knowledge that en- ables the organization to thrive as projects emerge and retire. Through knowledge sharing activities that bring the organization together, the project academy plays a vital role in ensuring that lessons learned and best practices remain accessible.
Conclusion Creating a future for project management—as a profession and as an approach to ef- fectively delivering corporate strategy—demands capability that goes beyond mini- mum standards for competence. To meet this challenge, a number of corporations are taking direct responsibility for developing sufficient people with the right set of skills, experience, and behaviors to cope with the management of complex projects. Development of higher-order expertise, which is required to manage more complex projects, requires opportunities to gain relevant experience. This is supported by the meta- or overarching competencies required to support critical reflection and the ability to learn effectively from that experience. While some organizations are partnering with academic institutions to provide education that will support the development of the required meta-competencies, few are investing in the difficult
96
Aspects of complexity: mAnAging projects in A complex World
but vital and rewarding challenge of providing structured work-based experiences, supported by mentoring and coaching, to fast-track development of the talent they need to manage their portfolios of projects and programs.
References P87, line 15. Cicmil, S. J. K., Cooke-Davies, T. J., Crawford, L. H., & Richardson,
K. A. (2009). Exploring the complexity of projects: Implications of complexity theory for project management practice. Newtown Square, PA: Project Manage- ment Institute.
P87, line 21. Crawford, L. H., Hobbs, J. B., & Turner, J. R. (2005). Project categoriza- tion systems: Aligning capability with strategy for better results. Newtown Square, PA: Project Management Institute.
P87, line 24. Pitsis, T., Clegg, S., Marosszeky, M., & Rura-Polley, T. (2006). Making the future perfect: Constructing the Olympic dream. In D. Hodgson & S. Cic- mil (Eds.), Making projects critical (pp. 265-293). London, England: Palgrave.
P87, line 26. Atkinson, R. W. (1999). Project management: Cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. International Journal of Project Management, 17(6), 337–342. and Atkinson, R. W., Crawford, L. H., & Ward, S. (2006). Fundamental uncertainties in projects and the scope of project management. International Journal of Project Manage- ment, 24(8), 687–698.
P87, line 29; P88, line 2. Snowdon, D. (2002). Complex acts of knowing: Paradox and descriptive self-awareness. Journal of Knowledge Management, 6(2), 100–111.
P88, lines 13, 18. Crawford, L. H., Morris, P. W. G., Thomas, J., & Winter, M. C. (2006). Practitioner development: From trained technicians to reflective practi- tioners. International Journal of Project Management, 24(8), 722–733.
P88, line 15. Herzberg, F. (1968). One more time: How do you motivate employees? Harvard Business Review, 46(1), 53–62.
P88, line 18. Winter, M. C., Smith, C., Morris, P. W. G., & Cicmil, S. J. K. (2006a). Directions for future research in project management: The main findings of a UK government-funded research network. International Journal of Project Management, 24(8), 638 –649.
P88, line 31; P91, Figure 7-2. Eraut, M. (1994). Developing professional knowledge and competence. London, England: The Falmer Press.
P88, line 40. Winter, M. C., Smith, C., Morris, P. W. G., & Cicmil, S. (2006b). Di- rections for future research in project management: The main findings of the EPSRC Research Network. International Journal of Project Management, 24(8), 638.
P89, line 9. Robotham, D., & Jubb, R. (1996). Competences: Measuring the immea- surable. Management Development Review, 9(5), 25–29.
P89, line 10. Brown, R. B. (1993). Meta-competence: A recipe for reframing the com- petence debate. Personnel Review, 22(6), 25–36.
P89, line 11. Delbridge, A. (1985). The Macquarie dictionary (Rev. ed.). Dee Why, NSW: Macquarie Library Pty Ltd., p. 1651.
P89, lines 12, 13. Woodruffe, C. (1992). What is meant by a competency? In R. Boam & P. Sparrow (Eds.), Designing and achieving competency (pp. 16–30). London, England: McGraw-Hill Book Company.
97
Beyond competence: developing mAnAgers of complex projects
P89, line 15. McClelland, D. C. (1973). Testing for competence rather than for intel- ligence. American Psychologist, 28, 1 –14.
P89, lines 16, 27. Boyatzis, R. E. (1982). The competent manager: A model for effec- tive performance. New York, NY: John Wiley and Sons.
P89, line 20. Spencer, L. M. J., & Spencer, S. M. (1993). Competence at work: Models for superior performance (1st ed.). New York, NY: John Wiley & Sons, Inc., p. 9.
P89, lines 27, 29. Schroder, H. M. (1989). Managerial competence: The key to excel- lence. Dubuque, IA: Kendall Hunt.
P89, line 43. Gonczi, A., Hager, P., & Athanasou, J. (1993). The development of com- petency-based assessment strategies for the professions. Canberra, Australia: Australian Government Publishing Service.
P90, line 2. National Training Board. (1991). National Competency Standards Pol- icy & Guidelines. Canberra, Australia: National Training Board, p. 30.
P90, line 4. Cheng, M-I, Dainty, A. R. J., & Moore, D. R. (2003). The differing faces of managerial competency in Britain and America. Journal of Management De- velopment, 22(6), 527–537.
P90, lines 5, 6. Heywood, L., Gonczi, A., & Hager, P. A. (1992). Guide to develop- ment of competency standards for professions. Canberra, Australia: Australian Government Publishing Service.
P90, line 14. International Project Management Association. (2006). ICB-IPMA Competence Baseline Version 3.0. Nijkerk, The Netherlands: International Project Management Association.
P90, Figure 7-1. Crawford, L. H. (2005). Senior management perceptions of project management competence. International Journal of Project Management , 23(1), 7–16.
P91, lines 6, 13, Figure 7-2. Dreyfus, S. E., & Dreyfus, H. L. (1980). A five-stage model of themental activities involved in directed skill acquisition. Berkeley, CA: Operations Center, University of California, Berkeley for the Air Force Of- fice of Scientific Research (AFSC), USAF. and Dreyfus, H. L., & Dreyfus, S. E. (1986). Mind over machine: The power of human intuition and expertise in the era of the computer. New York, NY: The Free Press.
P91, line 12. Cheetham, G., & Chivers, G. (2005). Professions, competence and in- formal learning. Cheltenham, UK: Edward Elgar Publishing.
P91, line 16. Schön, D. A. (1983). The reflective practitioner: How professionals think in action. Aldershot, UK: Ashgate Publishing Ltd.
P91, line 17; P92, line 1. Cheetham, G., & Chivers, G. (1998). The reflective (and competent) practitioner: A model of professional competence which seeks to harmonise the reflective practitioner and competence-based approaches. Jour- nal of European Industrial Training, 22(7):267–276.
P91, line 24; P92, line 6. Brown, R. B., & McCartney, S. (1995). Competence is not enough: Meta-competence and accounting education. Accounting Education, 4(1), 47.
P92, lines 12, 17; P93, line 8. Dewey, J. (1963). Experience and education: The Kappa Delta Pi lecture series. London, England: Collier Macmillan Publishers.
P92, line 21. Brookfield, S. D. (1986). Understanding and facilitating adult learning. San Francisco, CA: Jossey-Bass Publishers. and Miller, N., & Boud, D. (1996). Animating learning from experience. In D. Boud & N. Miller (Eds.), Working with experience (pp. 3–13). London, England: Routledge.
98
Aspects of complexity: mAnAging projects in A complex World
P92, lines 28, 33. Turner, J. R., Keegan, A., & Crawford, L. H. (2000). Learning by ex- perience in the project-based organisation. Proceedings of PMI Research Con- ference (pp. 445–456), Paris, France. Sylva, NC: Project Management Institute.
P92, line 42. Bernstein, A. (1998, June 22). We want you to stay: Really. Business Week, p. 67. and Branch, S. (2010, November 9). You hired ‘em, but can you keep ‘em? Fortune.
P93, line 1. Lo Presti, A. (2009). Snakes and ladders: Stressing the role of meta- competencies for post-modern careers. International Journal for Educational and Vocational Guidance, 9(2), 125.
P93, line 2. Kunreuther, F., Kim, H., & Rodriguez, R. (2009). Working across genera- tions. San Francisco, CA: Jossey-Bass.
P93, line 22. Meister, Jeanne C. (1998). Ten steps to creating a corporate university. Training & Development, 52(11), 38.
P93, line 25. Meister, J. C. (2006). Corporate universities: What works and what doesn’t. Chief Learning Officer, 5(3), 28-70.
Part 2
With Researchers and Students in Mind
101
Chapter 8
Human Behavior and Complexity Terry Cooke-Davies
Why Human Behavior Matters Human behavior, as mentioned in Chapter 1, is potentially both a significant source of complexity in projects, and an effective antidote to it.
Perhaps this is intuitively obvious, since both specific research studies and more general reviews of the research literature demonstrate or assert the primary significance of managing people effectively in delivering successful project results. Indeed, on the basis of more than two decades of research, teaching, and consulting, Dennis Slevin and Jeffrey Pinto asserted, “Project managers who take the time to perfect their skills in the critical areas [of leadership, motivation, communications skills, team building and so forth] continue to demonstrate that successful project management depends first and foremost on our ability to effectively manage the human resources for which we have been made responsible.”
More recently, a research project led by Dr. Svetlana Cicmil and partially funded by Project Management Institute investigated the implications of complexity the- ory for project management practice. Cicmil et al. concluded that project managers deal with project complexity by utilizing standard project management tools and techniques in combination with a set of alternative skills and competencies that are not codified or captured in the conventional recommendations of good practice.
These skills and competencies, however, are notoriously difficult to hone, and there is considerable evidence that organizations in many industries that undertake complex projects are faced with a shortage of skilled people in both professional and craft categories. In Chapter 11, Lynn Crawford and Ed Hoffman share their insights on the development of skilled professionals, but this present chapter will pull to- gether research not only from within the sphere of project management literature, but further afield from the general management literature, from social psychology, and from the study of cognition in its various aspects.
Many of these skills and competencies are concerned with relationships be- tween either people or groups of people or different aspects of human behavior that arise from nonrational or irrational behavior that seems to be endemic to the human condition. Indeed, as scientific attention turns to a more accurate understanding of the internal world of human beings through advances in fields such as psychology
102
Aspects of complexity: mAnAging projects in A complex World
and neuroscience, a new basis of understanding is being developed in which the reflective leader can base his or her skills and competencies.
That is not to say that these advances open up completely new aspects of leader- ship. Projects have always been delivered by people working together and leading and motivating them to align their efforts behind the project goal has always been an important task for the project manager. But such is the pace of these develop- ments coupled with the increase in what could be called the “human and cultural dimension” of many complex projects. An effective project manager of today must master these “soft” skills, and have profound insight into their own cognitive pro- cesses, as well as recognize how this plays into their leadership of the people who they are leading.
If human behavior is indeed pivotal in the unfolding of complex projects, then we cannot afford to ignore what has been discovered about humankind in the course of the past decades. As the headline of a review of one of Howard Gardner’s books in The Economist once put it, “Might the proper study of management be man”?
For projects, perhaps, the right place to start investigating the “behavior of (hu) mankind” is at that place where projects become concretized in contractual rela- tionships—in relationships on projects.
Relationships on Projects The study by Cicmil et al. observed that “An effective project manager is a partici- pant in … process of relating, continuously engaged in emergent enquiry into what they are doing and what steps they should take next and reflexive in thinking about the quality of their own participation in complex processes of relating in their local project situation.”
Apart from the general run of daily interpersonal relationships, projects involve certain formal power-relationships that crucially contribute to the context within which behavior is played out on projects. Perhaps the most salient of these is the relationship between the “buyer” of the output of a project and the “seller” who manages the resources necessary to deliver that output. An international study of communications between the buyer’s project sponsor and the seller’s project man- ager in 100 IT projects provides some interesting insights into the gap between good practice and general practice in this particular aspect of behavior. The study dem- onstrates that project performance is greatest when there is a high degree of col- laboration between the buyer and seller, and the sponsor and project manager work together in partnership, with the project manager empowered to take appropriate decisions. The study also demonstrates, however, as has been shown in numerous other research studies, that such behavior is not commonplace. There is a critical need on even the most straightforward projects for alignment of interests between principal and agent, for the use of both structure and informality in communica- tions, and for the provision of trustworthy quantitative data for analysis where re- quired by the principal.
With more complex projects, the potential for difficulties arising from relation- ships becomes even more problematic, with multiple layers of hierarchy involved in some version of a principal-agent relationship, as illustrated in Figure 8-1.
103
HumAn BeHAvior And complexity
The illustration is taken from a paper discussion of two specific kinds of unde- sirable behavior—delusion and deception—that combine to result in projects that are “over budget, over time, over and over again.” These two sets of behaviors and the problems that they cause on complex projects will be considered in more detail. However, before leaving the problem of managing relationships, it is as well to deal with a specific behavioral aspect of relationships—the question of “identity” or, in its most extreme expression, “tribalism.”
People seem to like to belong to groups, whether they are rotary clubs, church congregations, Girl Scout troops, supporters’ associations. The reasons for joining these groups are many and varied, and indeed, may be inadvertent or resisted. How many people want to become asylum seekers, or a persecuted minority? However, once one “belongs” to a group, a human tendency seems to lead us all to distinguish between the “in-group” to which we belong and the “out-group” to which we do not belong. In his book, Irrationality, Stuart Sutherland observed that, “if the member [of a group]’s attitudes are biased in one direction, simply by interacting together their attitudes become even more biased in the same direction.” In other words, any differences of attitude between specific groups that are party to a particular project are likely to harden as the project progresses. This tendency for the attitudes of a defined group to become extreme has been named by Irvin Janis as “Groupthink” (after its use in George Orwell’s influential novel 1984). Although there is some evidence in recent years that more is at stake in group dynamics than Janis claims, managers of complex projects can expect the attitudes, norms, and behavior of dif- ferent parties to the project to call for high levels of expertise in managing inter- group relationships.
Taxpayers (Principal Tier 1, Principal Tier 2)
State Government (Agent Tier 1, Principal Tier 2)
Local Government (Agent Tier 2, Principal Tier 3)
Analysts and Planners (Agent Tier 3)
Contractors (Agent Tier 3)
Tier 3
Tier 2
Tier 1
Figure 8-1: Complex principal—agent relationships in large-scale infrastructure projects
104
Aspects of complexity: mAnAging projects in A complex World
But what of these attitudes, norms, and behaviors?
Understanding Human Behavior In 2002, one of two people who shared the Nobel Prize for Economics was a Prince- ton University professor of psychology named Daniel Kahneman. He was awarded this honor for having integrated insights from psychological research into eco- nomic science, especially concerning human judgment and decision making under uncertainty. The official press release for the prize states that, “Kahneman’s main findings concern decision-making under uncertainty, where he has demonstrated how human decisions may systematically depart from those predicted by standard economic theory. Together with Amos Tversky (deceased in 1996), he has formu- lated prospect theory as an alternative, that better accounts for observed behavior. Kahneman also discovered how human judgment may take heuristic shortcuts that systematically depart from basic principles of probability. His work has inspired a new generation of researchers in economics and finance to enrich economic theory using insights from cognitive psychology into intrinsic human motivation.”
With these words, the world of economics recognized that when it comes to making economic decisions, such as happens frequently in the world of complex projects, human behavior is not always rational. Kahneman and Tversky demon- strated through an impressive body of experimental evidence, that a person’s at- titude to risk depends on the “frame” through which the risk is viewed. People are more willing to entertain risk in order to avoid “loss” than they are in order to increase what they already stood to “gain.”
Examining the same phenomenon through the lens of the emerging discipline of “neuroeconomics,” Benedetto de Martino and his colleagues at University Col- lege London gave experimental subjects a decision task to perform while they were in a functional magnetic resonance imaging (fMRI) scanner. They demonstrated not only that the results of the experiment were entirely consistent with prospect theory, but also that different parts of the subjects’ brains were involved depending upon which of the two decision frames they were presented with. A particular re- gion of the brain known as the orbital and medial prefrontal cortex (OMPFC), which is known to mediate emotional responses, showed activity that rose in correlation with a subject’s propensity to be susceptible to the particular frame in which their decision was taken. This led the researchers to speculate that, “that more ‘rational‘ individuals have a better and more refined representation of their own emotional biases that enables them to modify their behavior in appropriate circumstances, as for example when such biases might lead to suboptimal decisions. As such, our findings support a model in which the OMPFC evaluates and integrates emotional and cognitive information, thus underpinning more “rational” (i.e., description- invariant) behavior.”
For project managers leading major complex projects, this has at least four im- plications: (1) there is a psychological aspect to the management of risk that needs to be considered along with all quantitative and qualitative risk assessment tech- niques; (2) if human beings are irrational about risk, then there may well be other aspects of human behavior that are not rational; (3) if the degree of “irrationality” exhibited in decision making is related to how individuals integrate emotions into
105
HumAn BeHAvior And complexity
their decision-making processes (of which more later) then “emotional intelligence” is particularly important to the managers of complex projects; and (4) if the “frame of reference” through which a risk is viewed fundamentally influences someone’s willingness to take risks, then the “frame” through which someone views other aspects of a project might influence other aspects of their behavior.
In the remainder of this section, different insights from social psychology and its related disciplines will be explored, before moving on to consider the importance of “frames” or “viewpoints” when understanding context.
Quirks of Thinking
In 2003, in an article in the Harvard Business Review titled “Delusions of Suc- cess,” Daniel Kahneman and Don Lavallo stated “in planning major initiatives, executives routinely exaggerate the benefits and discount the costs, setting them- selves up for failure.” In this article the authors of the paper cited three main causes for this failure: “optimism bias” reinforced by “attribution errors” and the “illusion of control,” anchoring and competitor neglect.
Each of these factors highlights a different aspect of human nonrationality of which the manager of a complex project needs to be aware, both with regard to his or her own mental processing, and to that of project team members. There is, of course, a thriving industry of self-help books and training courses led by charis- matic figures all of which could be characterized as popular psychology, or “pop- psych.” It is an industry that has dealt superficially and/or pragmatically in “how to” tips for getting by in the face of these and other idiosyncrasies of human behav- ior. For the aspiring manager of complex projects, however, the skills and competen- cies must go much deeper. Research in the field of social psychology has identified many “quirks” of human nature that belie the rational nature of human behavior that has been assumed not only by economists (as has already been seen), but also by project management practitioners and the developers of project management tools and techniques (See Chapter 1).
There are few people who have not at some time or other experienced in their own lives, the drive toward irrational behavior or faulty reasoning, when under the influence of strong emotion. Love, euphoria, frustration, envy, or anger (to name but a few) can lead us astray from the paths of reason and rational thinking. Strong emotions bring about physical changes to the human body, such as increased heart rate, raised blood pressure, or a dry mouth, but they also make us see the world in a distorted way. The well-known Victorian fable by Robert Louis Stevenson, Dr. Je- kyll and Mr. Hyde, pushes this notion to extremes. However, the general truth that emotion leads to both a loss of control and a greater propensity to irrational and an- tisocial thinking has been clearly demonstrated in a most dramatic way by examin- ing the decisions about “safe sex” taken by teenage boys when in a state of arousal.
For example, in a series of imaginative experiments, male students at Uni- versity of California at Berkeley were asked to predict how they would react to a range of propositions involving sexual activities when aroused. They first an- swered these questions in their normal state, and then, with the aid of graphic stimulation, answered similar questions while in a state of arousal. The results were dramatic. The students in their rational state proved themselves quite inca-
106
Aspects of complexity: mAnAging projects in A complex World
pable of predicting just how they would react when in a state of arousal. In every case, when aroused, the students predicted that their willingness to engage in a variety of slightly unusual sexual activities would be nearly twice as high (72%) they had predicted when they were “cold.” Of particular interest in the context of managing projects was the result of five questions about whether or not they were willing to indulge in immoral activities: When they were aroused, they predicted their propensity to be more than twice as high (136%) than they had predicted in their cold state (Ariely, 2008, p. 96).
As Ariely said “Every one of us, regardless of how ‘good’ we are, underpredicts the effect of passion on behaviour.” And passion, of course, includes emotions such as anger, frustration, or elation just as it does sexual arousal.
As cognitive neuroscience starts to supplement the results of experimental psy- chology with the observed activity of the brain obtained from PET scans and fMRI images, a picture emerges of the way that emotions and other brain functions that are not accessible to human consciousness combine with reason to motivate and direct all human decisions and behavior. For example, Paul Wason’s experiments in the 1960s on “confirmatory reasoning” revealed the human tendency to look for and select evidence that supports a particular hypothesis, rather than that which contradicts it. As has already been seen in the case of prospect theory within the past decade or two, neuroscientists such as Antonio Damasio and Antoine Bechara have demonstrated the intense activity of those parts of the brain that process, con- trol, and integrate emotions while purely rational decision-making tasks are being undertaken. It appears that our apparently “rational” activity of decision making is actually strongly influenced by emotional activity that introduces a whole series of biases into the process.
This isn’t to deny the strong impulse that people feel to base their decisions on rational grounds, rather it is to emphasize that much of the processing that is tak- ing place in our brains is happening beneath the surface of our conscious minds— like much of an iceberg lies beneath the surface of the sea in which it is floating.
As a result of this part-conscious and part-preconscious processing, we are all prone to a number of errors in terms of our decision making, for example: seeing patterns and meaning in data that is actually random; drawing unsupported con- clusions from incomplete and inconclusive data; seeing what we expect to see when the data is actually ambiguous or inconsistent; seeing what we want to see (along the lines of Wason’s experiments) and expressing “optimism bias”; and being hard to persuade to change our views or beliefs.
Each of these five habits is well attested in research, and a brief description of each is appropriate.
Seeing Patterns and Meaning in Data That is Actually Random When people look at the moon with the naked eye, they can see patterns that make up the face of the “man in the moon” and when looking at Mars through a telescope, it is possible to make out a series of “canals.” Gamblers claim that they experience hot and cold streaks in random rolls of the dice and alter their bets accordingly.
107
HumAn BeHAvior And complexity
Of course, this isn’t all bad. The ability to spot patterns is highly beneficial to humankind in numerous ways. This ability can often lead to discovery and ad- vancement. However, coupled with this useful intuitive ability, we do not seem to possess the same intuitive understanding of numerical probability. In an elegant experiment, Kahneman and Tversky illustrated this lack of intuitive understand- ing with a simple experiment. Subjects were told that in a certain town there are two hospitals. The larger of the two has an obstetrics ward that has an average of 45 births per day while the smaller of the two averages only 15. Over a period of one year, roughly as many boys are born as girls. Subjects were asked which of the two hospitals would have more days on which 60% of the births are boys. Most of the subjects thought that there would be no difference. In fact, male births will be 60% of all births on about twice as many days in the small hospital as in the large one.
The same fallacy is at work when considering any sequence of random occur- rences in order to understand the “gamblers’ streak” problem. Consider, for exam- ple, the likelihood of all “heads” turning up when a coin is tossed, say, five times in a row. The likelihood of that happening is one chance in 32, since there are 32 possible combinations of heads or tails (one half multiplied by itself 5 times). There is exactly the same chance of the sequence being TTHHT, THTHT, or any other possible sequence of 5 results, even though intuitively people tend to regard the notable sequence of five consecutive heads (or tails) as less likely than any other.
On the other hand, if the sequence is changed to 10 tosses of the coin, there are 1,024 possible sequences, of which all heads is only one. This leads to the formula- tion of what is known to the general public as “the law of averages,” but which is referred to by statisticians as “the law of large numbers”—the larger the population, the more likely it is that the statistical average will be achieved.
This is perhaps related to another observation of the general limitations of hu- man cognition, which is the failure to appreciate the exponential nature of conse- quences involved in “positive feedback loops.” As was shown in Chapter 1, a failure to appreciate systemicity is cited as one of the major causes of complexity on proj- ects, and certain kinds of systemicity involve escalating consequences similar in kind to the deafening “feedback” heard when a microphone is placed in too close a proximity to a loudspeaker in an amplified circuit. Just as people have a tendency to see patterns where none exists, there is also a seeming incapability of recogniz- ing the presence of the alarming nature of geometric progression (of the kind that produces compound interest).
Try this simple “thought experiment:” imagine an ordinary sheet of paper, of the sort that you place into any office printer, say 8.5 x 11 inches, or A4. Imagine that you fold it in half, mid-way along the longer side, and then repeat this. Imagine yourself repeating the action 30 times more. Before reading on, try to estimate how thick the resulting folded stack of paper would be. You might estimate that it would be more than 10 meters thick, perhaps even more than 100 meters. But most people are totally shocked to learn that the resulting stack would in fact be nearly 400,000 kilometers thick. In the same way, the escalating impact of systemic imbalance is not intuitively obvious to most people working on projects.
108
Aspects of complexity: mAnAging projects in A complex World
None of this means that the managers of projects need to be qualified stat- isticians, but it does mean that when basing judgments on apparent patterns of occurrence, they need to exercise caution before deciding whether a particular phe- nomenon forms part of a pattern, or is a random happening.
Drawing Unsupported Conclusions from Incomplete and Inconclusive Data It is not only natural, but also laudable, to seek evidence that confirms something that we hold to be true. If, for example, a project manager believes a member of his or her team is a fast and effective worker, each time that team member works fast and effectively, or is told by a colleague about the work that has been done fast and effectively, the project manager will consider his or her belief to be well founded.
If we are to hold anything to be true, it is necessary that we can cite confir- matory evidence that it is, indeed, the case. Unfortunately, on their own, isolated instances and credible anecdotes are not sufficient to support the case conclusively. At best, such evidence only suggests that our belief may be true, which is a long way short of providing proof that it is a valid belief.
Let us call the admirable team member Albert. We should also recognize that the belief that Albert’s work rate is actually a belief about how fast and effectively Albert carries out his work in comparison with a control group, let’s say his team- mates. Now, in order to prove conclusively that the belief is grounded, it is necessary to note not only times (a) when Albert’s work is fast and effective, but also times (b) when Albert doesn’t work fast and effectively, (c) when other team members work fast and effectively, and (d) when other team members don’t work fast and effectively. The belief then turns out to be well founded if the proportion of Albert’s work that he does fast and effectively is greater than the proportion of the other team members’ work that they do fast and effectively. In effect, for many of us, our belief is based on an excessive reliance of data in only one out of four possible segments.
There is a great deal of literature about how well people evaluate the kind of information in assessing the presence or strength of relationships of which Albert’s work rate is simply an example. Gilovich reported on the basis of eight separate citations that although people sometimes perform such tasks accurately, there are as many or more occasions when they perform poorly. The problem appears to be an excessive reliance on data that confirms our beliefs (i.e., a and d) and, in many cases, simply the data (a) that positively confirms our pre-existing beliefs.
Paul Wason, for example, carried out extensive research during the 1960s to demonstrate that when people can choose what evidence they gather to support or refute their beliefs, they more often than not seek evidence that confirms their beliefs, rather than challenges them. Wason’s experiments, involving the choice of cards to turn over in order to prove whether a particular “rule” is or isn’t valid, are interesting in that it is not likely that the subjects will have any desire for the hypothesis to be true or to be untrue. Simply, there is a human tendency to seek evidence that confirms our hypotheses, rather than challenges them.
Seeing What We Expect To See When the Data Is Actually Ambiguous or Inconsistent There is a third “quirk” of thinking that, like the two prior ones described previ- ously, seems to be a function of human cognitive processing, rather than any willful
109
HumAn BeHAvior And complexity
or self-seeking activity. “Anchoring” is the name given to another well-researched phenomenon that demonstrates the mind’s unfailing tendency to “anchor” calcula- tions and estimates to some baseline that it has previously established. It has been suggested that the actual mechanism of anchoring is similar to the well-observed phenomenon of “imprinting” in the brains of birds and animals first described so convincingly by 1973 Nobel Laureate Konrad Lorenz. Whether or not this is so, what is indisputable is that once the idea of a particular number has been planted in a human mind, it will be taken as a reference point for subsequent calculations and estimates, regardless of whether or not there is any logical connection between the anchored number and the subsequent calculation. This has far-reaching conse- quences for anyone involved in “high-level” or “order of magnitude” estimates and, when coupled with optimism bias, suggests that underestimating costs or delivery dates is an almost innate human tendency against which one must be constantly on one’s guard.
Seeing What We Want To See Each of the three foregoing “quirks” contributed in some way to the “delusions of success” identified by Lovallo and Kahneman, but the particular cognitive error that received the greatest attention in their article was what they referred to as “op- timism bias.” They asked their readers to “consider a survey of 1 million students conducted by the College Board in the 1970s. When asked to rate themselves in comparison to their peers, 70% of the students said they were above average in lead- ership ability, while only 2% rated themselves below average. For athletic prowess, 60% saw themselves above the median, 6% below. When assessing their ability to get along with others, 60% of the students judged themselves to be in the top decile, and fully 25% considered themselves to be in the top 1%.” Other experiments also confirmed the tendency of people to be over-optimistic about their own ability to control events.
Resisting Learning In view of these quirks of thinking, it is hardly surprising that managers of complex projects find that they have a difficult time coping with the complexities of people’s behavior.
Indeed, the work of Lovallo, Kahneman, Tversky and others adds weight to the work of Chris Argyris and his colleagues during the 1980s and 1990s. Argyris concluded that “Professionals embody the learning dilemma: they are enthusiastic about continuous improvement—and often the biggest obstacle to its success.” Ar- gyris observed that executives strive to remain in unilateral control, to maximize “winning” and minimize “losing,” to suppress negative feelings and to be as “ra- tional” as possible. In view of this, they tend to use their intelligence to “reason de- fensively,” and as the prior discussion has shown, they have an extensive cognitive armory to provide them with whatever evidence they need to support their views “rationally.” This helps them to avoid the “doom loop” of bad feelings that threaten to engulf them once they stray too far from their comfort zone, and are confronted with the serious possibility of their own personal failure.
Argyris’ work points to another dimension of the human aspect of leading com- plex projects, one that has not been given its due weight in recent years—the con- text in which complex projects take place, especially the business context.
110
Aspects of complexity: mAnAging projects in A complex World
Attribution Errors Many of the quirks of thinking described result in well attested “attribution errors” that are acknowledged by psychologists and underpinned by rigorous research and that are not given the attention they deserve in project management formation or literature. These include:
• Self-serving bias: The tendency to take the credit for success, and blame ex- ternal factors for failure.
• Self-centered bias: The tendency for an individual contributor to take a dis- proportionate amount of credit for the outcome of group effort.
• Egocentricity bias: The tendency to exaggerate the importance of one’s role in past events.
• False consensus effect: The tendency to believe that most people share one’s opinions and values.
• Assumption of uniqueness: The tendency to overestimate one’s uniqueness. • Illusion of control: The tendency to exaggerate the degree of one’s control
over external events. • Hindsight bias: The tendency to retrospectively overestimate the probability
of past events occurring. • Self-righteous bias: The tendency to regard oneself as having higher moral
standards or greater moral consistency than others have. • In-group/out-group bias: The tendency to view members of the group to
which one belongs in a more positive light than members of groups of which one is not a member.
• Base-rate fallacy: The tendency to neglect population characteristics and prior probabilities when making probabilistic inferences.
• Conjunction fallacy: The tendency to regard the conjunction of two events as more probable than either of them occurring singly.
The Neurological Basis to Persistent Habits Not only are these habits ones that we are all prone to, but they stem from cognitive processes that are usually quite helpful in making sense of and participating in the everyday world around us. Without the ability to recognize patterns, for example, Fleming would not have discovered penicillin, Semmelweis would not have intro- duced the practice of antisepsis, and Darwin would not have drawn conclusions that led eventually to his theory of evolution by means of natural selection. It is the “unforeseen consequences” (to borrow a term from system dynamics) of human- kind’s habitual use of these abilities that persistently creates for us the difficulties of complexity and nonrational behavior that have been described in this chapter.
As cognitive neuroscience gains more ground in understanding the patterns of usage of energy in the brain (in the form of oxygen and blood sugars), there is also evidence emerging that responding in a habitual manner is actually the most en- ergy-efficient response for the brain to take to any particular situation with which we are confronted. The brain uses an inordinate proportion of the total energy pro- duced by our bodies (20% to 60%) relative to its proportion of our total body weight (~2%). In view of this, it is an entirely appropriate survival strategy for the brain to operate in general using the lowest possible amount of energy consistent with the
111
HumAn BeHAvior And complexity
task in hand. Higher order cognitive processing calls for unsustainable use of large amounts of energy, whereas habit or conditioned reflex uses much less.
It is hard to overstate the importance of these findings, although there is a great deal of research yet to be done before the precise linkage between the neuro- logical aspects of energy use and the cognitive aspects of human decision making and interpersonal behavior are well-understood. As a working hyothesis, Roth sug- gested that project managers should recognize that 90% of all tasks are likely to be performed by 1% of the neurons in the brain (reflexes and reflex-like responses) and 99% of the tasks are carried out by 10% of the neurons in the brain (more or less automized responses). Furthermore, the remaining 90% of the brain’s neurons are reserved for complex non-routine tasks such as dealing with novel cognitive, emotional, and motor problems, especially with respect to social interaction and communication.
Getting To the Truth of a Situation As has already been stated, in Delusions of Success, Lovallo and Kahneman blamed the kind of cognitive errors that have been explored so far in this chapter under “quirks of thinking” for the failure of so many initiatives in business which, by extension, can be readily seen to add to the complexity of projects.
In responding to this article, however, Bent Flyvbjerg wrote to the Harvard Business Review stating that the research that he and his colleagues had carried out, while supporting the presence of “optimism bias” in large infrastructure proj- ects, suggested that what he called “strategic misrepresentation” (lying, to you or me) played a greater part in the failure of these complex projects to deliver their promises. Flyvbjerg wrote,
Lovallo and Kahneman underrate one source of bias in forecasting: the delib- erate ‘cooking’ of forecasts to get ventures started. My colleagues and I call this the Machiavelli factor. The authors mention the organizational pressures forecasters face to exaggerate potential business results. But adjusting fore- casts because of such pressures can hardly be called optimism or a fallacy; deliberate deception is a more accurate term. Consequently, Lovallo and Kah- neman’s analysis of the planning fallacy seems valid mainly when political pressures are insignificant. When organizational pressures are significant, both the causes and cures for rosy forecasts will be different from those de- scribed by the authors.
In our study of bias in cost and demand forecasting in capital-investment transport projects, my colleagues and I found strong evidence of heavy po- litical pressures on executives to make rosy forecasts and minor penalties for having made such forecasts. Indeed, during the 70 years covered by our study, forecasters consistently made errors of the same size and frequency, resulting in repeated cost overruns and demand failures.
This introduces perhaps the most sobering aspect of this chapter: the evidence that senior and responsible managers and government officials regularly practice “deliberate deception.” But perhaps we should not be so surprised. This chapter opened with the suggestion that the study of human behavior should lie at the heart
112
Aspects of complexity: mAnAging projects in A complex World
of project management studies, if we are to understand complexity in projects. If we are to take that seriously, then we should pay attention to the words of a professor of cognitive science and evolutionary psychology who wrote, “Deceit is the Cinderella of human nature; essential to our humanity, but disowned by its perpetrators at every turn. It is normal, natural and pervasive. It is not, as popular opinion would have it, reducible to mental illness or moral failure. Human society is a ‘network of lies and deceptions’ that would collapse under the weight of too much honesty. From the fairy tales our parents told us to the propaganda our governments feed us, human beings spend their lives surrounded by pretense.”
References P101, line 3. Lechler, T. (1998). When it comes to project management, it’s the peo-
ple that matter: An empirical analysis of project management in Germany. In F. Hartman, G. Jergeas, & J. Thomas (Eds.), Proceedings of IRNOP III. The Na- ture and Role of Projects in the Next 20 Years: Research Issues and Problems. University of Calgary, Calgary. and Strang, K. D. (2005). Examining effective and ineffective transformational project leadership. Team Performance Man- agement, 11(3/4), 68–103.
P101, lines 4, 11. Slevin, D. P., & Pinto, J. K. (2004). An overview of behavioral issues in project management. In P. W. G. Morris & J. K. Pinto (Eds.), The Wiley guide to managing projects (pp. 67–85). Hoboken, NJ: John Wiley and Sons.
P101, line 14; P102, lines 20, 24. Cicmil, S., Cooke-Davies, T., Crawford, L., & Rich- ardson, K. (2009). On the complexity of projects: Exploring the implications of complexity theory for project management theory and practice. Newtown Square, PA: Project Management Institute.
P101, line 19. Zack, J. G. Jr. (2007). The greatest project risk of all. Cost Engineering, 49(5), 3–4.
P102, line 15. Might the proper study of management be the man? (2004, April 15). The Economist. Retrieved from http://www.economist.com/node/2592934?Story_ ID=2592934
P102, line 31. Turner, J. R., & Müller, R. (2004). Communication and co-operation on projects between the project owner as principal and the project manager as agent. European Management Journal, 22(3), 327–336.
P102, line 44; P103, line 3. Flyvbjerg, B., Garbuio, M