Work Breakdown Structure (WBS) Archives

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

By Humphreys & Associates / June 1, 2021

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.

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

Formal Reprogramming – What Happened?

By Humphreys & Associates / October 20, 2017 / CPR/IPMR, DCMA, Formal Reprogramming, Internal Operating Budgets (IOBs), IPMR, OBS, OTB, OTS, Over Target Baseline (OTB), Over Target Schedule (OTS), parca, wbs

CPR/IPMR, DCMA, Formal Reprogramming, Internal Operating Budgets (IOBs), IPMR, OBS, OTB, OTS, Over Target Baseline (OTB), Over Target Schedule (OTS), parca, wbs

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 »

Budgeting for Rework | SRR & EVM | Earned Value Management

By Humphreys & Associates / February 22, 2016 / budgeting for rework, CAM, earned value management, EVMS, Integrated Master Schedule, Management Reserve, OTB, Scrap Rework Repair, SLPP, SRR, summary level planning packages

budgeting for rework, CAM, earned value management, EVMS, Integrated Master Schedule, Management Reserve, OTB, Scrap Rework Repair, SLPP, SRR, summary level planning packages

One of the Earned Value Management (EVM) topics that always initiates lively debate is the planning of Scrap, Rework, and Repair (SRR). These debates often become very emotional. So, what makes the topic of planning SRR so emotional? There are two primary factors. First, you are planning for something that is not in alignment with a success oriented plan. In an ideal project there would be no Scrap, Rework, or Repair. Second, we do not know what parts will require SRR or when it will occur. Let’s start with baselining some definitions:

Scrap – Manufactured articles or parts that are rejected or discarded. Waste that either has no economic value or only the value of its basic material content. Examples include a part that was made too small or a part that was damaged and could not be repaired.
Rework – The process of bringing a non-conforming part back into conformance by re-performing a previous process step. An example would be a part with a hole that was drilled undersize that could be re-drilled to the correct size.
Repair – The process of bringing a non-conforming part back into conformance by using a process outside the original process. An example would be a part that was painted and the undersized hole was not discovered until after it was painted. The repair now requires additional process steps, of stripping and re-preparing the material, that were not part of the original process. (Note: for this discussion we will focus on inline repairs. Repairs that arise post acceptance are not included in this discussion.)

Along with these basic definitions, we need to understand how your company defines and handles these costs. Some companies treat these costs as indirect and some treat them as direct costs. When these costs are classified as indirect costs, the company establishes material overhead pool(s) that collect the costs for allocation across the direct material dollars. These pools might be segregated by material type and have different allocation bases. A company’s CASB Disclosure Statement will define the pools and bases. Some companies treat these as direct charge items and will have procedures for the treatment of SRR and non-conforming material costs. RULE 1 – The budgeting of SRR must be consistent with the way costs are collected and charged. Because of the vagueness of knowing what parts will require SRR and when it will occur, the indirect costing approach is the most straight forward method within an Earned Value Management System (EVMS).

Next we need to understand how your company’s shop floor works and how non-conforming material is handled. Most shop floors work with shop orders that are issued to direct how parts are processed and routed through the process. As a part is processed into a higher level part or subassembly the costs are usually collected at that next level part/subassembly. In this way each part’s cost can be established by summarizing all the lower level parts and routing steps. In an EVMS, these shop orders are usually grouped into work packages. Usually the shop floor has procedures in place to identify the cause and corrective action associated with an issue when a part is identified as non-conforming. The corrective action approach will define what will have to be done to resolve the issue. The corrective action can be anything: scrapping and starting over from an earlier process step with an updated procedure, re-procuring, repairing, or reworking. In any corrective action approach, new procurement request(s) and/or shop order(s) will be issued with new direction. The costs are then collected and handled based on how your company has defined the process. Most companies have an additional requirement to segregate these costs to support their Cost of Quality program/system. (We could dive deeper into the processes for each scenario, but that is not the focus of this blog.)

