"The prevailing traditional project management paradigm is, at best, struggling to deliver to the increasing expectations of business and government clients. At worst, it has become increasingly focused inward on certification, bureaucracy, and formal complexity."

Nothing New Under the Sun

Talk all you want about "agility," but there's no escaping the PM triangle of scope, resources, and time. Project management is nothing more than ensuring stated requirements are delivered on time and on budget.

New Models for New Projects

Perfectly delivered projects are pointless if they don't deliver the business outcomes. Today's projects require new methods that can foster collaboration, innovation, and, most of all, responsiveness to change.

Opening Statement

In his landmark 1962 book, The Structure of Scientific Revolutions,¹ Thomas Kuhn argues that when a new worldview or paradigm emerges, a predictable series of stages are evident as the new paradigm becomes the dominant one. These stages are:

• Prescience. New ideas are developed without a coherent and integrated framework.
  
  
• Normal science. The integrating framework is enhanced by research, practice, and challenges, often seen as errors and mistakes by the dominant paradigm.
  
  
• Crisis. The emerging paradigm becomes dominant over the prevailing paradigm.
  
  

A similar progression has been occurring in the case of agile project management. As Cutter Senior Consultant and agile pioneer Alistair Cockburn notes in his article in this issue, many of the key artifacts, practices, and behaviors of agile project managers and agile developers have been known for over 20 years. For example, in my first book, People and Project Management (published in 1980 and now out of print), I argued that project management was about people and relationships, not technical process. Lean manufacturing, the Toyota Way, virtual organization structures, and flat organizations have been "common" knowledge since the 1980s.

Just as Kuhn's theory would have it, these disparate ideas were often developed in isolation (within a specific domain such as manufacturing practice or organization theory, for example), but they have now become an integrated, consistent, and proven worldview. The agile movement and its associated components -- agile governance, agile project management, and agile development -- are bound by four key threads that are common to all the articles in this issue. These threads are:

1. Change. Change in projects is normal and must be managed in a light and agile manner.

2. Culture. Openness, honesty, trust, and courage are the values that agile project sponsors, managers, and developers adopt.

3. Contingency. The mix of methodology and tools is flexible and reflects the risk of the project and the business drivers.

4. Concepts. Agile practitioners embrace collaborative project management and development approaches such as Scrum, XP, collaborative planning tools, wikis, and so on.

If there is a single and unifying theme in all the articles in this issue, it is that the prevailing traditional project management paradigm is, at best, struggling to deliver to the increasing expectations of business and government clients. At worst, it has become increasingly focused inward on certification, bureaucracy, and formal complexity.

In many ways, the sequence and content of the articles in this issue reflect the evolutionary nature of the emergence of the agile model. Bonnie Cooper's wonderful story of her project management office's "midlife crisis" highlights a struggle I have observed in every PMO I have worked with when implementing agile project management. She acknowledges that in the beginning (like so many project managers), she assumed that by focusing on process and tools such as Microsoft Project she would be able to add value to her organization. However, she eventually began to see that her focus on formal process had left her "out of sync" with her organization as it dealt with the challenges of change that all organizations are facing. She undertook a journey to "deemphasize process" and move to relationships focused on business value.

I feel that Cooper's (and many agile experts') focus on process as one of the failures of traditional project management tends to miss the point that it is the "heaviness" of traditional project management processes that is the issue rather than the need for process itself. All models have processes; however, these can be "lighter" and more flexible. Indeed, I have argued that just as average athletes can build upon basic skills to become elite athletes, so must users of agile models build upon the basic processes to achieve an expert level of process excellence. In effect, agile is about knowing which processes not to use.

Cooper acknowledges that formal training in project management focuses on a narrow set of concepts and tools. In our next article, Alistair Cockburn laments that most project managers have not sought out and learnt from the broader concepts of lean manufacturing, the theory of constraints, and the project management "Declaration of Interdependence," which mirrors the Agile Manifesto in its emphasis on collaboration, openness, and light process. In addition, Cockburn highlights the critical role of senior management (a theme that Mark Mullaly also explores) in driving a top-down approach to vision, priorities, and other key elements of effective project management.

Next, Mark Mullaly clearly identifies three dominant approaches to managing the delivery of IT-related projects. The first two are strains of the traditional project management paradigm -- formal methodologies such as Prince2 and Rational Unified Process (RUP) and the large and still growing group of formal certifications from such bodies as the Project Management Institute (PMI), the International Project Management Association (IPMA), the Australian Institute of Project Management (AIPM), and others. All of these groups have associated "bodies of knowledge," most of which are based on traditional project management concepts. While some of these organizations (such as the PMI) are beginning to include the emerging agile models, they generally have to compromise the agile concepts in order to minimize their impact on major constituents. The third approach Mullaly discusses is the agile movement itself.

