After five years of extraordinary growth, consultant Atkins had become so big that nobody really understood the whole business. So in a bid to create a coherent structure, its new chief executive introduced a centralised accounting program – and a year later its shares were almost worthless. The question is, was it really the fault of the software?
three weeks ago, building published A league table of the largest 200 consultants by number of staff employed. In the commentary that accompanied the table, we mentioned some disadvantages of being big. These included the complexity of co-ordinating lots of divisions, the gargantuan task of periodically restructuring them all – and the constant danger of a spectacular crash if management makes an ill-advised or unlucky decision.

We didn't know it at the time, but the company at the top of the table would soon exemplify all of those problems.

Atkins, arguably the most successful consultant in the UK, was going through a period of extraordinary growth: turnover had more than trebled in five years. Much of this expansion had come through a policy of acquisition and diversification, and it was acknowledged by Atkins' management that it had had the side-effect of making the business extraordinarily difficult to understand, even for them.

The firm had also taken on Robin Southwell, a former BAE manager with a background in marketing, as chief executive. He had been given the job of creating coherence in all those subsidiary businesses so that they provided a comprehensive service for their markets. "We need to simplify matters so that we all understand what [Atkins] stands for," Southwell told Building shortly after taking on the job.

Fifteen months later, matters became very simple indeed. Atkins' shares hit the bottom after four months in freefall, Southwell left along with 400 colleagues, and chairman and acting chief executive Mike Jeffries had a choice between selling the firm, dismembering it or taking it private.

If this wasn't a sufficiently astonishing turn of event, Atkins had another surprise in store: it put much of the blame for its troubles on a computer software package. More precisely, the company said trading conditions had been difficult, but that an increase in debt of £73m since the end of March could be traced to problems with its accounting system. So was this a terrible warning that apparently friendly technology can suddenly turn round and blow your head off? Or was Atkins blaming its tools for wider-reaching management failure?

Surprise package
In June 2001, Atkins announced that its UK business was to be centralised at a "shared service facility" in Worcester, to be in operation by January 2002. In theory, this should have given the company some of the desired focus. The idea was to bring together the whole of the company's payroll, human resources and financial management systems, along with the 350 staff who would run them.

Southwell was effusive about the centre: "This will give us significant competitive advantages as well as improving the delivery of core services as the group grows," he said at the time. "The shared service facility will be a centre of excellence, leading the field in the supply of support services and sharing the benefits of our experience with our clients."

At the same time as this new structure was being set up, the company adopted an accounting program called OneWorld, supplied by software house JD Edwards. Edwards confirms that it sold the package to Atkins, but that it was not asked for training or support. It adds that Atkins engaged a non-accredited third-party consultant against its advice.

Employees complained that after OneWorld was installed, expenses and overtime payments were being delayed by up to six months. This sounds irritating enough, but the implication is that if staff could not put expenses or timesheets into the system, the company did not know what to charge its clients and so could not issue invoices. And when a company should be invoicing £3m a day and isn't, it doesn't take a genius to understand that disaster is just around the corner.

"People didn't know whether to bill clients and there were cash flow problems," says a source at Atkins. "Cash flow went down at first, but it was meant to come back up after nine months – and it didn't."

The strategy of centralisation had spectacularly backfired. Instead of pulling together the scattered Atkins empire, it had ensured that every bit of it was affected by the failure of the central departments.

What went wrong?
A number of factors seem to have played a part in the debacle – Atkins has declined to comment on any of the specific issues raised here.

First, OneWorld is a complex package to configure. JD Edwards belongs to a family of systems called ERP – short for enterprise, resource and planning. These integrate all the facets of a business, including planning, manufacturing, marketing and sales, to improve business efficiency. To implement an ERP solution, companies are faced with a choice of going through a hugely complex and expensive process of adapting the software to fit their business model or alternatively changing their business model to fit the software. This is a process that costs millions of pounds and can take years to successfully implement.

Second, the installation of the package was done at the same time as staff were being moved to the Worcester shared service facility. "This is a ferociously ambitious project to carry out at the same time as trying to move; it would stress any organisation," an industry source says.

Third, Atkins adopted a "big bang" strategy. In other words it did away with its old system after it adopted the new one, rather than running the two in tandem. And it moved the whole of the Worcester facility to OneWorld at the same time, rather than rolling out the new system progressively, so that difficulties could be sorted out in a controlled manner. Running two systems together can be expensive, but it does mean that problems can be contained.

A fourth factor was that the company seems to have failed to prepare adequately for a big bang solution. Not only were there the technical hiccups that go with a new system, but staff had not fully learned how to use it. David Taffs, IT director at Arup, says that installing such a system is necessarily complicated. "Always start with the assumption that the IT isn't going to work, then you are unlikely to be wrong-footed," he says. And he should know: Arup uses OneWorld too. But in Arup's case it was carefully evaluated and introduced incrementally.

"People start off thinking it's simple but find they have to define all the tiny details, a million and one things you normally take for granted," says Taffs, who has not reported any problems with the system so far.

All of the above are conducive to a possible fifth factor. Philip Youell, regional managing partner for southern England at QS EC Harris, warns that firms can get so bogged down with the process of adopting a system, especially if that adoption is problematic, that they can be distracted from their wider business.

