Government // Enterprise Architecture
Commentary
1/14/2014
08:36 AM
Connect Directly
RSS
E-Mail
50%
50%

4 Ways To Improve Federal Software Procurement

Agencies need to think beyond buying and customizing enterprise software systems and look for software that can be adapted as requirements change.

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:

  • Can the client make the needed changes, or just the vendor?
  • How much will it cost, and how complicated will it be?
  • How successful is the vendor at adding capabilities and technologies?
  • Is the software flexible enough to automate as-yet-unidentified processes?

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.

Federal CIO Steven VanRoekel speaking at Churchill Club in October 2011. (Source: TechwireNet - YouTube)
Federal CIO Steven VanRoekel speaking at Churchill Club in October 2011. (Source: TechwireNet - YouTube)

I envision a set of principles like XML First, Web Services First, Virtualize 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 yield a higher return on our IT investments, increase productivity, and improve the way the government interacts with the American people.

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).

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
moarsauce123
50%
50%
moarsauce123,
User Rank: Ninja
1/17/2014 | 7:07:02 AM
Agree as well, but ...(as well)
Major IT projects fail often, that has nothing to do with the government. Look at the many SAP implementations that went sour. The problem is that these projects are too big, too complex, and lack decision makers.

For government projects and that includes IT projects the procurement rules are designed to spread the wealth. That is why over 50 contractors were in the mix for healthcare.gov. That alone needs a massive effort in project management to have the 25 left hands know what the 25 right hands do. Congress needs to put measures in place where the number of contractors for a project can be reduced to a manageable number. Spreading the wealth is still possible by ranking those who got a deal lower the next time a project is up for bid. The UK government already put measures like this in place and has most IT projects succeed. But I guess the US will continue using Europe simply as whiping boy rather than as source of knowledge...
jries921
50%
50%
jries921,
User Rank: Ninja
1/16/2014 | 12:25:44 PM
Agreed in full, but...
One of the things we should get out of the problems with federal software procurement  is a sense of the dangers of overreliance on outsourcing (we should get that out of the Snowden incident as well).   Organizations typically employ a fair number of intelligent people with good ideas and not all of them are managers.  And unlike contractors or consultants, regular employees have invested part of their working careers in the organization and are likely to be there to pick up the pieces when the contract is finished.  Ergo, the regular IT staff in both federal agencies and elsewhere should have the freedom to experiment and develop programs and systems that help them do their own jobs better and help the front line employees do their jobs better.  IT makes sense to outsource for big ticket items, but the careerists should be actively involved in developing the specifications, and they're the ones who should be administering the systems when they go on line (there's really no valid excuse for outsourcing system administration in a large organization).

The general principles should be:


1.  Contractors should handle temporary needs.  Permanent employees should handle permanant ones.

2.  Core governmental functions (especially the ones involving the use of force) should always be in the hands of regular government employees (who might be temporary or part time); never contractors.

 
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest - September 17, 2014
It doesn't matter whether your e-commerce D-Day is Black Friday, tax day, or some random Thursday when a post goes viral. Your websites need to be ready.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.