An Agile Perspective on Defense Acquisitions (Sponsored Content)
A more flexible acquisition process is gradually coming into use throughout the Department of Defense that is especially well suited for technology-based projects such as software systems development. This process meshes well with software design methodologies such as agile development because it allows agencies to rapidly modify a project or a design well before its final stages, saving both time and money, and ensuring the solution meets end user needs.
The Department of Defense has long struggled with acquisition programs. As new business challenges become more complex and cross-functional, traditional development methodologies can lead to miscommunication and cost overruns. However, the growing use of alternative acquisition models, combined with new software tools to help manage technology-based programs, can help agencies meet their operational needs in a faster and more agile way
There is currently a tremendous opportunity to improve how the Department of Defense conducts its acquisition programs, says Cynthia Stuebner, futurist and director of the defense business line at Pegasystems, Inc. (Pega), a Cambridge, Massachusetts-based company that is a leader in software for operational excellence and customer engagement through digital process automation. One of the more promising changes taking place in defense acquisition is the increasing use of other transaction procurement instruments. They have existed since the 1950s, but it is up to Congress to decide which agencies are authorized to use the process (often referred to as OTA—other transaction authority)—an alternative to the traditional Federal Acquisition Regulation (FAR) process. The process requires Congressional reporting, which includes the rationale for use of an OTA, which is typically for research or prototyping.
Congress has recently amended the authority to expand the definition of a prototype project to increase the department’s ability to engage with nontraditional contractors and seek out the latest technology to improve readiness and streamline business operations. These changes allow more Defense Department agencies to pursue OTAs instead of traditional acquisition methods and has led to an increased number of these acquisitions across the department, she says.
Some key elements make OTAs a much faster approach to acquisition. While not applicable in all circumstances, Stuebner notes that OTAs are very useful for technology acquisition programs because they encourage participating parties to experiment, prototype and even potentially fail, but “fail quickly and cheaply.”
Another advantage to OTAs is that the contract award itself cannot be protested. Award protests have become a common occurrence in the Defense Department, especially for major, expensive programs. “With an OTA, you don’t have that kind of dark cloud hanging over you,” Stuebner observes.
As OTAs become more widespread, they will fundamentally change acquisition culture in the Department of Defense, Stuebner says. It will take time because instituting any kind of change in a very large organization like the department does not happen quickly, but she is optimistic that OTAs will make a major impact on how military acquisition contracts are conducted, thus speeding innovation in support of warfighters and national defense.
Alternate contract methods like OTAs are also important because one of the problems currently facing defense acquisition is that not all programs are equal or require the same amount of oversight. For example, a weapons system or platform like the F-35 Lightning II multirole fighter performs warfighting missions in the harshest battlefield environments. There are a host of regulations and requirements to meet to ensure that the aircraft meets its mission requirements and is safe to operate. There is no commercial equivalent to reference, and the platforms are intended to operate for several decades, adding layers of complexity to the acquisition.
By comparison, “when you deliver a financial system, if it works properly everybody’s happy and then you move on to something else,” she says. But the risk expectations for a back-end system such as a logistics or payroll processing application should be on a different level compared to a direct warfighting system.
“From an acquisition modernization standpoint, you need to segment what it is you’re looking at buying first, and what is the ultimate intent and outcome of what you want to deliver in order to determine what rules make common sense to apply and how to approach it,” Stuebner says.
OTAs can be run very quickly, with awards being distributed in as little as a few months from the start of the competition. There is also often a downselect process where several vendors can demonstrate their products, trying to meet the capability the awarding organization is looking for. “The process is rigorous in its own way and has so far provided a significant amount of very impactful results for the organizations that are using it,” Stuebner shares.
The OTA process meshes well with agile development. Stuebner explains that agile development in a software sense is about iterative refinement. This allows an agency to work through a development process, tweaking a process or system until it arrives at something useful. She cautions that like an OTA, agile development does not work for every acquisition situation.
However, these new acquisition tools are necessary because they help the Department of Defense more efficiently purchase unsexy, but essential, back-end systems that help warfighters. She explains that as these systems work in the background to issue paychecks; manage personnel, medical, and service records; and manage taxes they enable leadership and warfighters to focus on their core missions.
Because OTAs and agile development projects enable both speed and multiple iterations during their life cycles, the right tools are necessary to help manage and streamline the process. Pega’s business process automation software platform helps program managers map out and automate end-to-end processes as well as integrate to other systems.
In some cases this means linking to legacy systems that have been operating for decades.
An important part of Pega is its no-code software that writes software. This provides an operational foundation that allows program managers to visually design a process using models that enable business and IT to design together. Stuebner explains that it allows a business architect to sit with a customer, such as someone in a finance or accounting department, and map out a process together. This is done visually on a screen or monitor in the same way that a process is done on paper by drawing boxes or laying down Post-It Notes.
Each of the boxes visualized on screen is represented by blocks of operating code and when the entire process is mapped out for the customer, a button can be clicked and the process will run. This allows the architect to sit with the stakeholder, map out a potential process for a back-end system such as a payroll or personal documents management system, and then generate code to automate the process, Stuebner explains.
“You’re deploying your process in real time. What that helps to do, from a requirements standpoint, is to sit down and understand ‘here’s how my requirement would be executed in the software—is that what I want, yes or no?’” she says.
By using a drop-down box of menu options, the Pega platform allows project managers to map out the development of a back-end system and see if there are any unintended results. In an acquisitions sense, this helps circumvent the part of the process where the organization running the project writes an extensive set of requirements and then passes them off to a team of software developers who then return months later with something that may or may not resemble the intended system or tool.
The Pega development platform can integrate with enterprise systems such as Oracle and SAP, as well as other custom-developed legacy systems, helping to mitigate the risk of a complete rip-and-replace solution. The software can map out a variety of different steps for setting up a supply chain and ordering parts/services and the finances for setting up payments. This information is then organized in a central data repository that allows program managers to have a birds-eye view of the development process.
Besides providing an overview for management, the system allows developers to connect legacy platforms together and integrate them into new applications. This gives program managers and mission directors the flexibility they need to make the back-office tools and applications meet their mission objectives. “It’s able to connect a number of different legacy systems that normally you would have to write program code to connect to each other—hard code them. Our system essentially automates that process and elevates it to the point that you have one environment that you’re working from and unifying a number of different systems,” Stuebner says.
Another important feature of Pega’s software is that it automatically generates documentation, recording every change and modification. This also serves other functions, such as facilitating auditing because there is a clear documentation trail of every purchase and transaction throughout the program’s life cycle, she explains.
Pega is already helping defense services and agencies, including the Air Force and Defense Information Systems Agency (DISA), employ digital process automation to meet their missions more efficiently. The software fits in with the department’s growing use of OTA acquisitions and agile development processes to meet its technology development needs.
“The genie’s out of the bottle. More and more agencies are getting comfortable with it [OTA], and using it for prototyping, which is a key area for Pega,” Stuebner says.
For more information, visit pega.com/defense
