EVM Terminology

EVM Terms

Earned Value Management and Agile Integration – Work Scope as the Foundation

By /

A previous H&A blog, “EVM (Earned Value Management) vs. Agile Project Management,” provided an introduction to the differences between an Earned Value Management System (EVMS) and Agile development methodologies.

At first glance, it may seem that EVM and Agile development methodologies are incompatible. Agile is all about rapid incremental product deliveries and responding quickly to an evolving understanding of the desired deliverable or outcome. Depending on how an EVMS is implemented, the EVMS can often seem rigid in comparison.

Can the two methodologies coexist and complement each other to create an effective integrated project management system? The answer is yes, provided you have thought through how you intend to use the two systems together and map how and where they integrate. The goal is to leverage the benefits of each system and without forcing either system to do something it wasn’t meant to do.

There is a natural top down and bottom-up process integration when defining the scope of work and acceptance criteria. This process integration continues for planning and scheduling the feature estimates of effort, establishing the budget baseline, and ultimately maintaining the estimate to complete (ETC) in the EVMS. It also supports an integrated process for measuring completed work. The Agile daily standup meetings provide current information about accomplishments and impediments at the lowest level of the project. The Agile system provides the quantifiable backup data for claiming earned value in the EVMS for performance reporting.

The following image illustrates the relationship between the two systems.

The source for this image is the NDIA IPMD Industry Practice Guide for Agile on EVM Programs, Revision May 2019, Figure 2-4.

The Foundation for Integrating EVM and Agile: Defining the Scope of Work

A work breakdown structure (WBS) is commonly used to organize and decompose a project’s scope of work into manageable, product-oriented elements. It is an essential communication tool for the customer and contractor so they have a common frame of reference to capture and manage requirements as well as expected deliverables or outcomes. It establishes a common basis for measuring progress and defining accomplishment criteria. It is the framework for developing a project’s schedule (timing of tasks), identifying resources to accomplish the scheduled tasks, creating cost estimates as well as the budget baseline, and identifying risks. In an EVMS, the WBS is often decomposed to the control account level which is further decomposed into work packages or planning packages. Once extended to the lower level, it provides a framework for tracking technical accomplishments, measuring completed work, and identifying variances from the original plan to complete the work.

There is a similar planning hierarchy to Agile projects – the Product Backlog is the foundation for defining the scope of work. The Product Backlog starts at the Epic or Capability level and is further defined through product planning. The process includes prioritizing the capabilities and defining the sequence of deliverables to create the Product Roadmap (timing). The capabilities are decomposed into features along with an estimate of the effort to deliver the feature. Features should include exit criteria (definition of done) and have minimal dependencies. At the lowest level, features are decomposed into Sprint Stories and related tasks forming the basis for the schedule and measuring completed work in the EVMS. As illustrated in the image above, in the Product Backlog hierarchy, an Epic/Capability relates to the control account level in the EVMS. Features relate to the work packages in the EVMS.

In an integrated environment, there can be a natural mapping between the WBS and the Product Backlog regardless of the starting point. When starting from the Agile system, the Product Backlog could be used to create the project’s WBS. The customer may also pre-define the top level WBS elements that could form the backlog structure. The DoD uses MIL-STD-881, Work Breakdown Structures for Defense Materiel Items, for this purpose so they have a set of common templates they can use across programs to capture historical actual cost data for cost estimating and should cost analysis. Even though the top level WBS elements may be pre-defined, the lower-level content can reflect an outcome based Agile structure that focuses on customer driven deliverables.
An example is illustrated here.

Possible Agile software development MIL-STD-881 WBS breakout. The source for this image is the DoD ADA Agile and Earned Value Management: A Program Manager’s Desk Guide, Revision November 2020, Figure 2.

What’s common between the two systems?  You have:

  • Decomposed a common understanding of the scope of work into manageable, product or outcome-oriented elements of work.
  • Defined the agreed upon accomplishment criteria or definition of done for a given deliverable or outcome.
  • Built a framework to determine the timing of tasks, identifying the resource requirements, creating a cost estimate to do the work, and means to objectively measure completed work.  Ideally, you have also identified the risks or uncertainties so you know where potential issues may surface.

Best Practices for Integrating the WBS and Product Backlog

Keeping in mind you have a similar decomposition of work between the two systems, you can set up the WBS and Product Backlog to align with each other.  The goal is to ensure traceability so you can easily support the EVMS requirements. 

