Failed Software Development: De Beers Debacle

January 19, 2011 by Bierce & Kenerson, P.C.

Written by William B. Bierce and Henry (“Hank”) Jones, III

When can a software developer (such as Atos Origin) walk off a critical systems design project for business-process transformation when the customer (such as the De Beers Diamond Trading) fails to provide the necessary subject matter expertise? Atos Origin found out, in a London court decision in December 2010, that it might have been able to walk away but failed to protect its legal rights properly. Consequently, it owes net damages of over £1.4 million (about US$2.25 million).

This article addresses best practices in “fixed fee” services agreements in business process management. Instead of transforming the diamond industry’s leader into an efficient integrated operation, Atos encountered a litany of challenges including an adverse lawsuit outcome, adverse corporate publicity and intensified scrutiny of individual careers.

Software development, systems integration, outsourcing, and business process management all directly depend on carefully defining, documenting, and then actually achieving robust processes. Transitioning from sub-optimal silos to improved operations in dispersed organizations is challenging and sometimes chaotic at best. And making the leap successfully requires effective management and communications at each step.

When De Beers Diamond Trading planned an entire relocation of its diamond sorting operations from South Africa to Botswana in 2007, it hired global systems integration services vendor Atos Origin, who won a competitive tender, to integrate a number of process silos for greater efficiency. According to the court, “Previously, in about January 2000, [De Beers] had engaged Accenture to redevelop its integrated stock management systems, but the project did not go well and after three years it was terminated without achieving most of its objectives. Accenture complained that the project had gone badly because Accenture’s team had not received sufficient cooperation from the relevant personnel within [De Beers], and so one of the lessons that came out of this unsuccessful project was that [De Beers] came to recognise just how unusual the nature of its business was and the difficulty facing outside consultants who needed to understand it.” (Court opinion, Para. 11.)

Atos Origin found itself in similar circumstances, deep in a hole of project failure and consequent court proceedings and costs. And today De Beers still operates its old silos.

The detailed opinion of Judge Edwards-Stuart of the specialized UK technology court offers actionable lessons learned at considerable cost and frustration for both the enterprise customer and the technology services provider – particularly including the necessity of very smart, project-customized contracting up front. De Beers UK Limited (Formerly: The Diamond Trading Company Limited) v. Atos Origin IT Services UK Limited (UK High Court Of Justice, Queen’s Bench Division, Technology and Construction Court, Dec.16, 2010).

As with shared success, shared failure means both parties made mistakes. The key lessons for all enterprises from this costly project and its consequent large commercial litigation relate to the well-known but hard-to-tame beast of “scope creep.” The “scope creep” challenge has extra vigor in two particular contexts, which both existed in this transaction: (a) fixed-fee pricing models, particularly for business process transformation from silos management to integrated resources management across business segments and (b) blended vendor-customer control and staffing of extensive, expensive endeavors. This true fable raises many questions on “best practices” in initially designing and drafting agreements and then managing projects for sourcing and systems integration. Ready for some fun?

I.      Unique Business Process Methods – Diamond sorting is a unique and complex process, more than what both the customer and service provider envisioned.
II.    Chronology – Timeline of events.
III.     Project Plan – De Beers (DB) and Atos development plan failures.
IV.    Business Process Mapping and Pilot Project Management – What went wrong during this phase.
V.     Pricing for Fixed-Fee Projects – Why this type of pricing structure and its change control procedures failed.
VI.    Governance – Good governance procedures in place, but not enacted properly.
VII.    Failed Governance: Termination for Anticipatory Repudiation – Which side was ultimately responsible for the termination of this contract.
VIII.   Conclusions.
________________________________

I. Unique Business Process Methods

The software development project was planned to allow De Beers to move its diamond sorting process to Botswana in conjunction with an extraordinary “corporate catalyst” event: a five-year mining agreement with the Government of Botswana. The diamond sorting process was the acknowledged underpinning to De Beers’ successful business – and the key to maximizing revenues and preserving decades of accumulated goodwill.

The arcane, unique and potentially confusing character of this particular business process merited a brief description by the court. This description serves to elucidate a hard, fundamental question in initial architecting and negotiating a large contract: which party would be liable, in what particular later circumstances, for losses when the parties failed to achieve the mutually intended goals in the project plan on time and in budget? The complexity of the unique business process was central to allocating the risks of “scope creep” in a fixed-fee pricing model. As the London judge noted:

12. “The identification, classification and valuation of the diamonds take place before they get to the aggregation process. This sorting and blending process requires highly trained experts because there are over 16,000 different categories of uncut diamond based on a stone’s size, shape, quality and colour. This gives an indication of the sophistication of the operation. The object of aggregation is to ensure consistency and accuracy in supply for DB’s customers, who are known as “sightholders” (because they attend the “sights” or sales weeks at which the rough diamonds are sold).
13. The following description of the physical processes which take place along the Aggregation part of the supply chain (or pipeline) is largely taken from Atos’s opening submissions. For the purposes of this action it starts with the diamonds which are already sitting in a local sorting office (“LSO”), to which they have been transported from the mine. The first module in the pipeline is “Export for Aggregation”: this covers the steps which need to be taken in order for the diamonds to be transported (exported) from the LSO to their destination for Aggregation (which was to be Gaborone in Botswana). The next module, “Import for Aggregation”, covers the steps taken when the diamonds are received for Aggregation. Having received the diamonds, the next stage is described as “Rolling Management”: here the diamonds from the different mines, which have been imported for Aggregation, are aggregated or “rolled” together – a process which, as will now have become apparent, is not as simple as it sounds. After the stones have been aggregated, they are split up into the groupings in which they will be presented to the sightholders for sale: this is known as “Splitting”. It is common ground between the parties that “Splitting” was originally outside the scope of the Contract: it was introduced by means of a change request. Once the diamonds have been split up (into boxes), they are then exported for the purposes of the sights which are to be held: this is “Export for Sight”. The next module is “Import for Sight”, which consists of the steps to be taken at the LSO (now a local sales office) when the boxes of diamonds are received. The final stage in the pipeline is the steps to be taken in order to prepare for and hold the sight, attended by sightholders from all around the world, “Prepare and Hold Sight”.
14. From an IT point of view one of the challenges of the aggregation process was that it required a system that would keep a precise check on the diamonds as they moved through the process so as to ensure that no stones are lost and would provide facilities for valuing the stones (or groups of stones) as they went on – as well as providing a proper audit trail of the movements of the stones.” (Court opinion, Paras. 12-14.)

