% fortune -ae paul murphy

Ethics? what's that gonna cost me?

It seems to me that IT fraud comes in two main forms: those perpetrated for money or power, and involving failures to act ethically.

The first kind are generally easier to spot and deal with. Consider, for example, these three illustrations of different kinds of buyer fraud:

1. One billion dollar company I did work for had gone to market three times for an ERP/SCM suite. In each case the same individual wrote the RFP and chaired the selection committee, and in each case they selected companies owned by at least some of the same people but operating under different name plates.

   In each case senior management announced a desire to procure a "world class" packaged solution, but each process led them to a combination of source code licensing and internal, Wintel, development with the assistance of "consultants" from the winning partner.

   Neither the internal auditors nor the Big four external auditor brought in to review the inevitable failures found anything wrong with the RFP process. So what did he do?

   Simple: he allowed each credible vendor to believe that it had won his confidence to the point that he had given it an improper advantage by talking too much about what his committee really wanted to see in the winning bid. As a result the non IT people on the decision committee saw proposals from companies including SAP and Oracle as wildly inappropriate to their needs -and, indeed as utterly incompetent and unprofessional money grabs.

2. One large organization I did work for had (and may still have) an unstated requirement: proven loyalty to the One Right Way - i.e. to data processing ideas and IBM.

   Their enforcement strategy was simple: the public RFP process had both a drop dead component and a failsafe: the drop dead component was that bids outside the range set by plus or minus 15% of the average of credible current bids or winning bids on comparable previous RFPs, could be discarded unread - and the failsafe gave about 30% of the points awarded during evaluations to the review committee's judgement on proposal (i.e. staffing) credibility.

3. Another large IT organization I worked with routinely issued requests for proposal describing complete projects, but restricting the scope of the bid to tiny parts of the workflow - describing, for example, a project to custom build an HR system, but restricting the actual bid to defining and coding the direct deposit process. The record didn't show a lot of preference for one bidder: in fact the numbers showed that project budgets were reasonably well distributed between $20 and $40K, with the group accounting for better than 98% of total billings actually only winning about one bid in five.

   How? Scope change orders awarded on a cost plus basis - done in plain view of the auditors and everyone else on the grounds that the tiny contracts were trials and only this company's people generally earned the right to continue working to bring million dollar projects to completion.

So what are the patterns, and what data do you need to see if there's cause for concern?

The first kind is trivial for IT people to detect - provided we have the vendor proposals and the RFP documents. Basically, if you have a fairly tight RFP but vendor proposals are all over the ballpark, you get to ask why - and the greater the divergence, the more likely it is that someone's been lying to bidders.

The second type is equally easy to spot - but almost impossible to defeat because the practices involved are easy to defend; and especially so to non technical bureaucrats and politicians. Just imagine, for example, yourself explaining to a defensive, technically ignorant, senior manager that the 15% rule means no one offering a two week, $10K, Perl based solution can compete against a big firm offering a three year COBOL, SDM/70, process.

The third type is easy to spot - but try to prove to a senior executive who doesn't want to hear about computers - they never work anyway, right?- that the people who got kicked out after completing pilot projects are actually no less capable than the people who didn't.

In fact the latter two cases illustrate the practical definition of market hegemony: everybody knows it's fraud, but nobody can do anything about it.

Ethical frauds, i.e. frauds perpetrated by failing to act when you should, are harder to spot, harder to categorise, and hardest of all to be sure about - because the "right" action can be far from obvious, especially if your paycheck is on the line.

Some, of course, are easy to deal with: imagine yourself in a situation where your specialist knowledge combines with your job to give you inside information about a continuing fraud being perpetrated by your boss. Pretty clear what you should do, right?

But most are not that simple. Consider these examples:

1. An audit firm with which you have a long term relationship sends you a client who wants someone to write the RFP for a big development project. Several meetings later you know that the audit partner involved has enthusiastically blessed the project but the client lacks the resources to pull it off - plus there's a perfectly adequate commercial package which neither the client manager you're dealing with nor the audit partner want to hear about.

2. You've been hired to review IT operations at a large government department experiencing 40% annual turnover among its 200+ IT staff. You're told in advance that your recommendations will be critical in bringing order to chaos before the department proceeds with a hundred million dollar key application re-development and deployment. The CIO tells you right up front that his CTO is sleeping with the guy who sold them their last disaster; the CTO tells you that the CIO is a drunk fronting for the reigning hardware vendor; the development manager has zero project experience; Systems and users exist in perfect contempt of each other; and you accidently discover that the assistant deputy minister who hired you has a hidden business relationship with the international job shopping firm widely, but inexplicably, considered most likely to win the contract.

3. You're a sysadmin/DBA working for an integrator hired to help get a large ERP/SCM system implemented. The project is far behind schedule and you soon discover why: the network is continually on the edge of failure; the database server is absurdly under powered relative to the requirement while an adequate machine sits unused; there is no rollback and recovery capability for the test system; users are publically denigrated by key IT staff, the people assigned to the project are the people with the least applicable skills; and forty plus people come to daily progress meetings.

In each case the problem is clear, but your ethical obligations are not. So what do you do? Refuse the work? ignore the issue and just do what you're told? step outside your own chain of authority to raise the issue with top management?

I've been in all six situations -and got all six wrong. So what would you have done?