How to put together a successful IT system
Spectacular failures of large IT projects are well documented. Anthony Harrington flicks the switch on putting together a system that works, is cost-effective and delivered on time
Large IT projects have a horrendous reputation for coming in late and over budget, often massively so, while at the same time failing to deliver the functionality that users were expecting. The track record of a number of major government IT projects, such as the NHS records project, is eye-wateringly bad. So, what can be done to improve the chances of a reasonable outcome?
Sarah Pumfrett, audit director for business risk assurance at Johnston Carmichael, argues that there are just three things that can go wrong with any project, and three things that you have to get right. This trio of wrongs and rights applies to all major projects, whether it is an IT project, a major piece of capital expenditure, or a corporate acquisition.
“The three things that can go wrong are: a) it breaks the budget; b) it isn’t delivered on time; and c) it doesn’t deliver what was expected of it,” Sarah says.
Having had to do forensic work on dozens of failed projects, Sarah reckons that the causes of failure always come down to inadequate governance, inadequate assurance and poor risk management. So, these are the three things that have to be done right, from the conception of the project through to its conclusion.
“These three factors, governance, assurance and risk management, are a hierarchy, starting with governance. If you define governance correctly, then, by definition, you have to specify what you mean by assurance, or in other words what the milestones will be that indicate to the governance team that the project is on track,” Sarah notes. “The how and why of assurance are all about risk management,” she says. How much has been spent to date, by comparison with what has been delivered? And does it look fit for purpose?
Accounting for "human nature"
When things go wrong in major projects it very often comes down to human factors, Sarah points out. A common theme is the project team falling behind and not wanting the risk management team or the governance team to know that things are slipping. So the assurance provided is rigged. Often this is done in the hope that the project team will get everything back on track before management even knows there is a problem.
“What you find is that people are being told what they expected to hear and not what is actually happening. By the time the gap between fiction and fact becomes too wide to conceal, it is already too late to rescope the project and get it back on track within anything resembling the original budget and time constraints,” she notes.
The main thing I would stress to any business contemplating a substantial IT project is to ensure they have openness and honesty in the procurement process
There is nothing deliberately criminal or fraudulent about this. It is just “human nature” at work, and this is one of the factors risk managers need to have front and centre when they are working out or agreeing assurance milestones. They need to know how to distinguish real progress from smoke and mirrors, and they need to be able to hold their ground and not get baffled by techno-speak.
Two other “human factors” that can doom a project from the outset are: a) the belief that a project will not get sanctioned if those responsible for giving it the green light were told honestly at the start what the real cost was likely to be, and b) the standard practice of calling for competing tenders.
The former can mean that the project is under-specified, and that the client will have to let the budget slip if they want the project to be delivered in a usable form. The second ensures that whichever supplier wins the contract will be on such a tight margin they will be motivated to treat any deviation from the initial specification as an opportunity to recoup some profit. It also, of course, encourages vague or deliberate under-specifying of the project so that costs can seem more acceptable.
Managing for success
Despite the many ways in which IT projects can fail, they can also go well, if properly managed from the outset. Steven Gant, a partner in EY’s advisory practice says: “There have been a lot of lessons learned by government. Suppliers have been invited to Public Accounts Committee sessions [in the House of Commons] so that their views on how things should be done can be considered. There is now a lot more maturity in the contracting organisations in government.
“There is now a good balance between ensuring that the taxpayer is not asked to pay an unreasonable price, and getting evidence from the outset that the supplier has the capability and the skills required to deliver a high-quality outcome,” he notes.
Lessons learned also include ensuring the technical capabilities of the supplier and being clear, from the start, about what is required for the project to progress in a collaborative fashion with the departments involved.
If you are trying to save money, but at the same time in effect betting your business’s reputation and fate on the IT project being successful, then you probably have a conflict that needs to be resolved at the outset, not halfway through the project
“The main thing I would stress to any business contemplating a substantial IT project is to ensure they have openness and honesty in the procurement process,” says Steven. Instead of sealed bids, with perhaps a single presentation from each supplier bidding for the contract, most big IT projects now go through a technical dialogue process. “This gives the supplier a much greater opportunity to engage with and understand the business and the challenges it is facing, along with the business’s capabilities to work with the supplier through the life of the project.”
Ron Weatherup, managing director at the IT systems and support house Lugo IT, points out that part of the problem is that IT systems – even relatively modest ones – have so many facets to them that it is actually very difficult to do a really good scoping job on them. “Often there are so many people who ‘own’ little corners of the project that it is very difficult to get your hands around the thing at the outset. You need someone from the user organisation who is, unequivocally, the person responsible for the project. This is hard to achieve, since being the person responsible is often seen as a massive career risk,” he notes.
Dave Anderson, a partner in the corporate commercial team at HBJ Gateley, says it is critically important to align an IT project’s cost-saving goals with its strategic goals. "You need to know where to place the emphasis. If you are trying to save money, but at the same time in effect betting your business’s reputation and fate on the IT project being successful, then you probably have a conflict that needs to be resolved at the outset, not halfway through the project,” he warns.
Another problem can occur when an IT project is designed to replace a number of staff. If you do not interact with the people whose jobs are going to be automated, you’re probably going to fail to scope the project correctly. But if you try to deal with the staff, you are going to run into massive hostility.
“You can try to address this kind of difficulty with a proper governance regime in the contract, that has clearly defined milestones so you can see the project is on track as it unfolds,” Dave advises.
The bottom line is that IT projects are difficult. Success has to be worked for and even then it cannot be guaranteed, but honesty on all sides and a proper governance, assurance and risk control process are indispensable.