DoD

Introduction to the Cost and Software Data Reporting (CSDR) Reporting Requirements

By / / , , , ,
, , , ,

A common client request is to assist them with sorting through the various DoD contractual reporting requirements and contract value reporting thresholds that apply. We frequently run into situations where a contractor needs clarification on why they have a Cost and Software Data Reporting (CSDR) requirement and whether they should seek to waive the requirement. Subcontractors to a prime often question the requirement to provide actual cost data directly to the DoD, especially for Firm Fixed Price (FFP) contracts.

Background

CSDRs are the primary means the DoD uses to collect data on the development, production, and sustainment costs incurred by contractors performing DoD acquisition contracts. It is a DoD system for collecting actual costs, software data, and related business data. The resulting data repository serves as the primary source for contract cost and software data for most DoD resource analysis efforts including cost database development, applied cost estimating, cost research, program reviews, analysis of alternatives (AoAs), and life cycle cost estimates.

CSDR reporting requirements are determined by the contract value regardless of the acquisition phase and contract type. In general, CSDR reporting is required for Acquisition Category I-II programs and Information System (IS) programs valued at more than $50M. They can also be required for Middle Tier Acquisition programs (greater than $20M) and other programs (greater than $100M). Risk can also be a determining factor regardless of the contract value.

DoD Instruction (DoDI) 5000.73, Cost Analysis Guidance and Procedures (March 2020), provides additional details about the cost data reporting. Table 1 in the 5000.73 lists the cost reporting requirements contract value thresholds. The DoD Manual 5000.04 Cost and Software Data Reporting (May 2021) is the primary requirements document for the development, implementation, and operation of the DoD CSDR system to ensure data reported is accurate and consistent.

About CADE

The Office of the Secretary of Defense Cost Assessment and Program Evaluation (OSD CAPE) established the Cost Assessment Data Enterprise (CADE), a secure web-based information system that hosts the controlled unclassified CSDR repository, the Defense Acquisition Cost Information Management System, and the forward pricing rate library. CADE also contains a selected acquisition report database, a contracts database, data analytics capabilities, and a library containing cost estimating content such as cost analysis requirement descriptions and cost estimates. CADE is access-controlled, and available through the public-facing CADE Portal website.

Similar to the cost estimating and proposal pricing functions within contractor’s organizations that rely on historical actual costs to assess the validity of a proposed cost estimate, independent and sound cost estimates are vital for effective DoD acquisition decision making and oversight. CADE plays a critical role in capturing the expenditure, technical, and programmatic data after contract execution in a consistent manner to enable independent cost estimating and analysis. This cost estimate data is essential to support efficient and effective resource allocation decisions throughout the planning, programming, budgeting, and execution process for the DoD.

CSDR Reporting Requirements

There are a series of Data Item Descriptions (DIDs) for this reporting requirement.  Some forms are submitted electronically using DoD defined XML schemas, Excel, or JSON encoded data in accordance with a File Format Specification (FFS) and Data Exchange Instruction (DEI). The list of DIDs are as follows. These DIDs can be downloaded from the CADE website.

  • Contract Work Breakdown Structure, DI-MGMT-81334D (May 2011).
  • Cost Data Summary Report, DI-FNCL-81565C (May 2011), DD Form 1921, XML Schema.
  • Functional Cost-Hour Report, DI-FNCL-81566C (September 2015), DD Form 1921-1, XML Schema.
  • Progress Curve Report, DI-FNCL-81567C (May 2011), DD Form 1921-2, XML Schema. 
  • Sustainment Functional Cost-Hour Report, DI-FNCL-81992 (May 2011), DD Form 1921-5, XML Schema.
  • Contractor Business Data Report, DI-FNCL-81765C (March 2021), DD Form 1921-3, Excel. 
  • Software Development Report, DI–MGMT-82035A (October 2022), DD Form 3026-1, XML Schema. 
  • Software Maintenance Report, DI–MGMT-82035A (October 2022), DD Form 3026-2, XML Schema.
  • Enterprise Resource Planning (ERP) Software Development Report, DI-MGMT-82035A (October 2022), DD Form 3026-3, XML Schema.
  • Cost and Hour Report (FlexFile), DI-FNCL-82162 (November 2017), JSON encoded data file following FFS and DEI.
  • Quantity Data Report, DI-MGMT-82164 (November 2017), JSON encoded data file following FFS and DEI.
  • Maintenance and Repair Parts Data Report, DI-MGMT-82163 (November 2017), Excel.
  • Technical Data Report, DI-MGMT-82165 (November 2017), Excel.

