Who Owns Subcontractor Management Reserve (MR)?

, , ,
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 »

Video Series – Common Problems Found in EVMS and Recommended Corrective Actions – 5 of 5

, , , , , ,

When is it appropriate to use the simple PERT method to calculate the BCWP?   Can Management Reserve be negative? How do I choose a Control Account Manager?  Our final video in this series looks into questions like these. 

This is video 5 of 5  for the blog series “Common Problems Found in EVMS and Recommended Corrective Actions”.

The following links will let you skip to the specific part of the video related to the issues we are discussing.  (each link opens in a new tab)

Common Issues reviewed in this video:

0:22 – Inappropriate use of PERT and LOE

3:55 – Misuse of Management Reserve

6:48 – Administrative Control Account Managers (CAMs) Selection

You can also read the blog post here:

Video Series – Common Problems Found in EVMS and Recommended Corrective Actions – 5 of 5 Read Post »

Video Series – Common Problems Found in EVMS and Recommended Corrective Actions – 4 of 5

, ,

This month we are dealing with three new issues that are commonly found in EVMS.  Misalignment between BCWP and ACWP, Freeze Period Violations, Failed Data Traces.  Learn what you can do to identify and resolve these issues. 

This is video 4 of 5  for the blog series “Common Problems Found in EVMS and Recommended Corrective Actions”.

The following links will let you skip to the specific part of the video related to the issues we are discussing.  (each link opens in a new tab)

Common Issues reviewed in this video:

0:16 – Misalignment between BCWP and ACWP

3:07 – Freeze Period Violations

5:00 – Failed Data Traces

You can also read the blog post here:

Common Problems Found in EVM Systems and Recommended Corrective Actions – Part 4

Video Series – Common Problems Found in EVMS and Recommended Corrective Actions – 4 of 5 Read Post »

Video Series – Common Problems Found in EVMS and Recommended Corrective Actions – 3 of 5

, ,

If you have been following Humphreys & Associates YouTube channel you know we have been releasing new a video library reviewing some of our most successful blog series.

This month we released video 3 of 5  for the blog series “Common Problems Found in EVMS and Recommended Corrective Actions”.

The following links will let you skip to the specific part of the video related to the following issues.  (opens in a new tab)

0:15 – IMS Health Problems

3:30 –Data Item Noncompliance

5:17 –Planning Package Mismanagement

You can also read the whole blog post here:

https://blog.humphreys-assoc.com/common-problems-found-evms-recommended-ca-part-3/ 

Video Series – Common Problems Found in EVMS and Recommended Corrective Actions – 3 of 5 Read Post »

Video Series – Common Problems Found in EVMS and Recommended Corrective Actions – 1 & 2 of 5

Video Series – Common Problems Found in EVMS and Recommended Corrective Actions – 1 & 2 of 5 Read Post »

Agile Manifesto

, , , , ,

Agile Alliance

On February 2001, seventeen people convened at the Snowbird Ski Resort in Utah to find common ground and develop an alternative approach to document-driven, heavyweight software development processes. The group included representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Programmatic Programming. They named themselves the “Agile Alliance” and created and signed the Agile Manifesto which became the cornerstone for the Agile movement.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Streamlines Documentation

Historically, enormous amounts of time were invested in documenting the product for development and delivery. The list was extensive and included technical specifications, requirements, prospectus, interface design documents, test plans, documentation plans, and untimely approvals, resulting in bottlenecks and long cycle times. Agile does not eliminate documentation, rather, it streamlines documentation by providing the developer with just the essentials that are needed to do the work.

People Over Process

Valuing people more highly than processes or tools is easy to understand because it is people who respond to business needs and drive the development process. If the process or the tools drive development the team is less responsive to change and less likely to meet customer needs.

Negotiation vs. Collaboration

Negotiation is the period when the customer and the product manager work out the details of a delivery with points along the way where the details may be renegotiated. Collaboration is a different creature entirely, with development models such as waterfall, customers negotiate the requirements for the product often in great detail prior to any work starting.

This meant the customer was involved in the process of development before development began and after it was completed but not during the process. The agile manifesto describes a customer who is engaged and collaborates throughout the development process, making it much easier for developers to meet the needs of the customer.

Welcoming Change

Traditional software development regarded change as an expense and avoided it whenever possible. The intention was to develop detailed elaborate plans with a defined set of features and dependencies so that the team had a clear understanding of what should be developed and when it should be worked.

Agile welcomes changing requirements, even late in the development and uses rolling wave planning to decompose work just-in-time, without going into elaborate decomposition of the high-level plan.

12 Principles

The Agile Alliance also created 12 principles that support and expand on the four agile manifesto values. These principles have resulted in a number of widely accepted best practices that are used in many agile approaches such as extreme programming, scrum, DSDM, Adaptive Software Development, Crystal, and Feature-Driven Development.

The Agile Manifesto has spread like wildfire since 2001, forever altering the way we develop custom solutions and making impacts far beyond its original software origin.

Visual Representation of Agile Manifesto

Agile Manifesto Read Post »

Scroll to Top