Here are a few best practices for integrating the WBS and Product Backlog.

  1. Verify the WBS aligns with the prioritized Product Backlog to at least the Epic/Capability level (control account level in the WBS).  Determine how you intend to maintain traceability between the WBS elements and the work items in the Product Backlog so it doesn’t matter which system you use to review or confirm the agreed upon scope of work.  Identify and document how you intend to map the WBS elements to a work item in the Product Backlog so you always have the necessary cross references identified.  Keep it simple.  Where possible, minimize the need to enter something more than once. 
  2. Use the Product Backlog to tailor the WBS.  This is particularly true for projects where Agile development is central to the final deliverable.  Consider your two end objectives: you need to provide project performance reporting via the EVMS and organize the items in the Product Backlog so you can decompose them from the Epic/Capability level to the Feature level and then to the Sprint Story and task level.
  3. Watch the level of detail in the WBS.  Avoid driving the WBS to too low a level of detail.  Depending on the project, it may be appropriate to go no lower than the Epic/Capability level (control account level).  The reasoning: in the Agile system, the lower-level Stories and tasks are flexible and subject to change.  You are focused on completing current near-term work effort within a Sprint.  Better to let the Agile system manage and track what is happening at the rapidly changing detail level – it is designed to do that.  For EVMS purposes, project monitoring and control should be at a higher level where scope can be consistently defined, aligned to the schedule and budget, and claimed as done (technical accomplishment).  The WBS should reflect the level of detail that is aligned to the permissible variation in requirements or configuration.  Otherwise, you create too much change “noise” in the EVMS.
  4. Confirm the WBS and Product Backlog contains 100% of the contract scope of work.  Verify the statement of work has been mapped to the WBS elements or work items in the Product Backlog.  Why is this important?  You need to demonstrate you have captured the entire technical scope of work to at least the Epic/Capability level.  You need this for internal planning purposes so your development teams have an understanding of the technical requirements and expected outcomes as well as managing changes.  Your customer also needs confidence that you have an understanding of the entire scope of work and have planned accordingly for the duration of the project. 
  5. Verify you have defined the Feature accomplishment criteria or definition of done so it is easy to measure completed work.  This could be in the WBS dictionary or documented in the Agile system Product Backlog.  Determine where that information can be found and document the process to maintain it.  Ideally it is in one place so you only have to maintain it in one system and everyone on the project knows they are referencing current information.  Clearly defined accomplishment criteria mean you can objectively measure accomplishments – in both systems.  Enable that capability right from the start when you set up a new project in the two systems.

Are your EVM and Agile systems are sharing useful information?  Perhaps you have learned the hard way the WBS and Product Backlog aren’t sufficiently mapped for you to maintain traceability between the two systems.  We can help.  Call us today at (714) 685-1730

Earned Value Management and Agile Integration – Work Scope as the Foundation Read Post »

New IPMDAR DID and Implementation Guide

By / / , ,
, ,
ALERT- New IPMDAR DID and Implementation Guide

The New Integrated Program Management Data and Analysis Report (IPMDAR) Data Item Description (DID) and Implementation Guide

On March 12, 2020, the Defense Department (OUSD/AAP) instituted the new Integrated Program Management Data and Analysis Report (IPMDAR), issuing the Data Item Description (DID) Number: DI-MGMT-81861B.
The IPMDAR is to be used for solicitations and RFPs for contracts with an EV reporting Requirement starting from March 12, 2020 forward. The IPMDAR can also be applied to modified contracts or to existing contracts (under the old IPMR or CPR requirements), but this has to be through a bi-lateral agreement (Government Program Office and Contractor).

Significant Change

This IPMDAR is a significant change from the previous iterations, the Integrated Program Management Report (IPMR) and the old Contract Performance Report (CPR). The IPMDAR has dispensed with the delivery of physical reports (Formats 1 – 7 of the old IPMR/ CPR), instead now requiring contractors to provide three (3) specific electronic data sets:

  • The Contract Performance Dataset (CPD)
  • The Schedule, comprised of
    • The Native Schedule File and
    •  The Schedule Performance Dataset (SPD)
  • The Performance Narrative Report, comprised of
    • The Executive Summary and
    • The Detailed Analysis Report

The DID states: “The IPMDAR’s primary purpose to the Government is to reflect current contract performance status and the forecast of future contract performance.”

Integrated Program Management Data Analysis Report (IPMDAR) Implementation & Tailoring Guide

Implementation & Tailoring Guide

