TMCnet - World's Largest Communications and Technology Community



Six Ways to Improve Federal Government Software Procurement

Government Technology Featured Article

February 20, 2013

Six Ways to Improve Federal Government Software Procurement

By TMCnet Special Guest
Evan McDonnell, VP of Solutions, Appian

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:

  • 35 percent have adopted manual workflow to cope with limitations in their acquisition applications
  • 30 percent use specific workarounds like printouts and e-mail
  • 60 percent asked their acquisition vendors to make changes, but decided against them because the cost were too high
  • 72 percent believe their organizations would be much more productive if they could easily modify their software

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: 

  • A “light” change could be to the way a user input screen works, how work it routed, or changes to business rules. 
  • A “medium” change could be to changing the core application logic. 
  • A “heavy” change would be extending the core functionality to incorporate a related process. 
  • An easy change capability is necessary for any agency to use its application to provide a shared service – which is being pushed under the Federal CIO’s “Shared First” mandate.

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. 

Some considerations:

  • Could the software chosen for this project be used for other projects or is it a one-trick pony? 
  • Could the application be extended to meet adjacent needs that may not be automated? 
  • What is the vendor’s track record for adding entirely new capabilities? 

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

Edited by Braden Becker



Technology Marketing Corporation

35 Nutmeg Drive Suite 340, Trumbull, Connecticut 06611 USA
Ph: 800-243-6002, 203-852-6800
Fx: 203-866-3326

General comments:
Comments about this site:


© 2018 Technology Marketing Corporation. All rights reserved | Privacy Policy