Now that we have some basic understanding of what SRR is, how it is handled on the shop floor, and how it is costed, we can look at how to budget it in an EVM environment. Remember, we do not know what parts will need SRR, and for those that will need SRR, we do not know when it will be needed.

Let’s take the indirect costing approach first. The budget for SRR is established by the overhead factor being applied to the base cost. The value of the overhead rate is determined based on the annual planning process. As a dollar of the base material pool is planned, the SRR rate is applied. An owner is established for each pool that will also be the source for future variance analyses and forecasts.

For the direct costing approach there are several options. The following are the most common planning and budgeting options used:

Control Accounts with Planning Packages
Summary Level Planning Packages
Management Reserve
Unplanned SRR

The first 3 options have an amount of SRR that has been identified either as a factor based on historic data or as part of the Risk Management process. This SRR is usually identified to an assembly, sub-assembly, or part. The fourth option addresses an SRR event that was not planned in the baseline.

The first option is to include SRR in the Scope of Work for the production Control Account(s). The CAM then establishes one or more planning packages for SRR. The planning package(s) are associated with a grouping of parts and/or timing for effort in the future beyond the detailed planning horizon. As SRR is identified, the planning package is detailed planned (partially or in its entirety) into a work package. The procurement directions and/or shop orders that make up the non-conforming corrective action are grouped to make up the work package. In this approach it is possible that the conversion from planning packages to work packages will occur in the current accounting period; note that this approach might be in violation of a company’s defined freeze period procedure. When there is enough insight into the items identified as possible SRR candidates, including the timing of the SRR, a budget will be pulled from the planning package into a work package as part of the normal rolling wave planning cycle. The goal always should be to plan the effort into work packages as early as enough information is available. In this scenario the CAM will assess performance, perform variance analyses, and provide forecasts.

The second option is to budget a Summary Level Planning Package (SLPP) at a WBS level higher than the Control Accounts. This approach is used when SRR is planned for a WBS element but the specific Control Account cannot be identified. This budgeting approach works similar to converting from planning packages to work packages, but there are additional steps to authorize and issue scope and budget from the SLPP to the CA. The Program Manager, Integrated Product Team Lead, or WBS Element Manager will provide forecasts for the SLPP as part of the EAC process.

The third option is for the Program Manager to hold the budget for SRR in Management Reserve (MR). As SRR is identified, the CAM will request MR using the normal change control process. The PM will address the MR when analyzing the program’s overall performance.

The fourth option addresses how to handle unplanned SRR. Often these approaches of creating new Work Packages and making Earned Value adjustments may “violate one or more EVMS rules” but pass the cost/benefit common sense rule. In this option the new procurement direction and/or shop orders are added to the existing work package grouping. There is no new budget allocated and the additional actual costs that are collected are explained as a variance. If that work package had been closed it will need to be re-opened. If cumulative BCWP is now overstated, it may need to be adjusted (de-earned) to reflect that work is still remaining. The ETC/EAC is also updated to reflect the estimated timing and cost for the SRR. If you select this approach, make sure your system description and procedures allow for these exceptions to generally accepted rules. This approach may drive numerous anomalies in the EVM data, which will need to be explained in Format 5 of the Contract Performance Report or Integrated Program Management Report.

If the SRR is a large amount of work and will take a significant amount of time, it might warrant establishing an Over Target Baseline/Schedule (OTB/OTS). If this is the case, be sure to discuss the approach with your customer.

Additional Cautionary Tales and Lessons Learned:

Cost versus Benefit – Make sure that your manufacturing system can support what is described in your EVM System Description. Also, understand the cost impact for the process benefits that you are designing. Sometimes the benefit does not justify the cost.

Understand how your manufacturing and accounting systems handle scrap, rework, and repair. These are the source systems that will drive how you handle SRR for Earned Value Management.

Material and Labor Cost in the Same Work Packages – If the part that requires repair or rework was a buy item, it was budgeted as material. The repair or rework may appear as labor. Some systems restrict the comingling of production material and labor in the same work packages. In the case of SRR that restriction should not apply.

