Revisions

Formal Reprogramming – What Happened?

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

Graph of an Increasing Budget

A long time ago, in a galaxy far, far away….an Over Target Baseline (OTB) – by design – was a rare occurrence (and the OTS concept did not even exist as part of Formal Reprogramming). Formal Reprogramming was a very difficult and cumbersome process that most contractors (and the government) really did not like to consider. The government, in its 1969 Joint Implementation Guide, said:

“Reprogramming should not be done more frequently than annually and preferably no more frequently than once during the life of the contract.”

The Office of the Under Secretary of Defense (OUSD) Acquisition, Analytics and Policy (AAP) – formerly PARCA – , in their latest OTB/OTS guide, states that Formal Reprogramming now has expanded to include an Over Target Schedule (OTS).  However, in that guide, it is stated in Paragraph 1.3.8:

“Ideally, formal reprogramming should be done no more than one time during the life of a contract. However, there may be instances where another formal reprogramming is warranted… When formal reprogramming is accomplished in accordance with the procedures in this guide, with a realistic cost and schedule estimate established for the remaining work, it should not be necessary to undergo formal reprogramming again.”

Today, though, whenever contractors incur a significant cost or schedule variance, instead of resolving the variance cause, the first words seem to be: “Let’s do an OTB or OTS.”  The lure of “getting rid of cost and schedule variances” seems too good to pass up.  Unfortunately, an OTB/OTS implementation has never been an instantaneous process. With AAP’s 12 step OTB/OTS process, it is obvious that the contractor will not be able to start today and incorporate the OTB/OTS in the next Integrated Program Management Data and Analysis Report (IPMDAR) dataset. In fact, AAP’s OTB/ OTS guide states in paragraph 3.8:

“It may be difficult to ascertain the length of time it will take to implement a new baseline based on the scope of the effort. It is not uncommon for the entire process to take up to six months which would be too long of a period without basic cost reporting.”

The last line of the above cited paragraph was referencing the reporting requirements to the customer when an OTB/OTS is being implemented.

The IPMDAR Implementation and Tailoring Guide (5/21/2020) even recognizes the issues with timeliness of implementing an OTB/OTS:

2.3.2.5.5  Formal Reprogramming Timeliness. Formal reprogramming can require more than one month to implement. During formal reprogramming, reporting shall continue, at a minimum, to include ACWP, and the latest reported cumulative BCWS and BCWP will be maintained until the OTB/OTS is implemented. 

So why does it take so long to implement the OTB/OTS?  Can the contractor just adjust the bottom line variances and move on?  Actually no, nothing is really that simple.  This is one of the reasons that implementing an OTB and OTS should not be taken lightly.   The AAP OTB/OTS Guide addresses adjustments this way:

“3.5.6.2 Adjusting Variances: A key consideration in implementing an OTB is to determine what to do with the variances against the pre-OTB baseline. There are essentially five basic options. This is a far more detailed effort than these simple descriptions imply, as these adjustments have to be made at the detail level (control account or work package).”

When considering the number of control accounts and work packages involved in a major contract, a Formal Reprogramming can become a rather daunting task.  The contractor also has to report the effects of the Formal Reprogramming in the IPMDAR Reprogramming Adjustments columns. These adjustment columns appear on both Format 1 and Format 2 of the IPMDAR database, which means the contractor must undertake the assessment for both the contract’s WBS and the OBS – for each WBS element and for each OBS element reported.  This can be further complicated if the OTB/OTS exercise were flowed down to subcontractors for a given program.  The AAP OTB/ OTS Guide, paragraph 3.8 also states:

“The customer should be cognizant of the prime contractor’s coordination complexities and issues with its subcontractors. The time to implementation may be extended due to accounting calendar month overlaps, compressed reiterations of contractor ETC updates, internal reviews, subcontractor MR strategy negotiations, senior management approvals, etc., all while statusing the normal existing performance within a reporting cycle.”

In the early days, when implementing an OTB with variance adjustments, the company and the customer agreed on a month-end date to make the data adjustments.  Then the contractor ran two CPRs or IPMRs (now the IPMDAR): (1) the first report as though no OTB had been implemented [to determine the amount of adjustments to cost variance (CV) and schedule variance (SV) at all the reporting levels] and, (2) the second report [after the OTB implementation had been completed – no matter how long it took] showing the Column 12 adjustments plus whatever BAC changes were being implemented.

Under the current OTB/OTS Guide, it appears as though this process is being done all at once. As stated in the AAP OTB/ OTS Guide paragraph 3.8 above, this implementation could take up to 6 months to complete, so lagging the second report until the OTB/OTS implementation is completed seems logical. The last sentence in paragraph 3.8 also stipulates that regardless of how long implementation takes, the contractor and customer will agree on interim reporting that will be required, further stating that:

