Design anti-patterns: Which Pot of Money?

This is one of the most pernicious problems in organizations. Decision making is often twisted by a single question that stakeholders apply to possible solutions: which pot of money is this coming out of?

To illustrate: I worked on a program to implement desktop applications in the call center of a financial services organization. One business was handed a large pot of money with these words: "Spend this pot of money for your call center. You can run as many projects as you like, but after the pot is empty you must pay for new projects from your own budget. The IT department is at your disposal. Defects or routine maintenance that are required after the applications go in comes from their budget."

The business unit, naturally, wanted to get the maximum amount of functionality onto the desktop as they could before the pot of money was empty, so they opened new projects as fast as they could write the statements of work--at one point the projects kept 15 project managers busy. The B.U. whipped the IT project managers to get the applications released as quickly as possible, secure in the knowledge that money to fix defects wouldn't come out of their budget, but the IT department's. Many PMs were happy to comply, since their performance was evaluated in part based on the number of projects they completed. Post production, requests for new functionality were disguised as "defects" and "routine maintenance," and handed to an overworked non-project service area within IT to implement. It was chaotic.

Of course, there were other considerations the B.U. had for getting applications released quickly. There was a schedule by which it was supposed to earn a profit, for example, and it needed the functionality on the CSRs desktop in order to deliver service to customers. In fact, that was a regular reason given for needing projects done so quickly. But the Which Pot of Money consideration was always there, like an unacknowledged whale shark in a swimming pool.