Purchasing Clauses – Ensure that SRR and the associated costs are adequately addressed in purchasing clauses for buy parts. Also, make sure you understand how major subcontractors with an EVMS flowdown requirement handle SRR in their systems.

Fast Tracking increases the risk of SRR – Starting Low Rate Initial Production prior to completing the design and development effort will lead to starting production with a dynamic technical data package. This increase in risk will also increase the amount of SRR that can be expected on a project.

SRR outside the shop floor – There are similar issues that need to be addressed when performing Software, Integration, Spares, Tooling, and Testing efforts.

Make sure your system description reflects how you handle the budgeting, earning, estimating, and costing of SRR.

We only addressed the topic of BUDGETING Scrap, Rework, and Repair at a summary level in this blog. The devil is always in the details. We recommend that you test your approach in your systems prior to implementing to ensure your tools operate as you expect. If your EVMS is validated through the DCMA, or other validating/certifying agencies, you should seek their approval of your procedures prior to implementation. Also, the Integrated Master Schedule (IMS) process and Risk/Opportunity Management System need to address SRR.

Budgeting for Rework | SRR & EVM | Earned Value Management Read Post »

EVMS and Agile Implementation FAQ’s

By Humphreys & Associates / February 4, 2016 / agile management, agile method, agile planning, agile project management, agile systems, DoD EVMS, EVM, EVMS, evms planning, project management, wbs

agile management, agile method, agile planning, agile project management, agile systems, DoD EVMS, EVM, EVMS, evms planning, project management, wbs

Title Image - EVMS and Agile Implementation FAQs

These are some of the frequently asked questions we receive when discussing EVMS and Agile implementations within the same company or on the same project.

Question 1: What documentation do you have that I can use to help me understand EVMS and Agile and how they are implemented?

Answer 1: There is expansive EVMS documentation, and the EVMS guidelines are well documented. On the other hand, there is little in the way of Agile documentation since the Agile mindset is to be lean and not to document unless absolutely necessary. The DOD released an
EVMS and Agile Program Manager’s Desk Guide that can be used for quick reference. H&A has done the homework and has created training for EVMS and Agile.

Question 2: What is the comparable Agile term or artifact for this EVMS artifact (for example the WBS)?

Answer 2: There is no roadmap between EVMS and Agile that is hard and fast. The best approach would be to identify “similar to” situations or likenesses. For example the EVMS WBS is similar to the Product Backlog within Agile. The Steering Committee of The World Congress in Computer Science, Computer Engineering and Applied Computing reported on Constructs to Support Agile and EVMS

Question 3: What roles within the PMO are there for EVMS and for Agile and how do they relate?

Answer 3: In Agile there is no real “management” role. So the PMO roles that are management titled are not germane to Agile. And in the opposite direction, the Agile roles do not really exist within EVMS. For example the Agile “Product Owner” is a person with a customer view of the product and speaks for the customer. In a stretch this could be a high level Software or System Engineer with requirements responsibilities. The Scrum Master is a facilitator on the Scrum team and there is no corresponding EVMS role. The team members organize themselves so there is no team lead like the Control Account manager in an EVM System.

Question 4: Since the Sprint in the Agile/Scrum approach is defined as a time-box with a fixed end date, how do you reconcile that with the EVMS approach of working the task until it is done?

Answer 4: The EVMS baseline can be set above the Sprint level and can correspond to known “mandatory” delivery points such as release deliveries. This will then align the Agile deliveries to the EVMS structure and the two can work together.

Question 5: Does the fact that Agile/Scrum Sprints have very short durations cause a problem with EVMS performance measurement?

Answer 5: Not at all since teams update their progress daily. But it is preferable if the Sprints are four weeks or less and align with the cut-off dates for the EVMS. In that way the EVMS can pull the stated performance from the teams and use it as the input for the EVMS without any translation work. If a Sprint crosses an EVMS period, that would need special consideration.

Question 6: Since Agile work is not really budgeted, how does that reconcile with the EVMS need for budgets and budget control?

