There is a difference between product development methodologies and the management of the project that makes use of an product development methodology. This is not clear in many of the discussions of agile software development. But there is another distinction - the distinction between managing projects in an agile manner and the management of an agile project.
Agile has many meanings, but Jim Highsmith provides one in Adaptive Software Development.
“Agility is the ability to adapt and respond to change … agile organizations view change as an opportunity, not a threat.”
The first part of this definition is a tautology. It’s the second part is useful for Project Managers. Trouble starts when the traditional high–ceremony project management method used in some industries is applied to Information Technology projects. In the IT domain, this trouble comes from several “myths” associated with try to apply the high–ceremony approach:
- Planning – It is not humanly possible to produce a plan so that its implementation is merely a matter of executing a defined set of tasks.
- Plans for complex projects rarely turn out to be good enough for this to occur
- Unanticipated problems are the norm rather than the exception
- If fact plans are "an ongoing dynamic activity that peers into the future for indications as to where the solution might emerge and treats the plan as a complex situation, adapting to an emerging solution." [Mike Dwyer, IT Program Manager, American Healthways, Westborugh, MA]
- Change – It is not possible to protect against late changes
- All businesses face late changing competitive environments
- The window of business opportunity opens and closes at the whim of the market, not the direction of the project manager
- Stability – Management usually wants a plan to which it can commit. By making this commitment, they give up the ability to take advantage of fortuitous developments in the business and technology environment
- In a financial setting this is the option value of the decision
- Deferring decisions to take advantage of new information and new opportunities is rarely taken into account on IT projects
Dealing with the Myths
So how does a PM deal with these “myths?” First, acknowledge they exist. Although the role of the PM manager is to “control” the processes underlying the project, these processes are in fact based on chaotic foundations. Not all project domains behave in this way, but projects that move the organization forward in some way must deal with the changing business environment in which these business processes are embedded.
Second, isolate the parts of the project that don’t have these behaviors.
Third, turn change into an advantage. It is the management of the project in the presence of changes where “agile” methods shine. Not "managing the changes."
I can hear the objections already.
“If the business requirements are changing, then there are bigger problems.”
“If the stakeholders can’t define the requirements up front, then they don’t know what they want.”
These are valid criticisms of “agile PM.” But like all criticisms, they need a context. Let’s make this easy. An industrial firm wants to procure and install a Product Data Management system (a product of which I'm deeply familar). PDM systems are like ERP systems for “engineers.” The current system in our real life industrial firm consists of 6 or so legacy applications all operating in “point solution” mode.
The PDM system is supposed to replace all these systems. So what is a PM to do? The PDM system is expensive (aren’t all enterprise systems these days). Gathering ALL the requirements up front, defining the system, deploying it, and operating it seems like a natural approach. A funny thing happens though in these environments. Once the user community starts to actually produce products on the PDM system they discover new and cleaver ways of using the system and producing products.
This self–discovery process is part of an evolutionary development project. Does evolutionary equal agile? Only if the changes that come from the new discoveries are seen as beneficial to the outcome. In the high–ceremony PM process, these changes are seen as disruptions to the orderly flow of the project. Questions get asked: “why didn’t you know about these things in the beginning?” “Why are we changing the business processes at this late date?” The way to answer these questions is with a Jack Welch quote “Change before you have to.” Change is part of any viable business process. Change is what drives business. Without the ability to deal with change, the business becomes an “instant legacy.” The systems that support that business and the PM methods used to deploy those systems need to have similar change coping strategies.
Another Welch quote says a lot about our views of agility (slightly paraphrased).
“Learning to love change is an unnatural act in many institutions. Change is the oxygen of our growth.”
