When an IT project goes wrong, the client's first impulse is often to assume the supplier is at fault. But BPG has been involved in many situations where this is not the case. If a supplier's new system does not work exactly how you'd like, it's not always correct to assume the system has been "oversold" or the supplier doesn't know what they're doing.

Blame could lie on either, or even on both, sides. But for this issue of the IT Risk Management Newsletter, we'd like to talk through a case study that focuses on client mistakes, to demonstrate how they can be avoided.

In the study, the client, AMarketCo, is a new media marketing company. The supplier, ABespokeCo, is a bespoke developer specialising in complex applications based on databases.

AMarketCo and ABespokeCo had a long-standing relationship. As AMarketCo's expertise is mainly design, in the past it had hired ABespokeCo several times to develop the more complex elements of Web applications it wanted to offer to clients.

When this study begins, ABespokeCo was halfway through building a large application to run a music site designed by AMarketCo. However, AMarketCo was secretly unhappy with ABespokeCo's work and paid an independent consultant to look at the plan for the web site to "come up with some better ideas".

The consultant did, of course, suggesting a design and function remarkably similar to that of a web site the consultant had already built for a different music site.

However, beyond offering high-level guidance, the consultant did not evaluate how difficult that system would be to build from scratch - only saying that it would take him, using already developed software, "about a week to build".

That offer sounded attractive to AMarketCo. They were being squeezed by the music site owner to put the site up as fast as possible. ABespokeCo's development was expected to take at least another two weeks and would, in addition, end with what AMarketCo felt was an unsatisfactory design.

But because the two groups had a long relationship, AMarketCo did not just want to take the work away from ABespokeCo. So AMarketCo gave the consultant's specification to ABespokeCo and asked how long it would take to build.

ABespokeCo, unsurprisingly, went ballistic. Work on the project halted as the two companies argued about whether it was reasonable for AMarketCo to change almost all its requirements midway through a project.

Eventually a compromise was reached and the project struggled through to completion. But relationships had been shattered, there was resentment on both sides, and the system that was finally built was not as strong as either the consultant's plans or those originally agreed by AMarketCo and ABespokeCo.

How did it all go wrong? If we focus only on what the client has done wrong, we find that AMarketCo has made three major mistakes:

No feedback .
Despite being so dissatisfied with ABespokeCo's work that it paid an independent consultant to come up with an alternative specification, AMarketCo had never actually told ABespokeCo it was unhappy. ABespokeCo had no incentive to improve its service and provide, as AMarketCo wanted, "more ideas".

In fact, so little feedback had been given that the developer thought AMarketCo wanted it to be only a technical partner - to not offer an opinion unless that was specifically requested. A pity, as ABespokeCo knew the site it was building was far from ideally designed.

Major requirements change .
Clients, especially those who have limited IT management experience, tend to have to learn the hard way that software is difficult to build. Or that more importantly, it is difficult to change the way a piece of software should perform once work has already started on its development.

It may seem easy, for example, to "just calculate the sales figures quarterly rather than monthly and have that appear on this screen as well as that one".

But each new function must be built, tested, made secure and usually provided with an interface that allows the data to be manipulated by the administrator of the website, not just by its users.

So as a (very broad) rule of thumb, each small change probably requires four times more work than you might expect. So if a project is on a tight deadline - or, worse, has minimal testing time built into a tight deadline - then major change to a specification will exponentially increase the risk that the project will not come in on time or on budget.

Poor business management .
Supplier management can be a dark art but common sense still applies. If you are sure you are going to dump a supplier, do not half-heartedly "sort of" dump them. Decide the time at which you will stop giving the supplier work and organise to phase in new suppliers around that deadline.

If, on the other hand, you think a relationship may be salvagable, do not give the supplier an ultimatum that is impossible to meet then wonder why they refuse to meet it.

The best time for AMarketCo to debrief its developer would have been after a previous project, by formally stating that next time round it would like ABespokeCo to offer more ideas.

But even if a major change in role needs to happen during the life of a project, there are less antagonistic ways to approach the issue. Asking a "friend of the company" for an impartial view can be helpful. But asking a consultant to pitch for the work then using that pitch as a bat to beat your supplier is far less useful. It is better to simply ask the consultant to sit in on a meeting with the supplier.

There's a range of reasons why an external consultant's pitch can seem more attractive than that of an incumbent supplier. They may make promises without knowing the detail - then find, once they begin, that their work takes longer and is more expensive than they had expected. Or a consultant may offer to "rip and replace" - throw out a working system and replace it with their own cheaper and supposedly more functional new system.

The moral of this story is clear. Sometimes it is necessary to change suppliers and that process can be extremely positive. But it is a high risk activity and should not be used as a way of "escaping" the responsibilities of supplier management.

In fact, in this case ABespokeCo had made a whole set of mistakes of its own. Neither side was blameless. But what bought the project down? Problems at the client end.

The company names in this article are intended to be and to the best of our knowledge are fictitious. They are not intended in any way to represent companies of similar names.

Taken from ITRM