Answer 6: Budgets will be held in packages in the EVMS based on the plan for the Sprints and the teams doing the Sprints. The Agile weighting of work will be within the same packages but is not considered to be budgeting; it is weighting of milestones, if anything.

Question 7: We do not like the idea of the 0/100 EV Technique even with milestones. At our company we have an allowance to earn partial credit for milestone work. How does that fit into the EVMS and Agile implementations?

Answer 7: Agile wants to measure work when done. The work should be in such small stories, or tasks, that they are in-process for only a matter of days. Partial credit should not be needed in this situation; if it is, then perhaps there are issues with work definition.

Question 8: Agile applies to software development, but can we use it for other types of work?

Answer 8: Yes. It is a misconception that Agile is for software only. If you are creative you can find ways to use Agile Development in many areas. One company reports it uses it for circuit design and breadboarding resulting in significant time savings.

For additional information about EVMS and Agile see the blog post:

Agile/Scrum Ceremonies and Metrics Useful in EVMS Variance Analysis and Corrective Action

EVMS and Agile Implementation FAQ’s Read Post »

Keeping Track of Budgets, Changes, and IPMR Data

By Humphreys & Associates / August 15, 2014

For 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.

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.

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 »

Executive Level Schedules: Humphreys & Associates Methodology for Top Level Program Schedule Road-Mapping

By Humphreys & Associates / January 17, 2014

Methodology for Top Level Program Schedule Road-Mapping

The lack of a useful, concise, easily understood top level plan for a project is an issue that our consultants have repeatedly noted. It is way past time for the adoption of more useful and understandable executive level schedules. Having a distinctive top level plan linked to the lower level Integrated Master Schedule (IMS) planning can help differentiate one approach or one project from another.

With the advent of modern scheduling software such as Microsoft Project or Primavera, we have been assisting clients in developing more and more complex Integrated Master Schedules. However, a bigger and more complex IMS does not make the project plan any more accessible or understandable. In fact, it makes having an attractive and useful top level schedule more important.

The Data Item Description (DID) that governs the IMS, the Integrated Program Management Report (IPMR) DI-MGMT-81861, requires a Summary Master Schedule and describes it as:

3.7.1.3.2 Summary Master Schedule. A top-level schedule of key tasks/activities and milestones at the summary level which can be sorted by either the Work Breakdown Structure (WBS) or IMP structure (if applicable). It shall be a vertically integrated roll up of the intermediate and detailed levels within the IMS.

The Planning & Scheduling Excellence Guide (PASEG) developed by the NDIA Program Management Systems Committee is a wonderful resource for schedulers. The guide discusses the Summary Master Schedule in a way that avoids specifying it is to be sorted either by WBS or by Integrated Master Plan (IMP) the way the data item description does. It also does not describe the top level as a roll up. The PASEG describes the Summary Master Schedule as:

Summary Master Schedule – The Summary Master Schedule is ideally a one (1)-page schedule and may also be called a Master Phasing Schedule (MPS), Master Plan or Summary Schedule. As the highest, least detailed schedule, the program’s summary master schedule highlights the contract period of performance, program milestones, and other significant, measurable program events and phases.

The Program Team initially develops the program summary master schedule from the analysis of requirements data during the pre-proposal phase and similar past program efforts. The program team review and approve the program’s top-level schedule, which serves as a starting point in the Top Down planning approach (See Top Down vs. Bottom up Planning). This process continues until contract award to include any changes caused by contract negotiations.

Key components of summary master schedules could include significant items from the following list:

Key elements of contract work
Test articles
Deliverable hardware, software, and documentation
GFE/customer-furnished equipment deliveries
Key program and customer milestones/events over the life of the contract
Subcontract elements

The PASEG further describes the process for developing the Summary Schedule. H&A agrees that this process is the effective one for creating an executable plan. The process makes the top level summary schedule even more important. The process outlined by the PASEG is:

Read and understand the RFP.
Make a high level plan to meet the requirements of the RFP.
Use the high level plan to guide the top-down development of the IMS. This includes building the milestones that represent the Integrated Master Plan (IMP) events, accomplishments, and criteria.
Validate lower level planning back against the top down plan.

