Software PM == Herding Cats?
On Agile Project Management And Earned Value
By Greg Alleman
I am currently engaged with a US Department of Energy contract in the Program Office. I was brought to this engagement through my previous “agile” activities. The initial challenge was to apply agility to the existing project management staff. IT strategy, application portfolio characterization and other traditional IT Department activities were in the mix. A primary tool for managing project inside the DOE is Earned Value. For those not familiar with EV, it is a cost and schedule “accounting” method that provides metrics for assessing the “value” of the project at a specific point in time.
The challenge here is to use the EV techniques while also deploying “agile” methods for software development and project management. From the past columns you will remember most of the agile principles and practices revolve around not doing activities that add no value to the project. Since EV is usually decreed in some manner for government projects, avoiding the EV activities is not actually possible. So what’s an Agile PM to do?
Let’s start with work reduction:
- A project management system is needed for managing all the moving parts of the projects. Our current choice is Microsoft Project 2002 Professional with the Server components. This of course if the “big hammer” approach, but in the DOE environment big hammers are common. The project server holds all the data and produces all the reports needed to comply with EV Reporting.
- There are several advantage to using EV for project management: Single control system that provides reliable data Integrates work, schedule, and cost using WBS Databases of comparable projects for future planning SPI (schedule performance Index) and CPI (Cost Performance Index) provides early warning signals
- Next install a management-by-exception method. This allows projects that are “green” to continue with their work, rather than have to report their “green” progress to management. Nothing worse than sitting through an hour project status meeting, listening to others report “my project is doing well,” and then getting your turn to say “my project is doing well.” If your project is doing well, it will show “green” on the EV Bulls Eye chart on the web page and you can keep working.
- EV is not a “low maintenance system,” it must be used as a tool, so once again there is no free lunch.
So how does this support Agile PM. What the PM needs is a “window” into the projects that is easy to use, provides visible indications of progress to plan and finally provides predictive powers. The production part of EV is there but only f you carefully define and manage what is meant by “value.” So this is how you do it with “agility.”
- Normalize the project reporting process – by having a standard by which all the projects in the organization define and report their activities, the PM can look at information with one set of metrics. This does'nt’t mean a big fancy PM standard operating procedure. It does mean that all the participants sit down in the same room, around the same table and decide as a group what are the minimal pieces of information needed to run the projects. The result is the collective ownership of this information and the processes around their creation and use.
- Engage the developers (or the execution staff) in agile reporting processes. Ask the question: “what is the minimum amount of information I need as a PM to manage this project?” This information can be gathered manually, electronically, or automatically. In all cases ask another question: “if I install this cleaver method of gathering and reporting project information how will it, and when will it, pay for itself?”
Starting with these two principles: normalize everything, and gather only the minimal information needed for the problem at hand, the Agile PM can proceed with the knowledge that she has placed the minimum burden on the group. As always there are problems with this approach:
- The PM must be technically competent “enough” to interpret this minimal information into useable project decisions. This is “always” the case to some degree, but even more so in the agile PM. The conjecture some have made that the best PM is one that knows nothing about the underlying technologies, just doesn’t make sense for me.
- The PM must be able to directly interact with the execution staff as well as the customer. In the agile world documents are far and few between. Direct face-to-face contact replaces the documentation that many times controls and over burdens the project.
Now back to Earned Value and its value. The latest Microsoft Project products as well as other “enterprise” products provide earned value reporting tools. In the concrete and pipe world these are easy to use approaches to reporting progress to plan. In software development it is not quite so straight forward. The hours worked and dollars spent do not directly translate into “value” delivered. In many cases that have little correlation other than to define how people have spent their time. So if tools are to be used that deliver value, the EV approach needs to be modified and modified to fit into the Agile PM’s paradigm, not the US DOD Standard 5000.1
For those who can't get enough of Earned Value here's a reading list from my recent searches for supporting materials.
Next month we’ll be deep into implementation of our new “agile” earned value system as well as deploying many of the Agile PM activities discussed in previous months. In the mean time there are many activities taking place in PM that are starting to converge on “agile.” My column in the coming months will pull together these varied ides into taxonomy of Agile PM that can serve as a road map for moving the discussion forward.
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>