Project Management Institute

The Art of Project Management® and complexity

Abstract

In this presentation, we describe project management system requirements as well as tools and techniques useful in dealing with complex projects (e.g. chunk theory, RUP, Gareth's 15 percent rule, chaos theory, Rule of 5s, and fragmentation). The nature of geographical, cultural, organizational, social, and technically complex projects is discussed in the context of tools available to simplify them, reducing their risk, and improving their likelihood of success.

Global projects are becoming technically, organizationally, and culturally complex. In such complex systems, decentralization and simplicity are necessities without which the project could destroy itself. However, decentralization without a mission, organizational support, simple roles and responsibilities, and an appropriate project organization may end up producing results that are quite different than those originally intended. “Till now man has been up against nature, but from now on, he may be up against his own nature.” (Gabor, 1964 , p 161)

This presentation provides a practical application of complexity theory, describing how project system requirements and tools can be used to navigate today's cross-cultural, cross-organizational, highly technical, globally complex projects.

Introduction and Challenge

Project management is about people, people working together in joint participation and synchrony in order to achieve a goal. Over 25 years ago, in their landmark book, “In Search of Excellence,” Peters and Waterman (1982) observed that our problem is that our fascination with the tools of management frequently obscures our apparent ignorance of “the art” of management---in other words, management is about people and not about tools such as MSP, EVM, and so on. However, faced with competitive pressures in an increasingly global economy, and in rapidly changing and technically challenging environments, companies have no choice but to adopt flexible strategies and structures in order to speed improved quality products to market and provide better customer service. As a result, projects in the global economy are more complex than ever before. This complexity comes in various forms, including the following:

  • Technical complexity associated with science and technology's quest for creative and innovative solutions to mankind's challenges
  • Environmental complexity that involves societal, political, or religious impacts on projects
  • Organizational complexity introduced by multiple and fragmented communication channels across geographical regions, with contracted and/or partnering companies or departments
  • Social complexity involved with people working jointly while having cultural differences and/or different beliefs or values
  • Value relativism complexity that allows values to shift in a direction of preferred outcome
  • Wickedness, the characteristic of nonlinear problems such as those of IT and R&D, whereby, one does not know the outcome until it is found

At the “Houston International Project Management Best Practices Conference,” Gonzalez (2007) of NASA JSC's, Advanced Planning Office noted that, historically, the approach of project management is frequently characterized by the classic linear project life cycle, consisting of Initiation, Planning, Executing, Monitoring and Control, and Closeout in connecting the problem to its solution. But, “When we fish for absolutes in the seas of uncertainty, all we catch are doubts,”Dee Hock (1999) and this linear approach is not adequate to navigate many of today's complex projects. González advances challenges to the project management community and to educators:

  1. “When will the tools be available to assist the project manager in the navigation of complexity?”
  2. “When will the curriculum be available to educate future program managers in complexity theory?”

It would appear that, as managers and educators, we must consider the “nature of man” in preparing our people to manage tasks, projects, and programs in our increasingly complex world.

Decentralization is a Requirement, Not an Option, in a Complex Management System

Complexity theory tells us that in a complex system, because many autonomous variables exist, attempts to control the system centrally by manipulating a few selected variables is doomed to failure, and can lead it to become dysfunctional and to breakdown; therefore, in a complex environment, simply imposing answers is not a viable survival strategy. We must decentralize control instead (Lucas, 2007). In the last 15 years, there has been an unmistakable trend in international companies toward decentralized modes of operation (Johns, 1995). In this “project management method,” specialists from various functional areas across the organization work jointly in ad hoc project teams from inception to completion of projects for which they are wholly responsible. These project teams are empowered to act on behalf of their company as extensions of “the customer's need” for service or products. As such, the function of their company is to provide coaching, support, and strategic direction to the project teams that conduct the business and perform the work of the organization (Exhibit 1).

Cross-Organizational Project Teams

Exhibit 1--Cross-Organizational Project Teams

Complexity theory also tells us, however, that small changes may produce significant changes in the final results that could not be predicted by simply looking at the parts by themselves. At first glance, the swirling patterns of swallows flying together over the Vatican in Rome (Exhibit 2) would appear to have been carefully orchestrated to fly in these complex formations. We might also assume there must be a “head bird in charge” giving the others instructions. Research into the nature of flocking behavior, however, has shown that all that is required is for each bird to attempt to maintain a distance between itself and its neighbors and to fly in the general direction of its neighbor; in other words, in a decentralized complex system, simple rules can generate complex behaviors that seem to emerge out of nowhere. In a project or company without a vision and without a continuously reinforced mission statement, we may end up at project closeout in a place and with something other than originally intended.

A Decentralized System with No Vision (A Swarm of Swallows Over the Vatican)

Exhibit 2--A Decentralized System with No Vision (A Swarm of Swallows Over the Vatican)

Contrast the complex system of a flock of swallows moving aimlessly over the Vatican to the complex system of “army ants” in the Brazilian rain forest observed by Wilson (1978) to be building a bridge (Exhibit 3). Wilson's ants exhibit a system equally complex as that of the swallows over the Vatican; however, in contrast, the ants maintain a system of communicating a vision (direction) and maintain simple rules of operation throughout the colony. As a result, they demonstrate a collective intelligence and are capable of teamwork aimed at fulfilling the vision.

A Complex System of Army Ants Having Both a Vision and a System for Communicating the Vision

Exhibit 3--A Complex System of Army Ants Having Both a Vision and a System for Communicating the Vision

In a complex project management way of working, “a vision without a system is as bad as a system with no vision,” which repeats the message from Peters (1987) who said “a passion without a system is as bad as a system without a passion.” Guidelines for such a system, as described by Morgan (2005), is to build a good enough “vision” and replace intricate (complex) strategic plans with a few short, simple statements that describe the general direction that the organization is pursuing and perhaps a few basic boundaries. An excellent example of such a vision/mission statement comes from a public document of BAE Systems, “Management of Project Charter,” which states:

  • Each project is to be run as a business
  • The project director is the project's “managing director,” with full support of the group and business unit senior management
  • Integrated Project Teams (IPTs) have fundamental responsibility for financial performance
  • Milestone and risk owners are named within the IPTs, and an attitude of “I own the problem; I represent the whole of BAE Systems” is fostered
  • Individual rewards are linked to one's “contribution” to the success of the project

The system of management for a project-based decentralized way of working described by Johns (1998) goes beyond and is more holistic than the project, program, and portfolio approach of the Project Management Institute's Organizational Project Management Maturity Model (OPM3) and includes additional human elements associated with the formation of cross-organizational teams, and emphasis on organizational support and governance. The decentralized system establishes a “state of nature” within the project, enabling the project to be “in control” through individual “ownership” by the project team members themselves. Bloom (1987, pp. 162-163) pointed out that such a system of “ownership,” first recognized by Thomas Hobbs in the 1700s, simply works better than centralized systems because it plays on a shared value common to “the nature of man” himself. The decentralized system is therefore “in self-control” guided by simple rules of operation and governance. We, as managers and educators, are wise to keep the management system as simple as possible.

According to “Chunk Theory,” (Miller, 1956), the memory span of young adults is around seven elements (seven for digits, six for letters, and five for words), called “chunks.” Some people like to refer to this as the “Rule of 5s,” based on the observation that the normal adult can retain no more than four to six things in active working memory at one time. This fact is based on how human memory works, referred to as one's phonological loop having the capacity to hold only approximately two seconds of sound. Therefore, two seconds is the duration of the English spoken form of seven +/- two digits (in Chinese it is around nine, and in Welsh around six). Thus “Chunk Theory” pertains to the maximum number of items that should occur in a given context. Extending this to educating project managers and team members, one would conclude that training strictly aligned to the knowledge areas as discussed in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)---Third edition (Project Management Institute [PMI], 2004) is 1) too challenging for the normal human to remember and 2) is linear in approach and ill suited for today's complex projects. It therefore may be wise to educate people regarding the functions of management using a simple, basic functional model of a manager's job such as that put forth by Drucker (1974), which has been used for years in training managers. Drucker's model does not neglect any management knowledge; rather, it organizes this knowledge into five basic management “chunks” or functions: 1) planning; 2) organizing and staffing, 3) directing and leading, 4) controlling, and 5) reporting. It follows that this model would be more practical and effective for training project managers in a complex environment (Exhibit 4).

