-
When IT Is Your Company’s “Piggy Bank”
February 10, 2012
-
4 Key Things a Project Manager Must Do
February 10, 2012
-
Essential Project Management
February 10, 2012
-
8 Traits of Top Project Managers - Part 1
February 9, 2012
-
Agile Project Management - Engaging Your Customer!
February 9, 2012
-
9 Tips to Avoid Traps in Project Planning
February 9, 2012
-
Why Projects Succeed - Executive Sponsorship
February 8, 2012
-
On Customer Participation in Agile Projects
February 8, 2012
-
A Project Charter for Lazy Teams
February 8, 2012
-
The Power of Process: How Bad Project Management Kills Great Ideas
February 7, 2012
Why Not Measure Earned Value?
March 4, 2009 | Author: PM Hut | Filed under: Performance Reporting
Why Not Measure Earned Value? (#2 in the series Measuring Project Progress)
By Johanna Rothman
So why not measure earned value? Earned value (taking credit for what you’ve been able to create in a specific amount of time) was developed to manage the tradeoff between measuring just the schedule and measuring what’s been accomplished. Earned value makes sense for products that can be created in self-contained pieces. You create a piece and measure how long it took and how much it cost (in people and time) to create that piece.
But for many software projects, it’s extremely difficult to calculate earned value. That’s because all parts of a software project are interdependent. Even if you implement feature by feature, which is as independently organized as you can make a software project, when you work on a new feature, you may have to return to completed work and change it. When you change completed work, it’s harder to determine the true earned value. Did you lose value because you changed something? Or, did you build on already-earned value? I have not worked on any project where it was possible to calculate earned value. In my experience, earned value is too often a fuzzy measurement for software projects.
This original article can be found at: http://www.jrothman.com/Papers/are-we-there-yet.html
Johanna Rothman consults, speaks, and writes on managing high-technology product development. Johanna is the author of Manage It!’Your Guide to Modern Pragmatic Project Management’. She is the coauthor of the pragmatic Behind Closed Doors, Secrets of Great Management, and author of the highly acclaimed Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. And, Johanna is a host and session leader at the Amplifying Your Effectiveness (AYE) conference (http://www.ayeconference.com). You can see Johanna’s other writings at http://www.jrothman.com.
Related Articles
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized
3 people have left comments
You obviously have never done earned value right, on IT projects of any magnitude. When I worked for Northrop Grumman IT, we used earned value religiously for all medium and large IT projects (we had a scorecard used to determine project size based on man-hours, budget, and level of risk involved in the project). Most of these projects fell somewhere between $400k - $1.5m and usually completed within 1 calendar year, although some were larger.
Using CPI and SPI to measure performance allowed us to gauge our progress along the way and to take corrective actions when necessary. Keys to success included proper planning (developing a resource loaded MS Project Schedule that typically had no more than 8-80 hours per task), regularly scheduled/accurate reporting by project team members, strong project management leadership, etc. Did EVERY single project come in on budget and schedule because we used EV? No, but typically that was due to poor requirements or scope creep, not EV, a topic for another discussion.
If you can not measure earned value you can not control your costs. Very simple.
Johanna,
You might be confusing “business value” with the Budgeted Cost for Work Performed (BCWP), the “earned value,” of ANSI/EIA-748B Earned Value Management.
Earned Value (BCWP) is calculated in a brutally simple manner.
At the time of assessment, BCWP = BCWS (Budgeted Cost for Work Scheduled) x Physical Percent Complete. How much did we plan to accomplish? How much did we accomplish?
This requires that the Budgeted Cost for Work Scheduled (BCWS) be defined before starting the work.
This means “what will we budget for this work at the time we want to assess the progress?” This is the “all in budget” for the work, based on a specific time of assessment - say the end of the iteration, the completion of the work package or the like.
A simple – simple means notional, and notional means not that all realistic, but informative – training deck can be found at http://www.niwotridge.com/PDFs/EVMSCookies.PDF.
At this point in time the “earned value” is that number times the percent complete.
Words like “true earned value,” or “I have not worked on projects where it is possible to calculate earned value,” leads me to believe this is not the same “earned value,” used on 100’s of billions of dollars of software intensive projects in aerospace and defense.
Scott Ambler has written recently in similar terms, confusing business value with 748B Earned Value. he is dead wrong of course, but this notion is spreading.
Time to deal with this massive misconception of EV and software projects.
Start with a few resources:
http://www.stsc.hill.af.mil/crosstalk/2000/12/lipke.html
http://www.askprocess.com/Articles/UsingEV1.pdf
http://www.askprocess.com/Articles/UsingEV2.pdf
McConnell has an entire course on this topic
http://www.construx.com/Page.aspx?nid=15&id=37
Buy Paul’s book (a colleague) and read it for guidance of applying EV to software intensive projects.
http://www.amazon.com/Performance-Based-Earned-Value-Practitioners-Solomon/dp/0471721883
Things like the $600M avionics suite for the Orion manned space craft, our Paul’s last project, the B2 avionics suite.
Paul’s work started some time ago,
http://www.testablerequirements.com/Articles/solomon.htm
With these materials “under your belt” so to speak, the notion of EV may be clearer as it is applied to software intensive projects.
Glen B. Alleman
VP, Program Planning and Controls
Aerospace and Defense
Denver, Colorado