"Trying to implement the system is very, very resource-hungry; you become internalised rather than facing the market," he says.

The lessons
The prevailing view in the industry seems to be that the buck stops with Atkins' bosses. One senior IT manager in the construction industry says the problems with changing software systems are well understood. "There are a number of known strategic approaches. Which is taken is a business decision, not an IT decision. You need to be guided by what the client wants and then deliver it."

Blaming IT people or the package for any problems with a new system can be tempting for senior managers. But often this is not where the problem lies. The IT manager says: "The fact it was allowed to fail so dramatically suggests a business failure. Either the IT voice was not heard at a high level or its opinions were disregarded. In our industry, IT does not get a seat at the top table."

Still, even if we allow the business failure theory, was Atkins simply expecting too much of a centralised IT system? Youell has had experience of extending an IT system to recent purchases, most notably when EC Harris acquired Citex's Asian operation. His opinion is that getting a single IT system to fit Atkins' business model was almost impossible, given the extent to which it had diversified and the number of businesses that were recent purchases. "It's possible they'd taken on too big a task in trying to implement a single centre where the organisations are very new; they may have had a clash of cultures," he says. "It's very difficult to do if a collection of organisations has come together. The number of problems that that can cause is immense."

According to Taffs – speaking generally – once a system of this size and complexity goes wrong, the problem can take on a frightening momentum. 'When you have a mega-sized system, getting any sense out of the vendor is impossible," he says. He says all systems have bugs, but some have more profound effects than others and can corrupt data downloaded onto the system. Eradicating the bugs is not always easy, particularly if a system has gone live and vast amounts of data are been downloaded daily.

The typical response is to issue a "patch", an additional piece of software that is designed to fix any problems encountered by the client. If the user then complains, the vendor typically says it can't do anything unless the patch is installed. The vendor may then issue a new version of the software. This can take weeks to install, and if it's trying to fix a fundamental problem, it still won't work. "That's why you do it bit by bit, so the vendor can cope with it," says Taffs.

The final lesson to be learned from Atkins experience is that businesses need some kind of safety net: in this case, some way of recovering debts. Industry observers are incredulous that managers did not employ temporary staff to process invoices manually. "What are they invoicing daily – £3m? You have to be red hot when it comes to invoicing," says an IT source. "The business of recovering those fees could have been done using a manual system comparatively cheaply – compared with the losses."

Why Atkins did not do this is a mystery. And a bigger mystery is why Atkins did not seek to mitigate the effects of the bad news on the City. A bewildered IT source says: "Why didn't they put this into their annual report earlier on and warn the City? They dropped it like a bombshell and the city panicked and dumped all their shares."

Don’t make the same mistake once

Consultant Parsons Brinckerhoff has undergone several large-scale IT system upgrades in the UK in the last few years. IT director Joanne Stanford shares her tips for ensuring IT projects run smoothly from beginning to end.
  • Define your business requirements
    It is vital to evaluate the business process to identify where an IT upgrade will bring benefits. It’s possible that business processes need reviewing rather than the IT system. Remember: bad business processes mapped to a good IT system will result in failure.
  • Produce a functional specification
    This document should formally identify the business processes and act as a brief for the IT consultant. It tells the consultant what it should design to satisfy business requirements. Identify stakeholders and champions within the business who are best placed to assess the tenders and work with the chosen developers throughout the design, test and implementation phases.
  • Clarify the tender
    Identify clear prequalifying parameters – including financial viability, how much help the consultant will give while the system is installed, and the extent of its technical back-up once it is running.
  • Design the implementation
    Define all stages of the project from beginning to end. Make sure that the project objectives, scope, cost and approach are thoroughly understood and agreed on with all stakeholders. Topics to consider are: How to make sure everyone in the team knows what is going on. How the new system will be integrated with the existing system. How to map your business processes onto the new system. Who will be responsible for delivering which parts of the system. Risk assessments to check that your business will not be affected by the transition. Planning how the new system is to be rolled out across the company. Working out the training programme and how to get end users to accept the benefits of the new system. Clearly defining the project timescale and milestones. Agreeing stakeholder sign-off for each milestone
  • Test the system
    The system must be thoroughly tested to ensure that it delivers what it is supposed to, and that it is technically robust before being rolled out across the business. Establish who is to test the new systems. Always run the tests in parallel with existing systems. Analyse the outputs from the new system. Agree the criteria for success or failure for both business and technical elements. Allow plenty of time for reassessment, redesign and retesting where necessary.
  • Implement carefully
    Follow the roll-out programme identified at the design stage. The programme’s champions should actively promote the benefits of the new system to encourage take-up. Implement a training programme. Measure the outputs to establish whether the new system is successful in delivering improved quality and delivery of business objectives. Establish that the new system is delivering improved customer satisfaction. Ensure that there is adequate support throughout implementation and beyond.
  • Decommission the old system gradually
    Only decommission the old system once the new system is proven to deliver all the project objectives in a robust manner. Bear in mind access may be needed to historical data for some time if it is not transferred onto the new system.
  • Always remember …
    Satisfying business needs must always be the highest priority – if this is not achieved, the project has failed.