Companies adopt various policies and schemes to reduce costs and control the administration of software projects. In the mid-90s when I worked at a major corporation, they implemented a management model called “software as an in-house vendor.” It was a system that sounded better on paper than it was in reality. Users would draft a software request and submit the draft to their superior who, if they approved it, would submit the request to their superior. The request would be passed up the chain until it was sent to the head of the development department for a price quote. If the quote was approved by the requesting user group, the request was sent to the development team. The purpose of this system was to itemize each item of software development, and bill the cost of each item to the budget of the department requesting it. It didn’t take long for problems to develop.
The first issue to develop is the obvious one: the increase of bureaucracy. With the requirement to document/approve every step of the process, even things as simple as adding a single field or column to a report could take weeks or months. In many cases, things simply didn’t get done; users hated filling out extra paperwork, executives hated dealing with minutiae, and department heads hated having to pay out of their budgets for services that had previously been free (to their department, at least). Additionally, department heads became alarmed at these new costs and often attempted to avoid them by using more expensive manual procedures whose cost could be buried in the department budget (and in some cases justify increasing the department’s budget and staff).
The bureaucracy also had the effect of separating the dedicated development teams from their user community. Previously, developers and users had worked closely to create the applications used by the company, but with layers of management between the two communities, miscommunication became the norm. Both developers and users became increasingly frustrated with the process, and more importantly, with their jobs within the company.
One of the most unexpected effects was black market development. After long association, development teams had become professionally vested in their user community; ways were quickly found to skirt the bureaucratic process as low level managers looked the other way when developers quietly met with users to develop small projects. Naturally, this completely undermined the model: there was no management of development costs whatsoever. Users and developers maintained a friendly relationship and both directed their frustration towards management.
Treating the development department as an in-house vendor was a costly failure. The easiest way to deal with a cumbersome system is to simply not use it; at my previous employer the users simply gave up trying to improve the existing system and begrudgingly worked with a poorly performing system that often made their jobs more difficult. Despite the work that needed to be done, developers were left with a decreasing number of approved tasks, which lead upper management to the erroneous conclusion that the development department was over-staffed. Overall costs continued to increase, while productivity decreased. This type of failure is common when management implements the latest popular theoretical model in a one size fits all approach.