EVMS Archives - Page 3 of 7 - Humphreys & Associates

EVM Consulting – Modeling & Simulation

By Humphreys & Associates / March 13, 2018 / deterministic model, Earned Value Consulting, EVM, EVM Consulting, EVMS, EVMS Modeling, EVMS Simulation, IMS, Integrated Master Schedule (IMS), Mesure Analyze Act

deterministic model, Earned Value Consulting, EVM, EVM Consulting, EVMS, EVMS Modeling, EVMS Simulation, IMS, Integrated Master Schedule (IMS), Mesure Analyze Act

Forewarned is Forearmed

Forewarned is forearmed. John Farmer, of New Hampshire, said that in a letter in 1685. But that advice is most likely biblical and very much older. No matter the source of the thought, we should take it as divine guidance if we are project managers. Maybe we should have it cut into a stone tablet, so we can share it with our team members.

Most of our work as project managers is spent in the “controlling” phase which is made up of the three steps “measure, analyze, act.” Our EVMS and IMS exist to be able to support this management function. The measuring part is done very well in our EVMS and our IMS; we know where we are and how we got there. The analyzing is equally well handled in the IMS and EVMS. Only the management task of acting is not well supported. Generally, we lack decision making support and tools.

Deterministic Path

No matter how well constructed and how healthy our IMS is, it has a deterministic path forward. The logic links between the activities are there because we expect them to be fulfilled. Indeed, if activity “B” is a finish-to-start successor to activity “A” we fully expect that at some point activity “A” will finish and will provide its output to activity “B”. That is a single path forward and it is a deterministic path. It is also a somewhat simplistic model.

Multiple Outcomes

Our management system asks us to perform root cause analysis followed by corrective action. But what if there is more than one corrective action to be taken. And worse; what if the corrective actions can have multiple outcomes with each enjoying its own probability. That means multiple choices and multiple outcomes. How would we show that in our plan? How would we analyze the multiple possible futures that such a situation presents?

Happily, there are ways to model a future without a set path. And once we have the future model, there are also ways to simulate the outcomes to give the probabilities we need to decide which actions to take. We are talking about probabilistic branching, and we are saying that we can build a probabilistic map of the future to use in making decisions; especially making decisions on corrective actions.

Take a simple example of running a test on the project. The expectation is that eventually we will pass the test. We will keep trying until we do. In the IMS deterministic model the test portion of the IMS might look like this:

Simulation

We can simulate this situation with different expected durations for the test. That is helpful information, but it does not explain or even capture what is going on in those different durations. It looks like we are just taking longer to do the testing but is that really what is happening? What is going on here? We certainly don’t show that.

In the real world, this simple model might have three potential outcomes. There might be three paths we can take to get to the point where we use the product. Each path has a time and money cost. We might run the test and find that we passed. Or we might have to stop the test for issues on the item or the test setup. We might even fail the test and must correct something about the product to improve our chances of passing a rerun. Eventually we will get to a usable product. But what do we put in our estimate and our plan? What do we tell the resources we need? What do we tell the boss? The customer?

Full Future Model

We now have a much better understanding of the future and can explain the situation. We also can simulate the situation to find out the most likely time and cost outcomes, so we can explain the future without any histrionics or arm waving.
If the issue is important enough we can build out the full future model and simulate it.

No matter how far we pursue the model of the future, having a valid model and being able to stand on solid ground are very valuable to us as project managers.

This is not to say that we should model out complex situations as a routine in the IMS. That would be impossible, or at least prohibitively costly. We are saying that when situations arise, we need to be able to use the IMS to help us make decisions.

This type of probabilistic modeling of the future is particularly useful in defining major decision points in our plan. When we reach a decision point the IMS may have multiple branches as successors but that implies we take every branch and that is not valid. Modeling each branch and its probabilities is valid. In the example below, where the milestone represents a decision point, we have shown three possible paths to take. If each were modeled out into the future with time and cost data, we should have the information we need to choose the path we wish to pursue. Without processes and tools like this, we would be flying blind.

Future Blog Posts

This discussion will be continued in future blogs to develop a better foundational understanding of the process and power of probabilistic modeling in our EVMS.

Good information sets the stage for good decisions. The IMS and the EVMS have sufficient information to help us model the pathways ahead of our critical decisions. We just need to learn to take advantage of what we have available to us.

Find out how an experienced Humphreys & Associates EVM Consultant can help you create a full future model and simulation of your most vital EVMS Systems. Contact Humphreys & Associates at (714) 685-1730 or email us.

