Agile assessments identify, evaluate and assigns risk to projects. Schedule risk analysis results are predominantly communicated in two important sets of intelligence.
Risk Exposure Chart
The first, and higher level output, is the Risk Exposure Chart. This chart depicts the level of confidence that the project scope, as modeled in the IMS, can be completed by a certain date. The chart commonly includes a histogram depicting the number of project simulations that are being completed on each specific date, and a curve that shows the cumulative values across time up to a 100% confidence level. Using the DeltekAcumen Risk Exposure histogram, the baseline finish, forecasted finish or any other desired date can be examined, as well as determination of the probability of achieving that date based on the number of simulations completing on or before that point in time.
Now that you know there are problems, what are you going to do about them? On which tasks should mitigation attempts be made? Is the current critical path comprised of the riskiest tasks? This is where the second area of intelligence output comes into play.
Tornado Chart
Acumen produces a list of “risk drivers” in the form of a Tornado Chart. These are the tasks that are expected to have the greatest influence on risk in the schedule. Put another way, this report highlights the tasks that, if they could be executed in less time, would have the greatest impact on increasing the likelihood of an on-time project completion. Acumen’s rendition of the Tornado Chart also displays the amount of the risk that can be attributed to duration uncertainty, logic, or any of the risk events. New to Acumen 6.1 is the ability to easily display this information in either days or hours.
But how does one know if all of the time and effort that has been spent mitigating risk is working? Acumen can help here too. The initial (unmitigated) plan can be compared to the current (mitigated) plan. Has risk been reduced as expected? Or, because of mitigation efforts in one area, has risk increased in other areas (a.k.a. collateral damage)? Stacking the results within the Tornado Chart, it can quickly be seen which risk drivers improved, were unaffected, or deteriorated.
Parting Thoughts
The goal of any SRA tool is to identify and quantify schedule risk to a project so that action can be taken to improve project execution. Used properly, Acumen Risk does exactly that. With over 20 years as a full-time scheduler, I have dealt with thousands of project schedules and many, many analysis tools. From what I have seen so far, Acumen is an evolutionary step in performing schedule risk assessments. It offers beginners an easy path to perform in-depth schedule analysis with advanced features for more experienced users to help further refine the accuracy of the results. I encourage you to register for a free trial version and test it out for yourself.
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:
This article provides an introduction to the differences between an Earned Value Management System (EVMS) and Agile approaches on projects, and isolates the challenges of implementing an EVMS on a project where the project management has chosen to follow an Agile approach to the development work. The article explores the principles of EVMS and of Agile, and contrasts them to show where there are inherent conflicts. The article then discusses how the conflicts can be mitigated so that the benefits of both the EVMS and Agile can be obtained from a joint implementation.
Earned Value Management is a 50 +/- year old methodology based on widely accepted principles that applies documented, systematized practices to support the processes of organizing, planning, directing, and controlling large complex projects, of any nature, which contain a high degree of uncertainty.
An EVMS is structured compliant to 32 guidelines that define what a project management information system should be capable of doing to support the program management team. Within the 32 guidelines there is a subset of generally recognized core principles. The core principles are:
Organize the entire scope of the project using a Work Breakdown Structure (WBS).
Organize the project team using an Organization Breakdown Structure (OBS).
Integrate the project work with the project team to create management control points (Control Accounts).
Schedule the project work in the Control Accounts across the entire project duration at the appropriate level of detail.
Establish time-phased budgets for the scheduled work in the Control Accounts.
Establish the scope/schedule/budget baseline as the Performance Measurement Baseline (PMB).
Authorize the scope/schedule/budget and control the start/stop of work.
Periodically measure the schedule and the value of completed work and determine the Earned Value.
Record direct costs (actual costs) and summarize into the Control Accounts.
Compare planned, accomplished, and spent to analyze the performance and associated variances.
Develop realistic time and cost estimates for the remaining effort in the Control Accounts.
Rigorously control changes to the Performance Measurement Baseline.
The EVM concept presented in these guidelines is a sound management approach, that once incorporated on any type of program, whether research and development, construction, production, etc. provides all levels of management with early visibility into cost and schedule problems. Earned Value Management now appears as a contractual requirement on programs world-wide. Primary EVM users include the United States, Europe, England, Canada, Australia, China, and Japan. It is a requirement of many U.S. Government agencies, including the Department of Defense (DoD), the National Aeronautics and Space Administration (NASA), the Department of Energy (DOE), the Intelligence Community, the Department of Homeland Security (DHS), the Federal Aviation Administration (FAA), the Department of Transportation (DOT), Health and Human Services (HHS), and others.
EVMS has been adopted by companies in situations where it is not a contractual requirement so that they can gain the discipline and benefits of the structural management approach discussed in the guidelines.
Flexible Planning with Agile
Agile Background
Agile is a 20 +/- year old approach to applying a mindset that values the use of small, empowered, self-organizing, multi-functional teams, mainly in software development, to establish a test driven product development effort. This uses a series of short, rapid incremental builds within projects with a high degree of uncertainty to achieve shorter development times, lower costs, and products more closely aligned with customer requirements.
Agile does not usually appear as a contractual requirement. The concept is adopted by companies and organizations with the belief that a better product will be produced faster, and with less expense, using this approach than if traditional approaches were followed.
There are a core set of principles for Agile that were initially established in the copyrighted Agile Manifesto. These delineated core principles are:
Early and continuous product delivery.
Deliver working software (product) frequently.
Expect change and respond positively to change.
Developers and project business organization (PMO) work together.
Product-focused build teams are at the core.
Support self-organizing teams – trust among peers.
Encourage face-to-face discussions (involve the user/customer).
Working software is the measure of progress.
Maintain a constant sustainable pace of development.
Simplify the process and the product.
Put the highest value on technical excellence.
Improve team effectivity.
So How Does Agile Work?
The Agile mindset or approach is implemented through a process of defining the product backlog into smaller and smaller subsets of work that are structured in a top down fashion. At the lowest level of product backlog, the work elements or requirements can be prioritized and assigned to teams. The self-organizing teams pull work from the backlog and work the tasks to completion in a series of short, time-fixed Sprints or iterations. Sprints are often from 2 to 4 weeks long.
Because the teams are self-organizing, there is no team manager or team lead. The teams work as a group and only pull from the backlog at the last possible minute, and do minimal planning for each Sprint. If the product backlog is properly deconstructed and defined into user stories, then the planning meeting for an entire 4 week Sprint can be accomplished in a few hours.
The teams design, code, test, integrate, and deliver functionality in every Sprint. Since tested product is output every few weeks, all on the project can see the product being created and can contribute along the timeline, as needed, to provide a complete finished product.
The product owner embodies the customer’s perspective and either accepts or rejects the team’s work. At the latter point of each Sprint, the tested product is demonstrated to the product owner.
High Level Side-by-Side
The two approaches are contrasted in the chart shown below. The EVMS is a methodology that is highly documented and highly systematized, while Agile is just the opposite. It is more of a mindset than a methodology with the preference not to have significant process documentation.
The EVMS is applied to entire projects and contracts, while generally Agile is applied to software portions of projects. However, it could also be used on other development work.
The EVMS is usually a contractual requirement with significant implementation and operation constraints while Agile has none of these. As a contractual requirement, the EVMS carries with it the option for customer reviews and the threat of non-compliance, which entails penalties.
EVM
Agile
Methodology
Mindset
Documented
Self-defined
Systematized
Self-defined
Any type of project
Software development (mainly)
High degree of uncertainty
High degree of uncertainty
Applied to the entire project
Applied to portions of the project
Often a contractual requirement
Adopted not required
Lower Level Side-by-Side
In addition to the high level side-by-side, there are significant differences within the details of the two approaches. These are shown in the side-by-side table below.
Agile
EVMS
Minimal documentation
More documentation
Plan at last moment
Plan ahead to end of project
Scope is flexible
Scope is baselined and controlled
Expect and embrace change
Avoid and/or control change
Schedule (Sprint) is fixed. Timebox ends the Sprint.
End the package when the work is done.
Budget is secondary
Budget is baselined and controlled
Cost collection is not mentioned.
Cost collection at the right level is critical
Accommodate and Capitalize on Differences
It is possible to implement Agile along with an EVMS if the EVMS application is set up to accommodate the differences and capitalize on them.
For example, the main reason that Agile’s embrace of change is a potential problem within an EVMS is because often the EVMS is used to plan too far in advance, and then reacting to change is difficult and expensive. If short term planning in the EVMS can be coordinated with the Agile planning, then the two can coexist.
The Agile free acceptance of scope changes within the backlog runs counter to the EVMS imposition of baseline change control. But if the EVMS baseline can be carefully set at a work level above the busy lowest level ups and downs, the impact to baseline change control is manageable.
A surprising chance to capitalize on Agile, within the EVMS, is found in the Scrum team approach in Agile where the team breaks work down into tasks far below what would normally be done in an EVMS, and then meets daily to update progress and provide corrective action. This low level constant attention means that the EVMS benefits from a better look at real progress as assessed by the real performers.
Not all the compromise needs be on the EVMS side of the equation. The Scrum team operations will often be defined to have the least possible recording of what happens during the Sprint. Since the product is king, then only the product really matters. But that misses the opportunities to capture the actions of the team for analysis, and use in upgrading their skills later. Necessary compromises would include some additional recording of the daily actions of the team and capturing the progress and problems. These would then be used in the EVMS functions of performance measurement, variance analysis, and corrective action planning.
One other compromise in the Agile realm that would be needed is the adoption of some minimum documentation of processes so that team operations can be repeatable and stable. Even a self-organizing team cannot change the way they work every time it wishes. That would raise the risk of a chaotic work environment.
These topics are recapped in the table below.
Agile
EVMS Accommodation
Scope is flexible
Select a higher level package for the baseline
Change is expected and embraced
Have the shortest possible planning horizon
Plan at the last possible minute
Have the shortest possible planning horizon
Daily Scrum Stand-up Meeting
Collect the data and use it for performance measurement
Sprint Review Meeting
Use for periodic measurement and analysis
Sprint Retrospective Meeting
Use in Corrective Action Plans
Lack of documentation
Add minimum documentation to stabilize team operations
Bottom Line
Implementing an EVMS is a challenge itself. Implementing Agile is a challenge too; perhaps a more difficult challenge. Implementing the two approaches side-by-side can seem impossible. But it is possible and even beneficial if done in a way the makes needed accommodations in both arenas for the project’s benefit.
I took the scenic route to selecting the theme of this blog. First, it was suggested that I write a blog on the benefits and costs of the earned value process as it applies to program management. Next it was suggested that I describe the harm of not using any of the elements of the earned value process.
In the case of the benefits and costs of the earned value management process, it would be difficult to improve upon Dr. Christensen’s 1998 paper on this heading or to attempt to improve other papers and studies done by Wayne Abba, Gary Humphreys, Gary Christle, Coopers & Lybrand and others. So I will not make citations to these past studies. Rather I will leave them undisturbed, as the monuments they have become.
This blog will summarize my observations of how companies have chosen “how much EVM is enough” for them and share my observations of the results of these decisions. Each company has selected an EVM implementation strategy and each company’s strategy falls along a bounded continuum.
I will describe this continuum of company EVM strategies with a left hand and a right hand goal post, and the space between as a cross bar. The “left hand goal post” represents companies that elect to be very poor at EVM or to not use EVM at all. The “right hand goal post” represents companies that have committed to being “best-in-class” practitioners of the EVM process and are the polar opposite of the companies at the left hand goal post. There are few companies at either the left or right hand goal posts. The “cross bar” represents the vast majority of companies that have selected an EVM strategy somewhere between the left and right goal posts.
Two Goal Posts And A Cross Bar; Recalcitrant, Merely Compliant, Efficiently Expert
There are as many strategies to earned value management as there are companies using EVM to manage their programs and projects.
Left Goal Post; The Recalcitrant
I have firsthand experience with a company, that at the time I initially joined them and had decided to ignore earned value management even though it was a requirement in several of its contracts. After many painful years of attempting to maintain this recalcitrant EVM strategy, this company decided that a better strategy would be to become “efficiently expert” at EVM.
Cross Bar; Merely Compliant at EVM
It has been my experience that most companies desire to “become EVM compliant,” which generally means being compliant to the 32 guidelines and not failing those guidelines so as to be de-certified. This is the vast middle ground between the two goal posts. I will now share five observations regarding companies in the “cross bar” majority.
Observation #1: Compliance As A Goal; Golf and EVM
Compliance should be a “given,” or a “pre-condition,” not a “goal.” Remaining merely compliant implies a status quo or static posture.
I will use the game of golf as an analogy. Golf is a game of honor and compliance to well established rules. All PGA professional tour golfers “comply” with the rules that govern golf. Although all PGA tour pro golfers comply with these rules, their performance on tour differs dramatically.
Fifty-three percent of all PGA golf pros, past and present, have no tour wins. That means only 47% of all PGA tour golf pros have won at least a single PGA tour. There are seven players in the history of the PGA that have fifty or more tour wins. If the bar is lowered to forty or more wins, only three players are added to the list. If the bar is lowered yet again to thirty or more tour wins, only eight more players are added to the list. Only 18 golfers have won 30 or more PGA tournaments.
Professional golfers do not confuse compliance with performance, nor do these professionals assume that “being compliant” will improve their performance.
Observation #2: “The Tyranny of The Status Quo”
With apologies to Milton Friedman and his book of the same name, companies that attempt to maintain mere guideline compliance will do no better than the status quo, and more often than not, regress toward non-compliance. Maintaining status quo is a myth – you either improve or regress.
All professionals, companies included, must compete in their markets and selected fields. To succeed in this competition requires constant improvement in areas critical to success. A company, organization, or individual without the means or the desire to improve will eventually fail and perhaps perish.
Observation #3: Blaming The Scoreboard
As a program manager, I considered EVM as my scoreboard. I reacted to the EVM data – the scoreboard – and made decisions based on that data (GL #26).
I recall the 2014 Super Bowl’s final score: Patriots 28, Seahawks 24. Did the scoreboard cause the Seahawks to lose the game or did a poor decision by their coach cause the loss? Imagine a coach that cannot see the scoreboard. That coach does not know the score or how much time remains. That coach cannot react to the realities of the game.
Observation #4: EVM Causes Poor Program Performance
I have witnessed several company leaders assert that the use of EVM on a poorly performing program is the cause of that program’s poor cost and schedule performance. A correlation between two variables, or a sequence of two variables (use of EVM and poor performance), does not imply that one caused the other. This is the logical fallacy known as “X happened, then Y happened, therefore X caused Y.” Night follows day, but day does not cause night. Use of EVM does not cause poor program performance. Not reacting to EVM data and promptly taking corrective action with your program’s cost and schedule performance often leads to poor outcomes.
Observation #5: It Takes More Energy To Be Poor At EVM Than To Be Expert
Returning to the earlier golf analogy, professional golfers make very difficult shots appear easy. I played in one pro/am tournament years ago. The pro I was teamed with took me to the range hours before our tee time. He asked me how many balls I hit before each round. I told him sometimes none and sometimes 50. He hit 1,000 balls before our round. When we finished our round, he was ready for another 18 holes. I was not. Both of us “complied” with the rules of golf. His score was significantly lower than mine. His game was effortless and produced a below par score. My game was labored and produced a poor result.
And so it is with EVM or any other process. The better you are at a skill, the easier it becomes. Experts consume far fewer calories at their craft than ambivalent amateurs.
Right Goal Post; Efficiently Expert At EVM
The polar opposite of a recalcitrant strategy to EVM is a strategy to become “efficiently expert.” As I mentioned earlier, I joined a company that attempted to sustain a recalcitrant EVM strategy. Their recalcitrant EVM strategy led to de-certification, large dollar withholdings, and significant damage to their corporate reputation.
After the most ardent EVM recalcitrants in this company “sought employment elsewhere,” a new strategy was adopted. This company embraced a strategy to become “best-in-class” as expert practitioners of EVM. This company’s goal was EVM perfection. EVM perfection is an impossible ambition, but wiser than “mere compliance.” And as with the PGA tour golf pro, EVM became nearly effortless.
Why Perform Schedule Risk Assessments? EVMS and Agile implementations within the same company or on the same project.
Before a project is ready to be baselined, a typical question the customer asks the project manager is, “How confident are you that the project will finish on time?”
This is a more difficult question than you might think. In competitive environments, guessing is not an option. The probability of success on a project must be quantified. The risks that impact the odds for success must also be quantified. If the risk is managed, the probability of completing the project on time and under budget is improved.
Customers are not blind to the importance of risk management. This is evidenced by recent changes in government contracting requirements that call for formal risk assessments of project schedules. Even if risk management were not a contractual requirement, it would be irresponsible for any project manager to ignore the need for risk management and proceed without identifying and assessing the project’s risks.
Schedule risk exists in every project. This risk can be quantified, analyzed, and mitigated, or it can be ignored. However, ignoring schedule risk does not make it go away. Fortunately, there are advanced software tools, such as Deltek’s Acumen Risk, that can help model the expected impacts of risk in the schedule. Then, the answer to “how confident are you that the project will finish on time?” can be answered with quantifiable information.
In the following sections, a few of the foundational elements of performing a schedule risk assessment (SRA) using Acumen Risk 6.1 will be discussed. The software was designed with the understanding that not everyone is an expert in schedule risk analysis. The software provides beginners with an easy to follow path to perform in-depth schedule risk analysis as well as advanced features for experienced risk experts.
Along with quick start guides and help documentation, the menu structure is laid out like a schedule maturity timeline. From left to right, the menu selections take one from the start-up steps of importing the schedule, to analyzing the schedule, assessing schedule risk, accelerating the schedule, and advanced customization features.
Deltek Acumen– Top-Level Menus
Schedule Health Diagnostics
Before delving into schedule risk assessments, let’s take one minor detour from risk into schedule diagnostics.
Would you trust a broken watch to tell you the correct time? The same goes for a schedule risk assessment. A broken schedule network cannot be trusted to yield reliable, and therefore actionable, SRA results.
The National Defense Industrial Association (NDIA) Integrated Program Management Division (IPMD) Planning & Scheduling Excellence Guide (PASEG), is widely regarded as one of the premier references on scheduling best practices. The PASEG was created by a joint team of both government and industry scheduling experts, thus it has no particular point of view to promote or defend. One of the scheduling best practices the PASEG discusses is that the integrated master schedule (IMS) should be validated before any SRA is performed. “Validated” means that the tasks, logic, durations, constraints, and lags in the IMS should be analyzed and corrected as necessary.
Acumen Fuse provides a complete set of schedule diagnostics. When I first clicked on the “Diagnostics” tab, I saw an initial set of metrics.
Each one of these metrics was applied to the project’s timeline that which makes it easy to see both where and when the issues occur. What I did not notice at first was that these metrics were just one subset; I was only looking at the “Schedule Quality” subset of the diagnostics. There were similar subsets in the areas of Logic, Duration, Constraints, Float, and the DCMA 14-point Schedule Assessment, just to name a few. All of these diagnostic tests can be modified to reflect your company or customer’s standards.
Before leaving the topic of schedule health, there are a few words of caution. No matter how useful a schedule analysis tool may be, there is no substitute for the task managers taking ownership of the IMS and ensuring that it is in good working order. For example, analysis software can be used to check to determine if a task has a predecessor and a successor, but only someone familiar with the effort can determine if a task has the “correct” predecessor and successor. Analysis software is becoming more and more sophisticated, but people still control the success or failure of the project.
Duration Uncertainty
Once a sound schedule has been developed, the next foundational elements of an SRA are the duration uncertainty estimates. There are two widely accepted methods of assigning duration uncertainty.
The preferred and more precise method is to obtain three-point duration estimates (best case, worst case, and most likely) from the task owners. At a minimum, this should be performed on all critical and near-critical tasks (and driving and near-driving tasks supporting significant events). For larger schedule networks, it may not be reasonable to gather this type of information for every task. If custom three-point estimates are not available, templated duration uncertainty could be applied based on the type of work, the task owner, historical performance, or any other applicable task characteristic.
Acumen Risk handles both methods very easily. Custom three-point estimates can be entered for each task in days (or hours), or as a percentage of the current remaining duration of the task. Standard duration uncertainty templates are easily applied to a task by selecting the appropriate risk level on the calibration bar. To streamline the process, by setting the calibration at any summary level, the uncertainty template is cascaded down to all the “children” tasks.
Risk Events
One thing traditional Critical Path Method (CPM) networks do poorly is model unexpected results. For example, if there is a 90% success rate on fatigue testing, the IMS will generally be constructed to assume the test will be successful, with no disruption to downstream tasks.
But what happens if the test fails? While unlikely, there is still a very real possibility that the results will be unfavorable. If the test does return unfavorable results, there will likely be a significant delay while re-work is performed in the areas of design, build and test. A traditional CPM network can model a successful test or an unsuccessful test, but not both. This is not a problem with a schedule risk assessment. Information from the project’s risk register can be used to model the likelihood of a test failure, as well as the consequence, or delay to downstream tasks resulting from that failure.
Is this an acceptable risk? An SRA can quantify the risk and provide information on the likelihood of successful deliveries. Acumen does not stop there though. One of its newest features is to organize and track all risk events within its built-in risk register, as well as to track the steps being taken to help mitigate that risk. Or, if your organization already maintains an external risk register in Excel, it can be imported into Acumen to eliminate the duplicate tracking of risk events. Whether the risk register is imported from Excel or built from scratch within Acumen, a single risk event can then be mapped to one or more activities, or a single activity can be associated with one or more risk events.
Simulation Process
A typical SRA uses Monte Carlo techniques to simulate hundreds or thousands of potential project outcomes using the risks and uncertainties that have been supplied.
For most users, simply accepting the default settings and pushing the “Run Risk Analysis” button would be sufficient. But if terms like “Convergence”, “Correlation Coefficient”, “Central Limits Theorem” and “Seed Value” are part of your normal working environment, Acumen provides a variety of settings that can be customized to tune the SRA to best model your project.
No matter which approach you take, the Acumen toolset provides a quick and easy simulation process.
What to Expect in Part 2
Part 2 of this blog will delve into the interpretation of SRA results.
On September 28, 2015, the Defense Procurement and Acquisition Policy Directorate (<abbr=”Defense Procurement and Acquisition Policy Directorate”>DPAP) released a memorandum entitled “Class Deviation – Earned Value Management System Threshold”. In this memo the DoD changed the threshold for <abbr=”Earned Value Management System”>EVMS application to $100 million for compliance with EIA-748 for cost or incentive contracts and subcontracts. That same memorandum stated that no EVMS surveillance activities will be routinely conducted by the Defense Contract Management Agency (<abbr=”Defense Contract Management Agency”>DCMA) on contracts or subcontracts between $20 million to $100 million. As attachments to this memorandum, there was a reissuance of the Notice of Earned Value Management System <abbr=”Department of Defense Federal Acquisition Regulations”>DFARs clause (252.234-7001) and the Earned Value Management Systems DFARs clause (252.234-7002), with both reflecting the new $100 million threshold.In response to this guidance, a series of questions from both contractors and other government personnel were submitted to Shane Olsen of the DCMA EVM Implementation Division (<abbr=”EVM Implementation Division”>EVMID). Below are the salient points from this communication:
There will be no EVMS surveillance of DFARs contracts under $100 million. Contracts without the DFARs clause, such as those under other agencies using the FAR EVM clause, will continue surveillance under their current thresholds.
The $100 million threshold is determined on the larger of the contract’s Ceiling Price or Target Price; as reported on the Integrated Program Management Report (IPMR) or Contract Performance Report (CPR) Format 1.
The threshold is based on the Contract Value including fee (at Price) as noted above. If there is an approved Over Target Baseline (OTB) which increases the Total Allocated Budget (TAB), this cannot push a contract over the threshold.
The new thresholds not only apply to subcontracts, but also Inter-organizational work orders with an EVMS flow-down.
Regardless of the circumstances, the DCMA will not conduct surveillance on contracts less than $100 million. However, if there are Earned Value issues that the buying command or other parties believe need to be reviewed, then the DCMA may conduct a Review for Cause (RFC) of the system against potentially affected guidelines.
The DCMA Operations EVM Implementation Division (EVMID) will not be conducting Compliance Reviews in FY-2016 unless there is an “emergent need”.
If a site is selected for a Compliance Review, only contracts greater than $100 million would be in the initial scope of the Implementation Review (IR). However, if an issue is discovered that requires the team to “open the aperture”, other contracts are not precluded.
The DCMA is still working on a response to the following questions:
How do I handle a contract that is currently below $100 million but has options that, in aggregate, would exceed $100 million?
Deltek Acumen – Top-Level Menus
On September 28, 2015, the Defense Procurement and Acquisition Policy Directorate (