While he believes that agile methods can be very helpful, he argues that agile project management -- like traditional project management before it -- is a poor substitute for the truly critical element in successful projects: project leadership. Mullaly writes, "We can develop new project management and delivery methods, but unless they are supported by the organizational leadership -- and contain a clear role for leadership -- they will probably fail." Working with my own clients, I have found the key to successful implementation of agile project management and governance is open and honest engagement of executives in both the cultural implications of agile as well as the changes in their roles as "hands-on" sponsors.² Mullaly highlights this when he focuses on the fear of failure that too often results in executives being told a sanitized version of the status of the project they are sponsoring. In his provocative article, Mullaly challenges project teams and organizational leaders to embrace the agile values of openness, honesty, and courage.

Cutter Senior Consultant Johanna Rothman, in our next article, gets to some of the more detailed issues that agile methods raise. Rothman begins by identifying the binary and often emotional argument that still seems to surface regularly between proponents of the "waterfall" development model and those of the various agile approaches. At a 2007 agile conference in London, I was amazed by the amount of "waterfall bashing" that was evident among participants and speakers. As one of Rothman's clients put it, "It feels as if I am stuck between the traditionalists and the agilistas."

In her well-balanced article, Rothman develops a comprehensive approach to one of the key agile themes -- contingency. Based on her consulting experience, she summarizes how different projects have adopted elements of both the waterfall and agile methods to adjust for the inherent risk and business environment of the differing projects. Rothman directly confronts one of the most perplexing challenges facing "traditionalists": if all projects are unique, how can we have just one way of delivering them?

As a professor specializing in software project management, Darren Dalcher is ideally placed to put some substance behind the often emotional debate about traditional versus agile project management. He begins his article with an account of a comprehensive experiment he and two colleagues undertook to determine the value of agile methods. Their conclusion is clear and unequivocal: agile project teams are much more productive and their products yield higher levels of customer satisfaction. However, having established the advantages of agile development, Dalcher then discusses a failed agile project and the project management implications of this and other agile project failures. He writes, "In fact a new kind of project failure may have been made possible by the ways agile methods are defined and applied -- a project in which each increment is a success but the overall project is a flop." He argues that as agile projects focus on delivering business value in short-term increments, they must take care that "the value [they] deliver represents coherent and complete content." Again, Dalcher returns us to the bigger issues of leadership, management, and the challenges agile poses to them.

Our last two articles explore how emerging Web/Enterprise 2.0 technologies can support the extended communication and collaboration essential to agile project management and development. First, Matthew Ganis and David McNeil describe how their project team used Scrum, the well-known agile development approach, to develop and deploy ibm.com's Virtual Business Center estate in Second Life. The combination of Scrum and Second Life's immersive 3D environment proved to be the perfect fit for a geographically dispersed team of developers who were largely unfamiliar with the new technology. Scrum's short iterations allowed the developers to gain knowledge and experience over time, and holding the daily scrums "in-world" with supporting virtual objects (whiteboards, flip charts, etc.) allowed far-flung developers to meet "avatar-to-avatar" and overcome their communication difficulties. Given the ongoing globalization of project teams, Ganis and McNeil offer a compelling example of how agile collaboration can really work.

Finally, Andrew Filev tells us how new Web/Enterprise 2.0 technologies and practices can help transform traditional project management. He identifies an all-too-common problem in project environments: "Knowledge gets buried in e-mails, as it is available only to the sender and the recipients; consequently, none of the other team members can benefit from it." I recently experienced this problem when assisting a client facing a meltdown of an SAP implementation. The original requirements (and associated tender documents) had been totally compromised with hundreds of changes hidden in e-mails and on servers. When an explosion of e-mail replaces face-to-face communication, resulting in reactive and limited information sharing, the agile value of openness is lost. In contrast, Filev writes, "blogs, wikis, and other second-generation tools offer better opportunities for communication and collaboration" by leveraging the agile project management practice of collective intelligence. Collective intelligence is the result of collaboration among many team members and stakeholders. As I constantly remind my seminar attendees and clients, involving more people doesn't slow projects. Rather, by including stakeholders in project management, the true ownership of the project and its outcomes moves from the project manager to the real clients. Filev concludes with an overview of how blogs, wikis, and the new Web-based project management tools (e.g., Wrike, Projectmanager.com) can enable this more open and collaborative project communication.

Perhaps the agile revolution discussed in this issue is best summarized by Gail Kelly, the new CEO of Westpac, one of Australia's major banks. As Kelly told the Australian Financial Review, "There are too many meetings, too much paper, and too little real communications. I am a fan of talking to people, not reports, not lists, not meetings but getting out there and listening."³ As those of us who have been part of the agile movement have learnt, agile project management is a business and cultural revolution first and a project management revolution second. I am confident that the articles in this issue will provoke, challenge, and inform you. They may even inspire you to join the revolution!

ENDNOTES

¹ Kuhn, Thomas S. The Structure of Scientific Revolutions. University of Chicago Press, 1962.

² Thomsett, Rob. Radical Project Management. Prentice Hall PTR, 2002.

³ "No Rotten Fruit Burdening Branches." Australian Financial Review, 2 May 2008, p. 72.

ABOUT THE AUTHOR