,

Big Government IT is Dead. Long Live Big Government IT

Non-government staff execute on the vast majority of government information technology (IT) projects. No biggie, right? After all, IT services government contractors are a dime a dozen. At the Ffederal-level alone, close to $10B of contracts are issued each year to support pure IT projects. This excludes broadly defined contracts which include IT support as part of the overall scope. Indeed, the federal government spends north of $80B on IT each year.

The reasons government tends to outsource IT is multi-fold and beyond the scope of this post. However, there is no reason to believe this structural dynamic will change over the next 10-20 years. The majority of IT – especially net new development – will continue to be outsourced to contractors. If anything, the dearth of skilled IT workers overall and the growing disparity between private and public compensation for developers and other technical resources will exacerbate this reality. Government will struggle to hire the required staff to execute against mission objectives.

So…what’s a government IT manager to do? Blow open the doors to our agencies, get out of the way, and let the private sector experts do their thing, right? Not quite.

Unfortunately, the majority of IT initiatives (defined as $10M+ in labor costs) in government fail. The Brookings Institute states that 93%+ of major IT projects fail. That is, less than 7% succeed. As taxpayers, let’s pause 7 seconds to truly appreciate that dismal record. Perhaps more surprising is that this abysmal track record is readily accepted. It has gotten to the point that a prior Defense Acquisition Performance Assessment Report described underperforming government projects as the “conspiracy of hope.” Yikes. So much for outsourcing bigly…

Given this dire (read embarrassing) reality, government agencies should consider changes to how they buy, what they buy, and how they manage IT projects. Specifically, government buyers, program staff, and IT managers should embrace 5 intertwined ideas for improving the landscape for big IT projects. The good news is that there are pockets of government – Federal, state, and local – that are already doing many of these ideas. Overtime and with a little effort, perhaps government IT becomes a little less big.

#1. It’s Time to Break Up Big IT

One of the leading issues with executing IT projects at scale is that they are simply too big. Not “too big to fail”. They are too big to succeed.

As the size of a project increases, so does the likelihood that it will go over budget, exceed the planned schedule, or fail to proceed as planned because of unpredictable hurdles. “Big bang” IT projects are a relic of the past. The ability to predict what is needed years in advance of the system being ready for use is nearly impossible. The world changes. Technology changes. Policies change. People change.

Instead, government should adopt agile principles and go small. Luckily many governments are. Iterative deployment, minimal viable product, and continuous deployment fundamentally alter the definition of project scope and schedule without sacrificing impact. Instead of waiting years for capabilities, government now expects working functionality within weeks or months.

In parallel, the emphasis during vendor selection should be less on cost and more on “time to value” or how quickly an agency can actually use the IT solution in question. If a vendor fails to deliver, the government should be able to hit the eject button quickly – fail fast(er).

The days of massive, monolithic $100M+ procurements should be coming to an end. It must. Of course, it is given that running a government procurement is not cheap. As such, issuing more, smaller contracts will mean more work for contracting staff. More on how to mitigate this pressure below. Assuming contract teams don’t revolt, the fundamental question is this: isn’t it worth the extra effort to do it right?

#2. Date a Little Before Getting Married

The rigid procedures and strict protocols around government procurement are meant to prevent fraud and abuse. All of that is logical and appropriate. If government can’t ensure fair competition, who can?

But at some point, we must ask the question: “at what cost?” While most agencies do conduct market research, issue request for information (RFIs), and some meet with vendors, it often seems like far greater energy and effort goes into the construction of a procurement instead of the research and planning beforehand.

Let’s look at an analog. Imagine you need to buy a new laptop or television. How many hours of online research do you do? Be honest! Let’s say your average hourly “rate” is $50. What percent of the total purchase did you spend upfront thinking about what you wanted, evaluating options, deciding on must-have features, etc.? If you are like most consumers, you probably invested a non-trivial amount. Why should government IT be any different? You can afford a little diligence for a television that millions of citizens will watch.

The goods news is that some government buyers are investing more up-front to improve the downstream outcomes. There is a growing emergence of reverse industry days and vendor one-on-one meetings. Go beyond paper-based submissions to actual conversations and discussions. These are steps in the right direction.

Before investing tens of millions of dollars, government should take time (and money) to think. Truly decipher what is needed, define what success looks like, and forecast how downside risk can be mitigated. As Albert Einstein once said, “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”

#3. Show Me, Don’t Tell Me

A continuation of the deeper, richer vendor engagement and planning exercises advocated for above is the (near) elimination of paper proposals. Instead of having vendors produce reams of paper proposals, government should shift (almost) exclusively to demonstrations and challenges. Again, the good news is that many governments are already taking this approach.

