Four Ways To Improve Procurement

Last year, in the midst of the Healthcare.gov’s troubled launch, President Obama said government IT procurement needs to be blown up and built anew. But how do you blow up federal procurement effectively?

Healthcare.gov troubled procurement wasn’t the only high profile acquisition failure out there; there have been others. What changes actually need to be made?

Chris O’Connell is a Vice President for federal sales at Appian. He has written about four ways to improve federal software procurement. O’Connell told Chris Dorobek on the DorobekINSIDER program that while procurement isn’t the only issue facing federal programs it is the starting point.

“Poor procurement is essentially starting each organization and each IT initiative behind the 8 ball before they even get started,” said O’Connell. “Obviously there are other issues associated with delivery that come into play, but today, what we see, is that the procurement lifecycle is antiquated and not keeping up with the times for today’s modern software.”

For years, after Steve Kellman and all the procurement changes that happened in the Clinton years, folks said, “We don’t need changes in legislation, we’re fine, we just need to use them better.” But now people said, “Maybe we do need to make some adjustments; maybe things aren’t keeping pace.”

“Even if you don’t change the legislation, I think some of the ways that procurement offices can approach the problem, and interpret how they’re going to acquire and come up with better plans,” said O’Connell. “They can take into account some of the newer technologies, agile delivery, that can really help facilitate more effective federal IT. I think that could be a good first step as well.”

Solution Number One: Stop thinking a single system can do everything you need.

• “Traditionally federal IT is really taking a look at large systems as either a large build or buy, and trying to ensure that every single requirement that could ever be conceived by every stakeholder is incorporated into that procurement,” said O’Connell. “What we see is that no one could ever imagine the various needs of a given agency, nor when you are custom coding something and trying to build something out over a long extended period of time is that in itself going to solve the problems because requirements change over time. That is a constant. What we’ve seen time and time again is, as detailed and laid out as these procurements have been, they’ve ended up faltering over time because they’ve not accounted for the variations within each agency, and/or the time associated with delivering and what might happen to those requirements downstream.”

“I think part of the reason contractors are hesitant to jump on agile, is it’s just such a huge cultural change. Frankly the budgeting lifecycle does not support anything other than trying to define the requirements for a given system,” said O’Connell. “Traditionally, they know the pain associated with trying to change downstream, because it costs so very much. Although we may be able to deliver more rapid procurement, they have felt the pain of needing to change applications downstream, and not having a contract that allowed for them to go back and do that in a cost effective way, let alone the technology.”

Solution Number Two: Start thinking future first compliant

• “Future First is really taking a look at what we are delivering, what we’re developing, what we’re planning, and planning for the future, not just planning for today,” said O’Connell. “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.”

‘We’re still seeing today procurements that are for federal IT programs that don’t include mobility because the policies may not be quite in place, stamped and sealed out of each given organization,” said O’Connell. “Yet we know that mobility is here to stay and that the future of information technology is going to be delivered on mobile devices. Agencies now have procurement lifecycles that are going to go purchase something that will be out of date before it’s even delivered.”

Solution Number Three: 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,” said O’Connell. “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.”

Solution Number Four: Understand lifecycle and cost of ownership

• “Cost lifecycles needs to change. I think Van Roekel has said although people say you don’t, you can’t do more with less, you do less with less. He actually said no, we actually need to do more with less. We need to be more efficient with our dollars spent in information technology,” said O’Connell. Understanding the lifecycle cost and the incredible increase of operations and maintenance across these huge portfolios of large federal applications, whether large ERP systems or custom coded applications that take just as much to change as they do to build it in the first place. You can start driving yourself towards these agile modern technologies that allow you to change quickly, with less dollars, less time, and have a greater chance of success too, because you’re delivering incrementally. Again, going back to that agile method of having the constituents as active participants and seeing value throughout the delivery of that lifecycle software. And of what we’ve seen in a number of large federal programs taking on this more modern application view, up to 50 to 80% reductions in operations and maintenance cost. That’s real cost savings that then can be applied to more innovative technologies modernization in order to provide greater service to con—to agency’s constituents.”

How much of this do we need legislative change for?

“I think legislation obviously helps push it forward. We have such a large acquisition staff across the federal government, and they are undermanned. It’s hard to move a vast organization across many different agencies,” said O’Connell. Legislation can always help, but there are best practices associated with taking a look at what is going to occur for Future First. And collaborating with the Information Technology departments. It’s also dependent on them to collaborate with that acquisition workforce, and then, you know, think through a true lifecycle cost of the program, and what’s associated with that. We have lessons learned that can be applied to the best practices and implementation of our current procurement lifecycle, and it just hasn’t been done on large scale. And I think the dollars being shrunk in each agency are going to help provide some impetus to go implement some of those best practices, and some of it’s going to be on the backs of the people in the system that know what needs to happen, and try to apply them to their daily jobs until, you know, legislation or other directives come down across the federal environment,” said O’Connell.