In short, the customer’s business was complex. Even this summary fails to disclose the challenges of making this business repeatable, transparent, well-documented, and manageable.

II. Chronology

This software development project followed a major corporate restructuring of the enterprise customer, De Beers. The contract and lawsuit arose in a context of two unprecedented yet simultaneous efforts; overlapping major changes in both geography (operations location) and management (operations integration, optimization, and automation) were undertaken. The customer was moving a key portion of its operations to a new country, and it was logical to want to improve its business process integration at that time. (Court opinion, Paras. 2-8.)

2. “In about May 2006 DB entered into a joint sales agreement for 5 years with the Government of the Republic of Botswana (“GRB”) which included an undertaking by DB to move a major part of its operations, in particular what is known as the aggregation process, to Botswana (although it is not clear whether this obligation was contractually binding). This undertaking came about partly because Botswana produces about 25% of the diamonds handled by DB and partly because DB wished to make a contribution to the economy of the Republic of Botswana. This transfer of operations would have involved the development of a software system to support the diamond supply chain management and DB decided also to take the opportunity at the same time to upgrade its existing software systems, which were out of date and often differed from department to department.
3. In April 2007 DB put the software contract out to tender with a view to selecting a shortlist of two potential suppliers from whom it would obtain a Best and Final Offer (“BAFO”) before finally entering into a contract with one of them.
4. The Defendant, to whom I will refer as Atos, was one of the companies who responded to the invitation to tender. It was ultimately successful. However, at some point during the tender process DB decided to enter into a preliminary contract, known as the Initiation and Analysis Phase (“IAP”), in order to give the chosen software supplier an opportunity to investigate and analyse the business requirements of DB so that it would be in a better position to enter into a fixed price contract for the project.
5. This duly happened and, by a letter of intent dated 11 July 2007, Atos agreed to carry out the IAP. They did so between the end of June and October 2007, at the end of which they entered into a fixed price contract for the project in November 2007 (“the Contract”).
6. Unfortunately things did not go well. In spite of attempts by Atos to replace the weaker members of its team and to bring in additional senior managers and other staff, progress fell well behind schedule and this continued until March 2008 when Atos told DB that it would not be able to deliver the software by the end of June 2008, as the Contract required, and would probably not be able to do so before mid October 2008. This was not acceptable to DB and protracted discussions ensued with a view to arriving at an acceptable revised programme, which the parties did in early April 2008.
7. In the meantime, on 3 March 2008 Atos issued its fourth invoice, which DB failed to pay. It was for a sum a little in excess of £320,000, and was due for payment at the beginning of April 2008. The reason given by DB for refusing to pay this invoice was its dissatisfaction with delays and with the quality of the work being done by Atos. At the same time the senior management within Atos had become very concerned about the substantial cost overruns on the contract.
8. By a letter dated 21 May 2008 Atos claimed that the progress of the work had been delayed and obstructed by the lack of co-operation from DB and by very significant increases in the scope of the work and that, unless DB agreed to renegotiate the contract by 31 May 2008, Atos would suspend all further work. Atos relied also on the non-payment of the fourth invoice. Although, at DB’s request, the deadline was extended to 6 June 2008, DB was not prepared to negotiate on these terms and Atos suspended work at the end of the first week in June. The work was never resumed.”

Eventually, De Beers failed to actually move its diamonds sorting operations to Botswana for confidential reasons (what the court – which apparently was never told by De Beers the actual impediment – dubbed the “blank” explanation in its lengthy ruling).

In the De Beers case, the customer had failed to identify, document, or describe in the initial vendor-selection (“tender”) process many of its own actual operations that its personnel already performed. This formal judicial criticism of a decades-old, well-known global company illustrates the immaturity of some companies’ process documentation, vendor selection, and contracting processes. This recent litigation provides a fresh, excellent case study, borne of significant effort, evidence, and expertise, showing that corporate size and longevity does not prove business skill or transactional quality. The judge’s opinion is a business “autopsy,” revealing that, even for a high-budget mission-critical project, there can occur insufficient internal advance analysis and self-assessment by a supposedly sophisticated customer before commencing bidding, vendor selection, budgeting, and contract negotiation phases. In short, it appears that De Beers was unprepared and had not learned the lessons of its failed software development with Accenture in 2000.

III. Project Plan

A. The Customer’s Development Plan

De Beers and Atos Origin jointly agreed to adopt a project plan for “agile” iterative software development. The customer’s subject matter experts would meet with the vendor’s software developers to assist in mapping the processes and defining the functional requirements. The developers would identify the non-functional requirements. The London judge concluded that project plan did not take into adequate consideration the degree of complexity of the processes, the historical secretiveness of De Beers’ management about the processes, or the relative non-existence of any internal process maps. The court decision suggests that De Beers was operating a multi-million dollar business with no realistic ability to map its current operations.

