The Rapids

Our state, like many governmental bureaucracies, struggles with technology. Vermont may have a relatively tiny population, but it exists in the 21st century, and needs systems to support its operations and serve its people. What's troubling is the price tags and implementation difficulties that have come along in the last decade rival what you might expect with stereotypical, large government boondoggles. In 2015, Vermont Public Radio tried to report what the state spends on technology; the result was, essentially, they couldn't. (http://digital.vpr.net/post/huge-money-small-oversight-state-it-spending-vermont)

The situation is sad (and maddening for taxpayers), but not at all unusual. The State is just one example of an organization floundering to manage information technology. And, like many nonprofits, technology is not part of its mission; it's a tool that should enable achievement of mission.

On March 1st, Green River's CEO Michael Knapp was asked by Representative Laura Sibilia to present to the Vermont Joint Committees on Energy and Technology and Government Operations regarding state IT. Green River has worked with municipalities, state governments, and federal agencies, but hardly ever served our own state. Based in the world we operate daily in, Michael made a pitch to reform procurement, and move, like so much of technology industry today, to a more agile processes.

A couple years ago, Vermont issued an RFP for implementing a system to manage professional state licensure. We initially jumped - it was something we could easily deliver and support, for a client that is literally our backyard. But then we started reading, and realized the state was dictating a process guaranteed to be expensive, large, and painful. Outside of agreeing to explicit staffing configurations and reams of contract language, we were asked to directly address in the proposal 838 specific requirements.

So we walked away shaking our heads. Sure, we could deliver a system that met every requirement. Probably for less effort than responding to the RFP (well, okay, maybe not quite). But to present a system so tightly specified in a vacuum, without any provision for iterative design and improvement, was guaranteed to result in disparity between theoretical design and actual need. And hence, cost overruns. (The contract ended up going to a large, multi-national corporation for a significant amount of money.)

The alternative? Update procurement procedures! Michael suggested:

• Describe the problem the system needs to solve, and then let an agile vendor guide the solution process.
• Focus selection criteria on the capacity to get the job done well.
• Prioritize the vendor's commitment to departmental mission (e.g. school improvement, public health, environmental protection).
• Structure contracts to support an agile process.