EVM Consulting – Modeling & Simulation Read Post »

Along the IMS Time-Now Line

By Paul Bolinger / August 22, 2017 / EVMS, IMP, IMP Troubleshooting, IMS, IMS - DI-MGMT-81650 (superseded by IPMR DID), IMS Data Date, IMS Scheduling, IMS Status Data, Integrated Master Plan, Integrated Master Schedule, Integrated Master Schedule Monitoring, Time-Now, Time-Now Line

EVMS, IMP, IMP Troubleshooting, IMS, IMS - DI-MGMT-81650 (superseded by IPMR DID), IMS Data Date, IMS Scheduling, IMS Status Data, Integrated Master Plan, Integrated Master Schedule, Integrated Master Schedule Monitoring, Time-Now, Time-Now Line

Recently one of our consultants was instructing a session on the Integrated Master Schedule (IMS) with a group of project personnel from one of our larger clients. The group was a mixture of beginners with no real experience in schedules and some much more experienced practitioners; some with more than 10 years of experience. The mixture made it somewhat difficult, but it also made for some interesting discussions that might have been missed in a more homogenous group. One of those things was the usefulness or importance of the “time-now” line.

When the group was asked about the importance of the time-now line and what information could be easily gained from a look at the line, there was silence. The beginners did not have a clue but also none of the experienced people had any response. What should have been a short discussion with just one “slide” as a visual, turned out to be a longer and more informative session on this topic.

The time-now line has different names in different software tools but it refers to the data date, or status date, of the schedule. That also would be the first day of the remainder of the schedule. When a scheduler sorts tasks by date, the time-now line runs down the screen and forms a highly useful visible reference.

In the small example below [see Figure 1], you can see the time-now line and visually assess the situation. Time-now is shown by a vertical line at the beginning of September, so all remaining effort has been scheduled to after that date. In other words, no work can be forecasted in the past. A walk down the line shows Task 1 has both started and completed. Task 2 started but has not completed. In fact, the remaining work in Task 2 has been pushed out by the time-now line. The start of Tasks 5 and 9 are also being pushed out by the time-now line. In most real project schedules, filters and other techniques may be needed to isolate information like this; but in our small example, we can simply “eyeball” the time-now line and see valuable information. Task 9 starts the critical path shown in red tasks.

Figure 1

A slightly different setup for that same small example [see Figure 2] shows something interesting. The time-now line is still at the beginning of September. But now there is a gap between time-now and work on the critical path. This is an unusual situation and should be investigated for the root cause. It is possible this is an accurate portrayal of the situation, but regardless of the cause, it must be verified and explained.

Figure 2

In yet one more variation [see Figure 3], we see that a broken link results in Task 8 ending up on the time-now line. A task without a predecessor will be rescheduled to start at the earliest possible time (if the task is set to be “As Soon As Possible”). And the earliest possible time is the time-now line; the beginning of September. Just as broken things fall to the floor in real life, “broken things” fall to the time-now line in a schedule. Un-started work can land there. Un-finished work can land there. And un-linked work can land there.

It is further possible to see that Task 2 has had an increase in the remaining duration that has driven it onto the critical path. Task 2 at this moment is the most important task on the entire project. A slip to Task 2 will drive out the end date for the entire project. One question that needs answering is what is holding up Task 2?

If the display had been sorted by increasing total float/slack and the usual cascade by date, then the critical path would be starting at the upper left-hand corner; like the critical path in this example. The action on the project is almost always on the time-now line and the most important action, when sorted as described, will be at the upper left-hand corner.

Figure 3

So, a walk down the time-now line can help us see the critical path action, find broken parts of the schedule, and locate unusual circumstances that need our attention. Our recommendation is to look at the time-now line any time there is data being changed in the IMS. This will help you catch issues early and keep the schedule cleaner.

Along the IMS Time-Now Line Read Post »

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

By Humphreys & Associates / December 7, 2016 / agile, Agile Earned Value Management, Agile EVMS, agile project management, Agile Scrum ceremonies, Agile Scrum EVMS, Backlog, Backlog Refinement, Daily Scrum or Standup, Disruption measures, earned value management system, Estimate to complete, EVMS, EVMS Forecasting, EVMS Variance Analysis, Feature Burn Up/Burn Down, Program Management Pla, Release Planning, Retrospective Action Log, Scrum, Software Development Plan, Sprint, Sprint by Sprint, Sprint Retrospective, Sprint Review, Stability measures, WIP