Instead of awarding 8 or 9 figure contracts based on words on a page, they invite vendors to show real, working capabilities. Building on idea #2 above, no more paper-driven arranged marriages. Asking vendors to demonstrate specific capabilities in an existing solution or through a real-time challenge is a far better proxy for the actual project work than the fancy diagrams and charts provided in a proposal.

Of course, the underlying implication of this approach is that much of the research cost that was once borne by the government is now shifted to the vendor community. It is not cheap to run a challenge team or to create a prototype for demonstration.  The cost of developers and engineers is higher than that of proposal managers. The duration of the development effort is also likely longer than the proposal window.

Ultimately, for this model to be sustainable, this higher cost of sales will be recouped one way or the other. The market can sort that out. In the interim, government evaluators will see and receive tangible output instead of rosy language that is divorced from value.

#4. Actually, You Aren’t Special

One of the many challenges of government IT is that every office, bureau, agency, and department believes that their business processes, functional requirements, and technical needs are unique. This drives up the reliance on custom coding, proprietary approaches, and fast aging solutions. Instead of leveraging off-the-shelf capabilities and platform-based solutions, government regularly opts for custom solutions. This is a recipe for project disaster.

Government should demonstrate a willingness to sacrifice certain needs, loosen some requirements, and embrace the boundaries of platforms and existing products. This shift in mentality will have a profound impact. Not only will it accelerate the time to value (see above) but it will also reduce the complexity and cost associated with maintaining the solution once deployed. Custom solutions are not only expensive to design, build, and deploy but quite costly to maintain over time. They age quickly and must be regularly modernized.

Indeed, the exorbitant amount of funding that is spent on maintaining IT deserves a blog topic of its own. Gartner reported that 60-80% of IT budgets were spent on simply “keeping the lights on.” That’s a terrible waste of money. The operations and maintenance associated with legacy systems handcuff CIOs and program managers from innovating and keeping pace with a changing world around them.

Low code platforms and commercially available products are the future of IT. Instead of starting from scratch, government should assess whether they can get a 70%-80% solution off the street. Think Pareto Principle (80-20) for IT. Starting that much closer to the finish line undoubtedly changes the likelihood of success. It also fundamentally changes the topography and characterization of ongoing O&M.

#5. Show Me the… Value?

Once government solves for the preponderance of IT failures by embracing some of the guidance above, it can and should look beyond. Government should examine the operational value of the IT solution vis-à-vis status quo. Value should be the language through which IT is evaluated. Indeed, the value of a working system needs to be about more than simply a working system. Not all systems are the same.

To continually improve how government buys and deploys IT, future solutions must more explicitly demonstrate value. Cost savings are just one value metric. Operational improvements are another. The next generation of government IT should magically / automatically capture baseline performance metrics. That’s step one. Once we have a baseline, those same systems should track improvement to the extent possible.

For example, a new collaboration software should provide an estimate of the amount of meeting time saved by staff. Or the number of emails eliminated when compared to the prior month. A new case management system should capture the efficiency gains from business process automation. Or the reduction in manual data entry related errors. The cost of IT would be balanced with operational gains.

To transform how IT is bought and deployed, the return on IT investment needs to become a standard criterion. This concept relates to the burgeoning field of Technology Business Management (TBM). TBM – which is widely used in the private sector – is a methodology used by IT organizations to communicate the value of IT to business stakeholders. It merges the views of the three principal stakeholders – finance, IT, and business – into an aggregated view of the value of technology.

TBM is a broader concept and fortunately becoming a common arrow in most CIO’s quivers. A narrower and much harder starting point along the journey is to unify how disparate parties view the operational benefits of IT. T

Big government IT is broken and (slowly) dying. Too many projects cost too much and don’t actually deliver for the American people. In the face of greater budgetary pressure and higher citizen expectations, government buyers, program staff, and IT managers must change their approach. From start to finish, transformation is needed. Change begins with procurement, but extends to vendor selection, includes the actual execution approach, and even the eventual solution defining parameters. The root causes of the problem with government IT aren’t singular.

There are many ways to move the industry forward. The concepts explored as part of this post are only a start. The good news is that none of the ideas presented herein are revolutionary. Nor are the many tactics being tried by progressive IT leaders across government. Indeed, many of them are small, simple, and are already being implemented by governments – Federal, state, and local. Long live “big” government IT.

Wagish Bhartiya is a GovLoop Featured Contributor. He is a Senior Director at REI Systems where he leads the company’s Software-as-a-Service Business Unit. He created and is responsible for leading a team of more than 100 staff focused on applying software technologies to improve how government operates. Wagish leads a broad-based team that includes product development, R&D, project delivery, and customer success across State, local, Federal, and international government customers. Wagish is a regular contributor to a number of government-centric publications and has been on numerous government IT-related television programs including The Bridge which airs on WJLA-Channel 7. You can read his posts here.

Leave a Comment

Leave a comment

Leave a Reply