Five Basic Functions That Constitute a Project Manager's Job (“Chunk Theory”)

Exhibit 4--Five Basic Functions That Constitute a Project Manager's Job (“Chunk Theory”)

Further, by consolidating detailed knowledge areas and topics, “planning” can be similarly simply expressed in terms of five basic management tools used by the project managers to create planning behaviors within their project team: 1) the project objectives, 2) the work breakdown structure [WBS], 3) the project organization, 4) the project schedule, and 5) the project performance baseline (or budget) (Exhibit 5). The goal achievement behaviors associated with these five tools are, respectively: 1) agreement within the project teams, with stakeholders, clients and managers, and team members; 2) accountability within the project team; 3) communications across the project team, with clients, stakeholders, and managers; and 4) “control” within and of the project overall. These five planning functions together---and frequently with a sixth, “risk”---constitute the most fundamental and basic elements of a “project execution plan,” which in turn is a manager's tool used to create planning behavior within the project team, with a department, and with a company/contractor/vendor/supplier. If a company were able to do only one thing to improve its return on investment, it would be to require that all project and task leaders, contractors, vendors, and suppliers develop a simple “project execution plan” consisting of these five tools and their associated goal achievement behaviors before work is permitted to begin. The detail of the plan should be the responsibility of the project team in the decentralized system and provides the basis of coaching and governance of management.

