IT Project failure: can we blame the techies?

The business commentators have noticed: IT is not giving most businesses the benefits they claim IT should.   The projects themselves bring change that the businesses and their people aren’t handling properly.  IT projects lock wasteful practices into new systems. The dream and the promises have been broken.

It is so easy to throw stones at IT people.

Businesses ask a lot.

First, the software developer has to be an expert detail-focused techie who takes direction. Then they need to be IT guys that talk to people and understand what they are not saying but really mean.  Those are two behaviours at the opposite ends of the personality preference scales: only rare people who can be both.

The users the IT guys may be able to talk to are probably ingrained in “this is the way we do it here” without understanding why. (Thank you “Just do it” and “Can Do attitude” managers.)  They don’t know if the constraints are real or “just the way we do it here (because that is the way Nellie taught us)” or if there is a control in the system that was needed for a defunct business governance process.

The managers, of course, want the projects done as cheap and fast as possible with as little disruption to normal work (IT time spent with the users) as possible.  Can they fit the IT Guy into their schedule to explain? Probably not in the time needed.  Will they pay a few more dollars for good people who work twice as fast to better quality? No.

But one constraint is a plainly silly: the boss doesn’t allow the IT guys the opportunity to ask “why” when they say “we need SAP” or “we need a CRM”. It takes a brave techie to ask what the business problem is  – especially as IT doesn’t get a seat on the board in some organisations and is not perceived as being capable of understanding the business.

The problem is as fundamental as this: IT is expected to do as it is told as cheaply as possible. Managers, because they use IT and know the business, think they are best placed to find the solutions and decide we will do X for this project – and they’ll decide on high level ideas not workface detail.  If the delivery is given to a supplier, they are even further away from the real business goals (there is probably a good reason not to share that with a supplier) and they have their own business imperatives: to make the customer feel they are getting their own way (they make money doing it).

Most IT people want to do a great job. They love the potential for the technology to make things better. They want to make the system they are building deliver the benefits.  Why are projects such a problem? A recurring explanation is “We’d be fine if only the users could explain what they want!” or “we delivered what the boss told us but now they say we got it wrong”.

There is a real need to look closely at what the organisation does, design a new way of working, train the people in the new systems and explain what must be achieved. If we make sure the people doing the work understand the “what” and “why” they are there to do, the IT people can find the best tools for the “how”.  Agile methods were designed to bring everyone together to solve these problems but that hasn’t worked well for everyone.

Most organisations aren’t places where people are  used to trusting each other: you might find yourself out of work. That needs to change so we can collaborate towards useful solutions. Giving the users and IT information about the business processes and needs also gives them responsibility to make them more effective and efficient: that’s our way forward.

No, we can’t blame the techies. We can’t blame the users. We can understand why the managers think the way they do. 

The system for developing system is broken.  The simple projects it was designed to deal with are not a reality today. Now is the time to reconsider how we do projects and educate people about the systems they work in and the IT systems they are creating. Each action has consequences in an IT project and can unintentionally stop value being gained.

Behaviour change and system thinking awareness all round!


About 3triangles
Helping organisations make change happen in 3 key areas: strategic change, deliver tactical impacts, efficient and effective processes. All blog content (c) 2009 - 2012 Carol Long and Three Triangles Performance Ltd

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: