We all know the scene – a customer wanders into a gents’ outfitters in search of something ‘off the peg’. Predatory sales staff, who have never met him before but who can only offer him what they have on their racks, assure him that what they have is what he wants. The customer tries on a suit in a fetching shade of brown. Showered in compliments and gasps of admiration, he stands in front of the mirror, his brow furrowed. Mustering all the moral courage at his command, he decides against it and returns guiltily to the changing booth amid a glacial silence and the unspoken resentment of the assembled pack of assistants.
A small thing in itself, but it is remarkable that many buyers still seem unwilling to apply as much healthy caution to the procurement of packaged software as they would to the purchase of a suit.
Purchasers of package software, whether a teenage ‘anorak’ or the ISM Director of a large corporation, have this in common: they are relying on a software product designed not to meet their personal requirements, but those of a perceived ‘average consumer’ within some notional market sector. In selecting one package software product over another, the customer is effectively betting that it will best meet his or her particular needs – and betting means risk.
Certain projects should be seen as high risk by their very nature; for instance, the annals of software/system development present endless examples of dramatic failure, massive cost and time overruns and protracted litigation. However, if many buyers recognised that the development of bespoke software is as much an art as a science and so carries real risk, there are still plenty of people who believe that simply buying off-the-shelf software provides a way to minimise or off-load such risk. The thinking often seems to be that if ACME Software’s product has ‘500 satisfied customers worldwide’, it will only take a signature on a purchase order to create number 501.
Alas, things are never that simple, and package software implementations go wrong all too often. Lawyers are renowned (or infamous) for their love of tradition and precedent, but it is often the non-lawyers involved in implementations who display a dogged adherence to traditional ways, so projects still tend to fail for all the same old reasons.
The aim of this article is to look at why package software implementations so often go awry, and what measures can be taken to prevent this. The classic reasons are that the software fails to live up to expectations, and/or cannot be made to work in time or without a significant overspend. The author cannot claim any special powers of perception – what follows is (or should be) common knowledge – but the very fact that the same classic mistakes get made over and over again justifies a restatement of some old truths.
There are a number of key measures which can be taken to maximise your chances of a successful package implementation, and the first of these should be taken before even the initial contact with would-be suppliers.
First Know Thyself
Many package implementations end amid cries from the disappointed customer that the product ‘doesn’t do what we want it to’ as it becomes apparent that business benefits promised or anticipated will not be realised. No matter that the product does exactly what the user manuals say it does – it will cut little ice with a frustrated customer to tell them that their real requirements were never made clear. The customer will be just as miffed.
It follows that in embarking on the selection of a package software product the aspiring buyer has to have clear understanding of its own requirements – a requirements specification. Without this, the buyer will have nothing against which to measure the product or compare it with rivals. Buying a car provides an obvious analogy: drivers have different priorities which will lead one to select a high spec roadster while another chooses a more spartan MPV. Few products perform well if used for tasks for which they were never designed. Is the roadster to be condemned because it cannot accommodate four adults with luggage?
It might not always be easy for the buyer to specify its requirements properly, there may be differing priorities within its organisation, or it may lack the skills or resources needed for the task. Shortcuts at this stage must be avoided if at all possible; some extra time and money spent identifying one’s real requirements will pay dividends later on, and customers who cannot do this for themselves should consider paying a suitably qualified consultant to do it. The requirements specification sets the agenda for prospective suppliers, and provides the ultimate baseline against which competing products will be measured. Getting this right will cement ‘buy-in’ from interested parties across the buyer’s organisation, and will lessen the risk of unfulfilled expectations later. Getting it wrong will lead the whole implementation astray as it will undermine everything which follows.
Realistic Expectations – The Art of the Possible
Few of us would buy a suit without trying it on, so it is hardly novel to suggest that suppliers should be required to demonstrate their product in use. This will usually involved a dedicated demo and visits to reference sites where it is already in use. The form and rigour of the demonstration will vary according to the nature and price of the product, but in any event it should be attended by customer personnel who would be involved in operating the product on a day-to-day basis. Any temptation to skimp on this must be resisted.
A product which has been designed for a market rather than an individual customer can never be ‘all things to all men’ and compromises have to be made. The realistic buyer has to recognised that no package product will meet all its needs, and (all other things being equal) he must be ready to do what is necessary to accommodate these gaps. There is an old adage that you don’t change a package to fit your business – you change your business to fit the package. There may be some business processes that cannot be changed, but in general this is sound advice.
The buyer should be prepared to revisit any unmet requirements, and review its business processes to identify changes necessary to achieve greater fit with the product. This is sometimes called ‘business process mapping’; and any reputable supplier or implementation partner should be happy to participate – after all, it is in everyone’s interests (and will be charged for). It is often undertaken as a preliminary project in itself, with the final decision to buy resting on the outcome and the customer able to walk away at that point. Beware suppliers who seem reluctant to get involved in this – they may not want the full extent of their product’s limitations laid bare.
Walking the Walk
So the great day arrives – demos are complete, reference sites have been checked out, and functionality gaps have been identified and allowed for. A clear preference has emerged, the users-to-be are all on board with the decision, and the lucky supplier (word always gets out) is already agitating for a signature on its standard form contract. The supplier has even been helpful enough to point out that delaying signature could have ramifications later as it has other projects pending and personnel earmarked for this one might get poached. Why not just sign the contract – surely by now the worst risks have been catered for, and it’s plain sailing from her on in?
Maybe, but maybe not. This isn’t like buying a suit off the peg – if the waist needs taking in, the tailor can do this with no help from the customer. Implementing a package is fundamentally different in that the supplier cannot improve the fit on its own. For instance, the purchaser has to allow access to its premises and systems, and key personnel have to be freed from their ‘day jobs’ so they can attend project meetings and training sessions.
The supplier should be asked to confirm any minimum hardware/networking specification which has to be met if the product is to perform properly. An understanding of the customer’s business/requirements (gained from the invitation to tender, or from participating in business process mapping) will be critical in this respect. There are a million and one things the buyer needs to do for the implementation to happen. If these are not done properly or on time, the whole project timetable can be compromised, no matter how efficient and skilled the supplier.
Disruption of the project timetable could have very serious, and costly, consequences. Typically, new software is bought to replace an old system and there will usually be a deadline date by which the customer must migrate from that old system to avoid having to purchase a further licence or period of maintenance cover. If the deadline is missed and the purchaser is forced to go cap in hand to the outgoing supplier, any quotation for such extensions (and the supplier cannot be compelled to agree any) is unlikely to be ‘competitive’. Suppliers also know how difficult it can be for a customer to terminate an implementation (even one which has overrun) and to go back to square one – and some are prepared to exploit this.
The supplier should want to avoid delay as much as the customer does, and it is in both their interests to understand what each of them needs to do if the software is to be operational on time. The supplier should be especially keen on this if there are to be any contractual consequences (such as liquidated damages or a right of termination) in the event that a critical deadline is missed due to the fault of the supplier. Assessing what is and is not the supplier’s fault can be a problem if critical dependencies which are the responsibility of the customer are not identified in the contract. Defining these is necessarily a task primarily for the supplier because it is the supplier (at least in theory) who knows the product and how best to implement it.
This isn’t rocket science. The supplier has only to explain in clear terms what it will be doing, and what the customer needs to do, and by when. When done in a professional manner this builds customer trust and confidence but, regrettably, the author’s experience is that many suppliers completely fail to understand how important this is. Time and again customers are expected to sign simple licence agreements which are completely silent about how the actual implementation will be undertaken – how a pack of CDs and a pile of user manuals will be turned into a working system.
Customers faced with this situation must stand firm and demand a clear explanation of how the implementation will happen, even if told that this puts the timetable under pressure – if time is a factor, it is even more important to resolve this at the outset. When pressed, suppliers can usually come up with a services agreement, but if there is any supplier resistance it is worth the customer offering one of its own. It can be very tempting (especially if timescales are short) to duck this issue and to hope it will work itself out as you go along. This is a mistake as it can only compromise effective project management and so increase the risk of failure.
It is a bizarre phenomenon that many suppliers who refused to explain to their customer what they intend to do will nevertheless expend Herculean effort in trying to limit their liability for their own acts and omissions. Perhaps they think that they don’t need to worry about whether the implementation actually goes to plan as long as their contractual liability is non-existent. This approach does the supplier customer/relationship no good at all, and when blatantly espoused it is insulting to the customer.
This also works the other way round. Prudent suppliers will insist on capturing critical dependencies in the contract, so the supplier won’t have to ‘carry the contractual can’ if for example delay is attributable to the customer’s failure to delver its end of the implementation. The supplier should be firm if the customer appears reluctant to entertain this idea – it could be a sign that the customer thinks that once they have signed on the dotted line, everything which follows must be the supplier’s responsibility. Given the less than fulsome support offered to suppliers by the courts, this could be bad news if the project starts to go wrong.
The End of the Rainbow, and Knowing when you’ve arrived
Even if the customer and supplier agree on what the customer is to get for its money, serious problems can arise if insufficient thought is given to how achieving this is to be measured or verified. We are talking acceptance procedure. If both parties are being straight with one another, this should not be a controversial topic as the interests of the parties should be similar. The customer needs to be able to prove the software delivers what he has paid for, and the supplier needs to know that, as long as he has delivered, he can call in his crew, pack up his tools, and collect the balance of his fee.
The contract should provide that the customer will test the software, and that the supplier will put right any glitches (there will be some). This will normally be undertaken during a period specified for this process in the project plan. The supplier should be entitled to treat the software as ‘accepted’ if it passes testing, or if the customer fails to test, fails to report any problem, or alters the software in any way. There should be clear provision for what happens if the product fails to pass the tests. Will the supplier be allowed a second chance?
This all supposes that there is some agreed contractual baseline against which the software will be tested. The end goal needs to be clear from the outset or getting there will be a matter of chance – not a recipe for success. Both parties need certainty; customer ‘requirements’ can be elastic and transient, so suppliers of package software will usually stipulate that acceptance must be tested against the product’s published specification and/or user documentation. Assuming the customer has properly examined the product before deciding to buy, this should not be a problem.
‘Acceptance’ is no mere formality, and must be treated seriously. It has important legal consequences, as it will extinguish any right the customer might otherwise have to reject the software.
The Limits of Contracts – Put not your trust in paper
So now you have a nicely drafted contract, capturing the customer’s ‘must have’ requirements, the supplier’s implementation method, the critical dependencies on both sides, and clear rules for determining acceptance. The payment profile is suitably ‘back end-loaded’ so that the supplier only gets the bulk of its money when it can be shown to have ‘delivered the goods’. All very nice, but there is a world of difference between having a plan and making it reality. It is fine to negotiate contracts which make proper provision in the event of failure, but it is far better to tackle its usual causes than to plan for the consequences as though failure is inevitable.
This is where project management comes in – the essential but unglamorous process of holding the project together and on schedule. It is a bit like refereeing a football match – done well it can almost pass unnoticed; done badly it can soon lead to disaster. Actual performance of critical supplier and customer obligations needs to be kept under constant review, so delays can be anticipated or at least spotted early on while there is still time to remedy the situation.
A properly drawn project plan is essential. If the supplier is unable or unwilling to come up with a detailed plan at the outset, it should be asked to supply a typical example (anonymised if necessary) from a previous implementation of the product. After all we are talking package implementations here, and the supplier should have a pretty good idea of what will happen. This can be very revealing. The author was involved in one implementation which had a short deadline and the supplier promised that immediate contract signature would allow implementation in a little over six weeks from project start. Very impressive indeed but, when asked to supply a typical project plan for a similar implementation in order to back up this claim, the specimen offered showed a project duration of over six months.
Both parties have to be committed to the project, and in particular the customer must be able to ensure that its key personnel can perform project tasks despite having other existing jobs within the customer’s organisation.
Good project management is needed on both sides, but on package implementations the overall lead really has to come from the one who knows the product best – the supplier. Again, the customer needs to be alert for any sign of supplier reluctance in this respect, and should not hesitate to query it.
Conclusion
Even package implementations carry risk, and they tend to go wrong because one or more fundamental aspects of the project (eg the what, the how, or the by when) gets fudged or ignored altogether. This builds stress into the deal from the outset, which will surface sooner or later.
The failings discussed in this article are those which in this author’s experience are the most common; there are others, but none is inevitable. The key to a successful package implementation is to treat contractual and operational issues as faces of the same coin. Even the most beautifully drafted contract for a world-class product will avail the parties nothing if its implementation is badly planned or managed, and the best project management money can buy may be unable to save a deal which badly fails to address the parties’ real requirements.
Deryck Houghton, Director, v-lex Limited.