The project plan was split into two phases: initial process mapping (for a fee under an “initiation” agreement, to allow Atos to recover its costs for investigation) and software system design, coding, testing and implementation. The relationship degraded during the first phase.

B. The Software Developer’s Development Plan

The project bogged down early and repeatedly. An internal Atos expert analyzed the situation mid-way, once problems arose, criticizing the overall development methodology. His “internal” analysis, not intended for public consumption, was quoted in the judge’s opinion to demonstrate that Atos had initially adopted a particular software design and development methodology (i.e., the by-now well-known “agile”) (Court opinion, Para. 129.) The court extensively quoted the “internal” corporate self-assessment by a candid veteran technical employee, reporting to his vendor-side management colleagues:

“DTC [De Beers’s project] was originally intended to be developed agile-style. To this end, the team was organised into BAs [Business Analysts] who would define the requirement, and then a pool of devs [software developers / programmers] who would be organised into teams to build elements of the solution incrementally, with the project beyond the requirements definition set up SCRUM-style; all supported by an architect and a few key designer/devs. This is all very DSDM [Dynamic System Development Method] as an approach, and can work fine in the right context, and of course with the right customer.
It became apparent that this wasn’t going to work. This is for several reasons.
• The application is much larger than was originally thought, in terms of function points.
• The application is much more integrated and complex than was originally thought: a huge end-to-end multi-country workflow, with many of the same business concepts and sub-processes popping up at many points in the workflow and many “wrinkles” in the detail of the processes..
• At contract signature the requirements were high-level. Detailed requirements were defined in January 2008 and signed off in February, and only then were the maintainability and extensibility requirements expressed in PR69/71 apparent..
• The customer is demanding, particularly on the technical side, and this did not fit well with an agile approach to build.
Accordingly the decision was taken to move towards a much more waterfall-style approach. However, this was not reflected in the team organisation, or in the definition of the artefacts [sic- artifacts] to be produced. As soon as I arrived I observed that the build team organisation was still reflecting the BAs, being effectively divided into functional silos. This was not appropriate given the points above, and we have started “specialising” so as to be able to provide the specific system support such a large and complex system requires. So for example, we now have a dedicated workflow team building the patterns and mechanisms that will be needed by the functional developers so as to build on top of Windows Workflow Foundation. We are in the process of setting up a dedicated UI team to do the same for Smart Client Software Factory and Composite UI Application Block. And more of the same will certainly follow; …I see the need to pull the BAs and devs into integrated teams.
However, the workflow work in particular (which is well under way) has exposed a massive gap. We have signed-off business functional requirements, courtesy of the BAs. We have a team of devs ready to build to those requirements. We have a number of architects and key designers busily defining how the devs are to build the system (defining the architecture, that is to say). But we have no definition of what system is to be built: how the workflows in the various functional areas interact, exactly what behaviour in each functional area is to be allocated to the client and what to the server, exactly what messages are passed between client and server, and so on.
In short, what is missing is systems analysis. This seems to be something of a lost art (within Atos Origin at any rate), and I am at a loss to understand why. To build a system of this size and complexity it is an essential activity, and doing it now will undoubtedly pay for itself in the long term and address many painful risks. But of course, it casts the current plan into outer darkness and will undoubtedly go down like a bucket of cold sick with DTC. Note also that this will have implications for both sides of the V-model: testing as well as analysis.
. . .
What specifically do we have to do now? We need to create a Systems analysis team, combining perhaps two of the best BAs (we know who we want), an architect, and if possible a Systems analyst with manufacturing process experience . . . We need to re-plan to account for this team and activity. We need to plan for and start issuing analysis artefacts from this team as soon as possible in order to get the dev team is rolling (that it is, we don’t have to do everything before we can do anything).” (Court opinion, Para. 129.)

IV. Business Process Mapping and Pilot Project Management

A. Customer’s Knowledge of Service Provider’s Ignorance of Material Facts about Customer’s Business Process. Even without reverse service level agreements (“SLA’s” – i.e., detailed, contractually-mandated services obligations of the customer), a customer cannot simply conceal material information from the service provider. In other words, the well known (in the i.t. services industry) challenge of inadequate cooperation or “buy-in” by some customers employees is a management challenge for customers too, not just the winning-bidder vendor. In post-litigation hindsight (i.e., in a “lessons learned” internal memo after termination), De Beers admitted that it knew that Atos had assumed that the high level requirements initially distributed by De Beers would not give Atos enough information to adequately understand De Beers’ business complexity, and De Beers knew that Atos’s assumption was a mistake. Indeed, within De Beers, there were concerns still within the business as to whether or not Atos had fully understood the depth of the business requirements. There were reassurances from Atos that the vendor project team indeed had understood fully the requirements, so the project proceeded.

Later, the litigation’s foci included the factual question of whether De Beers had timely notified Atos of the complexity of the business requirements and the resulting functional specifications (Court opinion, Paras. 27-28). The “lessons learned” analysis after termination showed that the customer had identified this as supplier failure. This issue might have been simply resolved if the e-mail records or governance committee records had shown any communication of this concern. In short, the customer was not forthcoming, and the project suffered.

B. Customer’s Inability to Provide Timely Business Process Information. When De Beers could not timely supply to the vendor’s on-site team enough knowledgeable subject matter experts, Atos added mid-project new business analysts (“BA’s”), ramping up from an initial two, to a total of ten BA’s.