The Cost and Hour Report (FlexFile) and Quantity Data Report play a critical role in collecting cost data from contractors for the DoD data repository because they use JSON data encoding to organize the content. They are intended to replace the legacy 1921 series of paper-based formats including the DD 1921, 1921-1, 1921-2, and 1921-5. It also requires contractors to provide significantly more historical cost data than the 1921 formats. As a result, the DoD cost estimating community has additional insight into historical costs. The goal is to establish a common framework and standard nomenclature to collect data from different contractors, all of them with unique cost accounting structures, that are mapped to the DID, FFS, and DEI requirements for use in the data repository.

Establishing a Consistent, Repeatable Process to Produce the CSDR Data Deliverables

For contractors new to the CSDR reporting requirements and in particular, the FlexFile JSON data encoding, can appear to be daunting. That’s where software tools such as those from Midnite Dynamics can help. Midnite Dynamics specializes in assisting contractors with producing the CSDR data deliverables. 

Their software tool, C*CERT+, streamlines, automates, validates, and produces the legacy 1921 family of Excel and XML reports as well as the FlexFile and Quantity Data Report JSON submittals. C*CERT+ eliminates what otherwise is a manually intensive, resource draining, tedious and costly effort subject to recurring rejections. It is one thing to create the required legacy reports or FlexFile JSON files for submittal, it is another to pass the submittal validation process. C*CERT+ provides numerous data validations and analysis reports to ensure the data is 100% compliant before it is submitted. For example, the software includes over 90 FlexFile validations to ensure data compliance as illustrated in Figure 1.

Figure 1: Example of FlexFile data validation results.
Figure 1: Example of FlexFile data validation results.

The software includes a Validation and Remarks utility to analyze the source data details that could result in a Validation Trip. Remarks can be entered directly into the validation module for anything that requires an explanation. This is illustrated in Figure 2. This narrative is included with the data submittal.

Figure 2: Example of providing remarks about the FlexFile data content.

C*CERT+ also interfaces with existing EVM cost tools and accounting systems to produce the existing legacy 1921 reports, the FlexFile, and other data submittals as well as to consolidate separate projects/CLINs/task orders into a single contract report.

Once the C*CERT+ Standard Category Mapping Rules are set up, they can be shared throughout the corporation or business unit to establish a standard and repeatable process for producing the data deliverables. This mapping process translates the contractor’s source data into an output that matches the CSDR data submittal format rules. This saves a tremendous amount of time and makes it much easier to consistently produce the CSDR data deliverables. An example of the Mapping Rules is illustrated in Figure 3.

Figure 3: Mapping Rules translate contractor unique cost data into a format that matches the CSDR data submittal requirements.

Do your process and procedures or training materials need an update to include specific guidance for project control teams to produce required DoD contractual reports or data submittals using your tool sets of choice? Give us a call today at (714) 685-1730 to get started. 

Introduction to the Cost and Software Data Reporting (CSDR) Reporting Requirements Read Post »

EVM (Earned Value Management) vs. Agile Project Management

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

This article provides an introduction to the differences between an Earned Value Management System (EVMS) and Agile approaches on projects, and isolates the challenges of implementing an EVMS on a project where the project management has chosen to follow an Agile approach to the development work. The article explores the principles of EVMS and of Agile, and contrasts them to show where there are inherent conflicts. The article then discusses how the conflicts can be mitigated so that the benefits of both the EVMS and Agile can be obtained from a joint implementation.

Controlled Planning with EVMS

Controlled Planning with EVMS

Earned Value Management (EVM) Background

Earned Value Management is a 50 +/- year old methodology based on widely accepted principles that applies documented, systematized practices to support the processes of organizing, planning, directing, and controlling large complex projects, of any nature, which contain a high degree of uncertainty.

