Sign In
App icon


Available Now!
Get the App
Click Here to Continue Browser Session   ❯



Creating Incentivized Agile Contracts Incentivized Agile Contracts2021-07-01T16:00:00Z,<div class="ExternalClassF1B26648AD8541DEB2518F640CE1A1BA">Changes are under way in how the Department of Defense (DoD) and the federal government in general develop, buy, and employ technology. The acquisition workforce, policies, procedures, and vendors all need to keep up with the changes. There has been a lot of talk about “Agile.” What is it? Are new procurement methods and strategies required to implement Agile?<br> <br> This article focuses on the kind of thinking that will allow the contracting officer to make use of the many excellent crosswalk references between the Agile terms and available acquisition flexibilities. Traditional procurement methods for product delivery, or waterfall software implementations, lack the flexibility to take advantage of the benefits of time, schedule, and cost that Agile potentially brings to acquisition process. For this reason, DoD must look to Agile methodology, using innovative and creative acquisition planning solutions to procure products and services while maintaining compliance with the Federal Acquisition Regulation (FAR), Defense Federal Acquisition Regulation Supplement (DFARS), Service regulations, and other related federal law. This article looks at the indefinite delivery (ID) contract formulation, and formulations to incentivize Agile behaviors using Firm-Fixed Price (FFP) task orders, as examples of applying current contracting flexibilities to enable the development of Agile contracts.<br> <br> To help meet the challenge ahead, acquisition professionals may choose a new way to look at the venerable statement of work (SOW) for the ID contract. That SOW is a written description of what life will be like once the product is delivered.<br> <br> <img alt="“Agile is not a method of procurement, but a framework based on a set of principles: Agile is based on values and principles that encourage frequent delivery of working solutions to users in order to gain fast feedback and enable continuous learning that is supported by a culture of collaboration.” —Ellen Lord, former Under Secretary of Defense for Acquisition and Sustainment, Nov. 18, 2019." src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article01_image01.jpg" style="width:800px;height:413px;" /><br> <br> Just like a novel, there are smaller stories within the SOW, stories describing each character, event, and location. These lists of stories describe and contribute to the complete novel similar to the way stories about how each feature in a product or software will contribute to how the final products fulfilling the expectations after delivery. The novel is the SOW or performance work statement (PWS) in the ID contract. The details of the SOW or PWS at the ID contract level describe the negotiated Agile processes, ceremonies, artifacts, roles, and responsibilities.<br> <br> The contractor and contracting officer develop the individual stories using the ID contract’s processes and execute the stories with the task orders. The contracting officer must negotiate and document the processes for writing those stories. That is the paradigm shift! Yes, we are ultimately buying a function or service. To get there we are practically buying a process of incrementally describing and executing the steps it takes to arrive at the final function.<br> <br> To make Agile work, we must contract for Agile work processes and trust the successful outcome to diligent execution of those processes. We must select contractors with proven ability to exercise a process, repeatedly, until they deliver the final functionality. Repeating the process through frequent interim milestones means that adjustments can be made for subsequent milestones without requiring the major contract modifications that would be needed by traditional methods.<br> <br> The new kind of thinking starts with a vison of the completed product functionality. This includes a description of the processes that will develop the described functionality in the ID contract. Task orders apply the ID contract processes to develop incremental stages and arrive at full functionality. Agile software development and acquisition procedures use this incremental thinking about an entire acquisition process to delivered product.<br> <br> Software developers, including Jeff Sutherland and Kent Beck, wrote the Agile Manifesto in 2001. Are 20-year-old core values still relevant? Do they have application beyond software development? The manifesto relies on four core values. These values prioritize individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Thinking of the product delivered as a service may help in understanding how Agile operates.<br> <br> The foundational structure of an Agile program includes: <ul> <li><strong>Release</strong>. Capability delivered to users, composed of multiple sprints.</li> <li><strong>Sprint</strong>. Priority capabilities developed, integrated, tested, and demonstrated in an iteration.</li> <li><strong>Daily Scrum</strong>. Team synchronization meeting to plan activities and assess progress and impediments.</li> <li><strong>Sprint Review</strong>. Demonstrate working product to the stakeholders and end users.</li> </ul> This repetitive process focuses on what the risks are, how they are mitigated, and also in the end, what value and success look like.<br> How could indefinite delivery contract formulations allow necessary flexibilities?<br> <br> Agile requires the flexibility to change the description of “acceptable product” as the product is developing. This flexibility already exists in the FAR. We do not advocate waiting for a magical, yet-to-be-developed, flexibility that will suddenly make Agile contracting a matter of fill-in-the-blank in an approved template. Such a regulatory rescue will not happen because: (a) The necessary flexibilities exist and are here, now, in the FAR, and (b) Creating new regulation at the FAR level takes a long time … time we really cannot afford.<br> <br> Agile works because there is frequent and early adjustment to requirements during product development. The example of new thinking at the beginning of this article highlighted the ID contract type. FAR subpart 16.5 presents ID contracts, which allow contracting officers to issue orders against the base contract during a defined ordering period. To make Agile work, we need a contract type that contemplates how requirements can evolve without driving a mountain of administrative effort and cost historically associated with modifying the contract to change the requirement.<br> <br> Implementing Agile with task orders under the ID contract helps projects achieve success in three ways. First, from an organizational perspective, Agile helps reduce costs and increase the value of the product delivered and thus increase the return on investment. Second, Agile’s emphasis on shorter delivery cycles allows teams to identify risk early in the project and, if need be, cancel the project or process before too much money is spent. Third, Agile emphasizes delivering the most valuable features first. Even if development teams cannot complete 100 percent of the features, at least the organization benefits from functionality headed toward the full product goal.<br> <br> Agile welcomes change in requirements at any point in the project. So if conditions change, and they always do, Agile teams can adapt accordingly. From a technical standpoint, Agile emphasizes the importance of quality in terms of reliability and adaptability Quality is achieved through such practices as continuous integration—with 100 percent completion and acceptance of each feature before moving on to the next one.<br> <br> A key difference between Agile and the more traditional waterfall thinking about requirements is that traditional thinking assumes complete requirements can be established up front and should not change as work progresses. Agile takes the opposite approach. An Agile project begins with the development of a product or project vision—the novel in our opening example.<br> <br> In other words, Agile begins with the end in mind. The vision usually includes the desired goals and expected benefits. Product owners—managers given authority to make decisions regarding what is an acceptable product at the working level—translate the vision into a product or project backlog.<br> <br> Product owners document the project backlog in rough outline or in the form of user stories. User stories, an Agile term, are precise, just-in-time, small technical requirements. Stories include measurable or tangible technical acceptance criteria. Product owners package user stories in short-cycle deliverables. Agile calls the short work cycles “sprints.” Product owners prioritize user stories by relative cost and benefit. When a sprint cycle begins, product owners meet with the sprint team to look at the product backlog and decide how much the sprint team will take on for that sprint cycle. While the Agile team works the sprint cycle, product owners update the plan. At the end of the sprint cycle, product owners review the work accomplished with the sprint team. During this review, the product owners and customer representatives go through the acceptance criteria defined for the cycle, and then sign off on whether the feature is fully complete.<br> <br> Completed user stories free up sprint team capacity to work on more or new features during the next cycle. Sprint cycles continue until such a point product owners determine the project is completed. Ideally, the goal at the end of each sprint is to deliver the product, or a portion of it, in a condition that is releasable to users. Breaking down major milestones into shorter events allows teams to build success, catch issues early, fix, and continue working.<br> <br> Courage is needed to embrace such a culture of collaboration. We must let go of the idea that minutely spelling out, within the four corners of the contract, exactly what “shall be delivered,” is the only path to reasonably assured contracting outcomes. Certainly, given enough time and funding, we can continue to specify and the contractor can continue performing, waiting until the final delivery to determine if the effort produces the desired results. We need a faster way to develop and acquire leading-edge technologies. We need a business process that identifies adjustments early and implements them without needing to alter the entire contract with each one. We need to adapt our thinking to see how we can implement Agile with the tools we now have at our disposal.<br> <br> The following is another approach to describing the change in thought necessary to implement Agile. ID contracts provide contractual flexibilities to shift the Agile development team’s focus to the next user story as that particular story becomes important. This elevation in importance of the user story can happen, for instance, when the threat changes or the operators find a problem with the system.<br> Through task orders, the ID contract allows quick change of work focus as details of the changed requirement emerge. The most important aspect here is the value obtained by the work accomplished in functionally delivering the user stories to end users. Documentation is still a very important part of these contracts, although it looks a little bit different from requiring management plans upfront and work breakdown structures. It becomes user stories, design documents, and continuous updates.<br> <br> Agile requires more technical oversight, not less. Agile contracts require more descriptions of what the detailed technical requirements will deliver. Smaller increments of work would be technically described serially rather than all at once in the beginning. Stated differently, the contract requirement is for a series of deliverables providing end-user useful functionality on their own that, combined, result in the complete satisfaction of desired end item function. This is different from fixed interim deliverable items.<br> <br> <img alt="Agile requires more technical oversight, not less." src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article01_image02.jpg" style="width:600px;height:253px;" /><br> <br> The key is to review the output of short periods of performance and determine what needs to change during the next work period to reach the goal. The contract requirements are expressed in terms of sprint iterations.<br> <br> How many iterations will be required in a period of performance, what do the iterations consist of, and what is the process by which those items are reviewed and approved on a regular basis? The collaboration and dialog are different and are very important. Each story under a task order is the object of the process. The contractor applies the agreed-upon process, and both contractor and government consider the results and adjust the next story under the next sprint. Here is the agility. Here is the ability to make corrections while on the path to the goal. FAR subpart 16.5, Indefinite-Delivery provides this flexibility. <h2>How Could We Incentivize an Agile Contract?</h2> Consider incentivizing what we most want: consistency and repeatability of the development process applied to the tasks and backlogs under each task order. The desired repeatability is the productive output generated by the sprint team. The Agile discipline has metrics for this. Incentivize consistency in those metrics over time. Agile uses the term “velocity” to describe the stable rate at which a development team should be able to produce indefinitely. Velocity is particular to each team. It is not realistic to compare one team’s velocity to another team’s velocity because they are different teams of different individuals with different skills. Development team staffing is the key to stable velocity for that team. The contractor should have incentives for taking actions necessary to keep teams together, focused, and producing at their optimum velocity.<br> <br> When thinking about a contractor exercising a process repeatedly, each time in the same way, what do we want to incentivize? Repeatability and consistency. Consistently repeatable processes do not have much cost variation. Cost reduction requires subtraction of something from that process. The contractor may subtract time, people, or materials to cut cost. How will the process remain stable if we encourage constant reduction to the process parts? Clearly, common cost incentives pull the rope in the wrong direction. We want stasis, not reduction. Cost stasis denotes a mature process.<br> <br> Cost reimbursement contracts may not accomplish our goal. In order to incentivize a performance metric on a cost-reimbursement contract, the contracting officer must first incentivize cost control. This would potentially work against our objectives of repeatability and consistency. Cost incentives could encourage the very behaviors detrimental to consistent staffing and constant velocity.<br> <br> Classic Agile software development processes work best with a stable team of seven to nine multi-skilled code writers. The team performs their work in two-week sprints. The longer the team works together, the better it works together. The stable sprint team soon will reach an indefinitely sustainable development tempo. It seems that the contractor could very accurately estimate the fixed price of having that team labor for two-week sprints at a time. This is a fixed price.<br> <br> A team is contacted to do work using the agreed-upon process for two weeks, and then the outcome is evaluated shortly after the two weeks. The next task order presents the team with a new story or maybe an adjustment to the story from the last task order. Agile calls this process, “sprint planning,” a collaborative effort between the government and the contractor at the start of each sprint iteration. The next task order is for the same team, same duration, but with an appropriately adjusted story generated during sprint planning. Our goal is to hold the teams and their function as a constant (i.e., FFP) and vary the tasks through the stories presented to the team. <h2><img alt="If stability remains constant, the value increases." src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article01_image03.jpg" style="margin-left:6px;margin-right:6px;float:left;width:492px;height:300px;" />Using Escalation Tables on FFP Task Orders</h2> Incentivize the contractor to deliver a stable velocity from a stable team—perhaps a value scale indexed to the longevity of the stable velocity and the longevity of stability in team staffing. Alternatively, a formula blending both values could be used. Negotiate a base fixed price for teams staffed according to full-time equivalent and labor rates, and then escalate that fixed price the longer the contractor holds those two metrics constant. For example, negotiations value a new team at $100,000 for the two weeks. If, after three sprints, the team demonstrates constant staffing and a stable velocity, that same team is now worth $110,000 for the next task order. A negotiated arrangement such as this certainly is possible.<br> <br> Incentives work in both directions (FAR 16.401(a)(2)). If stability remains constant, the value increases. If stability fluctuates, up or down, the team’s value under the contract decreases. Scaling to workload happens by adding or subtracting stable teams with stable velocity. This approach incentivizes objective Agile metrics without the administrative burden of calculating cost incentive outcomes. <h2><img alt="There is tremendous flexibility open to contracting teams…" src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article01_image04.jpg" style="margin-left:6px;margin-right:6px;float:left;width:167px;height:700px;" />Agile Data Item Descriptions (From ACCESS Database) as Roadmaps</h2> This article has described a way of thinking about Agile contracting and incentives. There is tremendous flexibility open to contracting teams concerning implementing language. There is much literature available on specific contract language, providing detailed examples. Rhonda Maus (DAU, Mid-Atlantic Region) developed lists of Agile resources for acquisition professionals as part of DAU’s ACQ 1700 Agile for DoD Acquisition Team Members class. ACQ 1700 is an integral part of the DAU Agile: DoD Team Member Credential (<a href="/training/pages/credentials.aspx" target="_blank"></a>)<br> <br> There is ample information out there regarding Agile. This begs the question, “Why does Agile software development seem so difficult to execute within the DoD?” Others have asked the same or similar questions—for example, a report by the Government Accountability Office, GAO-20-439, and a June 16, 2020, article in FEDSCOOP.<br> <br> Sometimes a format or template helps lead the way. Of all the templates out there, the most frequent challenge involves where to begin negotiations on such a complex requirement as an Agile development process. We suggest repurposing the data item descriptions (DIDs) already in the ASSIST database (<a href="" target="_blank"></a>) for use as a negotiation checklist. There are four Agile-related DIDs. The thinking here is that, if the DID provides enough of a list for developing an appropriate contract data requirements list (CDRL), it is probably good enough to use as a list of items to negotiate for the contract. <h2> </h2> In summary, using current contracting tools to build responsive technology and software acquisition strategies requires new thinking. Relevant law, regulatory guidance, and process information already exist and are available for immediate use. We need to increase our ability to understand, define, and communicate what end state the user needs. Senior leaders will need to give project managers and contractor teams a flexible contract—and believe and trust that they can deliver the required system. The basic tenet of Agile is trust between the government and the contractor.<br> <br> Agile works in an environment of trust where every team member contributes and understands roles and responsibilities. Everyone from the executive level to the production floor level will need to understand the Agile process. How does Agile deliver value? What is my contribution? Why is Agile so different from what has been done in the past? Acquisition professionals must understand the answers to these questions in order to adopt the thinking necessary to make Agile work.<br> <br> Only with new thinking will leaders empower government project owners and contracting officer’s representatives (CORs) with decision-making authority. Project owners and CORs need explicit authority, bound by appropriate contract language, to make day-to-day decisions on priorities without having to run through miles of review that can delay decision making. Vesting decision-making authority at the working level contributes to Agile’s success. Acquisition executives must constantly advocate for empowering the team at the working level to remove roadblocks and get projects delivered. This is the new thinking needed to keep up with the speed of change in our world today. <hr /> <blockquote> <h2><em><strong>Sample Excerpt</strong></em></h2> <p><strong>DATA ITEM DESCRIPTION</strong><br> Title: Software Development Process Description Document (SDPDD) Number: DI-IPSC-82208 Approval Date: April 17, 2018<br> <br> <em>b. If the software/programmable logic development process is an Agile process, the following must be addressed within this section or subsection(s):</em></p> <ol> <li><strong>Cite the Agile technique(s) being employed</strong> <strong>(Scrum, pair programming, extreme programming, etc.).</strong></li> <li><strong>For each Agile technique employed, describe your approach.</strong></li> <li><strong>Describe the approach for release planning.</strong></li> <li><strong>For Scrum, identify the sprint length and how it was determined.</strong></li> <li><strong>Describe how the backlog is initially established, and the process for modifying and re-prioritizing it.</strong></li> <li><strong>For Scrum, describe the typical sprint activities, and what happens during each iteration.</strong></li> <li><strong>Identify the Product Owner and his/her roles/responsibilities.</strong></li> <li><strong>Describe the acquirer’s role in the sprints if the customer is not also the Product Owner.</strong></li> <li><strong>Describe the mechanism for getting acquirer (or end user) feedback for each sprint.</strong></li> </ol> </blockquote> <hr /><strong>FREIHOFER </strong>is a DAU professor of Contract Management in Norfolk, Virginia. He is a retired Navy captain with extensive experience in Joint operations, military logistics and systems command, inventory control point, and operational contracting.<br> <br> <strong>DOTSON </strong>is a professor of Contract Management at DAU in California, Maryland, with experience doing contracts as a Department of Defense contracting officer and in heavy manufacturing industry.<br> <br> <strong>MAUS </strong>is a DAU professor of Software Engineering in California, Maryland, and has extensive professional software experience with Agile, contracting, engineering and program management.<br> <br> The authors can be contacted at <a class="ak-cke-href" href=""></a>, <a class="ak-cke-href" href=""></a>, and <a class="ak-cke-href" href=""></a>.</div>string;#/library/defense-atl/blog/Creating-Incentivized-Agile-Contracts
The Four C’s for Successful Other Transactions Four C’s for Successful Other Transactions2021-07-01T16:00:00Z,<div class="ExternalClass46774537E02347699ED3223F9D4045C6">Other Transactions (OT) have boomed in popularity in recent years at the Department of Defense (DoD). The trends show no signs of reversing as the United States remains in a dynamic environment where it must significantly transform business practices to keep pace with technology and Warfighter needs. <hr />While OTs are not new to the DoD, they are more widely used and preferred for science and technology and research and development efforts. Modernized contracting instruments allow DoD organizations to innovatively engage with industry partners and more efficiently respond to emerging threats from adversaries, such as those in the cyber and space areas. OTs help provide military personnel the relevant capabilities necessarily for the United States to retain its competitive advantage for national defense. If acquisition personnel have not already been exposed to OTs, it is almost certain that they will be in the near future. With flexibility and innovation come additional risks and uncertainties. However, OTs should still be pursued over traditional contracting instruments when it makes the most business sense. Culture change, collaboration, creativity, and competition are all crucial characteristics for OT success. This article provides essential lessons learned from past experiences to assist organizations and acquisition professionals making future use of OTs.<br> <br> OTs are flexible and innovative contracting instruments, authorized in the United States Code (U.S.C.), that permit DoD organizations to conduct research, prototype, and follow-on production projects. OTs are not required to adhere to all acquisition statutes and regulations. They are different than traditional procurement contracts, cooperative agreements, grants, and procurements for experimental purposes. The primary intent of OTs is to help the DoD broaden its industrial base, conduct business in forms more similar to those within the commercial industry, and attain access to state-of-the-art technology solutions with dual-use or military utility. OTs allow the DoD to engage with industry partners of all shapes and sizes, including traditional and non-traditional defense contractors, non-profit organizations, research institutions, academic institutions, and small businesses (including partners from certain foreign countries if security procedures allow).<br> <br> DoD’s OT use since Fiscal Year (FY) 2018 has skyrocketed. According to data from the Federal Procurement Data System, the DoD obligated a total of $4.4 billion for OTs in FY 2018 and $7.4 billion in FY 2019. Preliminary data for FY 2020 is expected to show more than $15 billion for OTs. The growth is not surprising as Congress enacted several laws since FY 2016 to clarify and authorize expanded use of OTs. For instance, in FY 2018, Congress enacted a law requiring the DoD to prefer the use of OTs for science and technology and prototype programs. DoD leadership also released expanded OT guidance through an updated OT guide and various policy memorandums. For example, in FY 2020 at the beginning of the global COVID-19 pandemic, DoD leadership expanded OT approval authority thresholds and delegation abilities for DoD organizations. The OT growth trends will likely continue, especially if DoD’s budgets for research and development increase or become a larger percentage of the DoD’s overall budget. While each OT project will differ and there is no one-size-fits-all OT option, four common characteristics will best position DoD organizations for successful use and favorable outcomes to support national defense transformation priorities. The sections below expound on the “C’s” and lessons learned.<br> <br> <img alt="A man standing in front of green grass to the left and dead grass to the right" src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article02_image01.jpg" style="width:779px;height:300px;" /> <h2>Culture Change</h2> OT success is easily achievable for organizations that are willing to adapt and strategically take risks. Personnel across the organization must support the transformative means of conducting business. While all personnel share the responsibility, leadership must be aware of and support OTs and all associated efforts. Although use of OTs has grown in recent years, some personnel (including those within organizations that have OT authorities) have not received sufficient training or opportunities to support OTs. As a result, personnel at all levels and from various functional areas have not learned the nuances of the flexible instruments or possible situations for determining when OTs may be the preferred choice over traditional options. Leadership must trust and enable its workforce to pivot from traditional business practices when OTs are most appropriate, given the identified requirement. If leadership does not support OTs or resists change, the program or project is less likely to obtain the necessary approvals or resources (funding or personnel) for using OTs or to have good results.<br> <br> Information is power because the lack of a general understanding can stymie efficient and effective OT efforts. Knowing specifically what does or does not apply holds equal value in maximizing the flexibility of the authorities and complying with the law. Personnel, including those in contracting, program management, and other functional areas, shall capitalize on professional development events to gain a solid foundation and obtain the necessary information needed for sound OT planning, execution, and administration. Training is valuable for those, whether they have or do not have any OT experience. In addition to being promoted by leadership, worthwhile training should outline current OT authorities, identify key terms and responsibilities, describe real-world OT uses across the DoD, and debunk myths. Training becomes more important as Congress and DoD modify laws and policies regarding OT use. Organizations should consider creating in-house training and other resources if sufficient training is not readily available.<br> <br> Also, consider the culture of the potential industry partners. While OTs tend to focus on the non-traditional defense contractor, the OT strategy may include traditional defense contractors. For traditional defense contractors accustomed to doing business under a procurement contract (based on the Federal Acquisition Regulation (FAR)), similar cultural changes and training may be necessary to succeed when pursuing the use of OTs. <h3>Lessons From Past Experience</h3> Be an agent for change, when necessary, to enable an OT-inclusive culture. Regularly engage with leadership to (1) strategically identify how the organization can use OTs to achieve the organization’s mission and (2) gain top-level buy-in for acquisition personnel to complete appropriate training. Remain a trusted business advisor who is accessible on demand. Work to ensure that professional development opportunities and resources are available to familiarize personnel with OTs. Develop multiple training events for leadership and the general workforce about a specific functional area or audience need. Develop resources, such as a guide, record of lessons learned or best practices, and frequently asked questions, to streamline processes and operations. If resources permit, assign seasoned contracting and acquisition professionals to provide OT assistance and guidance across the organization.<br> <br> <img alt="" src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article02_image02.jpg" style="width:776px;height:300px;" /> <h2>Collaboration</h2> OT success depends upon effective collaboration. Regular open and effective collaboration between the government and the industry partner(s), such as during project pre-award and execution phases, is critical to achieving desired technical, schedule, and cost results. Collaboration builds more trust between the parties and enables more relational (vs. transactional) business relationships. While the FAR environment allows collaboration, the tendency of many government organizations is to remain very conservative in communications with industry partners. OTs allow and encourage collaboration, and the government team should use this to gain additional insight into the technology. Teams can also clarify requirements for the industry partners and collaborate throughout the performance on technical, schedule, or cost trades to best meet the government’s needs. Remember that OTs involve government and its industry partners working together, in ways similar to the collaboration between private sector entities. Although OTs replace certain traditional bureaucratic processes and requirements with flexible terms and conditions, the increased flexibility can be as challenging for the government team as it is for industry partners. Contracting and acquisition personnel must put themselves in the shoes of the performer or potential performer, especially those who have never previously performed work via OTs with the DoD.<br> <br> There also must be collaboration as needed between teams within DoD and other government organizations. Government personnel from various functional areas (in addition to contracting and program management) must participate regularly and actively, from project initiation through completion. Examples may include participation from the legal, cybersecurity, financial management, and logistics communities. Who will determine if the efforts meet the intention of and comply with the OT authorities? Legal. Who will assist with fine-tuning and enforcing necessary cybersecurity requirements? Cybersecurity. Who will generate legitimate cost estimates and formulate budget requests to obtain adequate resources from Congress? Financial management. Who will ascertain product support requirements and maintain life-cycle sustainment plans (if applicable)? Logistics.<br> <br> A dynamic team will contribute to efficient operations and produce a steeper learning curve for the organization, especially for the various functional areas that provide valuable inputs to each project.<br> <br> Collaboration also may involve engagement with other government agencies (OGAs), including those outside the DoD. Examples of DoD OGAs are the Defense Advanced Research Projects Agency (DARPA), the Defense Innovation Unit (DIU), the U.S. Air Force, the U.S. Army, and the U.S. Navy. Examples of non-DoD OGAs are NASA and the National Institutes of Health. DoD organizations and their personnel should leverage best practices and lessons learned from others with sufficient and valuable past experience. Proactive collaboration can help less-experienced teams avoid common pitfalls or unsuccessful OT use and duplication. DoD and non-DoD organizations could strengthen business practices by openly sharing information and resources. Regardless of OT effort type or size, the DoD organization should always collaborate in fair and transparent forms throughout the project. <h3>Lessons From Past Experience</h3> At project initiation, specifically for initial planning or strategy development, and during execution, ensure participation by the right teammates from the appropriate functional areas. There is no universal listing or roster for the “right” participation, but teams will develop a better feel for appropriate functional area involvement with experience. Reach out to DoD OGAs that possess valuable OT experience, such as DARPA and DIU, for assistance. Collaboration with DoD OGAs and non-DoD OGAs identifies potential teaming opportunities on mutually beneficial projects. Also, teams can identify information for doing business with consortia or engaging with innovative industry partners that have never previously worked with the DoD. Finally, keep open lines of communication with all interested performers for each project. Flexible, fair, and transparent collaboration helps attract the widest group of potential performers. It also generates trust between stakeholders and helps industry partners achieve all technical, cost, and performance goals for successful outcomes. <h2><img alt="" src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article02_image03.jpg" style="width:1044px;height:300px;" />Creativity</h2> Organizations must apply maximum creativity to ensure OT success. OTs are simply synonymous with flexibility. Why? The statutes that provide the authorities are intentionally brief and DoD only has a guide to assist government teams with the unique instruments (as opposed to extensive policies or regulations). The government can develop custom business agreements and terms with industry partners. There also are many ways that organizations can award OTs based on a project’s individual characteristics. For example, teams can directly award OTs after independently conducting solicitation efforts and proposal evaluations. Or teams can utilize a consortium for assistance with the project. Organizations also have tremendous latitude compared to traditional contracting options because many laws and regulations do not apply. Those that do not apply include the Competition in Contracting Act, the Truthful Cost and Pricing Data Act, Cost Accounting Standards, the Bayh-Dole Act on patenting government-funded developments, the FAR, and the Defense Federal Acquisition Regulation Supplement (DFARS). Because FAR and DFARS do not apply, teams may not need to conduct formal efforts such as market research, acquisitions plans, earned value management, and contractor performance assessment reporting.<br> <br> Teams also should not limit their solicitation efforts through the normal government platforms such as<a href="" target="_blank"></a> and <a href="" target="_blank"></a>. Organizations are free to uniquely search for potential solution providers, both traditional and nontraditional, and should pursue all possible paths based on the requirement. Official definitions for the various OT types, or the lack thereof, enable organizations to apply creativity. The various types of research OTs (basic, applied, and advanced) outlined in the DoD Financial Management Regulation are very broad and generally permissible if the research project will contribute to national security or military needs. Prototype OTs are not officially defined but are broadly described in various sources to help DoD organizations determine use applicability. The statute, Authority of the Department of Defense to carry out certain prototype projects (10 U.S.C. 2371b), refers to a prototype project as any enhancement or improvement of platforms, systems, components, or materials for use by military personnel. The DoD’s Other Transactions Guide, published in November 2018, describes a prototype project as an effort that addresses a proof of concept, model, pilot, reverse engineering (as a result of obsolescence), or an innovative use of commercial technologies for military purposes. The guide also specifies that organizations can use prototype OTs for demonstrating technical and operational utility and for business processes. The DoD’s Prototyping Guidebook describes a prototype as a model, albeit in physical, digital, conceptual, or analytical form, built to assess and inform usefulness or feasibility.<br> <br> Table 1 illustrates how some DoD organizations creatively used prototype OTs in real-world projects. The intent of the information is not for others to replicate these projects for their own use but rather to provide notice of the flexibility and creativity applied to meet the statute’s intent.<br> <br> Latitude eliminates some bureaucratic processes but requires that personnel constantly apply creativity and strategic thinking. Organizations are challenged to find the best provider while maintaining a fair and transparent process with sound internal controls. Creativity within federal government acquisition can be a paradox; however, organizations can achieve successful OT projects by leveraging the full flexibility provided by law and not executing a close variation of traditional contracting instruments like those executed through the FAR. <h3>Lessons From Past Experience</h3> Creativity is easier said than done, especially when government acquisition training certification programs lack expanded curriculum on the subject. So long as DoD organizations have OT authority, leadership and personnel should approach each potential OT project with a “Why Not?” rather than a “Why?” mindset. Creativity largely depends on the organization’s culture and personnel with OT experience who shall resist, when appropriate, any temptation to default to or return to traditional contracting instruments with narrower guard rails (simply because of personnel comfort). Personnel should recognize that Congress and DoD leadership support the use of OTs.<br> <br> During the initial process of any potential OT effort, teams should flexibly assess whether their need or capability gap could meet the government’s broad OT interpretations. Specific to prototype OTs, teams should remain open minded and be cognizant that these projects could be in a physical, virtual, or conceptual form, include more than one unit or system, and include deployable or disposable end items. Creativity does not negate the need to adhere to all laws and regulations. Organizations must still comply with the False Claims Act, the Procurement Integrity Act, the Antideficiency Act, the International Traffic in Arms Regulations, and the DoD Financial Management Regulation. Personnel should always apply professionalism, exercise sound businesses judgment, and maintain key supporting documents for each OT project. <table align="left" border="1" cellpadding="5" cellspacing="5" style="width:800px;"> <caption><strong>Table 1. Examples of Prototype Other Transactions</strong></caption> <thead> <tr> <th scope="col">DoD Organization</th> <th scope="col">Prototype Other Transaction Project Description</th> </tr> </thead> <tbody> <tr> <td>U.S. Army</td> <td>In response to the global COVID-19 pandemic, develop a prototype ventilator that can quickly augment ventilator capacity. Assuming successful prototype efforts, there is a related follow-on requirement to produce 10,000 ventilators that are low-cost, reliable, readily manufacturable, and suitable for operation within eight weeks. The project is a part of a competitive prototyping effort where multiple industry partners could be selected and various opportunities for cash prizes are possible.</td> </tr> <tr> <td>U.S. Air Force</td> <td>Enhance base security and facility operations at Tyndall Air Force Base in Florida. The prototype project consists of developing a system of systems for condition-based maintenance, predictive maintenance, and improved situational awareness for the base’s first responders.</td> </tr> <tr> <td>U.S. Navy</td> <td>Improve Navy-wide data management for leadership to make more informed and timely decisions. A primary objective is to centralize data from several different information systems (major exercise documents, historical papers, research materials, and war-gaming materials) and make it readily available.</td> </tr> <tr> <td>U.S. Marine Corps</td> <td>Replace four legacy handheld systems with an upgraded handheld targeting system. The broad objectives are for the new system to be fully compatible with current and future fire support systems and reduce the weight of the existing systems by 60 percent.</td> </tr> <tr> <td>Defense Advanced Research Projects Agency</td> <td>Enhance medium unmanned surface vessels and their ability to navigate through harsh waters. The efforts directly involve the Navy and Marine Corps with the primary objective of overcoming vessel range limitations by exploiting significant reductions in water resistance.</td> </tr> <tr> <td>Defense Information Systems Agency</td> <td>Develop and potentially deploy new technologies (advanced solutions using the electromagnetic spectrum, such as 5G (fifth generation), augmented reality, machine learning, cloud computing, and beam forming) for military personnel. This effort could cost up to $2.5 billion, with potential future use across the DoD.</td> </tr> <tr> <td>Defense Counterintelligence and Security Agency</td> <td>As the single security clearance provider for all of the federal government, design, build, test, and deploy a new security clearance system. The effort has specific plans to transition from a prototype project to a follow-on production project if the prototyping efforts are successful.</td> </tr> </tbody> </table> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <img alt="" src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article02_image04.jpg" style="width:743px;height:300px;" /> <h2>Competition</h2> As previously mentioned, the Competition in Contracting Act does not apply to OTs. Should organizations avoid any forms of competitive procedures when seeking to award OTs? The answer is “absolutely not” for several reasons. It is specifically stated at 10 U.S.C. 2371b that organizations shall use competitive procedures to the maximum extent practicable when entering into prototype OTs. Additionally, DoD’s Other Transactions Guide states that organizations should use competitive procedures to the greatest extent practicable for research and prototype OTs. Competition is valuable because it can help the DoD save money and promote accountability for project results. Sufficient competition could also draw substantial interest from industry partners, particularly those that do not traditionally do business with the DoD, and thereby help identify the best possible solutions or performers. Bear in mind that OTs are used to broaden the industrial base and attain access to state-of-the-art technology solutions. If maximum competition is not provided, the government risks missing opportunities to do business with performers who can provide the best prices and quality.<br> <br> The extent of competitive procedures undoubtedly will vary from one project to another. While organizations have individual discretion to determine and structure competitive procedures, they must apply creativity, fairness, and transparency. For example, teams could structure a competitive prototyping project with phases and down-selects among multiple performers. Such approaches are quite common, factoring in consideration of project technical risk and funds availability, fostering competition among performers, and allowing only a smaller number of performers to advance to a following phase. This form of competitive procedures increases performance, reduces risk, and positions the government to have the most success with the entire prototype OT project and possibly facilitate a follow-on production OT project, if applicable. <h3>Lessons From Past Experience</h3> Organizations can leverage traditional government platforms for competing opportunities, but this may not be the optimum way to identify the best possible performers and capitalize on the most valuable opportunities. Organizations must thoroughly address competitive procedures during the planning stages of each OT project. For each prototype OT, organizations must identify that a follow-on production OT without recompetition is possible within the original prototype OT solicitation and agreement. This action could increase competition for the particular prototype OT, shorten schedules for follow-on efforts, and insulate the organization from a future protest. As resources permit, use competitive prototyping with phases and down-selects for prototype OTs.<br> <br> As Albert Einstein said, “A person who never made a mistake never tried anything new.” Culture change, collaboration, creativity, competition are all essential characteristics to support fair, transparent, effective, and successful OT projects. OTs are nontraditional and accompanied by risks, uncertainties, and learning curves. However, they are transformative instruments that will assist current and future national defense objectives and modernization initiatives. DoD organizations must maximize their use of OTs for research, prototype, and follow-on production products when appropriate to help the nation remain relevant and retain its competitive advantage. <hr /><strong>SPECIALE </strong>is a senior acquisition specialist supporting the Department of Defense (DoD). He is a Certified Defense Financial Manager–Acquisition and a Certified Fraud Examiner. POSKEY is a DoD supervisory contract specialist and agreements officer.<br> The authors can be contacted at <a class="ak-cke-href" href=""></a>.</div>string;#/library/defense-atl/blog/The-Four-Cs-for-Successful-Other-Transactions
Resolving Data-Rights Markings a Legal Battlefield Data-Rights Markings a Legal Battlefield2021-07-01T16:00:00Z,<div class="ExternalClass69CCBC66FDE045B6A025D2F76E5E023A"><h2><img alt="Knights in armor" src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article03_image01.jpg" style="width:736px;height:300px;" /><br> Events Leading to the Battle</h2> Suppose a Department of Defense (DoD) program office has received noncommercial technical data and noncommercial computer software (henceforth called “data”). The team inspects the data-rights markings (also referred to as “legends”) and identifies a problem—they are not in the correct format and inappropriately restrict the DoD’s rights. The DoD contracting officer notifies the prime contractor by letter that the data deliverables include “nonconforming” markings, but the prime contractor disagrees and doubles down on its position that the markings are indeed correct.<br> <br> This type of disagreement, which plays out often in DoD contracting and appears relatively easy to resolve, frequently leads to contentious, drawn-out battles. DoD personnel and their contracting partners’ battle over the rules contractors must follow to restrict the DoD’s use and sharing of technical data delivered in response to a procurement contract and the markings themselves. DoD points to the seemingly clear mandates set forth in the Defense Federal Acquisition Regulation Supplement (DFARS), while contractors seek the maximum protections for their data.<br> <br> Due to its complexity, we plan to write two separate articles on this topic. This first article discusses issues with nonconforming data-rights markings. It includes examples of nonconforming markings and guidance on the process and timing to correct these markings, as well as where to get assistance. The second article will discuss unjustified data- rights markings, which often lead to a much more complex dispute.<br> <br> For background, the DoD acquires data in every major systems acquisition. The underlying data are critical for almost every aspect of a program—from design and testing to manufacturing and sustainment. On the other hand, contractors fiercely guard their intellectual property (IP) as the lifeblood of their company and often a primary source of profit.<br> <br> Under the statute governing rights in technical data—Title 10 United States Code (U.S.C.) §2320—and the DFARS implementation of this statute, the DoD receives a license to technical data that a contractor delivers to the DoD under an acquisition contract. The scope of DoD’s license rights generally depends on the source of the funding (i.e., exclusively government, exclusively private, or mixed), the type of data (e.g., form, fit, and function data), the nature of the data (commercial or noncommercial) and any negotiated terms of the contract.<br> <br> In addition to granting the DoD the rights to use and, in some instances, share such data, the DFARS identifies certain markings a contractor must place on data deliverables if it seeks to impose any restrictions on the DoD’s ability to use or share the data. When a contractor places a marking that is not in the format authorized by the contract on noncommercial technical data or noncommercial computer software that it delivered or otherwise furnished to the DoD, it is deemed to be a “nonconforming” marking. See DFARS 252.227–7013(h)(2) and DFARS 252.227–7014(h)(2). An “unjustified” marking, to be discussed in the subsequent article, is a “marking that does not depict accurately restrictions applicable to the Government’s use, modification, reproduction, release, performance, display, or disclosure of the marked technical data” or computer software. See DFARS 227.7103—12(b)(1) and DFARS 227.7203—12(b)(1).<br> As shown in Figure 1, contractors also are required to include markings that are unrelated to data rights on data delivered to DoD. These additional markings may include export control notices, destruction notices, classification notices, and distribution statements.<br> <br> <strong>Figure 1. Assorted DoD Markings​</strong> <h2><img alt="Figure 1. Assorted DoD Markings " src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article03_figure01.jpg" style="margin-left:6px;margin-right:6px;width:681px;height:400px;" /></h2> <h6>Source: Army Data and Data Rights Guide, 2015.</h6> <h2>The Battlefield Maps</h2> Authorized data-rights legends required by the DFARS are analogous to battlefield maps. Skirmishes erupt on the battlefield over the wording and format of the legends—i.e., whether the delivered data are marked in a correct manner. The exact format and language of legends the DFARS authorizes contractors to place on data to restrict the DoD’s ability to use and share the data are listed at these three links: <ul> <li><a href=""></a></li> <li><a href=""></a></li> <li><a href=""></a></li> </ul> Any marking applied to a data deliverable by a contractor that restricts the DoD’s rights to use or share data but does not use the authorized wording and format specified in the DFARS is a nonconforming marking. Examples of nonconforming markings include legends such as “Proprietary” or “Company Confidential.” These types of markings lead to confusion in both the DoD and contractor workforce, as well as ambiguity about the DoD’s ability to share and even to use the marked deliverable. Such confusion and ambiguity cost programs time and productivity that should instead be used to execute the program’s mission.<br> <br> Figure 2 and Figure 3 are examples of real-world nonconforming markings that have been included on data delivered to DoD program offices. (Identifying information has been removed from all examples, which have been placed on mock deliverables).<br> <br> The two markings are not the language authorized by a contract that includes DFARS 252.227–7013(f) or DFARS 252.227–7014(f), and are therefore not appropriate to restrict the DoD’s ability to use and share data deliverables. The language of these markings also purports to restrict the DoD’s right to use and share the data deliverables. Restrictions such as “Not to be duplicated, used, or disclosed—in whole or in part—other than to evaluate the data contained herein” and “The Government may use such information solely for the Weapon X Program …” are inconsistent with even the lowest level of license rights in data deliverables that DFARS 252.227–7013 and DFARS 252.227–7014 grant to the DoD. Therefore, the markings are, on their face, nonconforming.<br> <br> <strong>Figure 2. Technical Report Nonconforming Marking</strong><br> <img alt="Figure 2. Technical Report Nonconforming Marking" src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article03_figure02.jpg" style="width:234px;height:300px;" /><br> <br> <strong>Figure 3. Noncommercial Technical Drawing Nonconforming Marking<br> <img alt="Figure 3. Noncommercial Technical Drawing Nonconforming Marking" src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article03_figure03.jpg" style="width:500px;height:357px;" /></strong> <h6>Source: Adapted by the authors.</h6> <h2>Reasons for the Battle<br> <span style="font-size:13px;">Instead of presenting a rare data-rights area where the contractor and the DoD can agree, contractors show abundant creativity in developing a variety of markings to be placed on the DoD’s data deliverables. As a result, and despite the contractually binding direction in the DFARS, nonconforming markings present a major conflict point for contractors and the DoD. Unfortunately, nonconforming markings on data delivered to the DoD can also have a profound and negative effect on cost, schedule, and performance of weapon systems. These impacts may include the following:</span></h2> <ol> <li>Interference with the DoD’s ability to perform statutorily mandated maintenance (depot, intermediate, and organizational). Title 10 U.S.C. §2466, the so-called “50-50 rule,” requires that no more than 50 percent of the funding for depot maintenance workload may be contracted to private sources. This provision is measured in dollars and must be met each year unless a waiver is granted by the Secretary of Defense. Likewise, 10 U.S.C. §2464 requires that the DoD sustain the ability to perform certain “core” logistics capabilities.</li> <li>Third parties’ refusal to accept documents with nonconforming, restrictive markings. This refusal can create a sole-source environment and increase the risk of suboptimal outcomes.</li> <li>An enormous loss of time, effort, and taxpayer dollars spent by DoD personnel addressing and resolving disputes with contractors over nonconforming markings. This also leads to a loss of productivity and efficiency in executing critical programs.</li> <li>Interference with DoD’s ability to use data in competitive procurements, potentially interfering with the DoD’s ability to comply with competition requirements in the Competition in Contracting Act, 41 U.S.C. §253, and FAR Part 6, Competition Requirements.</li> <li>An inability to modify, update, or correct software source code.</li> <li>An inability to disclose data to foreign military entities, which is often a necessary component of a foreign military sales contract.</li> </ol> Nonconforming markings such as those identified above thus interfere with the DoD’s ability to operate. Another critical problem, however, is that they also interfere with the government-contractor relationship. Instead of working together to execute a program, the parties end up wasting productive time and goodwill by battling over this issue. While resolution of these battles generally should be “self-executing” in that the DFARS clause specifies procedures that the contracting officer can follow to correct nonconforming markings, disputes not only waste everyone’s time and resources but can also lead to protracted litigation.<br> <br> In 2018, OshKosh Defense, LLC, filed suit against the U.S. Marine Corps (USMC) in the Court of Federal Claims, 18–404 C (March 16, 2018). The complaint describes almost a decade of back and forth between the USMC and OshKosh related to thousands of technical drawings for the Medium Tactical Vehicle Replacement. The parties battled over both nonconforming and unjustified markings on those drawings. The litany of interactions between the parties is an example of the wasted resources and squandered goodwill brought about by disputes.<br> <br> Likewise, the U.S. Air Force and The Boeing Company have been engaged in protracted litigation over nonconforming markings on technical data for a system installed on the F-15 fighter jet. The Armed Services Board of Contract Appeals (ASBCA) agreed that markings placed by Boeing on technical data delivered to the Air Force were nonconforming under DFARS. The case can be found at the ASBCA website, Appeal of The Boeing Company, ASBCA No. 61387 (Nov. 28, 2018).<br> <br> Boeing appealed to the U.S. Court of Appeals for the Federal Circuit, which interpreted the restrictions on markings in DFARS 252.227–7013(f) to apply only to markings that restrict the DoD’s rights (and not to markings that restrict only third parties’ rights). Consequently, the court reasoned that the DFARS provisions and clauses allow markings that impose restrictions on third parties but not on the DoD. See the the U.S. Court of Appeals for the Federal Circuit website: The Boeing Company v. Secretary of the Air Force, 19-2147, Dec 21. 2019.<br> So what markings, other than those set forth in DFARS, can a contractor place on data without violating the prohibition on nonconforming markings? Unfortunately, the Federal Circuit did not provide guidance on this issue. Instead, the court remanded the case to the ASBCA for further proceedings to determine whether the marking(s) Boeing sought to use did, in fact, improperly restrict the DoD’s rights.<br> <br> These are but two cases where both contractors and the DoD expended vast amounts of time and effort to address the issue of nonconforming markings. Contractors continue to place markings on data deliverables, and in fact may intensify their marking efforts after the Federal Circuit’s opinion, arguing that the markings chosen do not restrict the DoD’s rights. In response, DoD program offices will continue to direct contractors to remove markings that are nonconforming and do restrict those rights.<br> <br> So the data-rights battle continues, and it is imperative that DoD personnel understand the battle environment and what to expect. <h2>Order of Battle</h2> <p><span style="font-size:13px;">The order of battle over nonconforming markings should follow a predictable path. These are some of the steps program offices should follow to avoid and address nonconforming markings:</span></p> <ol> <li>The data-rights battle begins long before the first deliverable is received. During acquisition planning, a well-thought-out and clear IP Strategy should be developed. Communication with industry on data rights (e.g., via an industry day) might help to mitigate risk. Ensuring that everyone understands the IP Strategy during acquisition planning not only provides information needed by industry to submit a responsive proposal, it can reduce issues after contract award, including issues with nonconforming markings.</li> <li>The IP Strategy, which inevitably will evolve as the program progresses through its life cycle, should be a touchstone for program decisions and expectations regarding data deliverables. All program personnel should be aware of the details of the strategy, as well as the general rules that apply to contractor markings on data deliverables.</li> <li>Programs should have a process to review data that a contractor delivers and that is subject to the DFARS data-rights clauses. These procedures should specify the program office personnel that are responsible for the review (subject-matter experts, configuration management, program management, legal, or contracting). The procedures also should require that the responsible personnel identify any data deliverable that includes markings that are not in the format required by the DFARS clauses and that restrict the DoD’s rights. This review should occur as soon as the data are delivered and before acceptance; a program’s leverage to achieve correction of nonconforming markings decreases after acceptance of a deliverable. Once a data deliverable is accepted, resolution of nonconforming markings can be difficult and burdensome.</li> <li>The personnel responsible for inspecting the deliverable should notify the DoD contracting officer that the deliverables include nonconforming markings. After review of the information provided, if the contracting officer agrees that the markings are nonconforming, the contracting officer will usually attempt to resolve the issue by notifying the contractor of the problem. Ideally, the contractor will remove the improper markings, and the parties will move on to work together to execute the program.</li> <li>If the contractor does not voluntarily remove the markings, in accordance with DFARS 252.227–7013(h)(2) or 252.227–7014(h)(2), the contracting officer may issue a letter formally notifying the contractor of the nonconforming markings. A sample of information to be included in a contracting officer notification is shown in Figure 4. For removal of nonconforming markings, the contracting officer need not follow the formal procedures set forth in DFARS 252.227–7019 and 252.227–7037. These procedures, which will be discussed in a subsequent article, are required only for challenges based on unjustified markings on data.</li> <li>The contractor has 60 calendar days after this notification to remove or correct the markings. If the contractor fails to act, the DoD may ignore or, at the contractor’s expense, remove or correct the nonconforming markings. Keep in mind, however, that DoD personnel cannot remove, erase, or alter any nonconforming markings until the contracting officer resolves the markings issues and directs that markings be changed or removed.</li> </ol> <strong>Figure 4. Contracting Officer Letter</strong> <h2><strong><img alt="Figure 4. Contracting Officer Letter" src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article03_figure04.jpg" style="margin-left:6px;margin-right:6px;width:302px;height:300px;" /></strong><br> <br> How to Get Assistance</h2> <p>The authors can provide a tailored hands-on workshop on data-rights markings, including the processes to review deliverables to ensure that all markings on data delivered to the DoD are correct and to address problems.<br> <br> The Joint Tactical Networking Center (JTNC), a DoD organization, can assist program offices in reviewing deliverables. JTNC can verify data-rights markings via computer scans on both printed and digital media. They have the processes and tools to verify data-rights markings via computer scans of both noncommercial technical data and noncommercial computer software. Contact JTNC’s DoD Waveform Information Repository via email at <a class="ak-cke-href" href=""></a>.<br> <br> In addition, DAU has an IP community that can assist your program in markings and other data-rights issues. Reach out to the DAU IP community of practice at <a class="ak-cke-href" href=""></a>.</p> <hr /><strong>BURRIS </strong>is an acquisition attorney focusing on data rights at Headquarters Air Force Materiel Command at Wright–Patterson Air Force Base. She has more than 25 years of legal experience, a law degree from Cornell Law School, and a bachelor of arts degree from Purdue University.<br> <br> <strong>HARRIS </strong>is a professor of Program Management at DAU. He has more than 20 years of program management experience.<br> <br> The authors can be contacted at <a class="ak-cke-href" href=""></a> and <a class="ak-cke-href" href=""></a>. <hr /></div>string;#/library/defense-atl/blog/Resolving-Data-Rights-Markings-a-legal-Battlefield
Toward a Performance- and Quality-Based Adaptive Acquisition Framework —AAF Meets International Standards a Performance- and Quality-Based Adaptive Acquisition Framework —AAF Meets International Standards2021-07-01T16:00:00Z,<div class="ExternalClass3458F7049E3F404791718265D2777CB9">As stated in Department of Defense Instruction (DoDI) 5000.02 of Jan. 23, 2020, “the Adaptive Acquisition Framework (AAF) supports the DoD with the objective of delivering effective, suitable, survivable, sustainable, and affordable solutions to the end user in a timely manner. To achieve those objectives, Milestone Decision Authorities (MDAs), other Decision Authorities (DAs), and Program Managers (PMs) have broad authority to plan and manage their programs consistent with sound business practice. The AAF acquisition pathways provide opportunities for MDAs/DAs and PMs to develop acquisition strategies and employ acquisition processes that match the characteristics of the capability being acquired.” <h2>There’s more!</h2> “Performance Based Acquisition (PBA) is a method of preparing service contracts that emphasizes the service outcomes the Government would like the contractor to provide. The use of PBA has been encouraged by the Office of Management and Budget to drive down the costs of contracts while improving contractor performance.”<br> <br> What that means for PMs is that DoD tells contractors what capability it wants, and then leaves it to them to determine how to satisfy that capability.<br> <br> Does that make life easier for PMs, or help to ensure a product built most efficiently—on time and within budget? Not by itself. In fact, it exchanges one set of concerns for another set, and leaves policing the contracts and creating a quality product as challenging as ever.<br> The two primary directives of the AAF are (1) DoD Directive (DoDD) 5000.01 The Defense Acquisition System (DAS); and (2) DoDI 5000.02: Operation of the Adaptive Acquisition Framework.<br> <br> DoDD 5000.01 prescribes that the DoD will:<br> … employ the following operating policies: <ol> <li>Simplify acquisition policy</li> <li>Tailored acquisition approaches</li> <li>Empower PMs</li> <li>Conduct data-driven analysis</li> <li>Actively manage risk</li> <li>Emphasize sustainment.</li> </ol> <blockquote> <h1 style="text-align:center;">Word searches for terms such as quality, audit, verification, and validation will receive a “no matches were found” response for both directives.</h1> </blockquote> <p><img alt="" src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article04_image01.jpg" style="width:627px;height:300px;" /><br> <br> We will go into each of these six directed operating policies in the sections that follow. Two realities will form the basic theme of this article:<br> (1) The directives provide little guidance regarding how to realize these policies, leaving it to PMs.<br> (2) Word searches for the following fundamental management terms: quality, audit, verification, validation, feedback, follow-up, and accountability, will get you: “No matches were found” for both directives.<br> <br> A word search of other fundamental program management catchwords, such as measurement, objectives, risk, and performance, will lead the reader to an appropriate number of matches in all the appropriate places. Our job is to support the catchwords with a solid underpinning of sound management practices used successfully over many years by forward-thinking companies in the private sector. PMs can do this by planning a quality management system and making it part of the AAF in general and each acquisition project in particular.<br> The International Organization for Standardization (ISO) is a worldwide federation of national standards bodies. Preparation of International Standards, such as those discussed here, is carried out by technical committees in response to industry demand. Independent certification bodies “certify” organizations to applicable ISO Standards, and, in doing so, attest to the effectiveness of the organization as a responsible provider of quality goods and services.<br> <br> Government contractors (e.g., shipyards, weapons manufacturers) who certify to applicable ISO Standards are more likely to deliver a “quality” product—on time and within budget. ISO-certified contractors often receive (appropriately) the inside track in the awards process. Many DoD contracts specifically require contractor applicants to be certified to one of the Standards prior to the proposal submission date. This can give added value to both DoD and the contractors. However, it also can lead to what we auditors call “just-in-time certification,” which is often perfunctory. The ink on the certificate is barely dry, and there is no documented ISO-acceptable performance. An organization certified to any of the ISO Standards, in my opinion, requires about one year of actual implementation practice and self-audit before the standard reaches its maximum contribution.<br> <br> I have been a practicing ISO auditor and consultant since 1996, and remain a staunch advocate. PMs and staffs can download the ISO Standards (available online) to develop and implement viable program management in accordance with the AAF. The standards will help PMs with the “how” component of program management; they do not add anything to the “what” component. They do not require any additional work from PMs. In fact, streamlining already existing areas such as “risk management,” “internal auditing,” “reports management,” and “goals and objectives,” routinely reduces wasteful or redundant effort for certified organizations.<br> <br> Explaining any (or all) of the ISO Standards is too great an undertaking for this article. Tables 1 and 2 will give you the idea. The standards mentioned here have clauses that provide excellent guidance for the development and operation of quality-management systems. If you are not familiar with the ISO family of International Standards, maybe you need to learn about them, and if your vendors are not ISO-certified, maybe they should be.</p> <blockquote> <h1 style="text-align:center;">Put the emphasis on the results to be achieved—the deeds to be done.</h1> <h3 style="text-align:center;">—Joseph M. Juran, quality management consultant and engineer</h3> </blockquote> <h2>Where AAF Meets ISO</h2> <p>Table 1 takes the six “operating policies” of the AAF (source: DoDD 5000.01) and recommends appropriate ISO support processes. Here is where AAF meets ISO.<br> <br> Here is a deeper look into the AAF operating policies and ISO requirements that address them.<br> <br> <strong>(1) Simplify acquisition policy</strong><br> It’s reassuring to remember that even the most complicated strategic acquisition policy for the most complicated government program can be managed using quality evangelist Joseph M. Juran’s basic formula for getting results:</p> <ul> <li>Establish specific goals to be reached.</li> <li>Establish plans for reaching the goals.</li> <li>Assign clear responsibility for meeting the goals.</li> <li>Base the rewards on the results achieved.</li> </ul> <p>Acquisition policies need only to satisfy these four criteria. Goals must be “aimed-at” targets, toward which all the effort is expended. This is how you “simplify” the acquisition policy. The ISO Standards provide excellent structure to formulate acquisition policy. It does this by adding the ability to measure success through programs such as internal (self) audit, management review, risk management, data collection and analysis, corrective action, and feedback.<br> <br> <strong>(2) Tailor Acquisition Approaches</strong><br> PMs are told to consider acquisition approaches that leverage international acquisition and supportability planning to improve economies of scale, strengthen the defense industrial base, and enhance coalition partner capabilities to prepare for joint operations.<br> The actual type of contract is often a done deal long in advance of approach development. Similarly, regulatory requirements are not open for discussion. Accordingly, our focus is on what the approach must include, regardless of the type of the contract. Space limitations preclude lengthy discussion here, but PMs need to focus on time and security. Acquisition approaches are a function of the mission and its urgency; and time and security will always be vital to the “tailoring” (i.e., streamlining) process(es). The more urgent the Warfighter’s mission—the more tailored the approach.</p> <table border="1" cellpadding="4" cellspacing="4" style="width:700px;"> <caption>Table 1. AAF Operating Policies Meet ISO Standards</caption> <thead> <tr> <th scope="col">#</th> <th scope="col">AAF Operating Policies<br> (Ref: DoDI 5000.02)</th> <th scope="col">ISO 9000 Quality Management System Clauses *</th> <th scope="col">Applicable<br> ISO Standard</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Simplify Acquisition Policy</td> <td>Quality policies, goals, and objectives; risk-based thinking; environmental aspects; implementation and operation; continual improvement; product/process development</td> <td>1,2,3,4</td> </tr> <tr> <td>2</td> <td>Tailor Acquisition Approaches</td> <td>Quality, policies, goals, and objectives; operational planning and control; design and development controls</td> <td>1,2,3,4</td> </tr> <tr> <td>3</td> <td>Empower Program Managers</td> <td>Quality policies, goals, and objectives; management review; internal audit; checklist development; communication feedback, follow-up, and accountability</td> <td>1,2,3,4</td> </tr> <tr> <td>4</td> <td>Conduct Data-driven Analysis</td> <td>Quality policies, goals, and objectives; Information systems and Supply chain security management targets, data analysis and evaluation; performance evaluation; control of changes; measurement and traceability</td> <td>1,2,3,4</td> </tr> <tr> <td>5</td> <td>Actively Manage Risk</td> <td>Risk-based thinking; quality policies, goals, and objectives; threats, criticalities, and vulnerabilities; establish acceptable/unacceptable risk parameters; control of nonconforming product</td> <td>1,2,3,4</td> </tr> <tr> <td>6</td> <td>Emphasize Sustainment</td> <td>Quality policies, goals, and objectives; Implementation and operation; continual improvement; nonconformity and corrective action; preservation</td> <td>1,2,3,4</td> </tr> </tbody> </table> <p> </p> <table align="left" border="1" cellpadding="4" cellspacing="4" style="width:300px;"> <caption>*ISO Standards</caption> <tbody> <tr> <td> <ol> <li>ISO 9000: Quality Management Systems</li> <li>ISO 14000: Environmental Management Systems</li> <li>ISO 27000: Information Security Management Systems</li> <li>ISO 28000: Supply Chain Security Management Systems</li> </ol> </td> </tr> </tbody> </table> <p><br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <strong>(3) Empower PMs</strong><br> PMs are expected to plan their acquisition programs in a thoughtful, innovative, and disciplined manner. Library shelves are filled with recommended approaches—some appropriate and some not. Unmentioned is the amount of empowerment given and the form that it takes, as well as the manner in which program progress is measured.<br> <br> The ISO Standards, when employed by PMs, not only empower, but provide defensible measurements of success and the justifications for actionable correction. Clause 9.3: Management Review and Clause 5.1: Leadership and Commitment, in the latest ISO 9000 Standard, provide the foundation for an effective and successful program for “empowered” management. Following the steps of the clauses creates uncomplicated programs, leading to quality products, by way of solid processes and acceptable risks.<br> <br> I commanded a U.S. Naval Station in the late 1980s. “Environment” and “ecology” were the catchwords, and the “responsible line commander” was in the crosshairs. We were not even told what to do, let alone how to do it. We were promised only that an environmental incident (e.g., harbor pollution) meant loss of job and career and maybe even a civil lawsuit. I developed a set of checklists and wrote an instruction for the subordinate and tenant commands, and then I set up an audit and inspection process. My boss and I kept our jobs, but what I wouldn’t have given for an environmental management system like ISO 14000 back then. The first version of ISO 14000: Environmental Management Systems appeared in 1996.<br> <br> <strong>(4) Conduct Data-Driven Analysis</strong><br> DoDI 5000.02 directs that product support personnel and PMs: “make use of data-driven decision-making tools with appropriate predictive analysis capabilities to improve systems availability and reduce costs.” Again, it leaves the managers on their own with regard to how to collect the data, from what sources, and what to do with the data once collected.<br> <br> ISO 9001:2015 (operative version) Clause 9.1.3: “Analysis and Evaluation” guides PMs and staffs through the data collection and analyses process, giving collected data purpose and utility. Equally important, it guides PMs away from collection and/or reliance on meaningless, misleading, or otherwise irrelevant data.<br> <br> <strong>(5) Actively Manage Risk</strong><br> DoD tasks PMs to “Establish a risk management program to ensure program cost, schedule, and performance objectives are achieved, and to communicate the process for managing program uncertainty. In consultation with the user representative, the PM will determine which environment, safety, and occupational health risks must be eliminated or mitigated, and which risks can be accepted.”<br> <br> ISO 9001:2015 Clauses 4.4.1 (f) and 6.1 describe “risks and opportunities.” It is in the coupling of these two terms that PMs can assure themselves that their quality management system can achieve its desired results, enhance its desired effects, prevent/reduce undesired effects, and achieve continual improvement.<br> <br> ISO 28001:2007 describes “risk-based thinking” when dealing with security risks in the supply chain.<br> <br> <strong>(6) Emphasize Sustainment</strong><br> DoDD 5000.01 requires DoD Components to acquire systems, subsystems, equipment, supplies, product support, sustainment, and services in accordance with the statutory requirements for competition. Defining “sustainment” itself and in relation to other terms (e.g., life cycle) remains a challenge for the PM. However, an ISO 9000-based Quality Management System (in the aggregate) is a Sustainment Plan. Table 2 includes some of the ISO 9000 clauses that would help to create both a comprehensive Quality Management System (QMS) and a viable Sustainment Plan.<br> <br> Table 3 compares four of the ISO family of Quality Management Systems (QMS) with the tenets of the Defense Acquisition System, as described in DoDI 5000.02.<br> <br> The four International Standards support and complement each other and provide useful guidance for virtually any DoD program or contract.</p> <h2>ISO: Triumph of Titanium Over Boilerplate</h2> <table align="left" border="1" cellpadding="4" cellspacing="4" style="width:800px;"> <caption><br> Table 2. Using ISO 9000 to Create a Sustainment Plan</caption> <thead> <tr> <th scope="col">ISO 9000 Clause</th> <th scope="col">Clause Title</th> <th scope="col">Quality Mgt. System</th> <th scope="col">Sustainment Plan</th> </tr> </thead> <tbody> <tr> <td>4.3</td> <td>Scope of the quality management system</td> <td> <p style="text-align:center;">✓</p> </td> <td style="text-align:center;"> <p>✓</p> </td> </tr> <tr> <td>4.4</td> <td>Quality management system and its processes</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> <tr> <td>5.1</td> <td>Leadership and commitment</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> <tr> <td>5.2.1</td> <td>Establishing a quality policy</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> <tr> <td>6.1.2 (a)</td> <td>Actions to address risks and opportunities</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> <tr> <td>6.2</td> <td>Quality objectives and planning to achieve them</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> <tr> <td></td> <td>Measurement and traceability</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> <tr> <td>8.1</td> <td>Operational planning and control</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> <tr> <td>8.3</td> <td>Design and development of products and services</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> <tr> <td>8.7</td> <td>Control of nonconforming outputs</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> <tr> <td>9.1</td> <td>Monitoring, measurement, analysis, and evaluation</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> <tr> <td>9.2</td> <td>Internal audit</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> <tr> <td>9.3</td> <td>Management review</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> <tr> <td>10.3</td> <td>Continual improvement</td> <td style="text-align:center;">✓</td> <td style="text-align:center;">✓</td> </tr> </tbody> </table> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <div style="text-align:center;"> </div> <div>Table 3. Applying Some ISO/QMS Processes to AAF Tenets</div> <img alt="Table 3. Applying Some ISO/QMS Processes to AAF Tenets" src="/library/defense-atl/DATLFiles/July_Aug2021/DefAcq_Jul-Aug21_article04_table3.jpg" style="width:751px;height:300px;" /> <table border="1" cellpadding="4" cellspacing="4" style="width:500px;"> <tbody> <tr> <td> <ol> <li>ISO 9000: Quality Management Systems</li> <li>ISO 14000: Environmental Management Systems</li> <li>ISO 27000: Information Security Management Systems</li> <li>ISO 28000: Supply Chain Security Management Systems</li> </ol> </td> </tr> </tbody> </table> <h2>Summary</h2> <p>Check out these two quotes:</p> <h3>(1) DoDD 5000.01, Sept. 9, 2020:</h3> “Joint concepts, standardization, and integrated architectures will be used to the maximum extent possible to characterize the exchange of data, information, materiel, and services to and from systems, units, and platforms to assure all systems effectively and securely interoperate with other U.S. forces and coalition partner systems.” <h3>(2) DoDI 5000.02, Jan. 23, 2020:</h3> “Under the supervision of PMs, product support managers develop, plan, and implement a comprehensive product support strategy for all integrated product support elements and their material readiness. Product support managers will make use of data-driven decision-making tools with appropriate predictive analysis capabilities to improve systems availability and reduce costs.”<br> <br> The DoD directives provide guidance about “what to do,” but little direction regarding “how to do it” (or even how to know when you have done it), leaving it to program managers; and word search of the following terms: “quality,” “audit,” “verification,” and “validation” will get receive a “no matches were found” response to both directives.<br> <br> The ISO Quality Management Standards and clauses designated in the tables provide excellent direction for the development and operation of effective quality management systems in full compliance with AAF requirements and giving full support to DoD programs.<br> Many DoD contracts specifically require contractor applicants to be certified to one of the Standards prior to the proposal submission deadline. “Just-in-time certification” is often perfunctory, with no documented ISO-acceptable performance. An organization certified to any of the ISO Standards, in my opinion, requires about one year of implementation, execution, and self-audit before it reaches its maximum contribution.<br> <br> The ISO Standards are available online. You can order or download them in the time it took to read this. If you are not familiar with the ISO family of International Standards, maybe you need to learn about them; and if your vendors are not ISO-certified, maybe they should be. <hr /><strong>RAZZETTI</strong>, a retired U.S. Navy captain, is a management consultant, auditor, military analyst, and frequent contributor to Defense Acquisition magazine and the former Defense AT&L magazine. He is the author of five management books, including Hardening by Auditing—A Handbook for Improving the Security Management of Any Organization.<br> <br> The author can be reached at <a class="ak-cke-href" href=""></a>.</div>string;#/library/defense-atl/blog/Toward-a-Performance

Chat with DAU Assistant
Bot Image