C. Service Provider’s Change of Project Methodology. Atos also changed mid-project its method for software development (from “agile” to the traditional “waterfall” approach). Originally, Atos had planned to use an iterative process where individual modules could be tested and integrated on an incremental basis. Instead, once it realized the customer was failing to provide enough subject matter expertise, it converted the process to a unitary “Big Bang” development process. The “Big Bang” procedure is riskier, since it does not allow separate testing and corrections of individual modules and processes until the entire project is completed (Court opinion, Para. 87).

D. Minimum Standards for Customer Support (Sometimes Referred To As “Reverse SLA’s” Or Reciprocal SLA’s).

1. Contract Terms. The De Beers “initiation” agreement required De Beers to make its personnel available to Atos for consultation at all reasonable times. (Court opinion, Para. 202.)

“6.1.2 promptly provide the supplier with accurate and complete information concerning its operations and activities relevant to the Project and answers to queries, decisions and approvals required by the Supplier in connection with the Project as the Supplier may reasonably require.
6.1.3 provide the [Customer hardware identified in (the Architecture Blueprint)]” (words in brackets are incorporated by reference to Clause 1.1 and Schedule 6).
6.1.7 provide the Supplier with appropriate access to the Legacy System and Data of the Customer in order to enable the Supplier to perform its obligations under this Agreement.
6.1.9 ensure that the staff it assigns to the project have appropriate skills and experience for the tasks to which they are assigned. The Supplier’s Personnel shall have a right of access to the Customer’s staff at all reasonable times throughout the duration of this Agreement as is necessary solely for the purposes of the Project.
. . .
6.2 The Supplier will notify the Customer as soon as practicable if it becomes aware that the Customer is not complying with its obligations under this Agreement including the Customer Inputs. If any such failure is likely to impact on a Key Milestone Date the Supplier shall notify the Project Steering Committee as soon as practicable. Provided the Supplier duly notifies in accordance with this clause 6.2, if any Key Milestone is not achieved on or before the relevant Key Milestone Date as a result of such failure by the Customer, the Key Milestone Date shall be varied in accordance with the Change Control Procedure.”

However, this contract text proved to not adequately protect Atos from the customer-collaboration problems that Atos soon was to encounter: apparently repeated unavailability of needed staffers, plus a key person’s resignation. The Lord Justice penalized De Beers for this deficient performance of customer-side contract obligations, but, importantly, did not allow Atos to escape liability for its lateness as a result of such unavailability and resignation.

2. Availability of SME’s and End Users. In software development, “functional” specifications describe the business inputs, processes, and outputs to be performed. “Non-functional” requirements define the implications and enabling infrastructure (such as the need for bandwidth to accommodate the maximum number of users). Persistent delays in developing functional specifications arose in De Beers due to lack of availability of relevant key personnel of the customer: subject matter experts (“SME’s”) and key end-users. Unless such key personnel are available at the times, for the durations, and with the data and prior preparation as required by project leaders, the project will not go as planned. Availability parameters need to be adequately managed, including:

• the amount of advance warning (i.e., reasonably prior scheduling),
• the timing of the SME’s availability (e.g., are customer employees expected to commit to “after-hours” or weekend work, and/or intermittently skipping holidays, as vendor staff sometimes do?),
• the duration required, and
• the quality and specificity of the SME’s disclosures and inputs.

In this case, the court speculated that the unavailability of key customer personnel was partly due to a lack of direction from senior De Beers management. But availability is a matter of scheduling. The court found that Atos had possibly failed in some instances to give adequate advance notice of when such key persons needed to be available for meetings with Atos. While the judge identified instances of individual customer employee non-cooperation, possible bad-faith “politics,” and other diminutions of the credibility of some of the customer’s key project-participating employees (who testified or gave witness statements), the resulting partial undercutting of project chances did not release Atos from its ultimate court-ordered financial loss and liability (described below). (Court opinion, Para. 96.)

3. Service Provider’s Failure to Notify the Customer of Breach (Non-Availability of Customer’s Personnel). The court rejected Atos’s defensive claim that De Beers was in breach, to a degree releasing Atos from its overall contract obligations, due to the non-availability of De Beers SME’s. Atos had failed to notify De Beers of an alleged breach, so the judge ruled that the breach was waived. Project rescue, customer relations, and personal career considerations within Atos perhaps trumped, within Atos’ leadership, utilizing breach notification. Since Atos achieved a renegotiated agreement by project reorganization, this waiver was confirmed by the “fresh start.”

220. “First, at no stage prior to the letter of 21 May 2008 did Atos put any complaint in writing about breaches of contract by DB, let alone under clause 25 which deals with termination and material breach. The most that Atos put forward by way of protest in relation to potential breaches of contract by DB, was the occasional mention at meetings of the Steering Group of the unavailability of DB key personnel. The documents suggest that this was raised more as a point of irritation, rather than as a serious breach of contract.
221. Second, the overwhelming message from Atos conveyed by the contemporaneous documents from November 2007 onwards was that the detailed process requirements were proving to be far more extensive and complicated than Atos had envisaged at the outset. That was not a claim of breach of contract, rather it was directed at laying the ground for claims under the contract in respect of changes to the scope of the work. It cannot be dressed up as a claim that DB wrongfully refused to agree change requests, because relatively few change requests were put forward until much later on in the life of the Contract.
222. Third, the March/April re-plan effectively gave Atos an extension of time, if not money. The implicit acceptance by DB that Atos had valid claims for an extension of time is in my view inconsistent with conduct on its part that could be said to be repudiatory.”

