Evolution in Action

I ran across a blog by Matt Asay [Link] about the IT blunder of the Public Company Accounting Oversight Board in acquiring a document management system. The paean here is that open source is a better choice  than proprietary and Matt lays a good logical  basis of argument.

Sadly its largely irrelevant. The problem is that Matt, like most folks, doesn’t understand government and  how it makes IT decisions.  Instead he sees  a waste of $3M as a BIG bad thing.  I see it as a  small bad thing.

Until a few years ago if a government agency or office wanted a document management system, they would go out and hire someone to survey the requirements, assess the problem, and write code. Maybe they would even pay for some support after the coding but since that smelled a lot like personal servitude it probably wouldn’t happen courtesy of the  attorneys and procurers.

The only requirements that were considered were those of management, and the structure of the data was always simplified to what the programmers wanted it to be rather than what law, regulation, and business practice dictated was how it had to be done and how the government folks who handled the data actually did. Herein lies the demise of most of these systems.

If the system replaced an existing one, this usually boded a bit better for success than if it was an initiative. Regardless, it soon emerged that the data workers did no more than they absolutely had to with the system. If they used the system interactively to accomplish their work then it was usually a moderate success. If its only function was to provide summary reports to management, no amount of coercion would suffice to make it practicable. Hence something like 0.75 of such systems were abandoned, either actually or effectively, within three years of inauguration. Bottom line, organization worse off than before and a lot more than $3M down the hole.

This actually got better when networked PCs first came about, largely because IT had not been centralized as an economy of scale. As a result, each work area had to know something about IT and when some overambitious manager decided to generate his next promotion by introducing some information automation, one of two things happened. The first was that he did like folks had done before, hired a contractor to turn his requirements into code and write code. The result was that he usually got a black eye because the information savvy work areas put his Rube Goldberg to rest even faster. The second was the manager put representatives of his work areas to the task of overseeing the design of the code and then there was a product they had bought into and hence it limped along for a few years.

Then IT became centralized and decided it had to dumb down the users to make its job easy. The result was that the IT folks replaced the contractor in developing the requirements and assessing the problem. Little or no attention was paid to the users because they’re ignorant and just drones anyway, at least in those IT shops that don’t engage with their users as customers (or at least consumers if you favor the cat food model.) The IT went out and surveyed the commercial software and picked the best and installed. They might even hire the software contractor to do this. In many agencies this would have to be competitive, so it was a case of letting creative marketing guys in the companies tell you how great their software met your requirements and how much cheaper it was than anyone else’s.

Of, and open source? Forget it. There are laws and regulations that the Yankee government cannot use unpaid for software.


One thought on “Evolution in Action

  1. Great response. You’re right – my understanding of how government IT purchases is anemic. Getting better all the time, however, as I have customers (like Army, FAA, etc.) that are teaching me that “rational” isn’t always how things work. Thanks for reading/commenting.

Comments are closed.