Mind the Gap is an enigmatic phrase in the London Underground ostensibly referring to the space between the platform and the train and cautioning travelers to be aware of it. This post is contributed by Lee Moss who is in the Executive Master's in Technology Management program at the University of Pennsylvania. It discusses the technique of Earned Value Management which, among other things tracks the gaps between Budgeted Cost of Work Scheduled, Actual Cost of Work Scheduled and Budgeted Cost of Work Performed.
Everybody talks about how hard it is to estimate the cost and schedule of a software system project, but nobody wants to do anything about it. That's what I got from the reading this week, so I went off on my own to see if some of the Program Management Best Practices (Boeing and otherwise) could be applied. The first best practice that I looked at was Earned Value Management.
The first place I went on the web was a Google search for "software engineering earned value management." I found a number of useful links.
http://www.niwotridge.com/Resources/DomainLinks/EarnedValue.htm is a wealth of links.
http://www.stsc.hill.af.mil/crosstalk/1998/07/index.html is an excellent paper by Quentin Fleming
& Joel Koppelman titled "Earned Value Project Management: A
Powerful Tool for Software Projects." that provides very good insight to the EVMS novice, particularly on how EVM can be applied to a software project. Editor's: note: I added the title of the article to the text and I also recommend the journal Crosstalk, from the US Department of Defense. Subscription to it is free. Check out the link.
http://www.stsc.hill.af.mil/crosstalk/2000/12/lipke.html appears to be another interesting article where statistical process controls were implemented in a SW project. I didn't read this article in any great detail, but I have the link to return to if I need this in my tool kit someday.
http://www.stsc.hill.af.mil/crosstalk/1999/03/lipke.asp talks about applying Management Reserve to SW projects- something every PM should be interested in. In this article, they say "A nightmare for software project managers is "extras" thrown at them by the customer. Of course, revised requirements are supposed to be renegotiated and reflected by a revised project baseline that includes a new completion date and changed cost. However, many times the "requirements creep" seems so trivial that project managers forego the perfect practice and merely adjust their funding reserve to account for the change. For many situations, the effort required to re-baseline the project and negotiate the change is far greater than the amount of reserve lost. As an internal practice, we
advise customers that changes are being accrued and that we reserve the right to negotiate them once it is apparent the effort to do so is worthwhile; however, until payment occurs for revised requirements, the reduction in funding reserve will be reflected in decreased TFA and thus
a lower cost ratio." I'm not sure that I am comfortable with this particular approach, because it seems to encourage incremental creep that goes unaccounted.
http://www.stsc.hill.af.mil/crosstalk/2000/06/lipke.html is more on statistical process control and software engineering.
In general, unlike the weather, it seems that a lot has been done relating SW projects to other program management tools. I'll look at some of the other best practices another time.