agile, Agile Earned Value Management, Agile EVMS, agile project management, Agile Scrum ceremonies, Agile Scrum EVMS, Backlog, Backlog Refinement, Daily Scrum or Standup, Disruption measures, earned value management system, Estimate to complete, EVMS, EVMS Forecasting, EVMS Variance Analysis, Feature Burn Up/Burn Down, Program Management Pla, Release Planning, Retrospective Action Log, Scrum, Software Development Plan, Sprint, Sprint by Sprint, Sprint Retrospective, Sprint Review, Stability measures, WIP

P. Bolinger, CSM October 2016
Humphreys & Associates

How can Agile/ Scrum be used to support EVMS Variance Analysis and Forecasting in a way that provides program managers with cost and schedule integrated information for no extra effort?

The discipline of EVMS and the Agile/Scrum practices have several touch-points that are covered in two major documents: NDIA IPMD Agile Guide March 2016, and PARCA Agile and EVM PM Desk Guide. Neither of these documents, as yet, drives to the level of specifics when it comes to best practices for use of Agile to support EVM Variance Analysis and EVM Forecasting.

Looking at the literature for Agile/Scrum, we know that there are recommended ceremonies that are conducted at various levels of the product structure and at different times during the project life cycle. These ceremonies are supported by many discussions of the metrics that can be collected at each ceremony and their potential use in managing the technical work of development within the Agile/Scrum framework. But where do these ceremonies potentially support EVMS Variance Analysis and Forecasting?

Now suppose we are presented with a control account that has exceeded the EVMS thresholds for cumulative cost and schedule variances. Wouldn’t it be great to have at our fingertips the underlying data from the process? In this case we might find, for example, that the Velocity is less than that needed to meet the end goal, the story cycle time is longer than desired, the pass/fail ratio is not favorable, too many team members have been absent in the last Sprint, the number of disruptions has been excessive, and the work to accomplish the stories is higher than estimated. It is not difficult to surmise the outcome would likely be a behind schedule and overrun condition in the EVMS. These data measures would provide the fodder for deep diving to the root cause and impact statements.

Where would we get that information?

Let’s start with the Agile/Scrum ceremonies. The particular Agile/Scrum ceremonies that we find conducted during the project are:

Backlog Refinement. This ceremony can be nearly continuous. It involves redefining the backlog of development work (scope), the prioritization or re-prioritization of that work, and potentially the assignment of responsibilities for the backlog.

Release Planning. This is a recurring ceremony aligned with the release cadence for the project. It involves establishing the capabilities and features of the product and when they will be released.

Sprint. This is a short time-defined effort to accomplish the design, code, and test of some subset of the product. The Sprints are controlled by the self-managing teams.

Daily Scrum or Standup. This is a daily (recommended) team meeting to discuss what has happened, what roadblocks exist, what is planned for the day, and other necessary items.

Sprint Review. The session in which the team products are demonstrated to the owner and self-off is accomplished.

Sprint Retrospective. A meeting of the stakeholders to discuss what went right (or wrong) during the Sprint and to define improvement actions that are needed.

The relationship of these Agile ceremonies with EVMS might look like this:

Agile/Scrum Ceremony	Agile Purpose	Relationship to EVM Variance Analysis, Root Cause Analysis, Corrective Action Planning & Follow-up and Forecasting

Backlog Refinement	Manage, estimate, prioritize, and organize the product backlog in an on-going routine.	Estimating – impacts the EVMS ETC and EAC as well as durations of efforts.
		Prioritizing – in response to issues is corrective action management.
		Organizing the backlog could be a form of corrective action effort.

Release Planning	Establishing the contents and timing for releases of product.	Updates could be part of corrective action planning in response to issues. Creation of new work packages. Changes to planning packages and SLPPs would also.

Sprint	Short time-box performance unit. Work is done in Sprints.	Below the work package. Short span measurement period is possible.

Daily Scrum and Stand-up	Make short term plan, adjust to issues, discuss problems, clear roadblocks.	Much of the daily action would relate to root cause analysis and corrective action planning although the time-frame is very short and the issues may be too small to individually impact feature work package or the Epic control account.

Sprint Review	Demonstrate the product, update released work, make changes to product.	This would relate to corrective action planning and follow-up. Issues would be found here that would impact risks, ETCs, corrective actions, performance metrics.