Five Basic Management Tools Used to Create Goal Achievement Planning Behaviors

Exhibit 5--Five Basic Management Tools Used to Create Goal Achievement Planning Behaviors

Simplifying Your Project and Program Organizational Complexity

An organization is complex when it is no longer possible at any moment to connect every element with every other element. The ability or inability for organizational entities to “connect” (interface) depends on both the number of entities and their diversity. The WBS is how the project work itself is organized. We must not make the mistake of assuming that the WBS is the system; rather, it enables the system to function efficiently or inefficiently. Management systems have a life beyond any structure we impose upon them (Hutchens, 2007). It follows that the project organization becomes complex when at any moment it is no longer possible for every task leader to interface with every other task leader or when sufficient differentiation exists within the different elements such that task leaders share little in common. Every organization has a split personality---i.e., the “legitimate” organization as described by the WBS and what Hutchens (2007) calls the “shadow system,” an unofficial system of activity, “water-cooler talk,” “unofficial” relationships and informal short cuts for getting things done. The following are some of the many possible ways in which a project can be categorically organized (broken down) and roles and responsibilities assigned:

  1. Components, or parts of the product
  2. Chronological, or sequential
  3. Functional disciplines
  4. Organizational units
  5. Geographical areas
  6. Cost accounts
  7. Configuration characteristics
  8. Deliverables
  9. Purpose or functions
  10. Subsystems of the product or project
  11. Schedule milestones
  12. Phases

For large complex systems involving numerous functional interfaces, the preferred organizational arrangements whereby the people and functional communication pathways “shadow” or “align” with one another are items 1 and 10 in the above list. For a large technically complex project (e.g., space station, an aircraft or major telecommunications system), alignment of the people and functional interfaces provides for greater accountability and ownership of the interfaces that constitute a dimension of technical complexity. Thus, in addition to the greater efficiency of communications gained by this alignment, there is greater likelihood of successful configuration control.

Fragmentation and Wicked Problems

Collective intelligence of a project team is enabled when team members socially share their cognition and collaborate. When team members begin to see themselves as more separate than united (e.g., when they believe that their solution is the correct one and that the others are “going the wrong way”) or when information and knowledge are chaotic and scattered, the project team may become “fragmented.” In this state, the information and knowledge of the team are chaotic and their perspectives, understanding, and intentions to collaborate are scattered. An enabler to fragmentation might be the way in which the project is organized, its size, and geographic distance, or it might be technically driven by its degree of “wickedness” (Conklin, 2006, pp. 1-12). In many of today's complex projects, we do not start by simply gathering and analyzing data about the project in a linear fashion (as in Exhibit 6A), because the project team does not have a pure and abstract understanding of the requirements. Rather, the team's understanding of the requirements evolves toward the end of the project. The natural process by which the project team's cognition and understanding evolves may frequently jump to what Conklin calls “an opportunity-driven understanding of the requirements” (Exhibit 6B) that is quite different than the linear generic project life cycle described in the PMBOK® Guide---Third edition (2004).

