Federal IT failures are often caused by force-fitting commercial off-the-shelf (COTS) applications to make them fit government needs. This is particularly true with the acquisition and contract writing systems in use throughout the federal government.

Today, some companies have created flexible platforms for federal acquisition and contract writing systems. The components of these platforms are:

Business Process Management (BPM) Platform– These new solutions offer a codeless development environment with drag-and-drop icons to create software functionality. Application users and designers communicate through flow diagrams that build program logic. This leaves software engineers free to focus on new capabilities like social and mobile instead of writing specific application logic.

Acquisition “Framework”– Implementation of these new systems starts from a framework with common acquisition process elements already in place. This framework is a project accelerator, lowering implementation costs, shortening the go-live time, and increasing initial functionality.

Native Mobile Clients– When the BPM platform is extended with native mobile clients, agencies can offer mobile acquisition process participation without investing in mobile development.

Integrated Social Communication– Social media is becoming a common business tool. Tying it directly to process events greatly increases its utility, which is a built-in capability with these types of platforms.

Following are the most important steps to ensure this new generation of solutions is included as part of RFIs and RFPs for a new acquisition and contract writing system: 

Ask for “COTS-based,” Not “COTS”– Limiting your search to COTS products will exclude the new generation of systems. These highly flexible solutions technically aren’t off-the-shelf – although the platforms they are built upon are.

Rethink the Long Functionality Check List– COTS products are not flexible, so you need to test them for hundreds of specific capabilities. New software products focus on flexibility, so you can add capabilities with little cost or effort. Be sure to balance existing functionality with the ability to easily add or modify later.

Evaluate and Score Architecture– Unlike COTS products, the new options are built on open, flexible architectures so an explicit evaluation is necessary.

Require Demonstrations of Core Logic Changes– COTS vendors won’t demonstrate a core logic change during an evaluation because it’s complicated and costly. New architectures make rapid changes possible, so a demonstration of a core change is warranted to understand the options.

Require Scoping for an Incremental Build Out– Next generation systems built on BPM platforms can be extended for related functionality such as responding to a congressional inquiry on a specific procurement. Be sure vendors state how they would meet such a request and its cost.

Require Native Mobile Clients and Social Communications– We’ve already seen specific “Cloud First,” “Shared First,” and “Future First” guidelines. It won’t be long before “Mobile First” and “Social First” initiatives come out. Get ahead of the wave by including evaluations for mobile and social technology.

Finally, evaluate end user license agreements from potential vendors early in the process. Restrictions may substantially increase the total cost of software ownership. Look for items like a requirement to purchase upgrades in order to stay on maintenance, ownership rights of any customizations you pay them to create, and other restrictions.

Evan McDonnell is vice president at Reston, Va.-based Appian, a supplier of business process management software. He can be reached at evan.mcdonnell@appian.com.