It's heartening to see some new approaches government IT actually getting high level support to make a positive impact. Funnily enough I see someone I used to work with in one of the pictures.
Hopefully this will lead to more substantive change to how government IT is done. It's great to have teams that can drop into problem areas with a clear mandate to get things moving, but the whole system needs some serious reforms so that these IT quagmires don't get created in the first place.
This article heaps a lot of blame on contractors but fact of the matter is, contractors are often hamstrung by what the customer wants them to do and what the customer allows them to do. And some of that comes back to what was specified in the original contract.
Ultimately there are multiple components to the abysmal state of government IT projects:
* The government has moved to a model where very few full time employees are technical people. The idea is that almost all IT will be outsourced to the private sector
* Because fewer and fewer FTE's are technical, procurement and project management decision-making is compromised.
* There is little accountability for government employees, and by extension, contractors. Botched projects where millions of dollars are waste rarely have major career consequences for FTE's, and the bigger contracting companies don't have their ability to get new contracts affected at all.
* Building software for government often involves arduous interpretation of regulations, trying to build to undocumented and byzantine business processes, or waiting an inordinate amount of time for the bureaucracy to make important decisions (then change their mind!).
I feel like empowering the technical people is a very important first step, and getting them executive backing may create the momentum needed to change some of the common pitfalls. But I think there are some big changes that have to happen to the whole ecosystem to really get things to where they need to be.
It's all well and good to give small teams exceptional power to get around the bureaucracy but that approach doesn't fix the underlying problems.
Disclosure: I'm an engineer at USDS and these are my own opinions.
You make a great point - USDS is just one part of the solution. In fact, in almost all of the USDS projects, we work very closely with agency employees and contractors (many of which are just as talented and have chosen to serve their country). Most of the times, I spend very little time hands-on-keyboard and helping empower the existing team.
As for the longer term solution, there is a less publicized version of what folks are doing. USDS has a number of contracting officers who are helping teach others in government how to be savvy customers of technology. 18F and GSA have been doing a lot on this front as well to help bring in really good contractors and writing agile purchasing agreements. The Office of Federal CIO is rewriting and simplifying tech policy and the Office of Federal Procurement Policy has been working on the procurement side. These are the long term changes that I'm personally excited about.
That is great news, I think engaging and training COR's across government could yield some real improvements to how these projects go.
I'm personally seeing some 18F projects come down the pipe that are truly innovative and hopefully will encourage organizations to think differently about IT procurement. Still a lot of silly stuff out there but at least the ship is starting to change heading.
The contractors are hamstrung by their own business model. I'm sure a lot of the people on the ground are trying to do a good job, but when you're got a set-in-stone spec negotiated by people 4 levels of reporting away from the actual work in the trenches.. yeah that's probably not going to be a spec to do the right thing.
Whether they're contracted or government employees, we need to devolve authority from big top-down specs and towards programmers working alongside the actual users.
The problem is that the contractor doesn't write the RFP or the final contract, the customer does. So if you want that money you sign on the dotted line and hope for the best.
Within the contract there is often flexibility as to how the job gets done. But bottom line is that if you have a stubborn customer who insists on doing things the hard/stupid way, there's not a lot you can do. Maybe you go above their head and try to force a change but that is fraught with risk. The prudent thing to do from a financial standpoint is just put your head down and complete the contract, even if the work is compromised because of the customer you're dealing with. And indeed, that's what happens a lot of the time.
Fortunately more and more parts of government are buying into the agile mindset but there's still a lot of outdated thinking out there.
> But bottom line is that if you have a stubborn customer who insists on doing things the hard/stupid way, there's not a lot you can do.
This is something most people who have never dealt with the US government don't understand, thus they put all the blame on the contractors. Many groups within the government are the epitome of the "customer from hell". They hire you to do a job, to build a product, but think that they (and their experts) know better how to do it than you. Essentially, all they want is a body shop to implement their design. This is not what most commercial outfits, particularly SV-type companies, are used to.
In addition to providing technical expertise on the customer side which is hugely helpful, there is also a program from 18F focused on digital acquisition that is helping change the way technology RFPs are written that I think will have a huge downstream impact for any group trying to win the work (internal, or otherwise). The better the customer understands the value and roadmap of the work and can put that into words, the better the outcomes will be: https://18f.gsa.gov/tags/digital-acquisition-accelerator/
The contractors are hamstrung by being contractors. Because the contracting process is adversarial, and geared around a fixed objective against which fixed lowest bids can be made, the kind of iterative development which produces great results is ruled out.
Hopefully this will lead to more substantive change to how government IT is done. It's great to have teams that can drop into problem areas with a clear mandate to get things moving, but the whole system needs some serious reforms so that these IT quagmires don't get created in the first place.
This article heaps a lot of blame on contractors but fact of the matter is, contractors are often hamstrung by what the customer wants them to do and what the customer allows them to do. And some of that comes back to what was specified in the original contract.
Ultimately there are multiple components to the abysmal state of government IT projects:
* The government has moved to a model where very few full time employees are technical people. The idea is that almost all IT will be outsourced to the private sector
* Because fewer and fewer FTE's are technical, procurement and project management decision-making is compromised.
* There is little accountability for government employees, and by extension, contractors. Botched projects where millions of dollars are waste rarely have major career consequences for FTE's, and the bigger contracting companies don't have their ability to get new contracts affected at all.
* Building software for government often involves arduous interpretation of regulations, trying to build to undocumented and byzantine business processes, or waiting an inordinate amount of time for the bureaucracy to make important decisions (then change their mind!).
I feel like empowering the technical people is a very important first step, and getting them executive backing may create the momentum needed to change some of the common pitfalls. But I think there are some big changes that have to happen to the whole ecosystem to really get things to where they need to be.
It's all well and good to give small teams exceptional power to get around the bureaucracy but that approach doesn't fix the underlying problems.