In short, smart vendors should assume that no amount of customer non-performance of project-enabling Reverse SLA’s can justify a service provider’s unilateral suspension of services unless the service provider both (a) first documents the details of customer non-cooperation and (b) then puts the customer in breach by giving a formal, contract-compliant written notice of breach. Here, Atos grumbled but chose not to ruffle feathers and thus chose not to serve a notice of breach. Perhaps all courts and juries will assume that “coordinating and motivating inexperienced, even somewhat uncooperative or chaotic customer personnel, is merely part of the job and presumably already assumed in pricing and planned profits.” Atos later paid dearly for this failure to formally protect its interests.

V. Pricing For Fixed-Fee Projects

A. Structuring a Fixed-Fee Agreement. This lawsuit illustrates that the risk of later shared financial pain that can result from an inadequately defined scope of work, where only the top level requirements are listed, without adequate process and technical details for actual implementation.
The design of a project for a fixed fee and an inadequately defined scope can become a toxic combination when the service provider must extract process knowledge from the customer, and the customer fails to provide timely and adequately-nuanced clarifications and responses. Customer staffers, sometimes fearful of impending enterprise overhauling, sometimes fret about vendor delivery of an adequate solution, and consequently often add every conceivable “what-if,”, “might-use,” and “would-be-nice” detail to later, mid-project detailed specifications – i.e., generate “scope creep.” The resulting ultimate documentation frequently means the customer wants more services than the vendor believes that it originally contracted to deliver. Suppliers fret about hidden complexity.

But there is a third risk that both parties should worry about and proactively manage up-front, when designing and drafting the initial agreement. What are the respective rights and duties where the customer has not fully identified its own decisions and opinions at the low, operational, business process levels while it identifies high-level, outcome, strategic goals?

This case involves a little of all three, but the service provider was held accountable because it (rather than the customer) had the software-development experience and expertise, agreed to a fixed fee for fixed scope. It appears that the contract did not set any adequate advance parameters for process mapping and minimal customer enablement and participation.

B. Change Control Procedure

Every project and process requires a methodology for documenting, locking, unlocking and changing the target outcomes. This expected evolution is governed by a “change control procedure.”

Change control procedures are a key focus point for, and venue of, both challenging project tension and useful important scope-problem solving. And change control management often involves disputes. A contentious process can result in the customer feeling that the service provider is “nickel and diming” every change and “trying to make extra profits, once the vendor has the customer over the barrel in a mid-stream, deadline-pressures project.” And the service provider often believes that the customer is trying to get a “free lunch” for services, deliverables, or features that were not included or intended in the original, pre-contracting project discussions or pricing model. Hence, well-designed projects and sourcing relationships must address the inevitable harder, lingering problems:

• What exactly is a “change” for which formal documentation, rescheduling and/or pricing actions are needed?
• Who, particularly in the customer organization, has authority to declare that a “change” occurred or needs to occur? Which individuals can deny or veto a requested addition or modification from a peer customer employee?
• How do the parties reach agreement when they differ? What analysis, documentation, or proof is expected or required? Are short template forms really adequate to the foreseeable challenge, or should supplemental processes (e.g., labor, cost, and/or time analysis and disclosures) also be contractually required?
• When is the decision process initiated? How fast must the change-analysis tasks be undertaken? When will the particular change review cycle be completed?
• What happens in case of stalemate?

In this instance, no project-specific governance process resolved the foreseeable scope tension. Instead, the project was terminated mid-stream, leading to the litigation. In the De Beers case, the judge sought to clarify between two types of change that may increase the scope of work in a project: changes in breadth (or substance) and changes in depth (or mere detail). Here, the judge ruled that, under these parties’ particular contract, only changes in breadth were valid “changes” that require concomitant price changes (Court opinion, Para. 237).

1. Changes in Breadth (“Scope Creep”). A change in breadth involves a change that introduces functionality that was clearly outside the scope of the project when it was planned, and which may even have been explicitly stated to be out of scope. Changes in breadth are, effectively by definition, true changes in scope. The customer must pay.

2. Changes in Depth (“Complexity Levels). According to the service provider’s expert witness (hired for the litigation, rather than the initial project):

“The second type are changes that add scale or complexity to the work that was legitimately envisaged on the basis of the stated requirement, but that do not extend the required functionality into wholly new areas. These changes are often contentious because the customer may have understood the complexity from the start of the project and assumed that the supplier did too and based any estimates and plans on this understanding, whereas the supplier may legitimately have understood the requirement to be something far simpler than it subsequently transpires that the business actually needs.
… One test for this second type of scope increase could be to ask ‘is there a reasonable solution that meets the stated high level requirement, and at a significantly lower cost or effort than the minimum solution that would meet the business requirements as revealed by a detailed analysis?’. If the answer is ‘yes’, then the additional complexity is a scope change of [depth]…, and if it is material it should be the subject of formal change management.” (Court opinion, Para. 237).

3. Changes due to Insufficient Initial Customer Design or Description of the Business. Other changes arise when a customer has not been able (or willing) to devote adequate resources and time to initially identify its own processes sufficiently for a service provider to map and implement them into a standardized, repeatable process such as software. Such resource allocation impacts the project’s viability.

VI. Governance

A. Governance as a Framework for Communication. In any services agreement, relationship governance is a precedent condition to preserving rights and remedies. Good governance requires not merely managerial experience, good intentions regarding customer satisfaction, and “sweat equity,” but also defined, frequent, and detailed documentation of the interactions of the parties. Such documentation should specify joint planning, meetings, contractual allocation of decision making authority, and other scenario management in case of specific contemplated failures. Detailed governance provisions produce business benefits, including greater clarity regarding each party’s respective contractual compliance. And robust, granular process governance yields predictability in allocation of unexpected costs resulting from either party’s non-compliance.