To help expedite the adoption of the New IPMDAR, on May 21, 2020, the AAP office also issued the 87-page Integrated Program Management Data Analysis Report (IPMDAR) Implementation & Tailoring Guide:
“This guide covers the application of the DID, how to tailor the DID in the Contract Data Requirements List (CDRL), and clarification on the intent of the DID.”

Interesting Features

The IPMDAR has introduced some interesting features that are clarified in the Guide:

  • The default reporting is at the Control Account, but there is the option to have Work Package Level reporting (negotiated item)
  • Reporting is by Hours and Elements of Cost (EOCs) (for either the CA or WP level)
  • Time-phased Future Baseline (BCWS) and ETC Forecast (for either CA or WP level)
  • Best Case/Worst Case/Most Likely EACs reported by hours and dollars
  • The Native Schedule is a direct export from the contractor’s scheduling tool
  • The SPD must match the CA or WP level negotiated
  • The Government may have any subcontractors provide the IPMDAR directly to the Government
    • Even if this is required, the subcontractors must still provide the IPMDAR data to their prime contractor
  • The IPMDAR reporting components must be delivered to EVM-CR not later than 16 business days after a contractor’s accounting period
    • Incremental deliveries may be authorized, but all the items must be in NLT the 16th business day and the incremental deliveries are negotiated. A potential example is IMS by third working day after close-of-month, the raw data by fifth working day, and format 5 narrative by the sixteenth working day.
  • Historical Contract Performance Data – The Government may request this “time-phased historical data from contract award” in place of the normally provided CPD (typically no more than annually).

Applicability

IPMDAR Applicability:

  • IPMDAR is intended to be applied completely (i.e., not tailored) for cost or incentive contracts ≥ $20M – unless tailoring is specified within the DID and coordinated with the Service/ Agency EVM Focal Point.
  • If EVM reporting is required on contracts less than $20M, tailoring is more flexible, BUT the Native Schedule and Performance Narrative Report are recommended.
  • IPMDAR typically not required on FFP.

Humphreys & Associates, Inc. can help you properly implement the new IPMDAR requirements, please contact us at (714) 685-1730

New IPMDAR DID and Implementation Guide Read Post »

Who Owns Subcontractor Management Reserve (MR)?

By / / , , ,
, , ,
Who Owns Subcontractor Management Reserve?

Subcontractor, Prime Contractor… Customer?

There has long been discussion regarding who “owns” a subcontractor’s Management Reserve (MR).  Some believe that since the entire contract value was awarded by the prime contractor to the subcontractor, the MR belongs to the prime.  Unfortunately, they might have been influenced by some of their customers who believe a prime contractor’s MR belongs to the customer – even to an extreme in which the customers interject themselves in the prime contractor’s decision process in using their MR. So contractors might figure that if the customer is doing that to them, they should do the same to their subcontractors.

DCMA Cross Reference Checklist

They may try to justify this by pointing out that in the DCMA Cross Reference Checklist (CRC dated 22 March 2019) Guideline # 14 Sub-question b asks:  

“Is major subcontractor Management Reserve (MR) incorporated and traceable to the prime contractor’s EVMS?”

While this might sound to some as though it justifies the argument that the MR belongs to the prime, it really doesn’t.  The actual guideline 14 question is simply asking if the contractor implementing EVMS (in this case the subcontractor) simply does or does not “Identify management reserves and undistributed budget.”  Since the subcontractor is implementing their management system on their contract with the prime, the only requirement is that the subcontractor identifies a Management Reserve (MR) amount (which could be zero, by the way). If they do, then (strangely) subquestion b puts the onus on the prime contractor to reflect the subcontractor’s MR in their EVM system [i.e., strange because how would a subcontractor demonstrate to a review team that their MR is being reflected in the prime’s EVM System?]. This question would be more appropriate if the subcontractor was also the prime to a lower-tier subcontractor.

Reporting vs. Ownership

The above only addresses the reporting of a subcontractor’s MR, but what does the government documentation actually say about the “ownership” of the subcontractor’s MR?

Note: A point to remember in this entire discussion is that the Guidelines, the EVMIG, the Cross Reference Checklist (CRC), and the EVMSIG were written to apply to any contractor required to implement EVMS on a contract – whether they be a prime contractor to a government customer or a subcontractor to a prime contractor (their “customer”).

EVMSIG Chapter 3 Introduction

The EVMSIG Chapter 3 Introduction (pg. 17) says this about MR:

“An allowance is made for a portion of the CBB to be withheld outside of the PMB as Management Reserve (MR) for internal management control purposes. MR is intended to provide the contractor with a budget to manage risk within the established contract scope (Guideline 14).”

As this introductory paragraph points out, MR is established by the contractor (or the subcontractor) for their internal management control purposes to have budget to manage risk within the contract scope. There is no mention of customer involvement in the decision-making process.

Para 3.9 (Guideline 14), Intent of Guideline

A more definitive statement in the EVMSIG is: “Para 3.9 (Guideline 14), Intent of Guideline” in the second paragraph – bullets and underlines have been added for emphasis:

  • “MR belongs to the contractor Program Manager, not the Government,…” [ergo, NOT the prime in a prime/ sub relationship]
  • [It] “provides the contractor with a budget for unplanned activities within the current program scope. MR enables program management to respond to future unforeseen events within the work scope of the program by distributing budget to mitigate program risks.”
  • “To establish MR, the contractor’s program management sets aside budget based on the program’s risk management process and assessment.”
  • [MR] “is not a source of funding for additional work scope or the elimination of performance variances.”
  • “MR is not a contingency fund and may neither be eliminated from contract prices by the customer during subsequent negotiations nor used to absorb the cost of contract changes.” And finally,
  • “MR belonging to a major subcontractor must be incorporated into the prime contractor’s EVMS with traceability to the subcontractor’s reported MR.”

Subcontractor Reports

This last bullet specifically points out that the MR belongs to the subcontractor, and that it must be reflected in the prime’s EVMS as reported by the subcontractor.  Some choose to include a subcontractor’s MR in their own MR value; having it there, however, increases the risk of having the prime think they have more MR to use when, in fact, they do not.  The subcontractor’s MR is not the prime’s to use, so the prime would need a very good mechanism in place to keep the two MR amounts separated.  This needed segregation becomes more complicated if the prime has more than one subcontractor.  Regardless of where the contractor places the subcontractor MR, EVMS requires it to be traceable to the MR value the subcontractor reports.

A Contractor’s Control Mechanism

Management Reserve (MR) is something that is allowed to provide a contractor with flexibility in handling the unknowns on a contract.  It doesn’t matter if it is a prime contractor to a government customer or a lower-tier subcontractor to a higher level (or prime) contractor.  MR is a contractor’s control mechanism and should not be subjected to any level of customer involvement.  The guidelines and implementation/ interpretation documentation try to control improper uses of MR (e.g., covering performance variances, performing out of scope work, etc.), but customers – at all levels – should not interject themselves in a contractor’s decision-making process on the use of MR. Remember also, if customers involve themselves in that process, there is a risk that their perceived “direction” to the contractor could make them complicit in poor MR decisions.

Who Owns Subcontractor Management Reserve (MR)? Read Post »

EVM Consulting | Corrective Action Response

By / / , , , , , , ,
, , , , , , ,

Corrective Action Response

How do I respond to a Corrective Action Request?

In EVM Consulting, we deal with Corrective Action Requests (CARs) on a regular basis, so we have plenty of real-world experience. We created an outline of valuable information about DRs / CARs based on our collective experience. Part 1 of the guide is designed to inform you of why CARs are received and who issues them, so you can work to prevent them. Part 2 will prepare you to respond to a CAR in an effective and efficient way.

Corrective Action Response: Sources – Part 1 of 2

In Part 1 of the series we illuminated the varied sources of Corrective Action Requests:
1) Standard Surveillance Instruction (SSI)
2) Agencies that do not use the DCMA for surveillance, such as the Department of Energy.
3) Integrated Baseline Review (IBR)
4) Procedures that are compliant with the EIA-748 Guidelines
5) Contract Performance Report (CPR)
6) Integrated Project Management Report (IPMR)
7) Integrated Master Schedule (IMS)
8) Discrepancy Reports (Levels I-IV)

 

Corrective Action Response: Planning and Closure – Part 2 of 2

In part 2 of the series, we addressed responding to a Corrective Action Request (CAR):
1) Review the DRs/CARs with the customer
2) Organize for successful CAP management
3) Begin a thorough Root Cause Analysis
4) Develop and evaluate Corrective Action Plans
5) Develop verification closure steps
6) Develop a detailed Integrated Master Schedule for CAP implementation
7) Submit CAP and CAP IMS to the customer for approval prior to implementing the Corrective Actions
8) Implement Corrective Action Plans and track progress to successful completion
9) CAR closure and follow-up

EVM Consulting | Corrective Action Response Read Post »

Scroll to Top