“In all cases, at least ACWP should continue to be reported.”

Perhaps this agreement with the customer should also specify the content of the first IPMDAR following OTB/OTS implementation.

All things taken into account, the process of requesting and getting approval for an OTB or OTS can be a long and difficult process, especially if, at the end of it all, the contractor’s request is denied.  Even if it were approved and the contractor implements and works to the newly recognized baseline, immediately doing another one is not a pleasant thought – and remember, it was not intended to be pleasant. Reprogramming was always supposed to be a last resort action, when reporting to the current baseline was totally unrealistic.

Now, what about those cases where a contract has one or two elements reporting against totally unrealistic budget (or schedule) baselines?  The AAP OTB/ OTS Guide does cover a partial OTB, but reiterates that this is still an OTB because the Total Allocated Budget (TAB) will exceed the Contract Budget Base (CBB).  In the early days, however, the government allowed what was called Internal Operating Budgets (IOBs) for lower level elements (control accounts, or specific WBS elements, etc.) that were having problems resulting in an unrealistic baseline for the work remaining. The 1987 Joint Implementation Guide, paragraph 3-3. I (5) described IOBs as follows:

“(5) Internal Operating Budgets. Nothing in the criteria prevents the contractor from establishing an internal operating budget which is less than or more than the total allocated budget. However, there must be controls and procedures to ensure that the performance measurement baseline is not distorted.

(a) Operating budgets are sometimes used to establish internal targets for rework or added in-scope effort which is not significant enough to warrant formal reprogramming. Such budgets do not become a substitute for the [control] account budgets in the performance measurement baseline, but should be visible to all levels of management as appropriate. Control account managers should be able to evaluate performance in terms of both operating budgets and [control] account budgets to meet the requirements of internal management and reporting to the Government.

(b) Establishment and use of operating budgets should be done with caution.  Working against one plan and reporting progress against another is undesirable and the operating budget should not differ significantly from the [control] account budget in the performance measurement baseline. Operating budgets are intended to provide targets for specific elements of work where otherwise the targets would be unrealistic. They are not intended to serve as a completely separate work measurement plan for the contract as a whole.”

Current literature no longer specifically addresses Internal Operating Budgets (IOBs), but with the recent trend of contractors jumping to the OTB/OTS conclusion, it might be a better alternative to have individual instances of unrealistic budgets (or schedules) that do not otherwise push the total program to the need for a complete OTB and/or OTS implementation.

These could be good discussion topics for future AAP and DCMA meetings with industry representatives, to determine if there are ways to streamline the process, or at least reduce the amount of requests to implement Formal Reprogramming.  Variances are, after all, performance measurement indicators that should not just be routinely and artificially eliminated.

Formal Reprogramming – What Happened? Read Post »

Control Account Manager’s Log – A Valuable Tool

By /

It is not always easy on a rapidly changing project for a Control Account Manager (CAM) to keep track of where the Control Account is with regard to the current scope, schedule, and budget status and the history behind revisions, both directed and requested, approved or disapproved, and incorporated or pending actions.

The Control Account Manager’s Log is a valuable tool the CAM could use to keep track of all of the transactions affecting control account scope, schedule and budgets. This tool is most helpful to the CAM when there have been multiple Baseline Change Requests (BCR) submitted that are not necessarily approved in the order submitted (if approved at all) or are not approved as submitted; i.e., Program Manager approval varies from the CAM’s submittal. Using this type of Log, the CAM can track change requests as they are approved, rejected or altered. The CAM can update the Log with the change in scope, schedule, and budget for every change. The CAM can also compare what was submitted to what was actually approved and ensure that the scope, schedule, and budget amounts on updated Control Account Work Authorizations are correct for each transaction, or at least understand any reasons for the differences.

An example CAM Log is shown below. Obviously, the example can, and should, be tailored to fit the organization’s requirements. For example, the budget shown below is a total; one may want to show budget elements in terms of labor, materials, or other direct costs. If the organization issues budgets through overhead costs to the CAMs, then a logical breakout would be to show those as well as the direct budget elements.

Control Account Manager (CAM) log

For example, as you can see in the second transaction adding WBS 6.6.3.5, the entire amount was approved, increasing the total budget to $2,086,570. For BCR 171, however, the CAM submitted a request for $11,310 in September; in October the Project Manager’s decision was to approve only $11,200 from Management Reserve (MR), raising the total budget to $2,097,770. Meanwhile, BCR 194 was submitted requesting $121,320, but that BCR has not yet been approved, and since then three other transactions have taken place (AUW 101, BCR 162 approved, and BCR 182 was submitted but not yet resolved).