The De Beers case shows what happens when well-defined, mutually-agreed, workable governance committees, structures and procedures have not been both created in initial contracting and then deployed in actual project activities, to confront the later, foreseeable inability of parties to communicate effectively during the project. Indeed, ignoring governance in negotiating and documenting a large project agreement, or including only inadequate, “template,” ultimately illusory governance prose, can undercut the odds of a successful transaction: if governance terms are to have any ultimate value, they must serve as the platform for meaningful, directed, consequential communication between the contracting parties.

B. Good Structures: Committees. The judge’s opinion identified several project-related committees in the governance structure:

• A Project Steering Group Committee, with representatives of each party, including top-level committee managers to coordinate diverse tasks and decisions and exchanges information on progress. The judge noted that governance committees adopted defined agendas for process management. These included (1) milestone verification, (2) “quality” gating, (3) declaration of possible impending disaster (e.g., “RED” status) and “fire drills” (“fire break,” in British English) to attempt to bring the project back on schedule.
• A Change Control/Approval Board. The software development agreement established a Change Control/Approval Board for exchanges of information and resolution of problems. This was an operational governance structure for persons active in the project on a daily basis.
• Internal Steering Committees, one for each party, for internal coordination.

C. Good People with Human Failings. When the De Beers project stalled in November 2007, the Steering Group Committee identified seven core requirements that were behind schedule and attributed the delays to challenges with both De Beers and Atos personnel and functions. (Court opinion, Paras. 79-88.)

As the customer, De Beers was alleged by its former “partner” Atos (after project and contract termination, in court finger-pointing) to have provided needed information late or not at all. The veteran global vendor also asserted that De Beers staff was not sufficiently available to Atos for business analysis. The unavailability of De Beers’ subject matter experts due to the normal demands of their day-to-day functional roles was aggravated by the resignation of the only person with a complete view of the existing systems as well as detailed knowledge of the legacy systems.

As the service provider, Atos had project-process control over other causes of delays, including (1) complexity of the processes to be analyzed, mapped and programmed and (2) the identification of “new” requirements that were “in scope” that required further elaboration. Atos failed to communicate its worries and its objections in a legally sufficient manner.

D. Contemporaneous Governance Records: Preserving Credibility. Effective contractual governance provisions impose a duty on each party to document contemporaneously its problems, conclusions and allocation of believed responsibility for cure. Contemporaneous documentation is credible in court. After-the-fact analysis documents often will not persuade or prove the desired point. As the Lord Judge Edwards-Stuart wrote: “As with many commercial disputes, therefore, it is the contemporaneous documents that tell the most reliable story, particularly those e-mails or minutes of meetings where there was little likelihood of their being composed for the benefit of posterity. It is upon the contents of these documents that I shall base the majority of my findings of fact.” (Court opinion, Para. 23.)

Otherwise, later-created documents, written only by one party, or only for the context of an arbitration, lawsuit, and/or mediation, may meet with understandable skepticism, as being merely belated efforts to “spin the story” and for corporate or career self-justification. In De Beers, the judge specified and discredited some managers’ views and even sworn testimony, as mere “prevarication” (Court opinion, Para. 28) or “at best an extreme case of wishful thinking and, at worst, simply untrue” (Court opinion, Para. 46).

Litigators and witnesses are often accused of re-writing history. For example, here, the court concluded as to one litigator’s guru that “many of his conclusions were impressionistic, rather than being founded on careful analysis [whose] credibility was not helped by the fact that he reached few, if any, conclusions that were unfavourable to his client” (Court opinion, Para. 66). Regarding the other company’s expert, the judge opined that “he came a little close to espousing his client’s cause rather too enthusiastically.” (Court opinion, Para. 67).

In short, business managers should not expect their company’s case to be either supported or saved by the eventual employment of a supposed expert witness and/or an excellent litigation team. Judges and juries routinely can and do consider, dilute or dismiss the assessments of such “hired guns.” Instead, let timely (i.e., mid-project, contemporaneous), detailed documents do the talking. (See article on E-Discovery on the process of finding and using admissible records in litigation.)

E. Settlement Negotiations after Scope/Cost Overruns. Atos tried to renegotiate the deal midstream after it failed to meet Key Milestone deadlines. The Atos proposal for restructuring the agreement presents a classic example of the poor odds of rescuing mid-project a commercial disaster-in-the-making. (Court opinion, Para. 156.) Atos proposed:

• A new estimate of the entire project completion cost, without profit (£2.9 Million).
• Re-setting of the baseline assumptions about the business requirements, based on the discoveries to date as set forth in Requirements Definition documents.
• Re-pricing (under change control) for all changes from such Requirements Definitions.
• Re-definition of what would be an “acceptable” final delivery.
• Offering to complete the work at cost (without profit).
• Customer’s waiver of prior legal or financial claims (i.e., of alleged vendor defective performance).
• Revisions to pricing structure.
• Revisions to rate structure.
• Adoption of newly stated assumptions that could result in future price increases.
• Payment for services already rendered.

Faced with such a vendor’s renegotiation proposal, the typical customer would react negatively, claiming:

• all project problems resulted from poor vendor performance (e.g., inadequate initial “scoping” in the separately-paid advance Initiation and Analysis Phase” work), and
• the renegotiation would have eliminated the fixed-fee structure and put it onto a time-and-materials basis.

De Beers rejected Atos’s renegotiation proposal.

VII. Failed Governance: Termination for Anticipatory Repudiation.

