IT Project Failure: Can We Blame the Techies?
By Carol A Long
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 behaviors 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 organizations 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 workforce 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 organization 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 organizations 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!
© 2011 Carol A Long, All Rights Reserved
Carol A Long is Principal Consultant of Three Triangles Performance Ltd (www.3Triangles.co.uk) based in England providing programme and project management consulting and interim management. Carol specialises in the corporate governance aspects of project management, improving project management practices in organisations, and turnarounds of challenged business critical change and transformation programmes. She has written parts of the international project management standards for professional bodies in USA and Europe. Before founding 3Triangles in 2006, Carol had 21 years experience with multinational organisations in software development, quality improvement and management, and coaching project and programme managers. You can follow Carol on twitter.