Linear Project Life Cycle (PMBOK®

Exhibit 6A--Linear Project Life Cycle (PMBOK®

Nonlinear Project Life Cycle of “Wicked” Projects Guide)

Exhibit 6B--Nonlinear Project Life Cycle of “Wicked” Projects Guide)

In these projects, defined by Rittlel and Webber (1973) as “wicked,” the project team does not understand the requirements until they have developed a solution and frequently the solution is not right or wrong; rather, a solution “is when the money runs out.” There are practiced ways of “taming” the wicked project---for example, freezing the requirements (as we know them), asserting that “the problem is solved,” “the solution is good enough,” “it's better than it was,” “it will just have to do,” or “we are just going to do it this way.” Complexity theory, however, proposes that although they are appealing in the short term, sometimes such approaches can exacerbate the problem. Approaches to the project life cycle such as Rational Unified Process (RUP) (Exhibit 7), developed by Jacobson, Booch, and Rumbaugh (1999), evolved from earlier spiral models in which the project requirements that develop with the team's improved understanding of the problem are proven to be more effective for complex, nonlinear, “wicked” projects (Exhibit 7).

Interative Rational Unified process (RUP)

Exhibit 7—Interative Rational Unified process (RUP)

Such approaches are geared toward complex projects and programs establishing a point between order and chaos at which there is enough chaos for novelty and creativity but also enough order for consistency and patterns to endure.

Aspects of Social Complexity Dimension

According to Conkin, social complexity is a property of the social network within the project and is a function of both the number of players and the diversity of methods by which they solve problems. In global projects, a dimension of a project team's diversity in approaching problems is in the difference among the team's members as influenced by their culture. A global project team's cultural diversity is driven by the differences in what they value. Therefore, cultural differences may be societal (those we normally associate with “culture” in global projects), organizational (as demonstrated in contractor, supplier, and vendor relationships), or personal (e.g., personal cognitive preferences, vis-a-vis intuitive versus sensing, etc. [Jung, 1971]) (Exhibit 8).

The Societal, Corporate, and Personal Values Existing in a Socially Complex Global Team

Exhibit 8--The Societal, Corporate, and Personal Values Existing in a Socially Complex Global Team

The dimensions of cultural diversity within global project teams can be numerous (Exhibit 9), and add to the complexity of the social network.

Dimensions of Cultural Difference in Global Project Team's Members (Trompenaars, 1997, p. 8)

Exhibit 9--Dimensions of Cultural Difference in Global Project Team's Members (Trompenaars, 1997, p. 8)

These dimensions can be grouped into three major categories that collectively define a team's approach to time, its environment, and how it deals with rules and relationships. The culturally driven difference in how team members treat rules (e.g., standard operating procedures) adds to diversity in the behaviors within the team, further contributing to the complexity of the social network. Education of global teams, albeit academic and/or through lessons learned, is helpful in improving team members' tolerance to these differences.

 

Value Relativism and its Effect on Complexity

An additional source of diversity in the social network lies in the fact that some values (or beliefs) possessed by team members may not remain constant and may be relative to the situation. Bloom points to this “value relativism” as a characteristic (nihilism) existing in all people, regardless of culture. In an organization, value relativism can result in power being substituted for ideology; expediency replacing ideological criteria; policy becoming impossible; continuity and consistency becoming nonexistent; and decision makers becoming immobilized. (1987, p. 243) Consider the following example of value relativism: What would you do if your boss were about to implement an idea that you feel is a bad one? You may answer one way initially. Now, how would you answer this same question if you were to learn that your boss had fired the last three people who did not agree with him or her? Your answer may be different now. The insidious nature of value relativism is that we truly believe in our new shifted position. It can be argued that value relativism was a contributing factor in the decision to proceed with the launch of the space shuttle the “Challenger” (NASA, 1986), and has likely contributed to many other unfortunate situations.

This may sound like a “Catch-22” situation in that value relativism tends to complicate the very decentralized system of management needed to simplify the system. Therefore, in order to enable the full potential of the decentralized project management system, one needs to design the systems with the following characteristics to mitigate the likelihood and impact of value relativism:

  • Develops project management skills in everyone
  • Works through cross-functional project teams
  • Conceives middle management as facilitators and coaches
  • Practices participative management and eliminates fear
  • Maintains few organizational layers
  • Maintains a client-minded organization
  • Maintains operational procedures support teams

