I'm not sure if this is the result of a high-priced government contractor boondoggle. The U.S. judiciary isn't a monolithic entity. Each circuit, each district, and even each judge have a great deal of autonomy, and administrative matters are completely decentralized. There's not even a single uniform website for the various courts. Compare the page for the eastern district of Pennsylvania (http://www.paed.uscourts.gov) with the page for the northern district of Illinois (http://www.ilnd.uscourts.gov) and the 7th circuit (http://www.ca7.uscourts.gov). The only thing they all share is the domain!

What it looks like to me is the usual scenario in decentralized organizations. Different pieces adopted systems as the need for them arose, and various systems were layered on top over that over the years to try and achieve some uniformity in certain areas.

I wonder if there is anyway to electronically disintermediate the process by which someone wins a government software contract. There much be some way to make discovering contracts easy, quick and cheap and make the process to apply and build those projects super simply. Basically a startup needs to democratize access to these projects so you only need to be only an expert software developer and not a expert government bureaucrat to understand the process to win these contracts.

The system is there. They publish bids out with requirements then there is a process that companies go through to get that contract. So it is better but it is often just the motions, it provide official deniability "see the paper/electronic trail show it was an open and fair bid process".

What often happens behind the scenes is that requirements are written to a specific software product that is already effectively pre-determined. Like let's say it is a complicated inventory tracking system, out of 50 or so requirement points, every one basically matching the system that L3 provides without naming L3. Stuff like that.

It is vital to do behind the scenes networking, hiring insiders, that needs to happen besides also having someone full time that knows how to jump through the "official" red tape.

You should read a few call-for-proposals, it's pretty enlightening. What I learned (hopefully this differs from place to place) is that they write them in such a way that only huge, dishonest shops can respond, by making the requirements huge and contradictory. An honest shop can't call out the contradictions and get the work because "fully satisfying" the requirements is necessary to be accepted. A small shop can't afford the time and expense to respond with a proposal. In both cases you need to build in enough overhead to cover the countless hours spent arguing about the featureset and to afford the lawyers when the litigation comes a few years down the road.

I don't think the government means to lock out small vendors. It's just that bureaucracy tends to generate bloated and inefficient systems like this, in which the only part of the contract the vendor can afford to skimp on is the implementation itself (and not the lawyers, negotiators, managers, etc.) The people who work for the government want good, working systems, they're just prevented from choosing vendors who can produce them because using common sense is not sufficiently bureaucratic.

You might find this of interest:

http://www.thinkcomputer.com/corporate/whitepapers/restassur...

Except that it's near impossible to have a 'small and agile' team that interfaces with a government contract in any way. You need at least one person to just sit in meetings, at least one architect to draw up powerpoint charts that people will buy into, a project manager, a change order coordinator, and an accounts payable/receivable type person to do battle with getting the government to pay you (it is a full time job). On top of that, you need to have had experience doing government work in the past with good recommendations (for which many smaller shops pair up with bigger shops to act as prime contractors, which inflates the price enormously), and you need to have an ITIL or CMMI (depending on the customer) to make sure that all those processes are being followed.

In addition to the two or three people you need to actually do the work, you need a head count of at least 6 more just to manage customer expectations.

Yes, yes. Good point. Agile in this domain means about 10 people. It is huge compared to a start-up but when compared to L3 or Lockheed it is a _very_ small team.

And you are right, meeting, trade shows, filling out red tape, security audits all those need full time position to be handled.