Advice Centre

When IT projects go bad

So far this year I have witnessed the spectacular failure of three mid-sized accounting systems. All three projects were relatively straightforward installations or upgrades of well known products, but failure still happened and the costs ran into many tens of thousands of pounds.

Yet each project failure may have been largely prevented had the circumstances been different.

A project can be thought of as a unique series of interdependent events which will only ever happen once – otherwise it would be called a “routine”. It is this uniqueness, along with constraints upon time, money and people – that makes the outcome of any project uncertain.

IT projects take things a stage further – you face a greater degree of uncertainty as hardware and (in particular) software might only be fully tested once the entire system is in situ. Furthermore, in real-life IT projects – a lack of technical skills on the part of the customer and a lack of good project management skills on the part of the supplier(s) is often the kiss of death.

This, however, doesn’t prevent customers with over ambitious plans coming together with suppliers all too eager to sell their wares... The end result is usually the same – the minima for a successful outcome (such as a clearly agreed and nailed-down specification, project plans, a budget, or even any evidence that a key component or system might actually work) are often missing or hazy at inception. In my experience, these are often replaced by generous amounts of optimism from both parties and the genuine belief that “miracles do happen”. Yeah, right!

Rule one - There is no such thing as the “Project Fairy”

IT projects don’t fail because of some mysterious malevolent force – they fail because nobody bothered to check whether the TCP/IP stack would be compatible with the customer’s installed operating system, or some other equally baffling technical reason. Equally, it wasn’t the “Project Fairy” which ensured that things were working on the Monday morning after the weekend upgrade – it was the team of people working until 10pm the night before!

Projects are not driven by wishful thinking and good intentions – successes and failures only happen because they are made or allowed to happen. Often, failure is either designed in right at the beginning, or at some point along the way.

• A successful project only happens when that project is clearly defined and is allowed to exist within a suitably controlled environment.
• The starting point is the appointment of a suitably senior and technically competent Project Manager who will seek to understand both the commercial and technical issues within the project, and be prepared to act upon those issues in a technically rigorous and disciplined manner. Ideally that Project Manager is a full time employee of the customer.

Rule two – Project Management is Risk Management

So, you’ve been handed the mantle of your company’s biggest IT project to date – now what do you do? Well, first of all – don’t panic!

One of your key roles is risk management, so your objectives are (i) identifying any risks or uncertainties, (ii) managing those risks and (iii) reviewing (i) and (ii) on a regular basis.

Sounds simple – well in theory it is, however many Project Managers lack the crucial technical skills. For example, whilst a good Project Manager might not have to be able to write software, they will need to know enough about software development to spot when things are not right (e.g. too little time / money / resources allocated to a particular task, or that a key component is, as yet, untested).

“Show stoppers” need to be identified early and dealt with before you commit to the larger project and have spent all your money. Leaving long foreseen problems to fester in the hope that it will be “all right on the night” will not work (see rule 1).

• The Project Manager should establish issues and areas of concern or uncertainty at all levels of the business and from all suppliers as early as possible.
• Issues and uncertainties need to be dealt with head on – even if that means investing more money early on to check them out (e.g. building a pilot system to prove an untried technology).
• Spending money EARLY may seem counter intuitive for the accountants, but will be a tiny fraction of the cost of the final project if it moves to failure, and probably won’t increase the overall price of the project if it’s a success. This is a well-established practice.

Rule three – It’s all about communication

Communication skills are the order of the day – both in the upwards direction (with the board) and the downwards direction (with the people at the “coal face”)

• Human nature typically prevents both buyer and supplier(s) from discussing “bad news” or “failure” – most project meetings I attend involve everyone agreeing “things are going really well” – even though they clearly are not!
• Often, people have a vested interest in keeping quiet – particularly when it’s their project that’s under discussion. Successful project meetings are no place for pride or politics!
• A good Project Manager will be able to extract bad news from anyone on the project team (or indeed elsewhere in the business) and communicate those concerns appropriately – typically in these matters EQ (Emotional Quotient) is just as important as IQ (Intelligence Quotient).

Rule four – Plans are nothing; Planning is everything (Eisenhower)

It is important to distinguish between the process of planning and the plan itself; it’s all too easy to get lost in the depths of Microsoft Project or Primavera, and a pile of pretty Gantt and PERT charts.

• Charts and diagrams are merely an interpretation of the real world – like an underground map. I have yet to find the symbol on Microsoft Project captioned “and then a miracle happens” – but I think it would add a useful degree of realism to a great many projects!
• It is the planning process which adds the greatest value to your project – understanding how different parts of the project inter-relate, and which components are critical to the constraints of time, money and people.
• Even if no part of your project ever goes “to plan”, if you have taken the trouble to plan, you will instantly know how far out you were, and most importantly understand the impact on the rest of the project.

Rule five – You can’t delegate accountability

There seems to be a natural tendency amongst buyers these days to automatically assume that accountability is in the sole hands of the supplier. I believe that this is largely due to a lack of internal IT skills, resulting in a greater dependence on external competencies, which may not actually exist!

Even where in-house IT staff are available, they may lack the required commercial or communication skills, and hence be excluded from the project team, or there may be political reasons to exclude an IT team that are always seen to hinder rather than help change.

The trouble is, suppliers have not gone unscathed over the last few years, and I have seen an increasing number of projects fail because resellers or authors have lacked the right staff – especially developers and project managers. Even those that do have the right staff may have little “slack”, and may have to call upon contractors whilst they “hedge their bets” on a recovery in the marketplace. There is therefore no better time to practice supplier due diligence!

• Your choice of supplier(s) will naturally have a huge impact on the outcome of your project. Treat supplier selection as rigorously as you would carry out a job interview – and expect to meet (and interrogate) the very people you will be working with, not just the front-line salesperson.
• Check that the supplier has all of the relevant skills in-house needed to complete the work – an over-reliance on contractors (particularly in more senior roles) can result in a dangerous discontinuity of care.
• Check that the technical staff feel as comfortable with the proposed project as the salesperson does. In my experience, salespeople love to sell the impossible to the over-ambitious, so ask to see evidence that the supplier has indeed done something like this before. Check out reference sites, speak to other customers, do all the necessary background checks. If things don’t check out, be prepared to either change the project specification to something which the supplier can produce “off the shelf” or find another supplier.
• Once the project is underway, remember that accountability remains with you, the customer

Be prepared to work together on the project to make it the success it deserves to be rather than taking a back seat and hoping for the best.

Stewart Twynham is a Director of Bawden Quinn Associates Ltd, and has spent the last 15 years running IT systems in end users from ICI through to AIM listed enterprises. Stewart is a member of the British Computer Society.

(c) 2004, Bawden Quinn Associates Ltd