An interesting thing happened to me while making a recent personal software purchase. I recognized I was using the same acquisition approach the Federal government uses for software. Unfortunately, I got the same poor results they usually get.
I'm an avid home movie maker. I'm also known to pinch pennies so until two months ago, I was doing my home movie editing with a software package that was seven years old. I've paid for upgrades a few times to get some additional functionality, but stopped doing that when one upgrade made my home computer (which until recently was eight years old) operate so slowly I had to roll back to the previous version.
My "personal technology gap" had widened to the point where it was impacting my family ("Dad ñ The computer froze again and I can't finish my homework!") so I bit the bullet and bought a new state-of-the-art home computer (family happy!). Now it was time to finally upgrade my video editing software.
I did what any good penny pincher would do. I thought carefully about my requirements. I found a website that reviewed all of the leading video editing packages, comparing features and prices side by side. I learned about newer features to determine which I'd really use. I downloaded evaluation copies and tried them out. Convinced I had found the most inexpensive software that met my requirements, I went ahead and purchased it (now I was happy!).
But after actually using this software for months and not just running through test evaluations, I've uncovered a lot of limitations. The review website put checks in boxes for some of my most important features, but the actual performance of those features in the package I bought is so limited it makes me believe the software company just mocked something up to pass the review. Now that I'm more familiar with this generation of software, I also recognize that other features I considered optional are really necessary for the types of movies I want to make.
I was past the time limit for returning the software so my options were limited. I could either live with software that really didn't fit my needs, find workarounds, or accept producing poor quality videos. Or, I'd have to bite another bullet and purchase the more flexible software package I should have bought in the first place. Neither option was enticing. Buying the other package would mean I'd have to recognize a complete loss on the first package I bought. Producing poor quality family movies would clearly have an even greater long term cost, although putting numbers to it is hard.
So I decided to come up with a third option. I called the company that made the software I had already purchased and gave them a list of the things I wanted them to fix and add to the product. The customer support rep I spoke to said she would forward my list on to their product management group. That wasn't good enough as I needed to quickly make a decision as to whether I would throw their software out and buy the other package so I pressed further. I asked the rep if she could get me a price quote and timeline for making my full list of changes. After an awkward pause, the unfortunate support rep had to inform me that their company wasn't in the business of making specialized software just for one customer's needs, and if they were, the costs to do it would be orders of magnitude greater than the $99 I had already paid.
I certainly didn't want to shell out thousands of dollars on a fix so I went ahead and bought the other software package. I sure hope it fits my current list of needs and I don't come up with any additional ones that might make me need to purchase yet another software package.
So what does the government have to do with this?
I explained the details of my purchasing story the way I did because it is the exact same approach the Federal government uses to purchase multi-million dollar software systems. The Government's track record with these purchases is very poor and things aren't getting any better. The problem lies with the Government's approach to acquiring software.
The Federal Government buys software the same way it buys tanks, construction materials, or any other physical goods. When you're buying something physical, it is much easier to evaluate it against a long list of criteria. It is also easier to project likely additional needs and anticipate additional costs.
But software is a different animal entirely. Software applications at the heart of core government processes are very complex. Knowing which of many possible features are required to meet current needs is a challenge. I'm sure many government workers are like me and my video editing software. They are using technology that's so old they don't know what's possible and what they really need until they get to start using newer technology.
Technical evaluations are equally challenging. Most capabilities defy a simple check box. Each capability has unique ways it must be graded. That creates execution challenges for contracting officers (CO) and contracting officer technical representatives (COTR). Even if they do their jobs exceedingly well, new requirements can emerge after the software has been acquired and installed. Now the Government is faced with the same options I had with my video editing software, except that when they call the company that made the software, they get a price quote for the changes they wantÖ and it is almost always exceedingly high as the software company knows the customer is stuck and this is their chance to make up for what may have been an aggressively low initial bid.
What's the result?
A survey I conducted recently of Federal acquisition professionals found that 60% have requested changes to their contract writing systems only to decide against them when they got a price quote from the software company. They are living with disappointment and finding manual workarounds to gaps in their software. And some portion of the rest did pay the exorbitant prices to get the customizations they needed. Neither is a good outcome. The irony here is that the acquisition evaluation in all cases led to the selection of a system that was deemed to meet all core needs at a low price. Clearly the Government's acquisition process did not lead to the best value and lowest overall long term cost.
How can the Government get better results in software acquisitions?
Albert Einstein is noted for saying, "Insanity is doing the same thing over and over again and expecting different results." As long as the government continues to approach software acquisition the same way it approaches physical goods acquisition, it should continue to expect poor outcomes and unanticipated costs.
The answer is to adopt a new set of criteria for software purchases. Vendors should be evaluated on their current functionality as well as the flexibility of their software to economically adapt to changes, even at the core logic level. This can be accomplished by COTRs adding a set of typical changes to the software functionality at a surface, mid, and deep functionality level and requiring bidders to explain how they would make the changes in what period of time and at what cost. COs must make this a part of RFIs and RFPs. These estimates need to be factored into the final evaluation. The longer the anticipated life cycle of the application, and the more dynamic the business of the organization that will own it, the more weighting should be given to the core flexibility of the application and the cost of change.
To learn more about highly flexible software technology for acquisition and contract writing systems, please download my new white paper, "What Federal Acquisition Professionals Need to Know About the New IT Landscape."
Vice President of Solutions
Appian helps organizations build apps and workflows rapidly, with a low-code automation platform. Combining people, technologies, and data in a single workflow, Appian can help companies maximize their resources and improve business results. Many of the world’s largest organizations use Appian applications to improve customer experience, achieve operational excellence, and simplify global risk management and compliance.