Navigating Complexity Beyond Matrix, Beyond Decentralization

Will the organization of the future's most successful companies be functional, projectized, or matrix? Drucker (1988) pointed out that most successful companies of the next century would be those that learn how to take people from across their company to work in joint participation, in synchrony, and in harmony better than their competitors Perhaps this organization will resemble an orchestra or symphony. Because of complexity it will be necessary that greater responsibility and authority be placed in the hands of the people doing the work under the coordination and orchestration of the project manager. The role of the company then will become one of organizational support and governance acting as a “federal” communication center of the vision and progress (Exhibit 10) and linking the projects to the company's business strategy.

Beyond Matrix, Beyond Decentralization for Navigating Complexity

Exhibit 10--Beyond Matrix, Beyond Decentralization for Navigating Complexity

The organization that supports the decentralized project management system should possess enough flexibility and chaos for novelty and creativity, but also enough order to maintain consistency and patterns to avoid fragmentation. We began this paper by asserting that management is about people. In a complex world “the art of project management” is in the balance of tools and techniques with the “nature of man,”, or the “people side of things.” The project management system to navigate this complexity will include:

  • Giving direction (vision) without giving directives
  • Leading by providing organizational support
  • Maintaining a decentralized system with “self control”
  • Setting direction while not knowing the future
  • Creating a “large” organization while remaining “small”
  • Being both a system as well as independent parts

References

BAE Systems, (1999), Management of Project Charter, public document of BAE Systems,

Bloom, A. (1987). The Closing of the American Mind. New York: Simon and Schuster.

Conklin, J. (2006). Dialogue mapping: Building shared understanding of wicked problems. New York: Wiley.

Drucker, P. F. (1974). Management. New York: Harper & Row.

Drucker, P. (1988, Jan/Feb). The coming of the new organization. Harvard Business Review. Publication number (89606).

Gabor, D., (1964), Inventing the Future, New York, New York: Alfred A. Knopf.

González, S. (2007, February). Project management challenges in the next space era. 1st International-Houston Best Practices Conference, Houston.

Hock, D. (1999), Birth of the Chaordic Age, San Francisco, CA: Berrett-Koehler.

Hutchens, D. (2007). An introduction to organizational theory. Retrieved from http://www.davidhutchens.combizwriter/articles/complexity.html

Jacobson, I., Booch, G., & Rumbaugh, J. (1999), Unified software development process. Boston: Addison-Wesley Longman Publishing Co.

Johns, T. G. (1995). Managing the behavior of people working in teams. International Journal of Project Management, 13(1), 33-38.

Johns, T.G. (1998). On Creating Organizational Support of The Project Management Method. International Journal of Project Management,17(1), 47-53.

Jung, C. G. (1971). Psychological types (The Collected Works of C.G. Jung, Vol. 6). Princeton, NJ: Princeton University Press.

Lucas, C. (2007, March). Freedom beyond control. Retrieved from http://www.calresco.org/lucas/freedom.htm

Miller, G. A. (1956). The magical number seven, plus or minus two. The Psychological Review,63, 81-97.

Morgan, G. (2005). Build a ‘Good Enough’ Vision. An Introduction to Organizational Theory. Retrieved from http//ww.davidhutchens.com/bizwriter/articles/complexity.html

NASA. (1986). Report to the President: Actions to Implement the Recommendations of the Presidential Commission on the Space Shuttle Challenger Accident (PDF). Retrieved from http://history.nasa.gov/rogersrep/genindex.htm

Peters, T, (1987), Thriving on Chaos, Alfred A. Knopf, New York.

Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK® Guide-Third edition. Newtown Square, PA: Project Management Institute.

Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a general theory of planning. Amsterdam: Elsevier Publishing Company.

Trompenaars, F. (1997). Riding the waves of culture (Rev. ed.). London: The Economists Books.

Wilson, E. O. (1978). Army ants: A collective intelligence. American Scientist, 77, 138-145.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2008, Thomas G. Johns, PhD, PE, PMP, MAPM
Originally published as a part of 2008 PMI Global Congress Proceedings – Denver, Colorado, USA

Advertisement

Advertisement

Related Content

Advertisement