As you can see, without a CAM level log, it could easily become very difficult for a CAM to keep track of the control account’s budget.

Feel free to call or email us if you have any questions regarding this article. Your comments are always welcome.

Control Account Manager’s Log – A Valuable Tool Read Post »

Keeping Track of Budgets, Changes, and IPMR Data

By /

project IPMR DataFor projects, the moment the baseline is established it is subject to change and a disciplined approach in the change process must be in effect.  The source of project changes can be either external or internal. External changes frequently affect all aspects of a contractor’s internal planning and control system and are generally for effort that is out-of-scope to the contract.  Contract changes impact the Contract Budget Base (CBB) and are distributed to the Performance Measurement Baseline (PMB), which includes the distributed budgets containing control accounts, and Summary Level Planning Packages, and to the Undistributed Budget.

These changes may also impact the Management Reserve (MR) budget if the decision were made to withhold reserve from the budget for the change.  The Work Breakdown Structure (WBS) serves as the framework for integrating changes within the project’s structure.  Internal changes operate much the same, but they do not change the CBB. The most common reasons for internal changes are the allocation of MR for contractually in-scope effort, replanning of future work, and converting planning packages to work packages.

Keeping Track of Budgets, Changes, and IPMR Data

The Earned Value Management Systems Guidelines require that all changes, regardless of the source, be incorporated in a timely and disciplined manner. Consequently, the project needs to have a formal change process and procedures in place. Following these processes and procedures will also help minimize disruptions in the current effort while changes are being incorporated.  An undisciplined change control process has the potential to create timing or quality issues that will lessen the baseline’s effectiveness as a management tool.

Baseline changes must also be tracked to ensure baseline integrity. The most effective way to do this is to establish baseline logs to track all approved changes. These can include the Contract Budget Base (CBB) Log, as shown below, the Management Reserve (MR) Log, and the Undistributed Budget (UB) Log.  In addition, a log may be established to track all approved, unapproved and unresolved change requests.

Keeping Track of Budgets 2 blog

Once established, these logs must be maintained and reconciled to the data reported in the Integrated Program Management Report (or Contract Performance Report) that is delivered to the customer on a monthly basis. This reconciliation helps validate that the PMB accurately represents the project’s technical plans and requirements.

To find out more about this topic or if you have questions, feel free to contact Humphreys & Associates.

Keeping Track of Budgets, Changes, and IPMR Data Read Post »

Is it OTB/OTS Time or Just Address the Variances?

By / / ,
,

EVM: OTB/OTS Time or Just Address the VariancesNo project manager and project team ever wants to go through an Over Target Baseline (OTB) or Over Target Schedule (OTS).  The idea of formally reprogramming the remaining work and adjusting variances at the lowest level can be daunting and extremely time consuming. As painful as an OTB/OTS is, a project manager must first determine if the reprogramming is necessary.  Several factors should be considered before an OTB/OTS is declared and implemented.

NOTE: This paper addresses a Formal reprogramming as including both an OTB and an OTS.  If the Contract Performance Report is the CDRL Requirement, an OTS is not a part of a Formal Reprogramming.  It is a separate action.

Performance Data

Projected successful execution of the remaining effort is the leading indicator of whether an OTB/OTS is needed. Significant projected cost overruns or the inability to meet scheduled milestones play a major role in determining the need for an OTB/OTS as these indicators can provide a clear determination that the baseline is no longer achievable.

Leading indicators also include significant differences between the Estimate to Complete (ETC) and the Budgeted Cost of Work Remaining (BCWR). This is also demonstrated by major differences between the Cost Performance Index (CPI) and the To Complete Performance Index (TCPI).  These differences are evidence that the projected cost performance required to meet the Estimate at Completion is not achievable, and may also indicate that the estimated completion costs do not include all risk considerations. Excessive use of Management Reserve (MR) early in the project could also be an indicator.

 Schedule indicators include increased concurrency amongst remaining tasks, high amounts of negative float, and significant slips in the critical path, questionable activity durations and inadequate schedule margin for remaining work scope.  Any of these conditions may indicate that an OTB/OTS is necessary.

Quantified Factors

Various significant indicators in both cost and schedule can provide a clear picture that an OTB/OTS is warranted.  The term “significant” can be seen as extremely subjective and vary from project to project. For further evidence, other more quantified indicators can be used to supplement what has already been discussed.