An EVMS is structured compliant to 32 guidelines that define what a project management information system should be capable of doing to support the program management team. Within the 32 guidelines there is a subset of generally recognized core principles. The core principles are:

  1. Organize the entire scope of the project using a Work Breakdown Structure (WBS).
  2. Organize the project team using an Organization Breakdown Structure (OBS).
  3. Integrate the project work with the project team to create management control points (Control Accounts).
  4. Schedule the project work in the Control Accounts across the entire project duration at the appropriate level of detail.
  5. Establish time-phased budgets for the scheduled work in the Control Accounts.
  6. Establish the scope/schedule/budget baseline as the Performance Measurement Baseline (PMB).
  7. Authorize the scope/schedule/budget and control the start/stop of work.
  8. Periodically measure the schedule and the value of completed work and determine the Earned Value.
  9. Record direct costs (actual costs) and summarize into the Control Accounts.
  10. Compare planned, accomplished, and spent to analyze the performance and associated variances.
  11. Develop realistic time and cost estimates for the remaining effort in the Control Accounts.
  12. Rigorously control changes to the Performance Measurement Baseline.

The EVM concept presented in these guidelines is a sound management approach, that once incorporated on any type of program, whether research and development, construction, production, etc. provides all levels of management with early visibility into cost and schedule problems.  Earned Value Management now appears as a contractual requirement on programs world-wide.  Primary EVM users include the United States, Europe, England, Canada, Australia, China, and Japan. It is a requirement of many U.S. Government agencies, including the Department of Defense (DoD), the National Aeronautics and Space Administration (NASA), the Department of Energy (DOE), the Intelligence Community, the Department of Homeland Security (DHS), the Federal Aviation Administration (FAA), the Department of Transportation (DOT), Health and Human Services (HHS), and others.

EVMS has been adopted by companies in situations where it is not a contractual requirement so that they can gain the discipline and benefits of the structural management approach discussed in the guidelines.

 

evms 2

Flexible Planning with Agile

Agile Background

Agile is a 20 +/- year old approach to applying a mindset that values the use of small, empowered, self-organizing, multi-functional teams, mainly in software development, to establish a test driven product development effort. This uses a series of short, rapid incremental builds within projects with a high degree of uncertainty to achieve shorter development times, lower costs, and products more closely aligned with customer requirements.

Agile does not usually appear as a contractual requirement. The concept is adopted by companies and organizations with the belief that a better product will be produced faster, and with less expense, using this approach than if traditional approaches were followed.

There are a core set of principles for Agile that were initially established in the copyrighted Agile Manifesto. These delineated core principles are:

  1. Early and continuous product delivery.
  2. Deliver working software (product) frequently.
  3. Expect change and respond positively to change.
  4. Developers and project business organization (PMO) work together.
  5. Product-focused build teams are at the core.
  6. Support self-organizing teams – trust among peers.
  7. Encourage face-to-face discussions (involve the user/customer).
  8. Working software is the measure of progress.
  9. Maintain a constant sustainable pace of development.
  10. Simplify the process and the product.
  11. Put the highest value on technical excellence.
  12. Improve team effectivity.

So How Does Agile Work?

The Agile mindset or approach is implemented through a process of defining the product backlog into smaller and smaller subsets of work that are structured in a top down fashion. At the lowest level of product backlog, the work elements or requirements can be prioritized and assigned to teams. The self-organizing teams pull work from the backlog and work the tasks to completion in a series of short, time-fixed Sprints or iterations. Sprints are often from 2 to 4 weeks long.

Because the teams are self-organizing, there is no team manager or team lead. The teams work as a group and only pull from the backlog at the last possible minute, and do minimal planning for each Sprint. If the product backlog is properly deconstructed and defined into user stories, then the planning meeting for an entire 4 week Sprint can be accomplished in a few hours.

The teams design, code, test, integrate, and deliver functionality in every Sprint. Since tested product is output every few weeks, all on the project can see the product being created and can contribute along the timeline, as needed, to provide a complete finished product.

The product owner embodies the customer’s perspective and either accepts or rejects the team’s work.  At the latter point of each Sprint, the tested product is demonstrated to the product owner.

High Level Side-by-Side

The two approaches are contrasted in the chart shown below. The EVMS is a methodology that is highly documented and highly systematized, while Agile is just the opposite. It is more of a mindset than a methodology with the preference not to have significant process documentation.

