4 Ways To Improve Federal Software Procurement

The federal government's track record for implementing major software projects, unfortunately, is littered with high-profile, multimillion-dollar failures, HealthCare.gov being just the latest example.

The seeds of these failures are often planted right at the start with entrenched attitudes about what will work and, in turn, how the federal government purchases software. Too often, a project implementation begins with the purchase of an enterprise software system, with plans to customize it for the particular needs of the procuring agency.

In private industry, firms are increasingly choosing to avoid customizing a stock enterprise solution. Instead, they are configuring -- not coding -- specific instructions into new, more modern work platforms. Because that approach is more specific to the needs of the organization -- and because the approach favors agile development practices -- it typically leads to a higher level of success.

[The technology procurement game has fundamentally changed? Read why Vendors Must Cater To Developers Or Die.]

Given the current administration's desire to adopt best-practices, many of them from private industry (including how software is purchased), it may be useful to look at four key ways to improve federal software procurement.

1. Stop thinking that a single system can do all you need
Acquisition professionals often shy away from purchases that only meet a portion of their organization's needs. Because experience has taught them that changing software can be an expensive process, there is also a tendency to evaluate software from the point of view of each and every potential user's requirements.

The reality is that requirements change over time. Many federal software buyers have abandoned plans to adjust software because the estimated cost of making modifications was too high. As a result, they often adopt manual workflow processes to work around their enterprise software limitations.

Instead of a one-size-fits-all approach, procurement professionals should look at software products that are easy to adapt as requirements evolve. A good set of questions to consider:

These are easier factors to consider than finding a single comprehensive solution to an evolving set of circumstances.

2. Start thinking future first compliant
In his first public address in October 2011 at The Churchill Club, Federal CIO Steven VanRoekel, made it clear that information technology should conform to "future first" requirements. It should be flexible enough to "help us continuously architect for the future" with minimal customization, be able to reuse objects, and be web-based with standardized interfaces.

Clearly, mobile application access needs to be considered on the future first list, even though many agencies are still working out mobile policies, if government technology is to have any parity with the private sector.

Social collaboration is another future first area. As social tools catch on in private enterprise and among consumers, this component needs to be included in future federal plans.

Becoming compliant with these initiatives will make it easier to streamline software procurement and create more cost-effective and successful application implementations.

3. Ask vendors for application change demos
Under the Federal CIO's shared first initiative, enterprise applications must be easily changeable to adapt to shifting mission requirements if they are to be usable in a shared services context among organizations. For that reason, it's important to have vendors make actual changes to their software as part of your evaluation. If the software doesn't work that way, get firm estimates about the time and expense required to make changes.

Unfortunately, because that kind of change capability doesn't contribute to their revenue when selling their products, vendors often try to limit changes, or they try to charge customers for those changes. But you can't get an accurate understanding of total lifecycle cost unless you can estimate how much it costs to make changes. Therefore, cost estimates must be part of the evaluation process. Also, many user license agreements say that the vendor owns changes, even if you pay for them. Be wary of that kind of language.

4. Understand lifecycle and cost of ownership
When buying software, federal acquisition professionals look most closely at how much it costs to buy and implement the software and how much it will cost to operate and maintain it over a number of option years. What they should also consider is what the practical life expectancy is for the software (based on changing needs) and how much it costs to keep it up to date.

Vendors often require customers to buy regular upgrades to stay on a maintenance program, or the software capabilities won't keep up with new requirements. That's an important factor to consider, and in our experience, it is an easy factor to overlook.

These suggestions may be at odds with the way federal budgeting works today, but keeping them in mind may result in more successful software implementations overall.

Chris O'Connell is vice president for federal sales at Appian.

IT organizations must build credibility as they cut apps, because app sprawl is often due to unmet needs. Also in the App Consolidation issue of InformationWeek: To seize web and mobile opportunities, agile delivery is a given (free registration required).