“In these proceedings each side is asserting that the termination was the result of a repudiatory breach of contract by the other which it accepted. Which of them is right about this is the central issue in the case.” (Court opinion, Para. 8.)

A. Anticipatory Repudiation by Customer. When can a customer threaten to terminate for a service provider’s believed non-performance? In any project involving milestones that must be met before payment is due, the customer must think – and document – very carefully before withholding payment. In the De Beers case, the customer rejected the service provider’s request to renegotiate and instead insisted on vendor’s delivery of the expected milestone deliverables prior to making an agreed-amount payment. The court found that the customer’s initial claim about the vendor’s supposedly missed milestone was not justified, and therefore the customer’s refusal to pay the valid invoice was done “simply to put pressure” on the service provider. (Court opinion, Para. 155). One message from this litigation is that a customer’s motivations, actual collaboration, and management skills, may be subject to later close analysis and public assessment.

B. Anticipatory Repudiation by Software Developer. When can a service provider threaten to suspend work, or terminate entirely, for a customer’s non-performance? Atos claimed entitlement to suspend services, due to De Beers’ both alleged non-performance and admitted interim non-payment. In industry practice, termination by a service provider is usually limited to the customer’s large, lingering non-payment or non-performance of some essential support function.

In non-performance (rather than non-payment) situations, the service provider’s entitlement to terminate is more problematic. First, under most contracts and per industry norms, the service provider must identify and notify the customer of that customer’s particular believed non-performance, such as failure to provide “adequate” services to facilitate, support or transition “in-flight” work to the service provider. Second, the service provider usually must give written (sometimes, very specific and/or documented) notice of default and an opportunity for customer efforts to cure. Third, the service provider must wait for the customer’s cure, and meanwhile might be burning money by idling its employees.

In the De Beers case, the service provider chose not to focus on the customer’s non-payment (which the customer justified by claiming the service provider’s non-performance). Instead, the service provider threatened termination, if the customer would not renegotiate greater project payment and later deadlines. The De Beers court found, as a matter of fact, that, “during the period from 21 May to 6 June 2008 Atos knew that the course upon which it had embarked would amount to a breach of contract. It committed that breach of contract deliberately and that amounted to both wilful and deliberate default.” (Court opinion, Para. 379.)

C. Deliberate Breach; Liability Cap. Where the customer’s damages are less than the liability cap, a service provider’s deliberate breach might not require interpretation of the liability cap. However, as a matter of common law in England and contract law, willful and deliberate breach may result in unlimited liability. Accordingly, prudent service providers might more easily rely on the customer’s non-payment than on the customer’s non-performance. Of course, where the service provider has breached its own performance duties, neither remedy might be available. For both parties, there is a non-typical action, after a contract interpretation and enforcement dispute arises mid-project. Expert legal interpretation comes into play, and the stakes are high to ensure that the analysis of rights, remedies and scenarios is accurate (and consistent with what a court will decide).

VIII. Conclusions

The De Beers debacle offers a diamond mine of “lessons learned” for software development projects. The failure of the contract arose from a combination of causes:

• the customer’s failure to initially know, document, or disclose the true complexity of its business process;
• the customer’s failure to make its SME’s and users available for process mapping;
• the customer’s failure to warn the service provider that the vendor’s apparent level of understanding of the challenges (even after the initial, separate, paid Initiation and Analysis Phase) was insufficient to achieve the quality metrics;
• the vendor’s apparent unwillingness to adequately drive and document compliance with a robust project governance process, and
• perhaps overlooked and/or omitted optimal provisions in the original contract.

The Lord Justice found that Atos would have reached the following bottom line:

• DB’s claim in respect of upgrading the legacy systems and the ThoughtWorks system that I have assessed at £4,411,831 must be reduced by £2,999,116, leaving a net claim for £1,412,715 (Court opinion, Para. 372.)

A. Lessons for Service Providers. For outsourcers, the De Beers dispute highlights the flaws of neglecting the critical functions of transition. Some business process outsourcing (“BPO”) service providers have developed general domain expertise, so that the provider is no longer dependent on one customer for either learning functional requirements or implementing the necessary processes for operations, governance, regulatory compliance and risk management. The De Beers case shows that certain industries are so unusual, even arguably unique, that they are left or relegated to operating in under-analyzed legacy silos rather than integrating. So service providers need to consider the relative rarity of the prospective customer’s business processes, and perhaps decline “specialized” or “complex” customers, or at least demur from the “fixed fee” model in such settings. Moreover, detailed, enforceable, and administratively enforced (i.e., actively managed) Reverse SLA’s are essential whenever project performance depends in part on customer personnel participation.

B. Lessons for Business Customers. For multinational companies, the De Beers case serves as a cautionary tale. First, unique businesses should create and update detailed process maps as part of business process management (“BPM”). Reliance solely on the expertise and continuity of veteran-employee individuals with “tribal knowledge” exposes the enterprise to risks of resignation, retirement, disability or death of key individuals (and, as here, their lack of cooperation with hired outsiders).

While De Beers technically won the lawsuit, it lost in many ways. De Beers was unable to prove damages of the actual cost of implementing the restructured IT platform, because De Beers only improved the legacy systems after the restructuring project’s failure. In fact, De Beers refused to explain why it failed to re-bid the software transformation project, after failure and termination of the Atos project. (One might speculate that disclosure of the truth would have upset De Beers’ geopolitical risk profile in Africa, particularly its relationship with the Government of Botswana.)

De Beers also lost because it failed to commit the necessary management discipline, contracting skills, and human resources capital to make the project a success. De Beers relied instead on what has become a too-frequent practice in sourcing and global services: letting the service provider fail even though the customer sees the failure likely coming, when the customer could prevent such failure by providing greater support.

