Government Technology Featured Article
February 20, 2013
Six Ways to Improve Federal Government Software Procurement
The Federal government has a very poor success rate when acquiring software, with many front-page stories of projects that delivered negligible results having to be scrapped after hundreds of millions of dollars were spent.
While software acquisitions are complicated, the root cause of the problem does not rest there; after all, the commercial world has good success with software investments.
Former Federal Chief Information Officer Vivek Kundra noted in the introduction for his plan to reform Federal IT management; “Despite spending more than $600 billion on information technology over the past decade, the Federal government has achieved little of the productivity improvements that private industry has realized from IT.”
The real problem rests with the way the Federal government goes about buying software. Here are several suggestions to change the way the government runs software acquisitions so they can achieve success on par with private industry.
Drop the Notion of a Single Solution That Meets All Needs
Acquisition professionals don’t want to recommend a purchase unless it can meet all the needs of their organization. They find every possible user requirement to use as an evaluation point because past experience shows that software is very expensive to change.
Rather than trying to find one solution to meet all needs, acquisition professionals should change criteria to weight solutions which are easier to adjust to needs that are certain to evolve over time. They should focus on who can change the vendor’s software (the client or only the vendor), what it will cost, and how easily it can be done. Ongoing change is the reality of software in the Federal government today.
A survey of Federal acquisition professionals in August 2012 showed:
Use Expected Lifecycle and Total Cost of Ownership Analysis
Federal software acquisitions almost always focus on the initial costs to purchase and install, and operating and maintenance costs (centering around customer support) for a series of option years. What’s missing is an expectation of the useable life of the software (you can’t assume it’s the number of option years), likely changes in the core business process the software is automating over that time, and the costs of changing the software to meet evolving needs.
Upgrades are another important point to evaluate in a lifecycle analysis. Because the government usually only has “one year money,” procurement professionals may miss the fact that many software vendors require customers to purchase upgrades to stay on maintenance. If upgrades are not purchased, the application’s capabilities will fall behind evolving needs.
Require Vendors to Make Application Changes as Part of Their Demos
Changing software applications can be tricky. Many vendors limit changes because they don’t generate revenue – or they charge customers a premium to make custom changes. To complicate matters, custom changes can force you off the upgrade path, shortening the expected lifecycle. The software acquisition process must determine how changes are made and who can make them. Buyers may be surprised to find that many software vendors have “change control boards” to review customer change requests. Some may never be approved or put very low on the list, making the software less valuable to you.
A total lifecycle cost analysis cannot be accurate without an estimate of the number of changes and the cost to make each change. You can’t get a realistic estimate of the cost of a change from a vendor unless you ask for cost estimates as part of the evaluation process. Be sure to ask the vendor who owns changes you pay for as many end user license agreements show the vendor owns the change once implemented.
Even better is to require vendors to make actual changes to their software as part of your evaluations, which the most advanced vendors can easily do. For those whose software doesn’t work that way, require firm cost and time estimates and use these as part of your total cost evaluation.
Ask for changes at various levels, for example:
Put More Scrutiny into the Evaluation Points You Do Keep
The business evaluation section of a recent RFP for an acquisition system for a cabinet level agency contained 429 separate evaluation points, 88% of which were noted as “#1 priority.” Items with “#1 priority” ranged from “the ability to retain contact information” (super easy) to “a workflow management system based on user defined routing” (very complex). The amount of time allocated to evaluate each vendor’s offering was six hours, which translates to 72 seconds per evaluation point. (Things get worse if you include the system administration evaluation points.)
Worse than the length of the list was the language for many of the points. The requirement description for one item simply stated, “The system shall provide the ability to track closeout items.” A contract modification process could be used to mimic a contract closeout. Does that warrant a “check”? What if another vendor has a robust closeout procedure that meets the needs for closeout and helps with overall management, which using a contract modification can’t do?
Think Beyond the Single Application
By the time there is an RFP, the specific need has been tightly defined and the acquisition will move forward. But today, no software exists by itself and no process begins and ends as neatly as described in an RFP document. Acquisition professionals need to incorporate broader thinking into each purchase – both for what the particular application could do outside of the current need, and for the vendor’s track record in adding new fundamental capabilities to take advantage of new technology.
Evaluate Options for Compliance with “Future First”
Steven VanRoekel, the current Federal CIO, set a clear direction that all new information technology purchases should incorporate “Future First” requirements. In describing “Future First”, VanRoekel noted, “Given the rapid pace of change in IT, it’s not enough to just build solutions that meet the government’s current needs, Federal Agencies must look more at future requirements to ensure that IT solutions are flexible enough meet those requirements too whenever possible.” Requirements that fall under “Future First” include minimal customization, object reuse, and web-based solutions with standardized interfaces.
Acquisition professionals need to incorporate evaluation on these points; but to make the smartest purchases, they need to also look at the next most likely “Firsts.”
VanRoekel noted in the same speech, “I envision a set of principles like ‘XML First’, ‘Web Services First’, ‘Virtualization First’, and other ‘Firsts’ that will inform how we develop our government’s systems. They will effectively establish a new default setting for architecting solutions government-wide, and they will be continuously updated as new technologies emerge to ensure that our government is at the frontier of advancements that yields a higher return on our IT investments, increase productivity, and improving the way the government interacts with the American people.”
Application access through mobile devices falls clearly into this category. While many agencies still need to work out policies to support mobile, the government should prepared to extend “Future First” to include mobile access – even if that is not allowed under current policies.
Another “Future First” area is social collaboration. Social communication has grown at a fantastic rate with consumers and is catching steam with large businesses, as new social tools become available that fit within corporate access constraints.
By taking these recommendations under consideration, Federal procurement of software can be streamlined, reducing the cost of software and improving the success rate of implementations.
Evan McDonnell is VP of Solutions for Appian. He can be reached at email@example.com.
Edited by Braden Becker
LATEST GOVERNMENT TECHNOLOGY NEWS
Advanced Cooling Therapy Closes $1.5 Million Series A Raise for Medical Device Firm's Esophageal Cooling Device