The EVMS is applied to entire projects and contracts, while generally Agile is applied to software portions of projects.  However, it could also be used on other development work.

The EVMS is usually a contractual requirement with significant implementation and operation constraints while Agile has none of these. As a contractual requirement, the EVMS carries with it the option for customer reviews and the threat of non-compliance, which entails penalties.

EVM Agile
Methodology Mindset
Documented Self-defined
Systematized Self-defined
Any type of project Software development (mainly)
High degree of uncertainty High degree of uncertainty
Applied to the entire project Applied to portions of the project
Often a contractual requirement Adopted not required

Lower Level Side-by-Side

In addition to the high level side-by-side, there are significant differences within the details of the two approaches. These are shown in the side-by-side table below.

Agile EVMS
Minimal documentation More documentation
Plan at last moment Plan ahead to end of project
Scope is flexible Scope is baselined and controlled
Expect and embrace change Avoid and/or control change
Schedule (Sprint) is fixed.  Timebox ends the Sprint. End the package when the work is done.
Budget is secondary Budget is baselined and controlled
Cost collection is not mentioned. Cost collection at the right level is critical

Accommodate and Capitalize on Differences

It is possible to implement Agile along with an EVMS if the EVMS application is set up to accommodate the differences and capitalize on them.

For example, the main reason that Agile’s embrace of change is a potential problem within an EVMS is because often the EVMS is used to plan too far in advance, and then reacting to change is difficult and expensive. If short term planning in the EVMS can be coordinated with the Agile planning, then the two can coexist.

The Agile free acceptance of scope changes within the backlog runs counter to the EVMS imposition of baseline change control. But if the EVMS baseline can be carefully set at a work level above the busy lowest level ups and downs, the impact to baseline change control is manageable.

A surprising chance to capitalize on Agile, within the EVMS, is found in the Scrum team approach in Agile where the team breaks work down into tasks far below what would normally be done in an EVMS, and then meets daily to update progress and provide corrective action. This low level constant attention means that the EVMS benefits from a better look at real progress as assessed by the real performers.

Not all the compromise needs be on the EVMS side of the equation. The Scrum team operations will often be defined to have the least possible recording of what happens during the Sprint. Since the product is king, then only the product really matters. But that misses the opportunities to capture the actions of the team for analysis, and use in upgrading their skills later. Necessary compromises would include some additional recording of the daily actions of the team and capturing the progress and problems. These would then be used in the EVMS functions of performance measurement, variance analysis, and corrective action planning.

One other compromise in the Agile realm that would be needed is the adoption of some minimum documentation of processes so that team operations can be repeatable and stable. Even a self-organizing team cannot change the way they work every time it wishes. That would raise the risk of a chaotic work environment.

These topics are recapped in the table below.

Agile EVMS Accommodation
Scope is flexible Select a higher level package for the baseline
Change is expected and embraced Have the shortest possible planning horizon
Plan at the last possible minute Have the shortest possible planning horizon
Daily Scrum Stand-up Meeting Collect the data and use it for performance measurement
Sprint Review Meeting Use for periodic measurement and analysis
Sprint Retrospective Meeting Use in Corrective Action Plans
Lack of documentation Add minimum documentation to stabilize team operations

Bottom Line

Implementing an EVMS is a challenge itself. Implementing Agile is a challenge too; perhaps a more difficult challenge. Implementing the two approaches side-by-side can seem impossible. But it is possible and even beneficial if done in a way the makes needed accommodations in both arenas for the project’s benefit.

EVM (Earned Value Management) vs. Agile Project Management Read Post »

Clarification on the New Department of Defense Earned Value Management System EVMS Thresholds | DOD & DPAP

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

