Sign In

 

 

Faster, Greater Value and Cheaper—Is It Real?https://www.dau.mil/library/defense-atl/Lists/Blog/DispForm.aspx?ID=74Faster, Greater Value and Cheaper—Is It Real?2018-05-22T16:00:00Zhttps://wwwad.dauext.dau.mil/library/defense-atl/PublishingImages/DATL_May_June2018_4.jpg, https://www.dau.mil/library/defense-atl/PublishingImages/DATL_May_June2018_4.jpg https://wwwad.dauext.dau.mil/library/defense-atl/PublishingImages/DATL_May_June2018_4.jpg<div class="ExternalClass1ED1AF32187E4F93A899B82D866C962C">Yes, it’s real! But only if we adopt a paradigm shift and give the acquisition workforce the tools and resources to make it happen. Let me explain.<br> <br> While talk of acquisition reform in Department of Defense (DoD) acquisition is not new, a significant change in the paradigm for acquiring software reliant systems is being piloted in DoD. This change, when adopted more globally, will affect processes, policies, and job functions of the entire acquisition process—including requirements, testing, and budgeting. It is predicated on a shift from the current sequentially phased, product maturity model to a fully automated and repeatable, continuous integration and delivery model. One of the better known methods that embodies this shift is known as Agile Development, which is enabled by seamless Information Technology (IT) Operations of cloud-based computing resources in both the Development and Operations environments (hereafter referred to as DevOps).<br> <br> What is it? Wikipedia defines DevOps as: “a software engineering culture and practice that aims at unifying software development (Dev) and software operations (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at short development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.”<br> <br> As indicated in the definition, DevOps is not only a practice but also a culture. Organizational culture change is often difficult because behaviors and attitudes of an organization become ingrained after years of operations. Changing these normalized behaviors and attitudes will likely be one of DoD’s biggest challenges when this model is implemented on a larger scale. Another key word in the definition is automation, which is part of a technology wave that is realizing new and faster approaches to fielding capability.<br> <br> As background, Agile DevOps is a particular methodology and should not be confused with the generic term Agile software development that initially was developed in 2001 by a group of 17 software engineers and describes a set of 12 software development principles that are known as the Agile Manifesto. These principles address items such as early and continuous delivery of valuable software, welcoming new requirements, simplicity, customer satisfaction by delivering valuable software, and more.<br> <br> Several Agile-based approaches have been adopted, but the Agile DevOps distinction is its close bond between developers and operators and its fast release cadence, all enabled by leveraging cloud-native IT operations. Some programs have implemented a “Water-Scrum-Fall” approach, where Agile sprints (short development cycles) are integrated into a waterfall development method. Waterfall is based on the sequential development cycle of analyze, design, develop, test and field. Waterfall attempts to address all the requirements for that design baseline before testing and fielding the software. This Water-Scrum-Fall method is not consistent with the DevOps approach primarily because of the lengthier release frequency, treatment of requirements and testing approach. Agile Dev­Ops will be the basis of the following discussion to achieve faster, greater value and cheaper programs.<br> <br> Use of a faster and more effective software methodology has significant implications for DoD. Software is embedded in just about everything we use, including our cars, phones and household appliances. According to the March 5, 2009, <strong><a href="https://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf">NASA Study on Flight Software Complexity</a></strong>, the system functionality delivered by software in modern fighter aircraft grew from 8 percent in 1960 and to 80 percent in 2000 with the F-22 Raptor stealth fighter jet. This trend is accelerating and is enabled by advances in microprocessors that use less space and power while providing significantly greater computing performance. Other technologies such as cloud computing, test automation, mobile computing, and machine learning also contribute to this increased demand for software. Since many of these commercial technologies are readily available in the open market, potential adversaries are actively leveraging them as evidenced by multiple and continuing cyber-attacks.<br> <br> Before discussing the imperative to move to a new model that enables faster and high-value capabilities, we should consider the issues associated with long development and fielding cycles. Many of these are not new; DoD has emphasized reducing cycle times for many years—but with mixed results. The pace of technology advancement is so rapid that any long development effort risks producing an obsolete system before it is first deployed. Long development efforts enable our potential adversaries to deploy counter capabilities inside our acquisition cycles, potentially jeopardizing our technological edge and mission success. Long cycle times also suggest we cannot react quickly to changes in threats or exploit new opportunities without even longer extension of the cycle time. Finally, long fielding cycles are expensive and delay user feedback on system utility and value. Lacking rapid feedback, it is very difficult to make necessary corrections without another big investment of scarce resources.<br> <br> <span style="color:#B22222;"><strong>Faster</strong></span><br> A deliberate process of requirements generation and validation that attempts to address capability needs fully prior to initial fielding results in cycle times measured in years (and longer for complex systems such as fighter aircraft). Users devote significant effort to analyzing capability needs and then translating those needs into requirements documents that are vetted throughout the specific military Service and Joint Staff. Testing often is very expensive and time consuming, so testers desire a stable system design that is representative of production prior to initial operational testing. The phased acquisition process establishes a series of gate reviews (e.g., Milestone Reviews, Decision Reviews, Design Reviews) that often slow the cycle, based on progress toward greater product maturity within cost, schedule, and performance boundaries. Our contracting process can take years to award a competitive contract and often must then delay further work until a protest is resolved. So how can an approach like Agile DevOps speed up this cycle without losing the process rigor of the phased approach?<br> <br> A key tenet in today’s environment is that rapidly fielding technology and software capability is critical to success. We have seen how software is disrupting industries like taxi service (Uber), movies (NetFlix), and hotels (Airbnb). Many businesses know that rapid fielding gives them a competitive edge when they are the first to market, providing customers with features that can attract new sales and drive growth. Companies like Capital One, Target, Walmart, Nordstrom, Facebook, Adobe, Sony Pictures Entertainment, and Fidelity Worldwide Investment have adopted this continuous integration, continuous delivery model with great success. Amazon releases new software to the Amazon.com website every few seconds (see <strong><a href="https://www.youtube.com/watch?v=dxk8b9rSKOo">Jon Jenkins on YouTube at Velocity 2011</a></strong>). Commercial companies invest hundreds of billions of dollars each year on new IT, and it will be difficult for DoD and our private suppliers to keep pace without new and more flexible processes.<br> <br> DoD also needs the rapid fielding of capabilities to counter new threats, replace hard-to-maintain legacy systems, and keep pace with asymmetric adversaries such as cyber-attackers. DoD is attempting to pilot this DevOps model with the help of organizations like the <strong><a href="https://www.dds.mil/">Defense Digital Service</a></strong> and the <strong><a href="https://www.diux.mil/">Defense Innovation Unit Experimental</a></strong>. Those two new organizations bring commercial business and technology domain expertise to assist the transition to commercial technology and methods. The recent <strong><a href="https://www.congress.gov/bill/115th-congress/house-bill/2810">Fiscal Year 2018 National Defense Authorization Act </a></strong>directed DoD to implement Agile pilot programs within each military Service.<br> <br> Programs like the Air Force Air Operations Center (AOC) Pathfinder pilot have formed and started this effort. One of the early pilot software applications, the <strong><a href="http://www.afmc.af.mil/News/Article-Display/Article/1453339/airmen-code-for-combat-in-cambridge/">Tanker Planning Tool</a></strong>, was fielding very quickly and received great feedback from users. This new software application streamlined aerial refuel­ing tanker operations, saving 350,000 pounds of fuel and about 140 man-hours per week. The AOC Pathfinder team has partnered with the Defense Acquisition University (DAU) to document lessons learned, best practices and policy recommendations to enable greater use of the approach. This partnership is helping DAU build new courseware and performance learning content to enable the workforce’s consideration of this model as part of its acquisition strategy. It also enables the identification of statutory and policy obstacles that may need revision.<br> <br> <span style="color:#B22222;"><strong>Greater Value</strong></span><br> Delivering value with smaller releases of software is an important part of this new model. While it’s not intuitively expected that a smaller release of software with less functionality could provide greater value than a much larger software program, consider the learning and iteration made possible by getting the software to the user quickly. Even in a failed first release, the rapid feedback and learning will enable subsequent success as the software is iterated to meet user needs. Industry data on requirements generation and waterfall acquisition confirms that building to specified and static requirements results in building features that create no gains or perhaps even negative or lost user value to the user in 66 percent of the cases, afflicting the user’s organization with software that hinders rather than helps mission success.<br> <br> Consider the following from the <strong><a href="https://www.gao.gov/assets/690/682765.pdf">February 2017 Government Accountability Office Report 17-317</a></strong>: “Although the executive branch has undertaken numerous initiatives to better manage the more than $80 billion that is annually invested in information technology (IT), federal IT investments too frequently fail or incur cost overruns and schedule slippages while contributing little to mission-related outcomes. Agencies continue to have IT projects that perform poorly. Such projects have often used a ‘big bang’ approach—that is, projects are broadly scoped and aim to deliver functionality several years after initiation. According to the Defense Science Board, this approach is often too long, ineffective, and unaccommodating of the rapid evolution of IT.”<br> <br> The value obtained from Agile DevOps comes from small pieces of total system utility. These narrow slices of capability attempt to solve the user’s biggest problems and provide the greatest use. Using DevOps, the challenge is to provide these priority features quickly and then build out the rest of the pain points in a prioritized and iterative fashion. By comparison, Agile DevOps can solve the most pressing needs and provide the most useful capability before a waterfall development program completes the initial requirements analysis and system design phases. This iterative feedback after the quick releases gives all parties insight to the point when enough value is deployed, avoiding development of useless functionality and saving money and time.<br> <br> <span style="color:#B22222;"><strong>Cheaper</strong></span><br> It’s difficult to compare the costs of Agile DevOps to the waterfall method, but several important cost concepts are relevant. Agile DevOps does not track software development in terms of the traditional metrics of cost, schedule and performance. Rather, metrics such as value to user, throughput (measured by release cadence and backlog velocity), capacity (number of teams needed to keep up with user’s prioritized backlog); and quality (change failure rate). If we accept the Agile principle of welcoming new requirements, then a frozen baseline to gauge program performance does not work.<br> <br> A second consideration of cost involves automation. Agile software development leverages automation and built-in quality methods to ensure the product is always mature and deployable, even while changing. Automated developer and test tools are essential to enable this model. In approaches like test-driven development, testing begins at the start, not the end, in the project life cycle. Automated testing helps to eliminate error backlogs and deploy products more quickly and with better results. Automation is absolutely critical because end-to-end testing must be conducted repeatedly and iteratively to ensure quality of each viable software product. Note that cybersecurity can be enhanced with automated cyber scans and the inherited security attributes from the cloud computing environments that support the development environments.<br> <br> We can reasonably expect that automation will cost less than human labor. Through technologies like artificial intelligence, machine learning, autonomy and robotics, human labor is no longer needed for many tasks and thus will shift to other roles. Reducing the need to pay for human labor and for human errors will cut costs. For example, some of the selling points of driverless cars include fewer accidents, more efficient use of space and energy, and lower costs than owning, maintaining, and insuring one’s personal vehicle. Larry Ellison, Oracle’s chief technology officer, said during a keynote address at the 2017 Oracle Open World conference, “but the shock is, you have to be willing to pay much less” while discussing Oracle’s new fully autonomous database that requires no human labor to run, upgrade, patch or tune the software. And consider this recent news headline: “<strong><a href="http://www.newser.com/story/253057/after-humans-fail-drone-spots-lost-hiker-in-20-minutes.html">After Humans Fail, Drone Spots Lost Hunter in 20 Minutes</a></strong>” (John Johnson, Newser.Com, Dec. 19, 2017). The article discussed how a nightlong search for a lost hunter involving helicopters and extensive human foot patrols proved fruitless. The next day, a relatively new type of drone with automated sensors located the lost hunter within 20 minutes. Rescuers on foot then found him and escorted him back to safety.<br> <br> <strong>Conclusion </strong><br> The future is here when it comes to faster, more responsive, and high-value programs. However, a transition to the Agile DevOps model and other new approaches will not be easy for DoD. In addition to “unlearning” the old way of doing acquisition and adopting new processes, a big culture change is most definitely in order. Culture change is difficult and does not happen overnight. The good news is there seems to be wide consensus that change is needed and that DoD is starting to take reform actions.<br> <br> Several agencies have recently announced new initiatives to accelerate fielding and streamline acquisition cycles. Innovation is becoming more than a buzzword as DoD teams experiment with new techniques to accelerate the delivery of value to the warfighter. We should remember, though, that all the new technology and methods are great, but people will be the key to success. The workforce will need rapid and relevant training, automation and software infrastructure resources, and leadership support to enable this change. Momentum is building, if we can only keep it rolling! <hr /><em>Brian Schultz is a professor of Program Management at the Defense Acquisition University’s Fort Belvoir, Virginia, campus. He can be contacted at <a class="ak-cke-href" href="mailto:brian.schultz@dau.mil">brian.schultz@dau.mil</a>.<br> <br> The author thanks Lt Col Jeremiah Sanders, Air Operations Center Program Manager, for his contributions to this article.</em></div>string;#/library/defense-atl/blog/Faster,-Greater-Value-and-Cheaper—Is-It-Real
Treating the Side Effects of Processhttps://www.dau.mil/library/defense-atl/Lists/Blog/DispForm.aspx?ID=73Treating the Side Effects of Process2018-05-01T16:00:00Zhttps://wwwad.dauext.dau.mil/library/defense-atl/PublishingImages/DATL_May_June2018_1.jpg, https://www.dau.mil/library/defense-atl/PublishingImages/DATL_May_June2018_1.jpg https://wwwad.dauext.dau.mil/library/defense-atl/PublishingImages/DATL_May_June2018_1.jpg<div class="ExternalClassC8E7A63B2ADB49F1BBA1EB7228FB2AD7">When I arrived to my program management office (PMO) 9 years ago, my colleagues and I frequently met in the office of the chief engineer (CE) to troubleshoot problems. It often went something like this:<br> <br> Me: “Aircraft XYZ is broken, needs a temporary repair, and one-time flight. We’ve created the repair procedures and are ready to provide them to maintenance. What’s next? Who needs to approve them?”<br> <br> CE: “What did we do last time? Did we do a risk assessment? Did we have the program manager sign it? Did we coordinate with the operator?”<br> Me: “I don’t remember. I’ll research it.”<br> <br> Next, I would seek a colleague who would describe his experience. Of course, it differed from what I had intended. We would huddle again in the CE’s office and decide whether to repeat the previous process or do something different.<br> <br> The result was always the same: The airplane was returned to safe flight with appropriate approvals, but we killed hours trying to determine the approval process—something we had accomplished many times but not often enough to have memorized it.<br> <br> Finally, after several years of déjà vu, the CE and I took the time to write an organizational process. We printed all regulations, sequestered ourselves offsite, mapped the flow on a whiteboard, and authored the rubber-on-the-road process document. The result provided clear guidance to engineers and enabled consistent execution.<br> <br> <strong>Processes Spread ...Along With Side Effects</strong><br> Similar situations occur across all Department of Defense (DoD) acquisition. We need useful process documents to instruct, enable repeatability, incorporate lessons learned, and make us efficient. However, as I have gained experience as a creator, implementer, enforcer and leader, I have discovered processes also have significant negative side effects. Just as a physician must beware of potential side effects when prescribing medicine, we leaders must beware of potential side effects when prescribing processes.<br> My aim herein is to share three side effects that I have personally experienced. I propose that leaders adopt and communicate new principles to reframe the mindset of our acquisition workforce.<br> <br> <strong><img alt="" src="/library/defense-atl/DATLFiles/May-Jun2018/2_figure1.png" style="margin-left:3px;margin-right:3px;float:left;width:650px;height:639px;" />Side Effect Number 1: Distraction</strong><br> A few months ago, another government agency agreed to lend our PMO an aircraft for testing. This partnership would save taxpayers several hundred thousand dollars.<br> This was a unique situation and our organizational processes did not prescribe exactly what needed to be done for airworthiness, test or liability. Our engineering team dove deep into the details, resulting in an excellent, several-page-long justification on how we would execute in compliance with affected regulations.<br> <br> Unfortunately, the critical thinking about the test, which was not a trivial undertaking, was limited to a couple paragraphs. We had spent the majority of our time and brainpower on ensuring compliance with regulations, and not on ensuring a safe and technically adequate test. Our concern about compliance distracted us from our primary role.<br> We need to ensure that our mindset has a role for processes, but only a role in service to our DoD acquisition mission. Perfect process execution does not equate to mission success. Our mission is not to acquire and sustain process artifacts. Our mission is to deliver capabilities—a warfighter’s edge. Every process, form, coordination and approval requires time and money. The expense must be worthwhile. Often we limit our concerns to liability and regulatory noncompliance. We rarely think and talk of limited time as our threat.<br> <br> Consequently, every acquisition organization should be graded on mission accomplishment—not process compliance. An inspection should focus on whether we met our commitments to the warfighter. Did we appropriately equip them? If not, why not? Did we tailor existing processes? If we didn’t have the authority, did we raise the issue to the right decision level?<br> <br> Over the years, I have become more intentional about communicating how processes contribute to fulfilling our mission. I no longer begin trainings, e-mails, or process documents with a long list of prescribing regulations. Rather, I explain how the process enables us to successfully equip warfighters. If our workforce doesn’t believe in the purpose of the process, they will likely undermine it with passivity or slander.<br> <br> Another communication tool I use is a circle-of-importance chart (Figure 1). The chart clarifies to my team where I expect full compliance, where we can evaluate compliance case by case, and where I want them to maximize tailoring. Acquisition processes always will need to cover enormous breadth. It is the leader’s responsibility to orient their people to which processes are most valuable to the mission and which are not.<br> <br> <strong>Side Effect Number 2: Disbelief</strong><br> In preparing for my unit’s compliance inspection this fall, I tried to keep count of the Service, Major Command, and Center-level regulations that a PMO’s engineering workforce must follow. These are documents that say directly or indirectly “The program manager (PM), in coordination with the CE, shall … .” I gave up counting at 54 process documents, totaling 1,638 pages. I had not started counting DoD-level regulations, military standards, or any guides and templates.<br> <br> I honestly try my best to keep up—periodically checking multiple websites, downloading documents, printing and building binders, reading and highlighting, and distributing to my team. Frankly, though, it is tiring and unrealistic. I will never have enough staff to fully implement it. Recently I saw that a competency model had indicated we were staffed at 40 percent of the requirement level. I am in disbelief.<br> <br> We must embrace the fact that we are all regulators who influence the size of the government. If we complain at home about big government bureaucracy but want to enlarge our processes at work, we contradict ourselves.<br> <br> Processes should be value-added, minimum, clear, realistic, resourced, up-to-date, and at the right level. This is very hard and takes a long time! Each process I’ve authored has taken at least a year and involved numerous offsite meetings and peer reviews. <ul> <li>Value-added: This will help us execute our mission and equip our talented workforce.</li> <li>Minimum: The document is short enough that people actually will read it. It is not redundant.</li> <li>Clear: We can actually understand what the process is telling us to do. It is not ambiguous.</li> <li>Realistic: The process actually can be accomplished.</li> <li>Resourced: We have the resources to execute the process. We will follow through and hold ourselves accountable.</li> <li>Up-to-date: The process is relevant and accurate. The people and organizations exist.</li> <li>At the right level: The process is prescribed at the correct organizational level. We have not prescribed anything that can be figured out by lower levels.</li> </ul> Committing to these characteristics should result in less regulations and leaders who reward performance for simplification, elimination, and streamlining. As I’ve updated my process documents, I’ve counted words to ensure reduction. (And the instructions are undoubtedly improving.) Right now is the perfect time and opportunity for process killers. President Trump’s Executive Order 13771 requires any new regulation be accompanied with the elimination of two existing regulations. Every person in acquisition needs to embrace this guidance—not just senior leaders. Former Under Secretary of Defense for Acquisition, Technology, and Logistics Frank Kendall used to say that we must “have the courage to challenge bad policy.” Now is the time to do so!<br> <br> A good litmus test is to change our terminology. Instead of calling my instructions “processes,” I occasionally call them what they really are: regulations. No one ever says “I’m a regulation person.” The negative connotation forces me to think harder about its necessity and scope. Am I confident this needs regulated?<br> <br> We also need to communicate the values that guided the construction of the process. Without them, people will be less equipped to conduct smart tailoring. Is there another way to implement the values? I have developed charts at the beginning of my training sessions to communicate the guiding values. If you want to deviate from the process, you need to tell me how you will still satisfy the values.<br> <br> <strong>Side Effect Number 3: Division</strong><br> When I assumed the role of CE, I became responsible for all processes leading to safe, suitable, secure and effective products for my customers. I read military Service regulations, processes, delegation letters, and position descriptions to facilitate understanding my responsibilities.<br> <br> One major frustration was reading a document describing the authority and importance of a CE, and another document directing external approvals for every configuration change, regardless of size. (Furthermore, I would be frequently inspected.) Was I being trusted by leadership or not? Did I have autonomy or not?<br> <br> Process documents and external dependencies often send mixed messages of responsibility and trust. Too easily they lead to “us vs. them” attitudes within our own teams.<br> The nature of DoD acquisition requires a matrixed and multilevel work environment. However, external dependencies and authorities can easily have negative impacts on speed, unity and creativity. External authorities can leave PMOs with the impression they only care about their discipline. On the other side, PMO staffs can develop brain-dead behaviors, such as passing the buck, because “it’s someone else’s job.” In either case, our mission suffers.<br> <br> We should maintain high expectations of our professionals. Processes should start with expectations of trust and competence and show where there is freedom to act. Processes should provide enough framework for our talented people to understand their responsibility and succeed (Figure 2). Processes should get instructions right for the majority and expect core values and principles to guide the rest. We should prize competence over compliance. We should aim for professionals who know their craft and can smartly advise decision makers on tailoring. We should reduce external dependencies and increase empowerment and trust. We should increase training and communication.<br> <br> Admittedly, this is hard. People will disappoint us. Our natural reaction will be to write a process document. It may work in the short term, but it won’t in the long. We have to resist solving people problems with processes. If someone is not acting with competence, discipline and professionalism, we need tough supervisory work—not a new process or external dependency for everyone.<br> <br> <strong><img alt="" src="/library/defense-atl/DATLFiles/May-Jun2018/2_figure2.png" /><br> Commit to Treatment</strong><br> DoD acquisition is complicated and requires trained professionals. We are entrusted by taxpayers and warfighters. We need to deliver effective warfighting equipment. We need to avoid costly mistakes. We need to provide consistent and competent assurances. There is no doubt we need processes.<br> However, we must beware that processes often have unintended side effects: distracting us from our mission, creating disbelief in each other and the system, and dividing our teams. We must be vigilant to treat these side effects. Leaders must be willing to sacrifice personal comfort, adopt new principles about processes, and frequently communicate these principles to the acquisition workforce. If people can adopt a new mindset about processes, the change has the potential to be bigger than execution—it can be cultural. <hr />Bailey is a chief engineer in the Air Force Life Cycle Management Center at Wright-Patterson Air Force Base in Ohio.<br> <br> The author can be contacted at <a class="ak-cke-href" href="mailto:john.bailey.1@us.af.mil">john.bailey.1@us.af.mil</a>.</div>string;#/library/defense-atl/blog/Treating-the-Side-Effects-of-Process
Sizing the Supply Chain From the Top Downhttps://www.dau.mil/library/defense-atl/Lists/Blog/DispForm.aspx?ID=75Sizing the Supply Chain From the Top Down2018-05-01T16:00:00Zhttps://wwwad.dauext.dau.mil/library/defense-atl/PublishingImages/DATL_May_June2018_5.jpg, https://www.dau.mil/library/defense-atl/PublishingImages/DATL_May_June2018_5.jpg https://wwwad.dauext.dau.mil/library/defense-atl/PublishingImages/DATL_May_June2018_5.jpg<div class="ExternalClass2B6CD41AA8244AE3A32406BFE3F8190C">Spare-part inventory has been, and continues to be, an important element of logistics support to the U.S. Air Force (USAF) fleet of aircraft. Not only are spare parts a substantial cost driver for all acquisition programs, but securing these parts in correct quantities is critical in ensuring future aircraft availability.<br> <br> Inventory forecasting models typically use historical, or expected, item demands on the supply system, coupled with expected delay times, in calculating the size of inventory necessary to support a system or infrastructure. This method often suffices for existing systems. But what about projecting inventory sizes for new, or significantly modified, systems?<br> <br> One could simply select what is considered representative data and apply a set of business rules to predict the inventory requirements for any change in sustainment concept or requirements for a future system. However, the vagaries surrounding the supply chain of a yet-to-be-developed strategy or system are such that selecting a representative system, or group of items, may be problematic and drive analysis of multiple scenarios to determine a range of possibilities. Let’s look at a model that may dramatically simplify that process by eliminating all but one sole user input: the number of expected repairable items.<br> <br> <strong>How Much Do Spare Parts Cost?</strong><br> This effort began with a simple question: “What is the average cost of 1 day’s worth of repairable inventory pipeline?” Since the pipeline is a function of daily demand, cost and acquisition time, we defined pipeline as:<br> <br> where<br> P is the total value (in dollars) of the pipeline inventory for a particular part<br> d is the daily demand from inventory for a particular part<br> c is the cost (in dollars) of a particular part<br> n is the number of days required to acquire a replacement part for inventory<br> <br> <img alt="" src="/library/defense-atl/DATLFiles/May-Jun2018/3_table1.png" style="width:500px;height:842px;margin-left:3px;margin-right:3px;float:left;" />The initial question was suggested by the idea that if an average per part, per day pipeline cost could be established, that average cost could be then used to aid in the evaluation of alternative sustainment concepts—specifically, concepts that may increase or reduce the inventory resupply times. Using Air Force recoverable item data from March 2015 for 7,571 aircraft repairable items, the algorithm suggested that the average cost of a day’s worth of repairable item pipeline was about $10,628, with an average of 51 days in the pipeline. This average value of $10,628 was then used to compare a predicted total pipeline value to the actual total pipeline value, about $4 billion and about $3.4 billion respectively, revealing a disappointing disparity. Our model provided an overestimation of approximately 15 percent.<br> <br> The initial observation of the actual pipeline data suggested perhaps a number of high-cost and/or high-demand items could be skewing the estimations to the right. To investigate this premise, the same model was used while eliminating 292 items with a cost per day value of $50,000. In this scenario, the model revealed a predicted total pipeline value of $1.2 billion—within 8.3 percent of the actual $1.2 billion value of the remaining 7,279 items. It was this improvement in the accuracy of the estimates that prompted further efforts to find a better method for estimating pipeline values by leveraging the entire data set.<br> <br> <strong>Dealing With Difficult Data</strong><br> Visual observation of the 2015 data revealed that while 86 percent of the items fell below the $10,628 average, the remaining 14 percent were high enough to significantly impact the resultant average calculation, suggesting that segmenting the data set could prove helpful. Segmenting the data by effect on the average pipeline values into three categories provided an initial method of classifying the data: <ul> <li>Distant Outliers—more than $500 million per day (with short pipeline times) or, replacement times close to 2,400 days (with low cost).</li> <li>Contributing Outliers—below $125,000 daily demand and replacement times less than 300 days.</li> <li>Above Average—less than $30,000 daily demand and with a maximum replacement time of 75 days. There was no rigorous statistical testing to ensure the validity of the categories. But for the purposes of this initial effort, face validity was deemed sufficient. Also, the results, while interesting, were not particularly useful at this point.</li> </ul> <br> ontinuing the effort, we attempted to find meaningful break points or groupings in the data. Through repeated trial and error, four additional categories were developed based on repair cycle times: (1) Base (fewer than 10 Days); (2) Low (10 to fewer than 40 Days); (3) Regular (40–100 Days); and (4) High (more than 100 Days).<br> <br> “Base” represented items with a minimal repair cycle time, “low” represented items somewhat below average; “regular” represented items around and above average; and “high” represented the very items with very large repair cycle times. The categories’ usefulness was confirmed by examining the data in weapon system subsets and comparing them with the total. More specifically, we wanted to know if the item groupings for all aircraft items held true for platform level data. As shown in Table 1, the item groupings at the aggregate level hold true at the platform level as well.<br> <br> <img alt="" src="/library/defense-atl/DATLFiles/May-Jun2018/3_figure1.png" style="margin-left:3px;margin-right:3px;float:right;width:1038px;height:400px;" />While uniformity of data across the enterprise was clear, the related cost of each repair cycle time category was less consistent. As illustrated by Figure 1, none of the platform groupings aligns well with the all aircraft aggregation. On the low end, “Other Aircraft” indicated approximately half the all aircraft values. On the upper end, the Fighter category is particularly problematic since all categories except “High” are dramatically larger than the all aircraft average. This divergence in the cost across platforms led to poor results when testing actual legacy weapon system pipelines against the average cost values using platform groupings.<br> <br> Using the early data evaluation, once again, it was clear that a small number of items with dramatically high cost were the primary reason for cost inconsistency. That irregularity was not eliminated with the weapon system platform aggregations. Closer examination of the data revealed some weapon systems had a significantly greater number of contributing outliers (and above average items) than others. As demonstrated in Figure 1, Fighters tended to have the largest concentration of these high-cost and high-demand items. However, these items are not limited to the Fighter platform type. Specifically, the B-1 Bomber and the KC-135 jet-powered refueling tanker also had relatively high numbers of “outliers.”<br> <br> The percentage of high-cost contributors, coupled with some understanding of the technical complexity of the weapon system, led to the hypothesis that “complex” systems such as the F-16 Fighter and B-1 are more similar than “simple” systems like the helicopters. To say that any military weapon is “simple” is probably a<br> misstatement; however, these descriptive terms were chosen because of the nature of the supply pipeline more than because of the actual technology. Therefore, “simple” systems were those that had less than 2.5 percent high-cost contributors in their pipelines, while “complex” systems had greater than 3.25 percent high-cost contributors. The F-15 Fighter fell between the discriminating thresholds.<br> <br> <img alt="" src="/library/defense-atl/DATLFiles/May-Jun2018/3_figure2.png" style="margin-left:3px;margin-right:3px;float:left;width:807px;height:400px;" />Exploring the relationship between the high-cost and high-demand items and a weapon system’s actual calculated pipeline is important too. Figure 2 illustrates that, with actual pipeline value growth, the number of high-cost and high-demand items also grew, revealing that the ratio of high-cost and high-demand items is a dominant factor in pipeline cost. Moreover, it the number of items, does affect the pipeline, even though less dramatically. Figure 3 shows trends related to pipeline cost and number of items. In general, the number of items follows the pipeline cost with only the AC-130H gunship defying the trend.<br> <br> In summary, pipeline data analysis revealed the following attributes: pipeline distributions aggregate uniformly at the enterprise and weapon system platform level, pipeline costs aggregate differently at the weapon system platform level, high pipeline cost contributors correlate with actual calculated weapon system pipelines, high pipeline cost contributors tend to fall on a continuum of weapon system complexity, and the number of repairable items in a system relates to the cost of the actual pipeline.<br> <br> <strong><img alt="" src="/library/defense-atl/DATLFiles/May-Jun2018/3_figure3.png" style="margin-left:3px;margin-right:3px;float:right;width:701px;height:500px;" />Model Calculations</strong><br> The model constructed in support of this research used the number of repairable items as the single user input element. The calculations behind the model are illustrated in Table 2. The categories shown in the equation were derived from those from Table 1’s “All Aircraft” segment. The values varied somewhat since the distant outliers and contributing outliers above $50,000 were not included in the “simple” model. The product of this arithmetic was multiplied by the number of items input by the user (N) to calculate a pipeline of a simple system and a complex system with the same number of items. Comparing multiple data sets revealed the dollar values do change, but the net effect and rough cost output from the calculations remained consistent. At its simplest level, the model performs this calculation:<br> <br> Items (N) * $451,790 = Complex<br> solution<br> Items (N) * $181,556 = Simple solution<br> <br> <strong>Analyzing the Results</strong><br> As previously noted, modeling at the weapon system platform level was tested, but provided poor results, However, the concept of discrimination between “complex” and “simple” systems was ultimately chosen due to superior test results against actual pipeline values for individual weapon systems. Figure 4 shows actual pipeline values compared to the model results. In this test, the model computations used the actual number of repairable items for each weapon system. Also, weapon systems were grouped by “simple and “complex” by their specific data characteristics. As shown in Figure 4, particular systems performed at varying levels of accuracy. Some of the more notable results are described below.<br> <br> The majority of the “complex” systems track well. However, the F-16 and F-15E actuals were significantly above the complex model estimate. The F-15 and the B-52 were significantly lower than the “simple” estimate. Given the age of the platform, it would not be unreasonable to assume the B-52 would classify as a “simple” system. However, the actual pipeline value of about $206 million fell squarely between the “simple” ($124 million) and “complex” ($308 million) values computed by the model. In examining these results, it was discovered that a single electronic warfare item accounted for $62 million of pipeline.<br> <br> <img alt="" src="/library/defense-atl/DATLFiles/May-Jun2018/3_figure4.png" style="margin-left:3px;margin-right:3px;float:left;width:1118px;height:500px;" />The F-15 was better represented by the “simple” pipeline estimation. Unlike the B-52, a tangible reason was elusive for the F-15 (736 items with a $221 million pipeline) estimate being closer to the “simple” solution ($134 million) than the “complex” ($332 million). All of the F-15 characteristics point to it being a “complex” system, but the “simple” solution is $87 million below the actual, and the “complex” solution is $112 million above. Similar to the case of the B-52, the F-15 actual fell between the “simple” and “complex” points.<br> Finally, while the estimations are not precise, the model produced generally unbiased results. That is, the estimates generated were not consistently over or under the actual pipeline values of current systems.<br> <br> <strong>Model Applications</strong><br> The primary use for the model developed as a result of this research would be to estimate supply pipelines for future aircraft systems—specifically, systems that are in the post-Milestone A but pre-Milestone B phase of acquisition. At this point in the acquisition cycle, it is clear that a system is to be purchased, and the general system characteristics are known. But unclear at this point is the specific system and its configuration—hence the need for an estimation methodology.<br> <br> Another application is as for a method for estimating the cost, or savings, associated with a change to supply chain dynamics. Examples would include providing a means to weigh the relative impact of implementation of a method to accelerate pipeline times for high-cost/high-demand items or to reduce the overall average pipeline time for a system or systems. Conversely, one could estimate the cost of increases to pipelines as a trade-off for another product support element. For example, one could estimate the cost trade-offs between slowing the repair cycle (e.g., eliminating a work shift) and increasing the supply chain to accommodate.<br> <br> <strong><img alt="" src="/library/defense-atl/DATLFiles/May-Jun2018/3_table2.png" style="margin-left:3px;margin-right:3px;float:right;width:672px;height:500px;" />Conclusion</strong><br> This study developed and analyzed a method for computing aircraft weapon system supply “pipelines” using a single user input data element: the number of repairable items in a weapon system. Exploration of supply chain data revealed the following characteristics: Pipeline distributions (groupings) aggregate uniformly at the enterprise and weapon system platform level, pipeline costs aggregate differently at the weapon system platform level, high pipeline cost contributors correlate with actual calculated weapon system pipelines, high pipeline cost contributors tend to fall on a continuum of weapon system complexity, and the number of repairable items in a system impacts the cost of the actual pipeline. Using the uniformity related to high cost, high demand correlation and number of repairable items, it is possible to estimate pipeline values of future systems or concepts. Coupling legacy data with an expert judgment of future system and concept attributes (the level of system complexity and expected number of repairable items) the expected pipeline cost can be projected. <hr />Blakey is Senior Logistics Advisor for Headquarters Air Force Materiel Command Studies in the Analyses and Assessments Division at Wright Patterson Air Force Base in Ohio. He holds a Master’s degree in Logistics, is Level III certified in Life Cycle Logistics and in Program Management, and is certified as an Acquisition Technology and Logistics KLP PSM. Bayer is a professor of Life Cycle Logistics at Defense Acquisition University at Kettering, Ohio. He is a Level III certified Life Cycle Logistician, holds a doctorate in Business Administration and a master’s of science degree in Logistics Management.<br> <br> The authors can be contacted at <a class="ak-cke-href" href="mailto:robert.blakey@us.af.mil">robert.blakey@us.af.mil</a> and <a class="ak-cke-href" href="mailto:michael.bayer@dau.mil">michael.bayer@dau.mil</a>.</div>string;#/library/defense-atl/blog/Sizing-the-Supply-Chain--From-the-Top-Down
Exceptional Contributions Lauded in Four 2017 Packard Awardshttps://www.dau.mil/library/defense-atl/Lists/Blog/DispForm.aspx?ID=79Exceptional Contributions Lauded in Four 2017 Packard Awards2018-05-01T16:00:00Zhttps://wwwad.dauext.dau.mil/library/defense-atl/PublishingImages/DATL_May_June2018_9.jpg, https://www.dau.mil/library/defense-atl/PublishingImages/DATL_May_June2018_9.jpg https://wwwad.dauext.dau.mil/library/defense-atl/PublishingImages/DATL_May_June2018_9.jpg<div class="ExternalClass86CF6E9820AC4CF5A66BEBE3DCA68A59"><img alt="" src="/library/defense-atl/DATLFiles/May-Jun2018/38493185820_8a4bbee1e7_k.jpg" style="margin-left:3px;margin-right:3px;float:right;width:800px;height:302px;" />The 2017 winners of the premier Department of Defense (DoD) acquisition honor—the David Packard Excellence in Acquisition Award—made exceptional contributions in support of the National Defense Strategy, the Honorable Patrick M. Shanahan, Deputy Defense Secretary, said earlier this year.<br> <br> At the Feb. 16, 2018, Pentagon ceremony honoring the four teams that received the award, Mr. Shanahan commended the teams for their hard work, innovation and creative ideas. He said that their efforts support performance, affordability and increasing lethality: “Your work embodies what we want to accomplish with the National Defense Strategy [NDS]. The type of work that the teams have done is exemplary of what the NDS is all about.”<br> <br> The Honorable Ellen M. Lord, Under Secretary of Defense for Acquisition and Sustainment, said that the teams epitomized the best in acquisition: “We value acquisition because we are the people who need to take care of the taxpayers’ dollars. We have roughly $1.9 trillion in programs of record over the next 10 years, so it is significant that we take care of those dollars and spend them well.”<br> <br> <strong>A<img alt="Maritime Patrol and Reconnaissance Aircraft (MPRA) Program Office From the left: Deputy Secretary of Defense Patrick M. Shanahan, Mr. Jack Vess; CAPT Charles Stickney, U.S. Navy (USN); CAPT Anthony (Tony) Rossi, USN; Ms. Holli Galletti; Under Secretary of Defense for Acquisition and Sustainment Ellen M. Lord; Mr. James McDermott; CAPT Molly Boron, USN; and Mr. James Gerber." src="/library/defense-atl/DATLFiles/May-Jun2018/39590897804_01c7600f24_k.jpg" style="width:742px;height:400px;margin-left:3px;margin-right:3px;float:left;" /> Brief History of the Award</strong><br> The Packard Award is named for former Deputy Defense Secretary David Packard and recognizes organizations, groups and teams that have demonstrated exemplary innovation in the use of best acquisition practices that achieve acquisition excellence in DoD. It was first awarded in 1997.<br> <br> Packard was co-founder and chairman of the Hewlett-Packard Company and chairman of the President’s Blue Ribbon Commission on Defense Management, chartered by President Ronald Reagan in 1985. He was deputy secretary of defense in the Nixon administration. Packard founded the Defense Systems Management College in 1971 and was a strong advocate of excellence in defense acquisition practices and a revolutionary founder in how the DoD acquires products.<br> <br> The Navy’s Maritime Patrol and Reconnaissance Aircraft (MPRA) Program Office (PMA-290): For use of innovative contracting incentives and procurement approaches to manage its large and diverse portfolio of airborne platforms, including the P-8A Poseidon and P-3 Orion series antisubmarine aircraft and other special mission aircraft for the United States Navy and international customers and allies. The Navy office developed and implemented groundbreaking agreements and contracts with prime contractors and small businesses that lowered cost and delivered improved warfighting capability to the fleet between 30 and 40 days ahead of contract schedule, while leading plans to assume lead capability integrator for future P-8A incremental upgrade programs. Specifically, the office procured 49 P-8A aircraft at unit costs almost $60 million lower than earlier production average costs and identified cost-saving opportunities to acquire two additional aircraft under congressional authority to “buy to budget.” In addition, the PMA-290 team quickly secured and fielded advanced airborne signals intelligence and classified special mission reconnaissance capability systems to support combatant commanders in theater and ensure the highest level of aircraft and mission readiness within the MPRA fleet.<br> <br> <img alt="" src="/library/defense-atl/DATLFiles/May-Jun2018/packard.JPG" style="margin-left:3px;margin-right:3px;float:left;width:749px;height:500px;" />The Defense Contract Management Agency (DCMA) Special Programs Quick Closeout Team: For innovation and creativity in contract closeout. Previously, the rate of physically complete contracts coming due for closeout exceeded the number actually being closed, resulting in a 31.1 percent increase in overage (contract closeout backlog), further exacerbating the problem. The DCMA Team piloted new, quick closeout techniques that standardized risk factors and changed the paradigm in how contracts could be closed. There were 4,805 contracts for which quick closeout alone was used, and that made possible a 32.8 percent improvement in reducing overage in contracts, creating a positive closeout rate and reducing the overage contract backlog. In achieving this, the DCMA Team reduced the industry and government’s administrative burden and limited the DoD’s exposure to certain financial risks. This ensured that unliquidated funds from completed contracts could be used before they could be canceled and returned to the U.S. Treasury. The team continued to innovate by expanding application to subcontractors, opening up an additional 10 percent of contracts to quick closeout. The team also deployed multiple initiatives to encourage the practice beyond DCMA and across the DoD, as well as other federal agencies, with potential significant improvements to the acquisition community at large in contract closeout records.<br> <br> The National Reconnaissance Office (NRO) Signals Intelligence Systems (SIGINT) Acquisition Directorate, Low Earth Orbit (LEO) System Program Office: For executing a successful campaign and launching the final Block 2 SIGINT LEO spacecraft in the face of significant obstacles. A catastrophe at the launch base and launch vehicle upper-stage problems resulted in a lengthy delay and put the health of the batteries at risk. This forced a rare spacecraft de-encapsulation to allow for battery reconditioning. Once this reconditioning was completed, the launch proceeded without a single fault or out-of-tolerance condition. During the same time as the launch activity, the NRO SIGINT LEO team completed the critical resign review for Block 3, leveraging cutting-edge technology to meet evolving threats in a manner that focused on affordability. The team cut more than $1 billion in recurring costs by distilling the mission needs to a core set and saving 57 percent of spacecraft requirements. The team’s actions ensured that the newest addition to the NRO SIGINT LEO architecture will provide unmatched information to the intelligence community and the warfighter while affordably meeting the tough new intelligence challenges of the future.<br> <br> <img alt="" src="/library/defense-atl/DATLFiles/May-Jun2018/packard2.jpg" style="margin-left:3px;margin-right:3px;float:right;width:797px;height:500px;" />The National Geospatial-Intelligence Agency (NGA) Agile Web Presence Program Management Office (AWP PMO): For proactive approach and data-driven decision making efforts in addressing and satisfying external and internal user requirements within the intelligence community, DoD and NGA. The AWP PMO fundamentally changed how users access, search for, and discover geospatial intelligence through NGA’s primary online Web presence—the globe. The AWP PMO took the NGA strategy to heart and made significant changes to the globe, allowing customers from across the National System for Geospatial Intelligence to discover content, expertise, and services. Additionally, the AWP team used agile methodology to deploy software releases with minimal downtime or risk that consequently resulted in an increased capacity to integrate more than 10 data sources with more than 5 million products. This increased authoritative content creation, service, and catalogs, as well as advanced search functions with location, topic and event fields. Metrics collected showed these newest capabilities are driving more customers to the globe and enhancing their experience with faster access to the geospatial intelligence data and services, greatly enhancing intelligence-based decision making in support of the warfighter. <hr />Photo 1:<br> Maritime Patrol and Reconnaissance Aircraft (MPRA) Program Office<br> From the left: Deputy Secretary of Defense Patrick M. Shanahan, Mr. Jack Vess; CAPT Charles Stickney, U.S. Navy (USN); CAPT Anthony (Tony) Rossi, USN; Ms. Holli Galletti; Under Secretary of Defense for Acquisition and Sustainment Ellen M. Lord; Mr. James McDermott; CAPT Molly Boron, USN; and Mr. James Gerber.<br> <br> Photo 2:<br> DCMA Special Programs Quick Closeout Team<br> From the left: Mr. Shanahan, Ms. Heidi Frazier, Ms. Irene Johnson, Ms. Cindy Ebenal, Mr. James Norris, Ms. Lord, Ms. Kathleen Miller, and<br> Ms. Marie Greening<br> <br> Photo 3:<br> National Reconnaissance Office’s SIGINT Acquisition Directorate Low Earth Orbit System Program Office.<br> From the left: Mr. Shanahan; Col Mark Davis, U.S. Air Force (USAF); Ms. Tina Harrington; Mr. Mark Sardelli; CAPT Scott Josselyn, U.S. Navy; Ms. Lord; Mr. Steve Simione; Capt Blair Kirk, USAF; and Mr. Rich Ponder.<br> <br> Photo 4:<br> NGA Agile Web Presence Program<br> Management Office<br> From the left: Mr. Shanahan, Ms. Whitney<br> Blackman, Mr. Ryan Phillips, Mr. Bob Ballard,<br> and Ms. Lord.</div>string;#/library/defense-atl/blog/Exceptional-Contributions-Lauded--in-Four-2017-Packard-Awards