Successful projects are a critical part of our work environment, and we have learned much in recent years about establishing clear objectives and managing deliverables, quality, costs and schedules. Linear planning has given us some useful approaches but we are now faced with more difficult challenges as both the complexity of the outcomes and the number of partnerships continues to increase.
Complex projects often do not achieve the success that we want in the time frames we plan. Organizational or IT change projects that involve multiple organizations and stakeholders are often more complex than we expect them to be. Those projects seem to take on a life of their own, frustrating those trying to “leverage” success. By a “complex” project, I mean one where independent agents are interacting with each other in a variety of ways (Waldrop. 1992, p. 11). This is more than producing a widget. Such projects often involve new information management and personal or cultural change. The establishing of a centralized financial system with new business processes, the development of electronic service delivery between government and business or real community economic and social development are all complex projects.
For example, Starfield Consulting’s recent review of electronic collaboration options for government service delivery stated it this way:
“Given these new levels of access and expectations, effective service provision requires partnerships and alliances that span the new service domains. No one enterprise can do it all and keep up with the changes. Partnerships and alliances that provide such services are necessarily complex, often involving multiple providers, stakeholders and clients, sometimes across the whole domain, in order to develop and sustain effective responses. Given the pace of change they must also be agile and adaptive.” (Peterson. 2001, p. 1)
One effort to clarify such change projects was the development of “re-engineering” by Hammer and Champy. When they recanted a few years later, they recognized that most re-engineering projects had failed to achieve their main objectives largely due to “people” issues. Most project teams and managers that I have encountered, however, still rely primarily on the best of linear planning and engineering to try to “manage” the change. This is largely because the linear paradigm has served us well for developing materials or products. Many are still trying to articulate and improve on that approach.
When projects get stuck or it becomes clear that the current approach will not produce the intended results there is a tendency to adjust by narrowing the scope or redefining success. In a complex project it is often impossible to know how much time it will really take or how much it will really cost to get it done. As the project grows, one then gets a better sense of what can be done, by when. If this does not fit the expectations of the sponsors or the contract for deliverables, then the negotiations (or deceptions) begin. Either the scope has to be narrowed or what constitutes success rethought.
Sometimes this is accompanied by finding someone to blame. Project sponsors or managers would prefer not to blame themselves, so they often blame the people who were supposed to carry out or implement the changes associated with the project. For example, I have heard “the existing group did not have the new capabilities required by the software or could not change or learn fast enough” or that “the planning team did not really understand what they were asking for in the Request for Proposal, so how could the developer actually build it in the time required.”
The linear planning process is very useful for some aspects of projects. This is especially true for building a physical unit from component parts where the task is straight forward. Many engineering tasks can be successful in this way. However, the same linear planning process does not work well when “people” have to change their thinking or behavior in order to achieve success or when communities of organizations must collaborate to reach the project goals.
Thomas Kuhn developed the concept of “paradigm” in relation to changes in scientific research and learning. (Kuhn, 1970) He saw “scientific paradigm” as a set of practices or as an exemplar that leads to certain results. If you follow a certain paradigm’s steps, then you will get certain results. This is a different meaning for the term than what has often been emphasized. It is about practice or processes that create theory, not the worldview itself (Wilbur. 2002). A shift in paradigm or a transformation is required when you no longer regularly get the results that you expect from the processes you are using. Discovering that the Newtonian physics paradigm would not lead to accurate description of quantum phenomena was part of the development of a new paradigm.
The motivation for the next paradigm for project “management” is emerging from practices that do not give us the results we expect. We have learned much from strategic planning and scientific project management. Becoming clearer about the quality of the outcomes we seek, our assumptions about the context, the costs involved, the steps in our strategy or how we will measure success are critical skills. Identifying problems and finding solutions seems logical, given our worldviews. We now require another perspective and a shift in our set of practices to better understand and lead complex projects.
A real paradigm shift or a transformative change transcends and includes the previous paradigm or worldview. To shift toward more effective projects or organizations requires new perspectives on how human systems work. We now know that human organizations are not mechanical systems even though they have some mechanical components. The mechanical or physical components sometimes provide the spine or the frameworks that support the living system or organism. The next paradigm for successful projects incorporates recent learning on projects as complex adaptive systems.
This article continues in Part 2:- \”Living Projects – Complex Adaptive and Living Systems\”
Larry Peterson can be contacted by email at larry@spiritedorg.com or you can read more of his articles at http://www.spiritedorg.com/
Bibliography
Cooperrider, Sorensen, Yaeger & Witney. 2001. Appreciative Inquiry: An Emerging Direction for Organizational Development. Stipes Publishing.
Johnson, Steven. 2001. Emergence. Scribner. New York.
Kauffman, Stuart. 1995 At Home in the Universe. New York. Oxford University Press.
Kuhn, Thomas. 1970. The Structure of Scientific Revolutions, 2nd Edition. Chicago: University of Chicago Press,
Magruder Watkins & Mohr. 2001. Appreciative Inquiry. Jossey-Bass/Pfeiffer.
Owen, Harrison. 1997. Open Space Technology: A User’s Guide. Berrett-Koehler Publishers, San Francisco.
Owen, Harrison. 2004. The Practice of Peace. Human Systems Dynamics Institute.
Peterson, Panchyshyn & King. 2001. eCollaboration in Complex Communities. Starfield Consulting. 2001.
Von Bertalanfy, Ludwig. 1968. General Systems Theory. Braziller. New York
Waldrop, M. Mitchell. 1992. Complexity. New York. Simon & Shuster
Wilbur, Ken. 2002. “Kosmos Trilogy”. Unpublished.
Larry, we are so often trying to squeeze square projects into round holes that this approach of treating projects as living, evolving systems is so refreshing (although, I know, not new). Looking forward to the next part of this article.
Pingback: My Project is Alive