C. No Meeting of the Minds. The Atos-De Beers agreement shows a failure to communicate, and a failure to reach agreement on the project – and presumably inadequate up-front contracting quality. The contract was geared towards a fixed fee, but the scope and project governance processes were not adequately complete and clear.

Both parties apparently underestimated the degree of technical challenge and complexity. De Beers appears to have become aware of Atos’s scope and effort under-estimation, but failed to alert Atos to disclose the true level of complexity and provide the necessary SME support. Atos failed to understand the complexity, and apparently was over-dependent on inadequate customer resources, leading to attempted mid-project transition from the “agile” software design/development methodology to instead the traditional “waterfall” methodology.

Due to this miscommunication about complexity and availability of SME’s, perhaps Atos chose an inappropriate software development methodology (“agile”). This methodology depended on obtaining timely requirements definitions on a continuous-flow basis. Atos signed the “initiation” project contract on an “agile” development basis. Atos then discovered that this initial approach conflicted with the actual later timing of customer inputs and collaboration documentation of detailed specifications.. So the vendor aspired to save the project by moving mid-stream to the classic “waterfall” methodology (which starts with “requirements” before “designing,” implementation, verification and maintenance). But “waterfall” would not work without customer SME support. In short, the technical analysis supporting Atos’ pricing methodology was flawed, aggravated by De Beers’ lack of SME support. This technical analysis misinformed the pricing model. Atos failed to put De Beers into default by formal contract breach notification for lack of SME support, so Atos bore the loss of the failure to communicate on key assumptions for the development methodology.

Where there is no meeting of the minds, there is no meeting of the wallets. So Atos had to open its wallet to pay approximately £1,412,715 in net damages. (Court opinion, Para. 371, subject to later tweaking per expected post-decision calculation of interest amounts).

D. Business Process Transformation Requires Next Generation Contracting. In designing ADM and BPM contracts, the rules are now changed. “Traditional” summary-style contracting, without granular definition of processes and related tools, is inadequate – an invitation for commercial and career disaster. Reverse SLA’s, resource commitments by the customer, and process design and redesign can reduce the risks of failure and improve the quality of the successful outcomes. Better contracting yields clear commercial benefits.

E. The Right Team Throughout the Project. Complex IT transactions need the right team. Executives and contracting professionals undertaking any large-scale initiative involving software design, development, testing, documentation, installation, integration and maintenance should identify and deploy the expertise of veteran outsourcing transactions professionals – on both sides. The team should be consulted throughout the process, especially after Key Milestones are missed.

In this case, Atos might have saved its skin by making some small changes in the structure of this arrangement. It should have deployed ongoing, mid-project consultations with veteran IT / outsourcing lawyers with nuanced project governance expertise. Atos failed to give a notice of termination for De Beers’ breach. Instead, Atos’s team chose the technical solution without protecting its legal interests. Perhaps Atos’ senior management let the technical team run alone without extensive legal support. Instead, Atos was found liable for £ 1,412,715 in damages – plus De Beers’ legal fees under the English loser-automatically-pays legal system.

F. Looking Beyond Traditional “Waterfall,” “Agile” and “Scrum” Project Management Methodologies: Moving from ADM to BPM. The De Beers software development project proves the need for project management paradigms that reduce the risk of failure, particularly in major transformations of complex systems. Lawyers, contracting professionals, finance executives, and others involved in large-money project procurement must invest effort to increase expertise regarding the overall industry environment in which they propose to do their procurement. Mere technical career skill (e.g., as an accountant, solicitor, or procurement manager) likely is inadequate to achieve excellence in corporate risk management, without a firm foundation of subject matter and the processes that the services agreement will implement.

The De Beers project also highlights the need for a meeting of the minds on both the project management methodologies and the business processes that the project will capture and harness.

The “waterfall” method of software development assumes that the parties can define all requirements before starting the programming, testing, verification, stabilization and maintenance functions. This assumes that the requirements are known and will not shift, and that the subject matter experts will deliver their process knowledge at the project startup.

As an “agile” or “dynamic system development method,” the “scrum” method assumes that business analysts and programmers can, as a full team on the rugby field passing the ball to and fro towards the goal, define and implement modules in a logical sequence, with intermediate testing of each module. Here, Atos organized a team of business analysts to define the business requirements, to work with a pool of software developers to be organized into teams to build elements of the solution incrementally, all supported by an architect and a few key software designers and programmers. This method assumes that the business analysts can gather the business requirements from the subject matter experts.

As a result of the problematic assumptions in software development, traditional applications development and maintenance (“ADM”) has morphed into business process management (BPM). Every ADM project requires some level of BPM foundations. Today, BPM software exists to capture tribal knowledge, make transparent such “company-specific DNA,” enable process optimization on a continuous process improvement basis, and build new, more flexible and more manageable organizations. With BPM processes well identified, organizations can evaluate and distinguish processes for in-sourcing, outsourcing or elimination of a process or function. And such evaluation can be conducted in an ongoing manner to implement both strategic and tactical changes in core operations and ancillary supporting functions.

For your large projects, dig deep and deploy granular contracting provisions and expertise, that draw upon the lessons learned in several global services-based industries – e.g., not just software development, but also IT and BPO outsourcing – to avoid that inevitable risk of expensive commercial disappointments and costs. And management should engage in BPM practices for business continuity, disaster recovery, process transparency and changeability, not just for software design.

Failed Deals: Software Development – De Beers / Atos Origin

October 20, 2010 by Bierce & Kenerson, P.C.