In addition to the Data Item Description and the PASEG, H&A suggests that the Summary Schedule have some specific attributes that make it useful. It should be:

Complete – show the key milestones and the entire project top to bottom and across time at a level of condensation that makes sense and is natural to the project.
Easy to read – graphically it should portray the plan in a visually pleasing way that is easy to read.
Easy to follow – flowing from left to right and top to bottom in a sequence that follows the progression of the work of the project.
Self-explanatory – it should tell the story of the project even if adding notes are needed to make the story stand out.

Because the graphics in the IMS tools do not provide those attributes, H&A most often sees clients building some sort of “cartoon” plan, manually drawn in Excel or PowerPoint, and used during the proposal phase until the IMS can be considered solid enough to start using the roll up in the IMS as a Summary Schedule. The problem with this approach is that it is not linked electronically to the IMS; it is not part of the IMS and the data in the two can easily become different.

The maintenance of the cartoon version is continued in some cases or abandoned. When it is continued it involves labor effort to draw and redraw the plan based on changes and updates. Often the cartoon is abandoned and the roll up approach from the IMS tool takes over. At this point the top level executive type schedule no longer exists and the project plan is no longer readily accessible.

One of the main benefits of having an executive level summary schedule is that the program manager and team can easily tell the story of the project in a one page, coherent, easily understandable plan; and with the proposed methodology this summary schedule is linked to the IMS so the two do not become separated.

Looking at the two examples of a master schedule for the same project shown below, it is apparent that the first one is from Microsoft Project; it has the roll up look and feel to it. The summary bars do not really provide much information other than to indicate there is more information below.

The other example from the H&A methodology is a top level schedule that tells the story of the project in a form that flows the way the project does. It may be in WBS or OBS order but those may not be natural to the flow of the project. This example is grouped in the order that displays the evolution of the project the way the team thinks of the project. The tie to the underlying IMS is built into the plan. Each milestone or bar on the top level represents one or more tasks within the IMS so a user can find the identification of the corresponding work in the depths of the IMS when needed.

Gantt Chart with Project Tasks — Click image to enlarge

Humphreys & Associates Road Map Chart – click image to enlarge

H&A now has developed a methodology supported by commercially available software that follows the guidance of the NDIA Planning & Scheduling Excellence Guide (PASEG) and provides the ease of use and executive level visibility needed in a top level schedule. Now a project can have a useful and demonstrative top level schedule that drives the top down planning effort as recommended in the PASEG.

This methodology was recently used successfully in the aerospace industry to develop the top level executive schedule view that drove the planning of a proposed multi-billion dollar project and to tell the story of the proposed project convincingly. The benefits perceived in that instance were:

Enhanced communication with the customer – the story could readily be told on one page.
Enhanced communication with company executives – they could easily see what was being planned by the proposal team.
Top down planning from the proposal leadership into the Integrated Product Teams (IPTs) early in the proposal process when it counted most and kept all the teams focused on the same plan – everyone knew the plan.
Establishment of the System Engineering approach and the Technical/Program reviews as the key points in the plan.
Top down electronically linked planning into the Integrated Master Schedule (IMS) so that the development of the 5000 line proposed project schedule could be compared upward to constantly verify that the developing plan would support the top level plan.
Establishment of time-fences that alert proposal leadership when lower level plans were moving away from established time goals.
Rapid effective translation of the developing IMS into the understandable project plan – especially useful in planning meetings within the proposal teams.
Because the top level is linked to the lower level, it can be used in meetings to rapidly isolate and find sections of the lower level IMS relating to a particular topic – no more paging, filtering, and searching for a particular area of the project’s IMS.
Proposal quality graphics that did not require artists or artwork to tell the story.

To learn more about the H&A top level project road-map methodology and other EVMS topics, visit our website or call us to discuss your project.

Executive Level Schedules: Humphreys & Associates Methodology for Top Level Program Schedule Road-Mapping Read Post »