Weigh your Costs

Cost-Benefit (C-B) analysis used to be one of the major tools of system analysis. Unfortunately, it seems to have fallen by the wayside. Many IS managers these days make no attempt to quantify the benefits or enumerate the full costs associated with a project. Recently, I came across two separate situations where IT departments had initiated big projects without proper analysis. What’s interesting about these cases is the results that a thorough C-B analysis yields.

The first case concerns a multinational recruiting globally from India. The MNC in question (let’s call it XYZ Corp) has interests spread all over Asia, and has a heterogeneous work force. A couple of years ago, the top management woke up to the solid talent available in the Indian job market. Hiring from India became a top priority and a special cell was set up for the purpose. This cell used Executive Search consultants to find suitable people. The chain normally went like this–a vacancy (planned or unplanned) would arise, the special cell would be informed, it would develop the requirements for the post and turn these over to the Executive Search consultants. The consultants would prepare a shortlist of candidates and send it to the company. The company would then interview the candidates and appoint suitable ones.

The system worked well, and it was at this point that someone in the cell got a brilliant idea. Why waste money on consultants? We can easily process the applications ourselves. After all, people are eager to work for us. We’ll just advertise the post, key in the applications into a database and run a few simple queries on the database to generate a shortlist. What’s more, having a permanent databank of potential employees will be an added advantage. Nice and simple, isn’t it?

Implementation turned out to be anything but simple. Coding the unstructured data in a typical resume turned out to be an absolute nightmare. In many cases, it was easier to process the resume manually rather than code it. Data entry was a bigger nightmare. The project manager had calculated data entry times correctly, but completely forgot to factor in validation times. Throughputs were about one-fourth of what had been assumed. Costs mounted, while the actual recruitment process suffered because of lack of timely processing. A proposal for having candidates apply over the Net in a structured form was shot down, because it was felt that not enough senior executives are comfortable with the Net.

The fact of the matter was that the basic premise of the project was wrong. Consultants were actually far cheaper than doing the job in-house. A thorough C-B analysis would have revealed this much earlier, but some were in too much of a hurry to get the project going.

The second case concerns Electronic Data Interchange (EDI). A leading corporate with operations all over the country decided to use EDI to have sales and stock information available on a real-time basis. At the time of making the decision, the company was using a system of couriers to transfer zip disks full of data on a bimonthly basis. The company was doing well, a hefty IT budget was approved, and a new IT manager appointed. The new IT manager attended an EDI seminar and got hooked onto the idea. A service provider was located, software redesigned, and after months of cost and effort it was possible to move transaction data into the company in real time.

And then the fun started. The availability of real-time data had no impact whatsoever on the operations of the company. Why was this? Simply because the company operated in an industry where 90 percent of the shipments took place in the last week of the month. So the real-time data-feed up to the twenty-third of the month contained no real information. Sales closing was done in the first week of the next month and continuous data feed provided no real improvement over the disk couriered at the end of the month.



How could such a blunder have occurred? Part of the reason was that the new IT manager had no experience of this industry. And the non- IT managers were simply too busy to think about the project in detail. A thorough C-B analysis would again have revealed the basic flaw at the outset.





The bottom line Fools rush in where angels fear to tread. Sadly, this is true of far too many IT projects.