Industry guidelines (such as the Over Target Baseline and Over Target Schedule Guide by the Performance Assessments and Root Cause Analyses (PARCA) Office) suggest the contract should be more than 20% complete before considering an OTB/OTS.  However, the same guidance also recommends against an OTB/OTS if the forecasted remaining duration is less than 18 months. Other indicators include comparing the Estimate to Complete with the remaining work to determine projected growth by using the following equation:

Projected Future Cost Overrun (%) = ([(EACPMB-ACWP) / (BACPMB-BCWP) – 1)] X 100

If the Projected Future Cost Overrun percentage were greater than 15%, then an OTB/OTS might be considered. Certainly the dollar magnitude must be considered as well.

Conclusion

There is no exact way to determine if an OTB/OTS is needed, and the project personnel must adequately assess all factors to make the determination. Going through an OTB/OTS is very time consuming, and the decision regarding that implementation should not be taken lightly.

After all factors are adequately analyzed, the project manager may ultimately deem it unnecessary and just manage to the variances being reported. This may be more cost effective and practical than initiating a formal reprogramming action.

If you have any questions about this article contact Humphrey’s & Associates. Comments welcome.

We offer a workshop on this topic: EVMS and Project Management Training Over Target Baseline (OTB) and Over Target Schedule (OTS) Implementation.

Is it OTB/OTS Time or Just Address the Variances? Read Post »

Rolling Wave Planning for Earned Value Management Systems

By / / ,
,

If someone were to ask you: “Can you please give me a detailed explanation of what you will be doing on this date three years from now?” you would probably look at that person as though he or she were crazy.  It would probably be difficult to provide a detailed schedule of events for a date one week from now – although that might be more likely since you know a lot more about what might be taking place next week than what might be happening three years out.

In the early days of earned value management, contractors were expected to detail plan the entire length of a program to establish a “good performance measurement baseline.”  For a year-long development program this expectation might be okay, but for a 10 to 12 year shipbuilding program it might be unreasonable and probably a monumental waste of time.  The program will no doubt change several times before its completion – maybe several times in the first year alone.  With industry’s “help” the government soon realized requiring detail plans on lengthy programs was not always possible – or even meaningful – especially when program requirements are often fluid.

The government and industry agreed that contractors could provide an overall (general, straight-line, “average”, etc.) plan for accomplishing a program very much like what is already done in preparing a proposal, and then provide more details on an incremental basis as more became known about the work to be performed.  The government is not keen on having contractors do detail planning whenever they felt the urge, so they sought to put reasonable rigor into the incremental planning process.  All the work that existed beyond the detail planned work was considered by the government to be general “planning packages”, although contractors were still permitted to detail plan as much of the future work as they wanted.

The government also expected the contractors to identify the planning increments and frequency of planning to ensure there was not a time when the detail planned work was completed and there was no more future work detail planned.  The expectation soon became that contractors were to expand a detail plan from those planning packages into detail planned work packages with enough frequency to ensure there was always a minimum number of months of detail plans in place when the next detail planning event took place.   It also became evident that more months of detail (often called a “planning horizon”) could be provided on production or manufacturing type work vs. for development type effort.

As this “straight-line” plan was converted into detailed work package plans, the straight line became more curved (such as bell curve or skewed bell curves), with more “waves” rolling in as it became time to detail plan.  This type of planning became known as “rolling wave planning”.  Some companies call their process “incremental”, “accordion”, or “inchworm” planning process – the name does not matter, so long as the application of the process results in a minimum amount of detail planned work packages always being in place on a program.

A production program might have, for example, a 9 month planning horizon with a quarterly frequency.  In this scenario, the program starts with 9 months of detail planning in place.  Three months later, the Control Account Manager (CAM) is to look at the next 9 months (6 already detail planned and 3 new months) to make sure the existing detail planning is still good and to plan out in detail those new tasks that should be starting in the new three months of the planning horizon.

A development program however, is likely to use a different planning horizon.  Because of program volatility, it often has a shorter horizon and a higher frequency, such as 4 months of detail planning in place, with a one or two month frequency.

An example for a production program is illustrated below.  The program manager determines production can do detail planning for nine months and then every quarter review the next nine months for:

  • New work scheduled to commence in the next three months of the planning horizon and
  • Five of the six months already detail planned in the prior incremental assessment (depending on the company’s “freeze period”) – WP No. 3 and beyond can be re-plannedRolling Wave Planning

3 Months later: Rolling Wave Planning

Rolling Wave Planning for long term projects is a common area where control account project managers need help.  Humphreys & Associates earned value management experts can provide the guidance you need for your unique production or development project.  Contact us for more information.

Follow us on Facebook and LinkedIn.

Rolling Wave Planning for Earned Value Management Systems Read Post »

Scroll to Top