Software PM == Herding Cats?
Agility and the myths of software development projects.
By Greg Alleman
The management of software development projects has been problematic since the beginning of time. Many attempts have been made to gain control of the process and provide a reliable means for software production. I read in a recent brochure from a systems integrator that said, "... with mature repeatable process, we can zero in on any problems as soon as the occur. There's hardly any reinvestment for rework now."
The question is can such a repeatable process by actually work let alone be syndicated to other domains? First let's look at some of the myths that currently pervaded the software development world:
- Clear-cut investment opportunities exist, with an explicit purpose, beginning, duration, and end. These opportunities can be identified early in the project and remain in place throughout the projects development lifecycle
- Low opportunity costs for each business or technical decision exist. The decision processes can be reversed if the outcome is found to be in error.
- Feasible, suitable, and acceptable project attributes can be identified early in the life cycle. These attributes have known impacts on resources, technology, and the success of the project
- Accurate predictions of project duration and resource demands are possible once the requirements have been defined. These predictions remain stable throughout the life of the project.
- Worst-case consequences can be determined in advance. Risk assessment and mitigation is sufficient to address these issues.
- The failure of the project was due to lack of skills rather than inappropriate feasibility, suitability, or acceptability of the solution.
Do these "myths" sound familiar? Are they the underlying assumptions for the search for repeatable processes? It turns out the many software development domains have another set of "assumptions" at work, behind the scenes. It turns out the "project myths" described above are hardly ever true at the lower levels of "writing code for money."
There are instead:
- Highly uncertain facts about the project attributes. These are not "unknown" requirements, but they are emerging requirements that are discovered as the system development proceeds. Users actually "learn" more about their problem as the system is developed and deployed.
- Constant disputes about the values and expectations are due to user and business community impacts. Markets change, business success factor change, technology and economic forces directly impact the project. None of these are within the control of the project manager.
- High decision stakes with irreversible consequences are now the norm. Deciding on a technology or business process commits the company to a direction.
- Urgently needed decisions must be made in the presence of insufficient information. This is the norm is many competitive business domains. Waiting for perfect information is no longer possible. "Some" form of a decision is needed simply to keep the process moving.
- Outcomes that affect broad communities of interest. The consequences of a decision, be it technical or business processes, are now impacting communities outside the initiation stakeholders.
What does all this mean to a PM? The first thing it means is that the simple assumptions of "stability" is no longer valid. Stable requirements, stable business outcomes, stable, technologies can no longer be counted on - at least in any emerging e-commerce or discovery design project.
I know I talked about telling you how to apply agile processes to specific environment last month. But I've become sidetracked. I've was trained as an experimental physicist (digital signal processing) and understanding the "theory" behind the practice is somehow embedded in my brain. So before describing how agile PM is "actually" used here's a very brief tour of the theory of agile PM.
There are four theories of management: Management-as-Planning, Management-as-Organizing, Management-as-Learning, and Management-as-Adhering. The Management-as-planning approach described in traditional PM process (PMBOK being one example) has several flaws that directly impact software development:
- "Change" is assumed to be undesirable and control of change is the goal of the planning process. A conflict is created between "managing change" and "managing in the presence of change," that cannot be resolved using the management-as-planning paradigm. Without understanding that change is normal and even desirable in some contexts, the management-as-planning paradigm cannot take advantage of these naturally occurring change processes.
- Planning based methods are "transformational" in nature. That is, inputs are transformed into outputs. This transformation "style" takes place within a stage, phase, or process with clearly defined boundaries. What is not recognized is that the "real" processes taking place in the software project are non-linear, noise generating, and error prone. How many times have we heard - "we estimated 3 days and it took 5," "it passed all the unit tests, but somehow bugs are in the production system," "the code was implemented to match the requirements, but now the users have rejected that part of the system."
Before ending for this month, the last bullet describes some of the issues with transformational processes (inputs transformed into outputs). There are two other project styles that are being discovered. These are Flow and Value Generation. Two papers being given at the July 2002 PMI Research Conference discuss these approaches to PM.
About the Author
Glen
Alleman is Vice President, Program Management for the Information and Network
Services organization of CH2M HILL's Communication Group. Prior to this
position Glen was the Principal Consultant for Niwot Ridge Consulting, where
he specialized in the management enterprise application integration projects.
At CH2M HILL, Glen provides services to Rocky Flats Environmental Technology Site. This work involves program management services for software development, server and network operations, infrastructure installation and removal, as well as telecommunications and wireless devices. Glen B. Alleman < galleman@niwotridge.com>