| Creating Incentivized Agile Contracts | | https://www.dau.edu/library/defense-atl/Lists/Blog/DispForm.aspx?ID=239 | Creating Incentivized Agile Contracts | 2021-07-01T16:00:00Z | https://wwwad.dauext.dau.mil/library/defense-atl/PublishingImages/DefAcq_Jul_21_banner01.jpg, https://www.dau.edu/library/defense-atl/PublishingImages/DefAcq_Jul_21_banner01.jpg
https://wwwad.dauext.dau.mil/library/defense-atl/PublishingImages/DefAcq_Jul_21_banner01.jpg | <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">https://www.dau.edu/training/pages/credentials.aspx</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="https://quicksearch.dla.mil/qsSearch.aspx" target="_blank">https://quicksearch.dla.mil/qsSearch.aspx</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="mailto:Tim.Freihofer@dau.edu">Tim.Freihofer@dau.edu</a>, <a class="ak-cke-href" href="mailto:David.Dotson@dau.edu">David.Dotson@dau.edu</a>, and <a class="ak-cke-href" href="mailto:Rhonda.Maus@dau.edu">Rhonda.Maus@dau.edu</a>.</div> | string;#/library/defense-atl/blog/Creating-Incentivized-Agile-Contracts | | | | | | | |
| The Four C’s for Successful Other Transactions | | https://www.dau.edu/library/defense-atl/Lists/Blog/DispForm.aspx?ID=240 | The Four C’s for Successful Other Transactions | 2021-07-01T16:00:00Z | https://wwwad.dauext.dau.mil/library/defense-atl/PublishingImages/DefAcq_Jul_21_banner02.jpg, https://www.dau.edu/library/defense-atl/PublishingImages/DefAcq_Jul_21_banner02.jpg
https://wwwad.dauext.dau.mil/library/defense-atl/PublishingImages/DefAcq_Jul_21_banner02.jpg | <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="http://www.beta.sam.gov" target="_blank"> www.beta.sam.gov</a> and <a href="http://www.grants.gov" target="_blank">www.grants.gov</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="mailto:stephen.speciale@gmail.com">stephen.speciale@gmail.com</a>.</div> | string;#/library/defense-atl/blog/The-Four-Cs-for-Successful-Other-Transactions | | | | | | | |
