I have been using EVM for quite some time. Recently I came across an article on Agile project mgmt, and the author was stating that traditional EVM does not make sense for s/w projects.
According to the author, the EVM is good for construction/civil/defence projects, where deliverables can be seen and visualized. Software is ever evolving product so EVM cannot be applied to s/w projects, in terms of measuring progress.
Can you throw some light on this?
Thanks
Bhupendra Saving Changes...
Sort By:
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Hi Bhupendra, great post and question. Software projects, even Agile software projects can use EVM - the question is does it make sense for the particular organization to do so. Also, EVM can be applied in a variety of different rigors and detail. EVM theory is one thing; practical application is another. And, not all projects benefit (the same way) from the use of EVM. Longer projects with well defined work packages lend themselves well to EVM. Shorter projects (and very short projects) typically do not. Just because a project is a software project or an agile project does not mean that you can not measure the performance of the project. The real question always becomes whether or not there is value in doing so. Also, software projects as a project type covers a large water-front. Designing and development a software application is quite a bit different than implementing a commercial-off-the-shelf (COTS) software solution. We see more and more PMOs addressing EVM as a PMO policy matter - where EVM is or is not applied based upon the project type and size and based upon the value of EVM as a technique to the project effort and business environment at hand. Great post - I hope we hear and learn from others. Saving Changes...
Andrew MakarProgram Manager| AMAKAR LLCOakland Township, Mi, United States
Can you point me to the original article?
I'm a big fan of earned value management for software projects....not because it is a cure all for project management problems, but because it reinforces a metrics driven mindset. Without seeing the article, I can only guess the author was referring to the contractual nature of EVM and the alignment to cost accounts and specific work packages.
The reality is successful EVM implementations have flexibility in its methodology. You many not have an integrated WBS system with your corporate general ledger. You may simply be the 1 PM generating EVM metrics from your single Microsoft Project schedule.
Agile actually positions itself well for earned value management if you apply the EVM metrics to the specific iteration and release.
For a release planning effort, using a team's velocity will determine the scope and number of iterations that can be completed in a given release. The number of resources * the number weeks in the iteration or release can represent the PV for the iteration or release.
Each user story is a work package that can be assigned its own PV.
EV is still calculated based on project progress and AC is still captured. At the end of an iteration, your EV may not equal your PV but this is ok based on the viewpoint of the product owner.
Remember that Agile allows scope to be flexible as progress and changes are introduced. The main benefit I see is being able to demonstrate meaningful metrics vs. the typical qualitative and subjective status report.
If organization are new to EVM and hesitant to adopt, consider simply calculating the number of stories planned vs. the number of stories delivered. It will give a metric on progress and start conversations about adjusting scope as needed.
Hi,
Thanks for taking time and clarifying this for me, Andrew and Mark. Your insightful explanation does help me a lot. Here are some of the characteristics of typical projects we do
1. Projects span 5-7 months
2. All project implementation type of work efforts
3. We use in-house developed products for the implementation.
4. The products have evolved over a period of 10 years.
5. nevertheless, in a typical project we do significant customizations,specific to the customers.
6. In all situations, requirements are captured and signed-off by the customer, in the plan phase.
7. Post the sign-off of the requirements, project team does the effort estimation and scheduling
8. We do not allow much change in scope, during the lifecycle of the project
9. In some projects we do have significant dependecies on 3rd party deliverables, .. but these do not affect the scope.. only impact the schedule (.. and sometimes cause major delays)
10. We do not do COTS type work, as yet
11. Multiple products teams (in-house) are involved in the customization effort. (at least 4-5 teams, apart for testing/QA)
12. Most importanly, the organization never had any experience in using EVM. All projects have been managed and rendered on "best efforts" basis.
I am taking a cue from Mark's comment that "Software projects, even Agile software projects can use EVM - the question is does it make sense for the particular organization to do so...." Now my thought process would be to focus my discussion with my leadership to see if EVM suits my organization. But before I do that, I need a little more help fro you, all.
At this point, based on the bullet points I listed above, I feel EVM can easily be applied and should be.
Really appreciate your opinion.
Thanks
Bhupendra
Saving Changes...
Andrew MakarProgram Manager| AMAKAR LLCOakland Township, Mi, United States
Mark's comment is right on!
It will help if your senior leadership can agree that it does make sense for the particular organization to use EVM. I can attest to the challenge of supporting EVM from the grass roots. It is a significant challenge if the top-down organization doesn't support it or even know what it is...
The challenge is the customer organization may not understand the metrics either.
I did my doctoral research on Assessing CSF in EVM. You can find a summary of the work from one of my PMI chapter presentations that I posted at:
You may find it useful in considering before initiating an EVM implementation. The organization may not be ready and instead simpler metrics like Story counts or # of Use Cases completed may be more appropriate.
On a positive note, at least you're considering metrics for your project.
There are a lot of projects out there that simply run without metrics.
Please do not read such junk articles!! PMI has done a good job in coming up with PMBOK. Always refer to PMBOK!
If you do not use EVM, then how the management/stake holders will know if there is a schedule over run (or) cost over run. SPI and CPI are key indicators in a project!!
Best Regards,
Vivekanandan M Saving Changes...
Ken HarrisonManager, Business Architecture| Department of TransportAustralia
Does anyone have an EVM spreadsheet they use for Agile projects? ... I'd be interested in one to help me re-assess projects to see if it would have forcast issues Saving Changes...
