Lexpert Magazine

LEXPERT MAGAZINE | Q2 2019 65 (by name), and provide that they cannot be pulled off your project unless you give your prior written consent. And to guard against a scenario where the supplier contemplates breaching this covenant, there should be a meaningful liquidated damages amount that will really make the supplier think twice about not living up to this critical obligation. Integration is Central – and Hard e Claim describes how the customer wanted to make sure the new soware worked well on a traditional PC or laptop, but also on a smart phone, as well as on a tablet. e customer, however, alleges in the Claim that the functionality for the tablet wasn't delivered. is was one of the mate- rial deficiencies cited in the Claim – a seem- ingly simple feature that didn't come to fru- ition. You would think a feature such as this would be straightforward nowadays – we'll have to see what the supplier says about it in their reply. On the other hand, one deficiency high- lighted in the Claim that is usually acknowl- edged as difficult to do centres around the alleged failure of the supplier to integrate the new soware with the other computer systems of the customer. is is a huge area of risk in these enterprise soware develop- ment deals. at is, the core exercise is not simply to build the new functionality – in this case the client-facing website that would be the customer's primary e-commerce plat- form (not to downplay the difficulty of achieving that objective). But in addition, the supplier has to integrate the new so- ware with myriad systems of the customer, involving finance, inventory control, data- base marketing, loyalty systems, and so on. is type of enterprise level integration is so difficult because while the supplier is probably quite expert in the new soware it is building (in the case of the Claim, the so- ware for the new website), the supplier in- variably is not as experienced with the back office systems of the customer. And there- fore, however much the supplier knows the parameters of the new components of the project, it always has to get up the curve on the legacy environment into which the new soware must be integrated. is is typically hard work – and in the Claim the customer alleged that it was not done well. So, how to mitigate against this "integra- tion risk"? One way is to de-couple from the main, fixed price contract the exercise of having the supplier learn everything they have to know about the integration challenge – that is, make the integration exploration effort a separate small contract, perhaps even priced on a time and materials basis. en, once a very solid understanding of the integration effort is captured by the supplier through the initial small project, the supplier can bid the fixed price devel- opment work with a lot more confidence (which should let you breathe a lot easier). Tough Custom Requirements In many soware development projects, the customer says at the outset, "I just want something basic, something out-of-the-box, something "vanilla" – meaning straight- forward, simple. is is, indeed, the best practice approach, because if you can keep your requirements as "standard" as possible, you do go a long way to de-risking the proj- ect. But here's the thing – it seems that no matter how committed the customer is to "keeping it simple and vanilla", in every ma- jor project there is always something (and usually more than one thing ) that turns out to be anything but straightforward. In the Claim case, the difficult deviation from norm was the fact that the customer had several "sister operating divisions" in the same line of business. us, the custom- er wanted the initial website built in a man- ner that, aer it was completed, it could be "cloned", such that with not much addition- al effort, it could be modified so each clone of the system could be used for another af- filiate of the customer. is makes a lot of sense, and you can certainly understand why this design feature was asked for by the customer. Delivering on it, however, turned out to be very difficult, apparently, to such an extent that the Claim argues this critical functionality was not delivered at all. As noted above, until we see the Defence, and get a more thorough sense of what ex- actly happened, we'll never know (and if this particular case settles, we'll then we may truly never know). Nevertheless, the broad- er question of what to do about particularly tough custom requirements invariably aris- es in every material soware development or system integration deal. And the first ob- jective is for both sides – the customer and supplier – to admit that such tough hurdles will invariably exist, and therefore that they need to be ferreted out and surfaced right at the beginning of the mandate, in order that appropriate estimates can be made in the required budget and skillsets to make good on them. ere is nothing to be gained by one or both parties to these transactions re- fusing to face reality, especially early on in the mandate. e Claim concludes that the net effect of the deficiencies noted above (together with some others) caused the customer to have to cease work with the supplier, and then to pay $10+ million to a new supplier to finish the work (on top of the $32 million paid to the first supplier). en there is the cost of being late to market with a meaning- ful web presence, which loss is very hard to quantify (i.e., how many potential clients went elsewhere, etc.?). Hence, the customer in the Claim asks for an award of all of its damages caused by the supplier's alleged fail- ures. e scenario described in the Claim is not that rare. ere is still plenty of risk (I call it Risk 2.0) in the world of soware development, customization and implementation where large or complex IT systems are involved. And you will certainly want to manage your risk by using a fixed price contracting mech- anism, even if your day-to-day development methodology utilizes "agile" practices. But at the same time you have to conduct suf- ficient due diligence on the technical and user requirement aspects of the project, so that the fixed price contracting approach does not come back to haunt you. "In other words, the initial senior implementation team of the supplier got to know intimately the requirements, and idiosyncrasies of the customer. If that initial team leaves half way through the project, that knowledge of the customer will be largely or completely lost."

• Cover
• front
• back