I came across (actually Pat Richards alerted me) to an article about how Earned Value is not applicable for Software Development project. This article was in a PMI IS SIG news letter. See Pat's post. You can retrieve the article by following the link on Pat's Blog.
Here's the core of the concept proffered by a PMI Special Interest Group on Information Systems.
It is very difficult to accurately and objectively measure the progress in designing and developing software.
My first response was "really?" The very essence of project management is to apply some measure of progress to plan. Simply showing up and putting in 40 hours a week is a measure of progress to plan for a Level of Effort task like watching the trains pass the crossing. (They used to have a job like that in the old Federal Republic of Germany when I was there in the mid 70's detoxing from a tour in Vietnam).
Also the very essence of Scrum - or most agile development processes - is to produce planned measurable outcomes from the work effort. All agile methods MANDATE the production of working software. How to define what software to "get working" varies by method, but Scrum connects the work efforts with the "requirements" through a Feature and Story list developed by the stakeholder.
Software projects also have the problem of iterative development approaches in which certain activities often must be revisited a number of times before they can even be considered completed.
Yes this is true. This is true of every project on the planet. It's part of life cycle of projects. From the extreme approaches of XP to DoD 5000.02's procurement cycle, incremental and iterative approaches are used.
This is not a "problem," it is a fact. Apply the appropriate method to deal with this.
And then the final stroke is "really bad project management"
Many of the activities in software development projects more difficult to measure accurately and objectively in order to compute the actual earned value of the work accomplishments. It is very difficult to accurately and objectively measure the progress in designing and developing software. Often the project manager must simply accept the developer’s word for how they are progressing rather than use an objective measurement. For example, when is developing a computer program 25% or 50% or 90% complete? We can measure the cost of the developer’s efforts but not the needed corresponding progress toward completion.
Please tell me this is not the approach being blamed for software project failures. Better yet please tell me that Earned Value cannot be applied to software development because of these types of projects.
Earned Value is successfully used in a variety of software domains - Enterprise ERP, defense and space system, which are all software intensive, embedded control systems.
Core Success Critieria for Earned Value and Software Development
- Define the outcomes of the work effort in some tangible way. Physical evidence is best. 100% working code (at least for the planned deliverable) is best of software. Tangible evidence for other things is just that - evidence that work produced the "thing" that was planned to be produced on or near the day (or week or month) it was planned to be produced for something close to the cost that was planned.
- Define the way progress is going to be measured. 0/100% of the work. Either it's do or it's not done. Other measures of progress can be 50/50 (half when you start, half when you show up with completed product), apportioned milestones. But NEVER EVER is progress measured by asking someone "how far along are you on the software module you are working on?" The answer can NEVER EVER be "well, I've been working real hard and I think I'm making progress, so let's say I'm about half way there with half to go."
- Define the tangible evidence, the date the tangible evidence is expected, and the associated costs.
- With this you've got all you need to do EV on Software Projects. Ignore completely the suggestion in the IS-SIG article, that EV and SW Dev don't mix. It's done every day on billions of dollars of software development.
