I’m going to use an incident from my past to illustrate why bad business decisions drive IT people crazy. And if you work in IT and you don’t get involved in business decisions then you should – this example will show you why. This is possibly the single worst business decision I have personally been involved with in my entire IT career.
I’ve never been involved in some massive multinational company where the decisions involved billions of dollars and affected thousands of people. This story also isn’t about the collapse of a company. It might not be as sexy as some stories but it does highlight a typical, fundamental disconnect that occurs all too often between business and IT. Or between business and any sort of rationality and common sense. Some of the identifying elements have been changed to protect the guilty but the core aspects of the decision as I’m going to relate it are true.
I was working in a large logistics company that leased a large range of assets to companies all over the country. Everything from furniture to computers to vehicles were managed via the corporate leasing system. When leases expired on the assets (after 6 months to 3 years) my company took them back and usually sold them via auction (through 3rd party auction houses) to recoup the residual value. Each year, tens of millions of dollars worth of stock was sold this way. Here’s a tip: find out how end-of-lease merchandise is sold in your town – you can save a fortune buying this way.
I was the analyst on the development of an IT system to handle these auction transactions. The existing process was paper based – a list of inventory was distributed, auction houses nominated what items they wanted to sell, the items in question were delivered to the auction houses, they were sold at auction, the auction house took a commission and paid my company the remainder of the sale price.
I was given some high-level business requirements (essentially revolving around tracking and reporting on progress of the transactions) and had to develop some detailed specifications that the programmers could use to develop the system. A key part of the development cycle was that a pilot was going to be run with the single biggest auction house. This one outlet handled about 40% of all our inventory and the remainder was split among about 10 other auction houses. If the software worked with the big outlet, it would then be rolled out to the others.
Upon analysing the rather sketchy Business Requirements document (filled mostly with ill-defined jargon and waffling), one half-sentence stood out as essentially being the whole requirement for the project. After transactions were processed “an exception report is required.” This made sense – tens of millions of dollars in inventory was going out to external parties every year. It would be nice if you knew the sales they were reporting matched what you had sent them to sell.
I spent some time with the primary business user (who was much more switched on than the bodgy BR document suggested – it turns out he had very little to do with its creation.) He agreed that identifying any discrepancies between the items we sent out and the items reported as sold was the single most important requirement. After some discussion we identified a way to track discrepancies far more accurately than simply “we sent you something to sell and you didn’t give us any money for it.”
Because my company bought and sold such huge volumes we had a very detailed cost history in a database. We could say quite accurately what something should be worth new, after one year, after two years and so on. The system could be programmed to check sale prices against historical averages and if the deviation was too big (say, more than 20%) you could follow up with the auction house to find out why they’d sold it for such a low price. The whole thing could be managed much more efficiently because instead of having to check every transaction, the business user would only have to check out of the ordinary sales that triggered the exception rule.
So we had an elegant solution that wasn’t particularly difficult to implement. I was feeling pretty good. I submitted the specification to my manager for approval. And received a rather unexpected response:
Manager: “We don’t need to check the dollar amounts they report.”
Me: “Why not?”
Manager: “We trust them to get the numbers right.”
Remember, this was for transactions worth tens of millions if not hundreds of millions every year. My manager was suggesting the amount of oversight required for external parties handling these transactions was zero. I was stunned. I thought maybe I hadn’t explained the solution clearly.
Me: “We’re not talking about manual checking of figures. We already have all the information required to automate this sales audit. We can make the threshold as generous as you like – maybe a 25% deviation. Maybe only apply the check to transactions worth more than $10,000. If they never get the number wrong then nothing will ever happen – we’ll only be notified if a transaction looks wrong.”
Manager: “We trust them so there’s no need to check the figures.”
Me: “What exactly do we trust them to do? Do we trust them to never, ever make a mistake when they enter a value? Do we trust them to never dishonestly manipulate the auction and sell our stuff to a friend of theirs for far less than its fair value? Do we trust them to never falsely report a low sales price and pocket the difference?”
Manager: “Of course, that’s exactly what we trust them to do.”
Me: “That’s crazy!” (note to self: stop telling business people their ideas are crazy) “You trust every single person that works for that company? You trust people who might work there in the future, people we’ve never met? And even if you trust our major partner, this will be rolled out to a dozen other companies. Do you trust everyone who works for them and everyone who will ever work for them?”
Manager: “I’ve answered your question, stop trying to make things more complicated than they need to be.”
Me: “I’ve already talked to the programmers and this check is relatively trivial to put in place. Maybe two days of programming and testing. It won’t affect our overall delivery schedule and it will result in a much better system.”
Manager: “We don’t need to use even those two days because we trust them.”
Me: “So you’re going to consciously put into place a system that would allow massive errors to pass through undetected. A system that would allow large scale fraud to go undetected. When there’s a really simple solution already defined?”
Manager: “Yes. It isn’t required because we trust our partners.”
I think it would have hurt my head less to bash it against an actual brick wall rather than to continue to butt up against this figurative one. Here’s why business decisions like this make IT people so angry: it’s illogical, it allows bad data to enter the systems and it’s easily solvable. And here’s why IT people should care about decisions like this: you just know when the inevitable happens and some huge amount of money goes astray, IT are going to be blamed for building a system that “allowed” it to happen.
So what did I do? I circulated an email to everyone who could possibly be affected that this decision had been made. I made it clear that it was possible to have this check in place but it had been declared unnecessary. I included the same information in the specification. And at the first opportunity I found a job somewhere else because I wasn’t going to be subjected to that lunacy if I could avoid it.
Any suggestion that I took a job processing payments at one of the auction houses is unfounded conjecture. The fact that I have an early retirement planned at an offshore tax haven where I have a secret bank account is purely coincidental.
Angry 365 Days a Year 