New Department of Defense Earned Value Management System (EVMS) ThresholdsOn September 28, 2015, the Defense Procurement and Acquisition Policy Directorate (<abbr=”Defense Procurement and Acquisition Policy Directorate”>DPAP) released a memorandum entitled “Class Deviation – Earned Value Management System Threshold”. In this memo the DoD changed the threshold for <abbr=”Earned Value Management System”>EVMS application to $100 million for compliance with EIA-748 for cost or incentive contracts and subcontracts. That same memorandum stated that no EVMS surveillance activities will be routinely conducted by the Defense Contract Management Agency (<abbr=”Defense Contract Management Agency”>DCMA) on contracts or subcontracts between $20 million to $100 million. As attachments to this memorandum, there was a reissuance of the Notice of Earned Value Management System <abbr=”Department of Defense Federal Acquisition Regulations”>DFARs clause (252.234-7001) and the Earned Value Management Systems DFARs clause (252.234-7002), with both reflecting the new $100 million threshold.In response to this guidance, a series of questions from both contractors and other government personnel were submitted to Shane Olsen of the DCMA EVM Implementation Division (<abbr=”EVM Implementation Division”>EVMID). Below are the salient points from this communication:

  • There will be no EVMS surveillance of DFARs contracts under $100 million. Contracts without the DFARs clause, such as those under other agencies using the FAR EVM clause, will continue surveillance under their current thresholds.
  • The $100 million threshold is determined on the larger of the contract’s Ceiling Price or Target Price; as reported on the Integrated Program Management Report (IPMR) or Contract Performance Report (CPR) Format 1.
  • The threshold is based on the Contract Value including fee (at Price) as noted above. If there is an approved Over Target Baseline (OTB) which increases the Total Allocated Budget (TAB), this cannot push a contract over the threshold.
  • The new thresholds not only apply to subcontracts, but also Inter-organizational work orders with an EVMS flow-down.
  • Regardless of the circumstances, the DCMA will not conduct surveillance on contracts less than $100 million. However, if there are Earned Value issues that the buying command or other parties believe need to be reviewed, then the DCMA may conduct a Review for Cause (RFC) of the system against potentially affected guidelines.
  • The DCMA Operations EVM Implementation Division (EVMID) will not be conducting Compliance Reviews in FY-2016 unless there is an “emergent need”.
  • If a site is selected for a Compliance Review, only contracts greater than $100 million would be in the initial scope of the Implementation Review (IR). However, if an issue is discovered that requires the team to “open the aperture”, other contracts are not precluded.

The DCMA is still working on a response to the following questions:

  • How do I handle a contract that is currently below $100 million but has options that, in aggregate, would exceed $100 million?
  • How is the contract value determined on:
    • Indefinite Delivery/Indefinite Quantity (ID/IQ) Contracts
    • Non-ID/IQ with Multiple CLIN-Level or Task Order reports?

This blog will be updated and reposted as answers to these questions are given.

Clarification on the New Department of Defense Earned Value Management System EVMS Thresholds | DOD & DPAP Read Post »

Earned Value Management Implementation Guide (EVMIG) Rescinded

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

Earned Value Management Implementation Guide (EVMIG) Rescinded | DFARSThe DoD EVM Implementation Guide (EVMIG, Oct 2006) was rescinded on September 15, 2015 by the Office of Performance Assessments and Root Cause Analysis (PARCA). The EVMIG had provided guidance for understanding Earned Value Management System (EVMS) concepts; detailed procedures for implementing the EIA-748 EVMS Standard, Earned Value Management Systems (EVMS), on government contracts; tailoring guidance for EVMS application and reporting; and post award procedures. Most of the details contained in the EVMIG are also available in other, more recent, publications and the EVMIG is replaced with these other references. EVM System information can be found in the DoD EVM System Interpretation Guide (EVMSIG) which provides overarching DoD interpretation of the 32 EIA-748 EVMS guidelines. Additional information can be found in multiple Defense Contract Management Agency (DCMA) compliance instruction documents.

PARCA identified the following references to replace the contents and guidance found in the EVMIG:

EVM Concepts and Guidelines
EVM Concepts TBD EVM Analysis Guide
Defense Acquisition University (DAU) EVM Community of Practice
PARCA EVM Website
EVM System (EVMS) Concepts EVMSIG
DCMA Surveillance Guide

 

