Tuesday, September 23, 2014

Right Sizing: A Common Point of EVMS Failure - Revisions and Data Maintenance

This week we review the last set of criteria in the ANSI/EIA-748: Revisions and Data Maintenance

Have you ever seen or implemented a complicated, convoluted, nobody-can-understand-it-but-the-originator baseline change proposal?  The kind that makes you go cross-eyed just trying to sort out the pieces?  These beasts make it difficult to produce all the backup information; many times there are just too many renditions of before/after scenarios before the “right” one was found.  Scope was added and removed, resources and rates changed, the WBS and OBS were restructured, logic was refined, and then management took 10% right off the top!    In the end, no one remembers how they got from A to Z, but you’re still responsible for reconciling it, eh?  If you’re lucky, your EV software is friendly enough to aid you in your quest.  Even if it isn’t, the revisions and data maintenance criteria in the ANSI/EIA-748 will help prevent such a nightmare.

CloudEVM  ANSI-748 EVMS Excel Project Management
Revisions and data maintenance are common areas for the failure of an EVMS.  Why?  Well, to be frank, one reason is because the management of revisions and data maintenance is not fun and can be a pain in the rear (i.e. high PITA factor).  It can be time consuming and doesn’t “yield” any additional benefit beyond what is initially gained from the criteria in the other four frameworks of your EVMS.  It is a necessary evil—something you have to do in order to have valid EVMS data.  People don’t like spending time and money on things that don’t directly provide added benefit, so they tend to slack on the maintenance of the data.  This is a huge mistake, because it undermines your entire EVMS.  If you spent time and money to implement your EVMS, why not take care of it so it can continue to meet your needs in the future?

When it comes to implementing aspects of the ANSI/EIA-748 in a non-certified EVMS, you’ll find that really ALL of the criteria in this framework are necessary for your program.  The level of rigidity needed in their application is where you’ll find wiggle room.  Less formal programs may not need the strict guidelines that a formal program may need, but they still need the basics.  Either way, you can customize the methods and execution of the criteria through your procedures and implementation of them, including various approval levels for baseline changes.  Let’s take a look at the criteria and why they’re needed for any EVMS:
  1. Incorporate authorized changes in a timely manner.  This maintains integrity of your Performance Measurement Baseline (PMB) and allows you to measure and report earned value based on reality (as much as possible).  It also helps ensure work, budget, schedule are aligned with each other.  Ask yourself, “Does it make sense to wait for a year to implement an authorized change?”  Imagine having several baseline changes that have been hanging out there for a year.  It suddenly becomes easy to see how this will make your analysis more difficult and compromise the integrity of the baseline.
  2. Reconcile the new budgets with prior budgets - changes should only be made via baseline change requests that are authorized and have formal documentation and backup for traceability.  This is how you VERIFY the integrity of the PMB.
  3. Control retroactive changes.  Ever heard the term “Don’t change history”?  Retroactive changes can mask variance trends and limit the ability to use Earned Value to forecast.  Controlling these changes protects the integrity and accuracy of the PMB and EV.  The exception would be data entry corrections or routine accounting adjustments.
  4. Prevent revisions except for authorized changes.  Once again, the integrity of your PMB is at stake and you risk having an Over-Target Baseline (OTB) after the fact.  It’s always best to know if the proposed changes would create an OTB condition, before you implement it.  Additionally, implementing revisions that are unauthorized can make your project management technique the equivalent of Whack-A-Mole; complete with moving targets and ensuing frustration.
  5. Document Changes thoroughly.  It may sound easy but proper documentation sometimes slips by when you’re in a rush.  Or, you may think you documented everything in sufficient detail within your before/after schedules, timephased budgets, etc., but then a new manager walks in and wants to know some tiny detail that you didn’t document.  And you can’t remember.  That’s not a good feeling!  I’ve also taken over projects where there was a total lack of documentation of changes and no one can figure out how the project got to that point.  This isn’t fun, and it’s taking away precious time that could be used to manage the project better.  So, the bottom line is: make sure any lunatic can follow your logic and come up with the same result.  A baseline change proposal should be a stand-alone document.
See a trend yet?  The main issue here is traceability and integrity of the PMB, supported by adequate documentation.  Never undermine your EVMS by delaying or reducing project performance visibility through improper change control and data maintenance. The tools you’ll need to successfully manage and implement the 5 criteria listed above can include: change control logs, change management procedures, an active change control board, documentation showing impacts on budget, schedule, and scope.  And, if able, use your EV software to print reports that show exactly what changed—which is fabulous for reconciling the before and after scenarios.  The rule of thumb for revisions and data maintenance is “proceed with caution and leave a clear trail of breadcrumbs”.

Do you have any war stories cause by inadequate management of revisions and data maintenance?  Please share in the comments!  Stay tuned for my next blog where I’ll discuss Finding EV Software with a Low PITA Factor.  

- Melissa Duncan (About Melissa)

Earned Value legend as there may be a few of us that don’t yet have this memorized…
CA=Control Accounts
CAM=Control Account Manager
CPI=Cost Performance Index
EAC=Estimate At Completion  
EVM=Earned Value Management
EVMS=Earned Value Management System
EAC=Estimate At Completion 
IPMR=Integrated Program Management Report
LOE=Level of Effort
OBS=Organizational Breakdown Structure
OTB=Over Target Baseline
PC=Project Controls
PM=Project Manager
PMB=Performance Measurement Baseline
RAM=Responsibility Assignment Matrix
SPI=Schedule Performance Index
WBS=Work Breakdown Structure

1 comment:

  1. Melissa, I disagree with Retro changes unless performed on the current reporting period where reports haven't been issued yet. Once a period closes and reports are generated there is no feasible way to go back and re-issue with corrected information. Talk about undermining the confidence in your system. To me there is NO good reason for a Retro change. Make the correction in the current period and talk about it in the VAR and move on..... Steve Spencer

    ReplyDelete