Satyam – its bucket of woe already overflowing – faced further anguish last week with the revelations that its Oracle deployment at the World Health Organisation is going badly awry.

But it's not the only one to have suffered the slings and arrows of enterprise resource planning deployments.

Take US jeweller Shane & Co. It's 2005 rollout of SAP went so badly off kilter that it was cited as one of two chief factors in the 24 per cent drop in sales that led to it filing for bankruptcy in January this year.

I cite these two cases solely because they've been in the news recently. Over the years ERP horror stories have been legion. Indeed it has become almost accepted that ERP implementations are going to be protracted, painful affairs. So why do organisations persist with them?

Well for one, there aren't exactly an abundance of compelling alternatives. And that creates a dilemma for the IT leader: they are likely to have to guide their organisation through a risky project, where there reputation is on the line. Those stakes are pretty high.

So it might be pertinent to think about how we can go about minimising the risks on that project.

I was recently reading a piece in the Harvard Business Review, looking at why good leaders make bad decisions. I think the conclusions are relevant here.

The report's authors suggest that there are three red flag markers that indicate problems may be ahead. These are: conflicts of interest; attachments to people, places, or things; and the reliance on previous experiences which seem relevant but actually are not.

It's not hard to see how each of these issues can manifest itself during the course of an ERP implementation. But what can be done about it?

The HBR piece proposes three general solutions to flawed decision making: injecting fresh experience or analysis into project teams; introducing further debates or more challenges to the thinking; and finally imposing stronger governance.

None of these steps appear to be that revolutionary. But how often is fresh thinking introduced in to large IT projects? Isn't it more common to rely solely on previous doctrine of how things should be done?