Procedures For Government Use of EVM
Organizational Roles and Responsibilities TBD EVM Application Guide
PARCA EVM Website
Defense Acquisition Guide (DAG)
WBS Development and Use MIL-STD-881C
TBD EVM Application Guide
EVM/EVMS Policy and Application TBD EVM Application Guide
PARCA EVM Website
Cost and Schedule Reporting Integrated Program Management Report (IPMR) Data Item Description (DID) and IPMR Guide
TBD EVM Application Guide
EVMS System Compliance EVMSIG
DCMA Surveillance Guide
Integrated Baseline Review (IBR) Program Manager’s Guide to the Integrated Baseline Review (IBR)
TBD EVM Application Guide
Reprogramming Formal Reprogramming Over Target Baseline (OTB)/Over Target Schedule (OTS) Guide
EVMSIG
Training Defense Acquisition University Website
PARCA EVM Website

Earned Value Management Implementation Guide (EVMIG) Rescinded Read Post »

DoD Earned Value Management System Interpretation Guide | EVMSIG

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

The updated DoD Earned Value Management System Interpretation Guide (EVMSIG), dated February 18, 2015 was released in March, 2015.

This DoD update, per the GAO, focuses on “(1) problems facing the cost/schedule control system (CS2) process; (2) progress DOD has made with reforms; and (3) challenges DOD faces in fostering and managing potentially significant changes”.

The update commences with:

EVMSIG INTRODUCTION

1.1 Purpose of Guide

Earned Value Management (EVM) is a widely accepted industry best practice for program management that is used across the Department of Defense (DoD), the Federal government, and the commercial sector. Government and industry program managers use EVM as a program management tool to provide joint situational awareness of program status and to assess the cost, schedule, and technical performance of programs for proactive course correction. An EVM System (EVMS) is the management control system that integrates a program’s work scope, schedule, and cost parameters for optimum program planning and control. To be useful as a program management tool, program managers must incorporate EVM into their acquisition decision-making processes; the EVM performance data generated by the EVMS must be timely, accurate, reliable, and auditable; and the EVMS must be implemented in a disciplined manner consistent with the 32 EVMS Guidelines prescribed in Section 2 of the Electronic Industries Alliance Standard-748 EVMS (EIA-748) (Reference (a)), hereafter referred to as “the 32 Guidelines.”

The DoD EVMS Interpretation Guide (EVMSIG), hereafter referred to as “the Guide”, provides the overarching DoD interpretation of the 32 Guidelines where an EVMS requirement is applied. It serves as the authoritative source for EVMS interpretive guidance and is used as the basis for the DoD to assess EVMS compliance to the 32 Guidelines in accordance with Defense Federal Acquisition Regulation Supplement (DFARS) Subpart 234.2 and 234.201 (References (b) and (c)). The Guide provides the DoD Strategic Intent behind each guideline as well as the specific attributes required in a compliant EVMS. Those attributes are the general qualities of effective implementation that are tested in support of determining EVMS compliance as it relates to the 32 Guidelines. As applicable, the DoD Strategic Intent section may clarify where differences in guideline interpretation exist for development and production type work. DoD agencies and organizations charged with conducting initial and continuing EVMS compliance activities will establish amplifying agency procedures and/or guidance to clarify how they are implementing this Guide to include the development of evaluation methods for the attributes associated with each of the 32 Guidelines.

1.2 EVM Policy

The Office of Management and Budget Circular No. A-11 (Reference (d)), the Federal Acquisition Regulation (FAR) Subpart 34.2 and Part 52 (References (e) through (h)) require federal government agency contractors to establish, maintain, and use an EVMS that is compliant with the 32 Guidelines on all major capital asset acquisitions. Based on these federal regulations and the DoD Instruction 5000.02 (DoDI 5000.02) (Reference (i)), the DoD established the Defense Federal Acquisition Regulation Supplement (DFARS) 234.201 (Reference (c)), which prescribes application of an EVMS, via the DFARS 252.234-7002 EVMS clause (Reference (j)). When EVM reporting is contractually required, the contractor must submit to the government an Integrated Program Management Report (IPMR) (DI-MGMT-81861) (Reference (k)) to report program cost and schedule performance data. The IPMR is being phased in to replace the Contract Performance Report (CPR) (DI-MGMT-81466) and the Integrated Master Schedule (IMS) (DI-MGMT-81650). Hereafter, for simplicity purposes, the term “IPMR” is used to reference legacy or current CPR/IMS DIDs. There are times in this Guide when the IMS reference is to an output of the contractor’s internal management system, i.e., a work product, which may not be referred to in the same context as the IPMR. [The full EVMSIG update is found here.]

