IT projects: Don't slip up on technology
Mismanaged IT projects can lead to major problems but firms can make life a lot easier by following a few simple rules.
Investment in IT is, generally, a good thing. Thanks to IT advances, executives from the CEO down should have a clear vision of what is happening in their organization.
However, there is no denying that the onward march of IT has also been littered with disasters. Typically, the bigger the project, the bigger the disaster has often been.
Where projects go wrong
Steve Rumble, UK Lead Partner, Technology Risk Assurance at BDO, argued that, not surprisingly, where many projects go wrong is right at the start.
"The key to the success or failure of an IT project is how you obtain your view of the business requirements the project is designed to fulfil. Most organisations simply do not do this bit very well," he said.
The first mistake is for senior management to fudge the issue and leave it to the systems integrator to lead the solution on their behalf, while they sign off on decisions on a 'hit and hope' basis.
"When you abrogate responsibility for defining the scope of the project you end up with three likely consequences," said Steve.
- You start to find that the system is not fit for purpose.
- Costs can escalate because the project starts to loop back on itself.
- The project becomes a long-running cash drain due to constantly adjusting the system to make it fit for purpose.
Three simple rules to avoid these issues
1 - Control the scope
Jonathan Tate, Technology Consulting Leader at PwC, pointed out that whereas 20 years ago IT projects frequently failed because the IT systems themselves were not up to the job, that class of failure is very rare today.
"When you see IT systems falling over today, it is generally because they are predicated on elderly systems that were always clunky and that are now failing and bringing everything down with them," he said.
For Jonathan, most of the failures in IT projects today can be boiled down to two main causes.
- Failing to control the scope of the project
- Starting with a package-based approach which needs to be adapted to conform to the organisation’s way of working
Even if you get the specifications right upfront, continuous control of the project is still absolutely vital. You do not want requirements being added at the whim of end users," he said. Organisations should think long and hard before they move away from the 'out of the box' approach.
"There are huge benefits to be had in changing your way of working to fit the system, rather than the other way around. But companies generally end up convincing themselves that they are special, so they modify the system and then they run into endless difficulties with updates, which are no longer supported by the supplier.”
Costing the project properly
Frank Cooper, MD of Cooper Software, warned that all too often when a project is perceived to be a failure, it is because management failed to cost the project properly from the outset.
"In any major IT project, the internal and external costs are going to be significant. If you do not face up to this from the outset and quantify it reasonably well, things can get out of hand very quickly," he said.
There has to be a strong hand behind the project internally, so that it is not just the technical experts dictating to end-users.
The other crucial area where projects go wrong has to do with systems testing. Every new module needs to be thoroughly tested before the organisation goes live with it. Moreover, testing needs to start early in the process and not be left till the end.
"Much can be done to manage change by testing the applications through the development stage, with feedback from end-users, so everyone’s expectations are aligned, and there is a continuing sense that the system is going to be fit for purpose."
This is particularly true of outputs from the system. Reports should be tested and put into the hands of end users as soon as possible.
2 - Take it one step at a time
George Strathie, Software and Services Director at Castle Computer Services, said that rapid prototyping development strategies are a great way for organisations to 'tease out' what they want from a system when they are starting a new project and the required outputs are proving tricky to define.
Moreover, he said that there is much less likelihood of projects failing spectacularly these days since the whole industry has moved away from 'big bang' systems projects, where the whole system goes live on a set day, to phased implementations.
"When you break a project down into phases not only do you get the chance to prove each phase, but the client starts getting value from the system a lot earlier in the development process," he said. A more iterative approach is often a much better solution for the client.
No substitute for properly scoping the project from the beginning
"The most common failure experienced from IT projects is that they do not deliver on expectations. So the more tightly you can define the requirements and the scope of the project at the outset, the better."
However, George does not agree that changing requirements mid-way into the project is always a bad thing. Business is a dynamic process, and when the world changes the business has to flex with it, he said. What both sides need is a process for handling and costing changes according to a framework that is agreed at the start of the project.
Tom O’Hara, CEO at consultants KickICT, argued that because IT is now a necessity for most businesses and is a key driver in employee productivity, it really does repay organisations to put time and effort into defining in detail what they want from any project in this area.
"You need to invest in an IT roadmap which sets out your business requirements for the next three to five years. Plus, businesses need to put in the time to select IT providers who have the skills to help them fulfil that roadmap," he said.
As Tom explained: "If your next information and communications technology [ICT] project is driven by 'we like the look of this' or the 'latest fad' or worse, your IT provider at the latest sales meeting announces 'have I got a new product for you', as opposed to investing in the next stage of your ICT roadmap – stop!
"ICT is increasingly interrelated and interdependent. The 'brilliant app' you saw might work alongside your email, anti-virus/spam, Office and so on today but will it work when you automatically update to the latest version of software? Probably not."
Tom added that integrated IT is preferable to "islands of technology", but warned: "These ICT technologies will continually evolve – just think of the number of app updates you see on your iPhone. The key question regarding a 'bespoke' approach is, therefore: is it in your roadmap and will it be able to function in your desired integrated ICT environment in three to five years, and potentially beyond?"
3 - Avoid legal tangles
Paul Carlyle partner at Shepherd & Wedderburn noteed that clients are now disposed to accept the vendor's standard terms in many instances, creating much less work for IT lawyers.
"In the 1990s IT projects were considered to be very specialist affairs and there were a group of lawyers who were seen as having the specialist legal knowledge required to put the contract together to keep both sides on track.
"Now vendor terms and conditions are the starting point for contracts and it is only where the systems are absolutely mission critical, as in major financial services systems, that lawyers get involved in any depth," he said.
Paul argued that companies should, wherever possible, change their ways to suit the vendor's package. With the number of regulatory changes taking place, having a system that the vendor can update could save time and trouble.
One common IT project blunder that crops up quite a bit, he said, is a failure to define a proper exit strategy with the vendor. "You do not want to find, when you decide to test the market again after eight to ten years, that your vendor can hold you to ransom."
All these issues are symptoms of a failure to think through all the requirements involved in what is usually a complex and costly project. Proper planning prevents poor performance, and laziness or haziness at the outset will rack up costs later down the road.