Sprint Retrospective	Reflect on the project, progress, people processes, what was good, what was bad, and take actions to improve.	This should be the richest source of supporting information for EVMS root cause & corrective action within the VAR realm. Very timely for variance analysis as it happens potentially many times during work package (feature) duration.

Feature Retrospective (not one of the basic ceremonies)	Review situation regarding technical scope deficit. Reflect on the project, progress, people processes, what was good, what was bad, and take actions to improve.	Because this only happens at the end of the feature it is limited in value for variance analysis timeliness. Any lessons learned can only be applied to future feature work.

But where is the meat? Where do we get actionable data or at least data we can analyze to decide what management efforts are required?

There are numerous potential metrics that can be collected during these ceremonies. These metrics can form the basic data set that could be analyzed to define the root cause of cost and schedule variances. In addition to isolating the cause of issues, within some of these ceremonies the impact of the issue on the Sprint, or Feature, or team may be made. Certainly, these metrics can be used as the basis for projecting future workload and performance.

The total number of potential metrics is not known. In this paper, we looked at 17 metrics and considered what the data might mean. The results of this review are contained in this matrix:

Metric	Type of Measure	Discussion
Sprint Burn up/Burn Down	Backlog	Value of backlog remaining for Sprint. Decrease is expected when work is done. Increase means work increased. Burn up can include total completed plus remaining; a great metric.
Feature Burn Up/Burn Down	Backlog	Value of backlog remaining for Feature. Decrease is expected when work is done. Increase means work increased or shifted.
Customer support requests received.	Disruption	Number of instances. Unplanned interruptions by customer can lower the output of the team if excessive.
Disruption measures	Disruption	How many and what type (except customer support requests). Higher disruptions impact team efficiency.
Estimate Accuracy (Sprint or Feature)	Estimating	Measure of budgeted value (estimated value) for the Stories in the Sprint or Feature versus the actual cost (calculated cost) of the Stories when done. Related to team size.
Discovered work	Estimating	Emerging work discovered during the Sprint. Will translate to extra effort in future if adopted into backlog.
Exceeds WIP Limits	Management	If WIP limits are set on team or individuals then exceeding set limits will impact efficiency and output.
Retrospective Action Log	Management	Count of improvement actions listed in Retrospective. Increasing count means issues are not being resolved.
Attendance	Management	Comparison of actual hours worked by team compared to baseline expectations in plan.
WIP	Productivity	Measure of the number of stories or points in WIP at any time. WIP growth can indicate bottlenecks and inefficiencies.
Velocity	Productivity	Measure of the amount of work (Stories or Points) accomplished during a time period. Higher velocity means greater throughput per person/team.
Stability measures	Productivity	Comparing Sprint by Sprint basic measures from this list. If there is high variability between Sprints in measures, then future is unpredictable.
% Tests Automated	Productivity	Higher automated testing should increase efficiency & decrease cycle time.
Defects found by team	Quality	Number of bugs reported during team effort. Measures quality of work. Higher bug incidence translates to lower output and higher costs.
Defects found by customer	Quality	Number of bugs reported by user/customer. Measures quality of work delivered. Higher bug incidence translates to lower customer satisfaction and higher rework costs.
Pass/Fail (Re-do) measures	Quality	How does the rate of success in testing compare to the number of attempts? High success rate should mean greater output and efficiency.
Cycle Time	Schedule	Time from start of a story to complete. Short cycle time is desired.

Let us continue the theme of the behind schedule and overrun control account and look at what information would be available for support to developing the estimate-to-complete. An updated and refined backlog would have the scope of work remaining for the control account. The updated release plan would have the timing for the deliveries to be made in the control account. The metrics collected about the effort expended per accomplished story or story point would provide a factor for projecting future real-work hours. Planned corrective actions and improvements would tell us how we might expect improvement to the quality and improvement in the speed or cost of work. The insights available from a full set of metrics are impressive.

Does a project have to collect all of these metrics? If not all then which ones would be the right ones? Questions like that would be answered by the project management team analyzing their prior experience and the particular challenges of the project. The team would establish a data collection plan, likely described in their Software Development Plan or Program Management Plan that would explain the metrics, meaning, and frequency along with their purpose. With a clear understanding of the technical data to be collected and analyzed, the Control Account Managers would not have a difficult task to define how they would use that data in developing Variance Analyses and generating well-considered Forecasts. In fact, these tasks should be much simpler with the data in hand.

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

Who Owns EVM? Programs or Finance?

By Humphreys & Associates / March 14, 2016 / CFO, earned value management, EVM, EVMS, Integrated Program Management Division, IPMD, PP&C, program management, Program Planning & Control

CFO, earned value management, EVM, EVMS, Integrated Program Management Division, IPMD, PP&C, program management, Program Planning & Control

earned value management: finance department or programs

I have read several Earned Value Management (EVM) reports, papers, and articles that debate what company organization should “own” EVM and the company’s Earned Value Management System (EVMS). These debates most often mention the programs’ organization and the finance department as common EVM “owners.” The majority opinion seems to be that because EVM is a program management best practice it belongs in programs. A minority opinion is that because EVM is denominated in dollars, schedule included, and because EVM reports are financial in nature, EVM belongs in the finance department. Before we dive into this debate, a summary of the responsibilities of a Chief Financial Officer (CFO) and of the head of programs is useful. In our company A and company B examples to follow, both the CFO and the head of programs report to the company president.

WHAT ARE THE DUTIES OF A CHIEF FINANCIAL OFFICER ( CFO)?

A CFO has three duties, each measured in the time domain. The first duty of the CFO is as the company’s controller and is responsible to accurately and honestly report past company financial performance. The CFO is also responsible for the current financial health of the company – to insure that today’s decisions create rather than destroy value. And lastly, the CFO must protect the company’s future financial health and that all expenditures of capital maximize future financial health. Every business decision, especially those of the CFO, are either good decisions (are accretive – increase shareowner value) or are bad decisions (are dilutive – destroys shareowner value).

WHAT ARE THE DUTIES OF THE HEAD OF PROGRAMS?

The head of programs is typically a Vice President or higher and all program and project managers report to him or her. The head of all programs has profit and loss responsibility for his or her portfolio of programs and projects. In addition, each program is responsible for achieving the technical, cost and schedule requirements of the contracts it is executing on behalf of its customers.

A TALE OF TWO COMPANIES:

I will now describe first-hand experiences with two companies and how each company decided who should “own” EVM.

Company “A” had EVM assigned to the finance department. All EVM employees were overhead, even those assigned to a program. A new CFO arrived and quickly decided to reduce indirect costs, declaring that he was “coin-operated.” The new CFO terminated the employment of all EVM employees. Each program attempted to create an EVM branch office but failed. A level 3 CAR enumerating EVM deficiencies was issued and the CFO was fired. A second “new” CFO arrived and agreed to transfer EVM to the head of programs. The head of programs was instrumental in changing the disclosure statement making EVM personnel assigned to a program a direct charge to that program / contract. The head of programs created a Program Planning and Control (PP&C) organization and demanded all PMs and their program members to quickly learn, use and master EVM. A program control room was built with five screens. Daily 2:00 pm EVM data-driven reviews were held on short notice. These daily reviews became known as “CAM Bakes.” The EVM and program management culture changed quickly and dramatically at Company “A.”

Company “B” had EVM assigned to the CFO who was as “coin-operated” and unaware of EVM as the first “new” CFO of Company “A.” The culture of company “B” was very hostile to EVM, so it probably did not matter who “owned” EVM. The company failed 16 of 32 guidelines and was decertified. Significant withholdings were imposed and the company’s reputation was damaged. Several top managers hostile to EVM “sought employment elsewhere.” A new CFO arrived who was also “coin-operated” but expert in EVM. The new CFO formed a partnership with the head of programs. The new CFO was as much a PM as he was a CFO. The new CFO told his direct reports assigned to each program to “make the program managers successful.” And they did exactly that.

The new CFO understood that the company was the sum of all its contracts and that every dollar flowed from its customers. The EVM and program management culture at Company “B” changed rapidly.

Who Should “Own” EVM? Programs or Finance?

Returning to our original question of who should “own” EVM, the majority theory is that the Programs’ organization should “own” EVM. All else equal, I tend to agree with this theory.

However, while theory is suggestive, experience is conclusive. My experience at Company “A” proved that a strong programs’ leader could change the EVM and program management culture of a company rapidly. My experience at Company “B” proved that a CFO could “own” EVM and be successful at changing the company’s EVM and program management culture. The CFO and the head of programs must form an EVM partnership no matter who “owns” EVM.

Who “owns” EVM at your company?

Robert “Too Tall” Kenney
H&A Associate

Who Owns EVM? Programs or Finance? 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 »