Furthermore, also in March, 2015 the GAO released its “Report to the Committee on Armed Services, House of Representatives: Defense Acquisition | Better Approach Needed to Account for Number, Cost, and Performance of Non-Major Programs”.

An overview:

The Department of Defense (DOD) could not provide sufficiently reliable data for GAO to determine the number, total cost, or performance of DOD’s current acquisition category (ACAT) II and III programs (GAO-15-188 “Better Approach Needed to Account for Number, Cost, and Performance of Non-Major Programs” overview). These non-major programs range from a multibillion dollar aircraft radar modernization program to soldier clothing and protective equipment programs in the tens of millions of dollars. GAO found that the accuracy, completeness, and consistency of DOD’s data on these programs were undermined by widespread data entry issues, missing data, and inconsistent identification of current ACAT II and III programs. See the figure below for selected data reliability issues GAO identified. [The full GAO-15-188 document is found here.]

DoD Earned Value Management System Interpretation Guide | EVMSIG Read Post »

DFARS 252.234-7001 – “Thou Shalt Do Earned Value”

By /

Overview

Earned Value Management (EVM) have become increasingly relevant for industries like Biotech and Pharma.

Hypothetically, your organization has received a Request for Proposal (RFP) and wishes to bid for the work.  The RFP includes the clause DFARS 252.234-7001 if the cost to the government is anticipated to be in excess of $20M.  What choices does a company have?  First, the clause could be ignored and the bid made as Firm Fixed Price (FFP). However, this places the entire cost risk on the company and unless the scope is well known and routinely achievable, this risk may be unacceptable.

Otherwise, with any other kind of contract, be it incentive or cost plus, it will require the company to comply with the Earned Value Management Systems (EVMS) clause.  Assume that the proposal is anticipated to be in excess of $50M (as this is the most stringent requirement), your company does not have an EVMS, and it is decided to bid and include a plan to reach compliance.

The subject DFARS Clause requires that a contract be managed with a fully compliant Earned Value Management System as defined in EIA-748 (the latest revision is “C” dated March 2013).  If a system has not been validated, meaning accepted by the Government, the company must include in its proposal how validation will be achieved.

This includes a description of the system proposed to be used including an annotated checklist which addresses each of the 162 management system characteristics, proposed changes to the current system, resumes of the personnel who will design and implement a compliant system, how the Guideline requirements will be met, subcontractor compliance, and a time-phased plan to achieve EVMS compliance.

What is the Extent of the Requirement?

The answer to this question is the object of the first steps towards full Earned Value Management (EVM) system design, implementation, operation, and acceptance.

Step 1: Familiarize company management with the EIA-748 Guideline requirements.  This is usually done with a two to four hour presentation to management conducted by experienced EVMS personnel.  The single most important outcome from this presentation, leading to a successful EVMS implementation and acceptance by the customer, is senior management’s commitment in fully supporting the steps that follow.

Step 2: Review the current management control systems including existing software and identify which of these fully support the earned value requirements.  This information is then used to develop an implementation plan of the necessary tasks, their associated schedule as well as the costs of needed changes.

Step 3:  This significant step helps senior management to:

    1. Review the cost benefit of the EVMS and either change the proposal strategy to a Firm Fixed Price (FFP) bid and stopping the EVMS process without significant investment
    2. Decide to implement the system a step at a time and proceed with the design and subsequent implementation and maintenance of the EVMS; or
    3. Simply not bid

The Choice – Proceed to Implement

Assuming the answer is to proceed, the question becomes what are the next steps?

First, the management system is divided into the required subsystems such as:  work definition and assignment, planning and scheduling, budgeting, work authorization, accounting, material and subcontract management, data analysis and reporting, and change control.  Next, pertinent existing information and materials (forms, documents, reports, etc.) are gathered that support these same subsystems. Interviews are also conducted to determine the “real” needs.  After collecting the existing system documentation and understanding the processes from interviews conducted, the  system documents  are placed in sequence on wall flow charts, commonly called storyboards, which allow the identification of system/subsystem “holes” and/or “gaps and overlaps” versus the EVMS requirements.  New forms, procedures, software modifications and other additions can then be identified and developed to fill these holes.

