Software PM == Herding Cats?
Agile PM and Earned Value, a Field Report
By Greg Alleman
Last month I described some of the aspects of Earned Value and the high level benefits of deploying this method in the presence of an Agile PM method.
It’s been a very busy month, with nearly a 100 IT projects in the Microsoft Project Server, Balanced Scorecard connections to these projects through a dozen or so initiatives, and of course the daily activities of running a Program Management Office.
One critical aspect of agility is to enable developers and other project value delivery folks to do their job while the project managers actually “manage” the projects in a consistent and verifiable way. In the past we struggled with both consistency and verifiability. The natural approach was to seek some type of order in the process. As discussed last month, earned value is that order. But what does it mean in practice to have earned value management in an agile PM shop?
First some quick background
Our goal in software development as well as the infrastructure side of the business (telecommunications, networks, and server operations) is to move to “self directed teams,” agile PM, and maintain the needed formality required by our customer (a Federal Agency). These are code words for removing middle management while increasing the capabilities and skills of the people actually doing the work, all done for less money, in a shorter amount of time. The traditional approach to EVMS is to introduce reports, capture time, and introduce analysis processes to provide visibility to the project’s progress to plan. For an agile team engaged in self-directed work this is not only burdensome but actually adds no value to their efforts. In additional EVMS is typically deployed as a “management activity” which additionally burdens the team since they have to interact with management to produce the raw data needed for EVMS to work. In order for this to work, the data capture burden as well as the reporting and feedback processes need to be agile as well.
How is this done?
A very quick review of the elements of Earned Value
BCWS – Budgeted Cost for Work Scheduled – is the “planned” cost of the work that is “scheduled” to be performed. “How much will it cost for the work that we’ve planned to do?”
BCWP – Budgeted Cost for Work Performed – is the “planned” cost of the work that actually was “performed.” “How much should it have cost for the work we actually performed?”
ACWP – Actual Cost for Work Performed – is the “actual” cost of the work that was “performed.” “How much did it actually cost to perform the work?”
CV – Cost Variance – BCWP – ACWP. “We budgeted one amount and spent another amount to perform the work.”
SV – Schedule Variance – BCWP – BCWS. “We budgeted one amount for a scheduled amount of time, but we performed the work over a different schedule. Knowing the difference is the budgeted amounts gives us the variance in the schedule.
There are several important concepts that need to be understood before going any further:
Before a task states it’s Budgeted Cost for Work Performed (BCWP) is
zero, since of course no work has been done in the scheduled period.
The Actual Cost of Work Performed comes from labor hours, times the labor
rate, plus any Other Direct Costs (ODCs) for the period of performance
Once the task has been started, some method is needed to accrue “Value”
for that task. This simplest method – meaning the easiest to do, that
gives a useable number – is to assign a percentage complete for the
task without actually measuring the completeness. For our first try at this
we did the following:
A task earns 0% of its value if it has not been started – duh!
A task earns 50% of its value if it has started – more later
A task earns 100% of its value if it is complete – “we’re
done book all the value.”
Now the trick here is to define the duration of the tasks in such a way that the granularity of the “earned value” accumulation is small enough to represent the “real” progress of the project. If this granularity is too large, then the 0%, 50%, 100% process would not be representative of the tasks actual progress except at the 0%, 50%, 100% points in its life cycle. If however the granularity is “just right,” say 1 to 2 days on the high end and ½ to 1 day on the low end, then the 0%, 50%, 100% accumulation is itself fine grained and the earned value is also fine grained and properly representative of the actual progress of the project.
So what does all this mean for an Agile Project?
In agile projects the planning process is continuous, since requirements are changing all the time. If a traditional large grained EVMS process were used, then the only way to keep all the numbers straight is to re–baseline the project (new BCWS) for each iteration of the entire project. In some businesses (aerospace) these is called “rubber baselines.”
For an agile project, with fine-grained tasks adjustments occur outside the boundaries of the task, and therefore outside the boundaries of the BCWS number.
So everyone is happy (well so far anyway). The PMO gets an accurate indication of the Cost and Schedule variance, the developers get to react the changes in requirements in their agile way, the PM gets the progress to plan indicators needed to direct the work.
The fine-grained increments of work are called many things. In the SPMN world they are “inch pebbles.” In the Extreme Programming world they are “stories.” In SCRUM is are “sprints.”
This melding of what seems to be a high ceremony process (EVMS) with the tools of agility (for software development) is a new and unique process. I can’t take credit fore this idea. It was described in some detail in an European SEPG 98 paper on self directed teams and EVMS. As well the Extreme Programming concept of “stories,” seemed to fit well with EVMS even though the XP folks may not believe is possible.
Next Month
Now that the basics are here (and hopefully I’ve made them understandable), I’ll provide an example from a real project.
The BSC- PMO Process
For your interest here is a picture of the BSC - PMO process. The file is pdf and less than 6K so the download should be fast. Take a look at it and print out a copy to help in following future Viewpoints Columns on the implementation of EVMS, the BSC and a PMO.
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>
Counterspin - Letters to the Editor
Glen Alleman replies to Max Wideman's Letter on Agile PM...
Bob Youker writes on Glen Alleman's Viewpoint Column on Software Project Management...