Earned Value for software development projects is not a myth

I was minding my own business this morning, installing software on my home computer, when I decided to do my email.  There was an email from PMI-ISSIG about the ISSIG Review 2010 Vol. XIV No. 1.  One article that got my attention was “The Myth of Earned Value! (for Software Development Projects)” by Richard Fox.  I’m not including a link because it is copyrighted material and anyway I think the article is plain wrong.

You have to read most of the article before you get to the meat of the matter; basically, Mr. Fox states that EV and software development don’t mix because (my order so it makes sense to me):

• Software project have imprecise requirements. So, you don’t know what you want to achieve?
• Sotware projects are harder to estimate and it is harder to get an accurate progress report from a developer. Never worked construction, have you? This is not a software development exclusive.
• Until the software tests successfully we don’t know that we are done. Well then, claim nothing before then and then claim 100%.  Better yet, have clearly defined milestones with clearly defined deliverables and clearly defined %complete associated to them.

Add these 3 to this quote from the article:

The magnitude of trying to decide how much of the work of many software development activities has been completed may be best expressed by an old method of estimating the “ETC.” This is the 95% rule - “It takes “95% of the estimated schedule/cost to complete 95% of the work and ANOTHER 95% TO Finish it!”

Is it any wonder he claims EV and software development don't mix?  You could also guess who I’d be nominating for the CHAOS award this year…  For those who want to learn something about EV go to Glen Alleman’s blog, Herding Cats and type EV in the search box.

What do you think?  As always comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Comments

[Glen B Alleman]

The author would be interested to learn the our $600M flight avionics software project uses weekly EV.

This will motivate me to write about how to do EV on software projects. We're writing a paper for NDIA on how to integrate EV with Scrum.

[Glen B Alleman]

Pat,
the ISSIG articles can be downloaded. Your readers should do that.
As well is a nonsense article about how agile is incompatible with PMBOK®.
Mr. Massey makes the fundemental mistake most uninformed people do about Agile and the PMBOK® and that is PMBOK® is NOT a project management METHOD it is what it's title says it is - A Guide to the Project Management Body of Knowledge. The process groups and knowledge areas are descriptions of "why" and "what" not "how."
It's breathtaking our authors in official publications fail to understand this.

Apply agile software development during the executing process group. Most of the nine knowledge areas can be found in Scrum for example.

I'm wondering if Mr. Massey has ever worked a project where Scrum was used? If so, was he paying attention to what was happening.

Now there are just as many misunderstandings in the agile side about PMBOK®, and just as many boneheads writing about how agile and PMBOK® can't be mixed.

I've given up and gone back to applying agile methods to DoD EV based programs. Now we're going to write about it for NDIA. A staff member is doing his master's at CMU and I'm providing some guidance for his paper.

[Patrick Richard]

You should really send that article on EV and software project to PMI_ISSIG when its ready.

I saw the Massey article but refrained from slaughtering it; I don't want to come out as a grumpy bastard... It did sound like a "the sky is falling" article on top of comparing apples (Agile) and oranges (PMBOK). I guess that "debate" falls in the "tell the same lie often enough and it becomes the thruth" category.

Thanks for the comments,

Patrick

[Glen B. Alleman]

Grumpy bastard? Too late.
My wife asked "why are all the program managers on your program cranking all the time?"
"We're program managers," the program is always late, over budget, and the vehicle doesn't work as planned.
The notion that there is a black and white description of almost anything around project management, is just that "notional." Notional in our world means a really nice power point presentation.

[www.google.com/accounts/o8/id?id=AItOawlORgKDy23qA3da0-xzS32r9LzWeWcJt2c]

Pat/Glen You are earning your value as you post articles on the way things really are. I guess we are grumpy sometimes because we ask people to follow through on commitments, show the company "chiefs" where projects really are schedule wise and don't drink the "we'll catch up later" Kool Aid.

Thanks,

Bob

[Patrick Richard]

And I have mellowed with age...

[Patrick Richard]

Bob,

Thanks for the comment. I am not grumpy; I am merely "opinionated". :-)

Some people think I am too "by the book"; what would you expect from a project manager, engineer, ex-military combo?

[Glen B Alleman]

Grumpy is good in the right context. It says "I don't really believe what you'll telling me, you're going to have to produce 'tangible evidence materials' before I'll feel better about your report"

Trust but verify was Kissinger's suggestion for dealing with the Russians.

[Lawrence Peters]

Go for it - it is high time that software people began to realize that they have to contend with the same issues (Planning, Scheduling, Controlling, Staffing, Motivating) that all other project managers have had to contend with for about 5,000 years and there are methods and techniques that work just fine everywhere. After 40 years in the software field it is obvious that our parochialism is severely handicapping us. This is no more evident than in the makeup of the software project management core who are mostly programmers, untrained in even basic management skills.

[Patrick Richard]

Lawrence,

Spot on comments; thanks!