At this point in the process, the final management system design should be developed and a revised implementation plan/schedule presented to senior management for approval.  Upon approval, the first step is now accomplished.

Second, is to develop an EVMS compliant System Description, procedures and associated desk top instructions.  The System Description is a document that defines the management system much like the operator’s manual to your automobile.  It is a “what to do” document and includes definition of the processes, depicts forms and reports used in and produced by the system, and describes how the system meets the requirements of the EIA-748 Guideline requirements. This is typically organized by the Nine Process Groups of organizing, scheduling, etc.  The procedures and desk top instructions define how to do it and support the requirements outlined in the System Description.  Procedures and desk top instructions define the detailed steps necessary for all requirements and what organizations are responsible for those steps.   With the system documentation in place, and upon its presentation and acceptance by management, the second step is now complete. You could say that you have now designed and built a new automobile and it is time to train people how to drive.

The third step is to train all levels of management in the operation and use of the EVM System.  This can be accomplished in groups (functional management, control account managers (CAM), IPT Leads, senior management, etc.), and/or by one-on-one training.

Fourth, once all of the above has been accomplished, the company is ready to apply and operate the EVM system on a project.  Ideally the project that was proposed has now been won, and it is the one with which the system will be implemented—and used.  It is much easier to put the system in place and begin to operate it on a new project/contract than it is to try and retrofit it onto an existing project.  This entails following the definition, planning, and authorization subsystem steps defined in the approved Management System Description, procedures and associated desk top instructions, and then producing the required data for analysis and reporting to management and the customer.  Generally speaking, three months of system data and reports are required by the customer before the next step can be undertaken.

Fifth, the next major step is the customer’s review of the EVM system and its subsequent acceptance and validation.  Once system operation has begun, at least one visit will be conducted by the customer’s EVMS representative (in the case of DOD contracts it is the Defense Contract Management Agency (DCMA)).  The visit(s) is conducted to assess the progress against the plan that was submitted in the original proposal.  The visit(s) is usually two to three days in length and conducted by three or four well qualified government representatives.

Once an organization conducts a self assessment and informs the reviewing agency that it is ready for their review, that agency reviews the documentation provided by the organization to determine readiness for a Validation Review.  This review will then be scheduled with the company.  It may be quite some time in the future, as there are very few DCMA representatives available and there are many companies requiring reviews of one kind or another.  A “data call” will occur which is a request for information such as 12 months of Contract Performance Reports (CPRs) or Integrated Program Management Reports (IPMR), the baseline logs from the beginning of the program, etc. When the review does occur, the program team should plan on 15 to 20 reviewers for at least two weeks. The company will need to provide all of the support the review team requires. This will include work rooms, computers, printers, and other elements that will be specified in the review notification.  Other preparations will include development of in-briefings, construction/updates of storyboards, and conduct of mock interviews with project and management personnel to prepare them for their government interviews.

The company cannot expect to complete the Validation Review without action items being assigned.  The DCMA will create Discrepancy Report(s) which will lead to Corrective Action Reports (CARs) that are rated by the degree of severity from 1 to 4. These system discrepancies will each require a Corrective Action Plan (CAP) to be developed and accepted by the DCMA, monitored, and progress reported to the DCMA.  Once the DCMA has accepted all of the responses, the company can expect to receive a formal “System Acceptance Letter,” but it should not heave a sigh of relief – there is still one more step to be accomplished.

The On-Going Process

This last step is Surveillance, the development and execution of a plan that ensures continued system operation in accordance with the EIA-748 Guidelines.  History has proven over the past 46 years that EVM Systems’ operation tends to degrade over time.  This occurs because of taking short cuts, lack of continued management commitment and emphasis, degrading system use, a “we are too big to be failed” attitude, and an occasional laissez-faire attitude.

While all of the steps except this last one can usually be accomplished in nine months to a year, the last one, Surveillance, will need continued operational discipline as long as a validated EVM system is required.

If you have questions on the DFARS clause 252.234-7001 or would like to explore EVM training options, please feel free to contact Humphreys & Associates.

DFARS 252.234-7001 – “Thou Shalt Do Earned Value” Read Post »

Scroll to Top