CITATION: Atos v. Sapient, 2016 ONSC 6852
COURT FILE NO.: CV-10-8845-00CL
DATE: 20161207
ONTARIO
SUPERIOR COURT OF JUSTICE
COMMERCIAL LIST
BETWEEN:
ATOS IT SOLUTIONS AND SERVICES GMBH and ATOS INC.
Plaintiffs
– and –
SAPIENT CANADA INC.
Defendant
Peter Griffin, Paul-Erik Veel and Julia Brown, for the Plaintiffs
Mark Gelowitz, Alex Cobb and Evan Thomas, for the Defendant
HEARD: September 28, 29 and 30, October 1, 2, 5, 6, 7, 8, 9, 13, 14, 15, and 16, December 7, 8, 9, 10, 11, 14, 15, 16 and 17, 2015, February 1 and 3, 2016.
L. A. Pattillo J.
Introduction
[1] In early 2006, Enbridge Gas Distribution Inc. (“Enbridge”) embarked on a major project to replace its many software systems with a single enterprise resource planning (“ERP”) software to manage the many various and complex facets of its business on a single IT platform (the “Project”).
[2] The prime contractor for the Project was the defendant Sapient Canada Inc. (“Sapient”). Sapient, in turn, subcontracted both the application management support services and the document conversion parts of the implementation of the ERP software to Siemens Canada Limited (“Siemens Canada”).
[3] The Project was massive and involved extensive planning and implementation. The installation of the ERP software began in June 2007 and was not completed until September 2009, five months behind schedule.
[4] On June 29, 2009, Sapient terminated the subcontract with Siemens Canada for cause.
[5] This is a claim by Siemens Canada for damages for wrongful termination of the subcontract. In turn, Sapient has counterclaimed against Siemens Canada for damages arising from the delay in completing the Project.
[6] For the reasons that follow, I have concluded that Sapient breached the subcontract with Siemens by wrongfully terminating it on June 29, 2009 resulting in Siemens being entitled to damages. At the same time, however, I am of the view that Siemens was also in breach of the subcontract at various times during the Project, entitling Sapient to damages as well.
The Parties
[7] Siemens is a world-wide organization involved in numerous business areas, including information technology. Siemens Canada and Siemens AG Osterreich’s IT Solutions and Services (“Siemens Austria”) were subsidiaries of Siemens. The plaintiffs, Atos IT Solutions and Services GMBH and Atos Inc. are successor entities to Siemens Austria and Siemens Canada respectively. For ease of reference, I will refer to the plaintiffs as Siemens Canada and Siemens Austria and collectively as “Siemens”.
[8] At the outset of the trial, I was advised that Siemens Austria was not pursuing its claim against Sapient.
[9] Sapient is a subsidiary of Sapient Corporation, a global consulting company.
The Facts
[10] The following is an overview of the background facts as I find them from the evidence.
(a) The Enbridge Request for Proposal
[11] Enbridge provides gas services to over 1.7 million residential, commercial and industrial customers in the Greater Toronto Area, the Niagara Peninsula, Ottawa, Brockville, Peterborough, Barrie and many other Ontario communities.
[12] On February 24, 2006, Enbridge issued a request for proposal (“RFP”) for the implementation of and application management support services for a new customer information system utilizing ERP software from SAP SE (“SAP”) to replace its many existing software systems (“Legacy Systems”).
[13] SAP’s software allows a business to integrate many of its core functions such as finances, billing, human resources, supply chains, distribution and inventory management into one central and efficient system. SAP software allows each customer to configure the software to its particular requirements. The SAP software chosen by Enbridge was SAP Industry Solution for Utilities (“SAP IS-U”), which is an industry specific software solution developed by SAP for gas, electric, and water utilities.
[14] The RFP defined the SAP IS-U implementation services to include project planning and management, design, configuration, development, integration, conversion, cutover, testing, system documentation, training, post production warranty and other services necessary for the implementation of the SAP IS-U software (the “SAP IS-U System”). Application management support services were defined as the effort and resources required to provide support services and support systems for the SAP IS-U System for a period of three years following the warranty period, renewable at Enbridge’s discretion for one-year periods.
[15] The scope of implementing the SAP IS-U System at Enbridge was immense. The Project sought to integrate and consolidate into one IT platform over 56 Legacy Systems dealing with Enbridge’s many business functions such as customer care, service orders, meter reading, billing and work management. These functions were previously operated through many different internally hosted and supported software systems as well as third party hosted and supported systems.
[16] Sapient, having previously worked on numerous system integrations and web-related projects for Enbridge had an ongoing commercial relationship with Enbridge and was interested in bidding on the RFP. However, it did not have the SAP IS-U references required by the RFP.
[17] Siemens Canada was also interested in bidding on the RFP. Siemens, and in particular Siemens Austria, had extensive experience with SAP and specifically SAP IS-U implementations in Europe. But Siemens had no previous commercial relationship with Enbridge.
[18] SAP introduced Siemens to Sapient and, after discussions between the two, it was agreed that Sapient would submit a bid to the RFP as prime contractor for the Project, utilizing Siemens’ support and experience in SAP implementation, and partner with Siemens as a sub-contractor to perform the application management support services portion of the Project.
[19] From the outset of their discussions, it was always understood that Siemens’ expertise and experience in respect of SAP IS-U resided with Siemens Austria and that any involvement of Siemens Canada in the Project would engage Siemens’ expertise and experience worldwide and particularly that of Siemens Austria.
[20] On January 31, 2007, Sapient submitted a response to Enbridge’s RFP. The opening sentence of the submission began: “On behalf of Sapient Canada Inc. (Sapient) and our partner Siemens Business Services (Siemens), we are pleased to submit this proposal.”
[21] Sapient was the successful bidder for the Project.
a) The Prime Contract
[22] On June 4, 2007, Enbridge and Sapient entered into a written agreement (the “Prime Contract”) which provides, among other things, that Sapient will provide specifications, project plan, configuration, integration and implementation of the SAP IS-U System. Sapient is also required to convert the data in Enbridge’s Legacy Systems and migrate it to the SAP IS-U System and provide application management support services for the system. The fixed price for Prime Contract was $49,500,000.
[23] The Prime Contract provides that the SAP IS-U System will be activated or “Go-Live” on April 3, 2009.
(b) The Subcontract
[24] Also on June 4, 2007, Sapient and Siemens Canada entered into a written agreement entitled “Implementation Services For SAP For Utilities Solution Agreement” (the “Subcontract”).
[25] The Subcontract provides that Siemens will provide application management support services (“AMS”) for the SAP IS-U System after Go-Live for a fixed price of $16,190,000.00 excluding taxes through the three-month warranty period and thereafter for a period of three years. The Subcontract also provides for two further one year extensions at Enbridge’s election.
[26] The Subcontract provides, as part of the AMS services, that Siemens will operate a 24/7 toll free call center to respond to calls from Enbridge’s help desk concerning the operation of the SAP IS-U System once it is up and running and will provide documentation support. The Subcontract sets out various levels of service including number of calls and response times.
[27] The Subcontract also provides that Siemens Canada will provide other services in relation to the Project at Sapient’s request on a time and materials basis.
(c) The Joint Liability Letter
[28] On June 5, 2007, Siemens and Sapient entered into an agreement in writing with Enbridge which provides that both Siemens and Sapient will be jointly and severally liable to Enbridge with respect to the performance of the AMS services (the “Joint Liability Letter”).
(d) The Data Conversion Amendment
[29] As noted, the Data Conversion portion of the Project involves extracting the data from Enbridge’s Legacy Systems; transforming it into a format required by the SAP IS-U System; and then loading it into the SAP IS-U System. Data Conversion is an automated process and the Legacy Systems continue to operate up until the SAP IS-U System “goes live”.
[30] Reconciliation is part of data conversion. The objective of reconciliation is to validate the accuracy of the converted data by matching it with data from the Legacy Systems.
[31] The Prime Contract provides that Enbridge is responsible for extracting the data from its Legacy Systems and staging it. Sapient is responsible for the balance of the data conversion services.
[32] By agreement in writing made as of September 30, 2007, Siemens Canada and Sapient agreed to amend the Subcontract to add data conversion services to Siemens Canada’s scope of work (the “Data Conversion Amendment”) under the Subcontract. The Data Conversion Amendment provides, among other things, that Siemens Canada will provide the Data Conversion Services in accordance with the Data Conversion Services Statement of Work, the Project Plan and the New Solutions System Specifications for a fixed price of $4,370,000.00.
[33] The Data Conversion Amendment further provides that Siemens Canada will provide the Data Conversion Services to Sapient in a manner that meets the milestones, deliverables and other requirements set out in the Data Conversion Statement of Work or which are reasonably required for the performance of such work.
[34] The Data Conversion Amendment also provides that Sapient will provide two Sapient resources to Siemens whose identities and terms were set out in Schedule13.2A. The individuals identified are Ruari D. Monahan (“Monahan”) and Jeffery A. Peterson (“Peterson”).
[35] The Data Conversion Amendment defines Data Conversion Services to be the services set out in the Data Conversion Services Statement of Work, Schedule 10A, attached as Appendix A to the Data Conversion Amendment (the “DC Statement of Work”).
[36] Section 2.5 of the Data Conversion Amendment adds Section 17.4 to the Subcontract and provides that Sapient can terminate the Data Conversion Services “for convenience” by providing notice to Siemens of such termination, effective from the date of the notice. The provision also sets out a formula for compensating Siemens in the event the Data Conversion portion of the Subcontract is terminated for convenience.
i. The DC Statement of Work
[37] The DC Statement of Work, Appendix “A” to the Data Conversion Amendment, sets out, among other things, Siemens’ Deliverables under the Data Conversion Amendment including workshop design specifications, data conversion programs and reconciliation programs. The DC Statement of Work further sets out the Data Conversion Milestones, which are the dates by which various tasks are to be completed, and specifies whether the tasks are Payment Milestones, giving rise to payment, Termination Milestones, permitting termination of the Subcontract by Sapient, or both. It also provides for late penalties in respect of interim and final milestones.
[38] The DC Statement of Work also deals with the reconciliation approach and provides, in part, that the “reconciliation process will be run during mock conversions to validate the accuracy of the converted data and conversion process. The final mock must result in no control point having a matching result outside of its pre-determined threshold.” The details for the Conversion control points were to be defined in a separate Conversion Reconciliation Approach document.
ii. The Conversion Approach and Strategy Document
[39] The Conversion Approach and Strategy Document (the “Document”) was prepared by Monahan and signed off on by Sapient and Enbridge in late September and early October, 2007. It outlines the Conversion requirements and approach for the Project. The Document deals with the three primary areas of the Conversion Track’s work:
Legacy Data Extract – extracting data from the existing Legacy Systems which are to be replaced by the SAP IS-U System. As noted in the DC Statement of Work, Enbridge was responsible for the legacy data extract;
SAP Conversion – loading data provided by the legacy data extract team as required to ensure that the SAP IS-U System has the requisite data to function correctly after Go-Live; and
Legacy Data Archive – storage of data extracted from the Legacy Systems and related archive sources in a medium outside of the SAP IS-U System such that it can be accessed as required after the Legacy Systems are decommissioned.
[40] Section 5.12 of the Document is entitled Conversion Reconciliation and Controls and provides in Section 5.12.1:
The conversion process must have the proper control mechanisms to measure its validity and success. Conversion controls typically take the form of counters on items such as total numbers of meters, business partners, etc. These totals are taken at the end of the conversion process to determine whether the conversion was successful. Any discrepancy that cannot be explained by known differences between Legacy source systems and the SAP IS-U system indicates that the conversion process could have data defects. Problems in conversion identified by control discrepancies will be investigated to determine severity and the proper course of action.
The Reconciliation approach includes multiple levels of validation, with each hand-off of data. These levels, activities and processes will be defined in greater detail in the controls approach document. Summary level controls will show at a system level the accuracy of the conversion process. The results of the overall conversion controls will be one of the primary factors in determining the success of conversion at cutover.
[41] Section 5.12.2 sets out the reconciliation approach and notes that the details for Conversion control points will be defined and maintained in a separate Conversion Reconciliation Approach document. It notes that the reconciliation process will be run during Mock conversions to validate the accuracy of the converted data and the conversion process. As provided in the DC Statement of Work, it further states that the final Mock must result in no control point having a matching result outside of its pre-determined threshold.
[42] The Conversion Reconciliation Approach Document was also authored by Monahan and was signed off by both Sapient and Enbridge in early February 2008. The Milestones and the individual control point targets for each of the Mock tests are set out in Part 5 as follows:
5. Milestones
Milestone
Deliverable
Activity
Target Date
Mock 1
(Integration Test 1)
Reconciliation Report
Run/Verify 75% of defined controls
September 8, 2008
Mock 2
(Integration Test 2)
Reconciliation Report
Run/Verify 90% of defined controls
October 13, 2008
Mock 3
(Integration Test 3)
Reconciliation Report
Run/Verify 100% of defined controls
November 17,
2008
Mock4
(User Acceptance Test Cycle 1)
Reconciliation Report
Run/Verify 100% of defined controls
December 22,
2008
Mock 5
(Dress Rehearsal 1)
Reconciliation Report
Run/Verify 100% of defined controls
January 23, 2009
Mock6 (Dress Rehearsal 2)
Reconciliation Report
Run/Verify 100% of defined controls
February 20, 2009
Mock 7
(Dress Rehearsal 3)
Reconciliation Report
Run/Verify 100% of defined controls
March 20, 2009
Go Live
Reconciliation Report
Run/Verify 100% of defined controls
April 6, 2009
Individual Control Point Targets (Based on Controls Executed):
Mock
Matches
Within Threshold (< +/- 5%)
Outside Threshold (> +/- 5%)
1
10%
30%
60%
2
20%
50%
30%
3
50%
30%
20%
4
75%
15%
10%
5
90%
7%
3%
6
95%
5%
0%
7
95%
5%
0%
The Project
[43] Overall, the Project was very large and complex. It involved hundreds of team members from Enbridge, Sapient and Siemens, as well as outside consultants and third party providers to Enbridge. There were many interdependent work streams involving numerous activities, all of which were working towards the common goal of the successful implementation of the SAP-ISU System at Enbridge.
a) Organization
[44] Overall responsibility for the Project was with the Project Management Office (PMO) whose role was to manage and oversee all other streams of the Project. The PMO included both Sapient and Enbridge resources but was under the direction of Sapient.
[45] At a high level, the resources on the Project were divided into two areas or what were referred to as “tracks”: the Functional track and the Technical track.
[46] The Functional track dealt with the SAP business (or functional) application. It was responsible for writing the computer code and configuring the SAP-ISU System to Enbridge’s business requirements and included the following teams or tracks:
i) Organizational Change Management track (OCM) – responsible for the preparation of Enbridge’s employees, customers and vendors for the use of the SAP IS-U System through training, education and communication;
ii) Cutover track – planning and transition from the Legacy Systems to the SAP IS-U System;
iii) Support Readiness track – providing the various activities necessary to support the users of the SAP IS-U System, including help desk; AMS; technical services; business application; customer care; and enterprise services.
[47] The Technical track dealt with information about Enbridge’s Legacy Systems and was responsible for writing computer code so that the SAP IS-U System worked as planned. It included the following teams or tracks:
i. User Acceptance Testing (UAC);
ii. Integration Testing (ITC) – testing that is focused on the overall SAP IS-U System, ensuring that the individual components link together as expected;
iii. Data Conversion (DC) – converting the required data from the Legacy Systems to the SAP IS-U System;
iv. Parallel Testing – testing of the Legacy Systems and SAP IS-U System together.
[48] Enbridge and Sapient established two committees that met regularly to review the status of the Project:
a) The Operational Steering Committee (OSC). The OSC was made up of track leads from the various tracks and representatives from the PMO. The OSC met on a weekly basis and reviewed and discussed the status of the Project. Status reports in various formats were prepared for the OSC meetings.
b) The Executive Steering Committee (ESC). The ESC included executives from various stakeholders participating in the Project including Enbridge, Sapient, Accenture and Siemens. The ESC met approximately every six weeks.
[49] In addition, Enbridge retained TMG Consulting (“TMG”), a consulting firm with experience in SAP implementation, to audit the Project. TMG prepared regular risk reports for the ESC meetings throughout the course of the Project. The risk reports set out the Project’s status generally and specifically in respect of the various tracks and was presented at the monthly ESC meeting in the form of a slide presentation. In addition to its slide presentation, TMG also prepared a memorandum each month summarizing the high impact risks and issues for the Project at that time.
[50] The OSC meeting reports were produced weekly and provided an update on the overall status of the Project, as well as detailed reports for each track. The report utilized a red, yellow, and green colour code to indicate the status of each track. In addition, the report noted any significant issues in respect of each track.
[51] Given that the OSC, ESC and TMG reports/memorandums were prepared during the course of the Project and were relied on by both Siemens and Sapient during the trial, I accept the contents of those documents as reflecting the truth of their contents.
[52] The implementation of Enbridge’s SAP IS-U System involved five stages:
Project Preparation – estimated to be a four week period at the outset during which the Project team would set the Project standards and begin to plan the Blueprint Phase, which was the next phase;
Blueprint Phase – estimated to run for 18 weeks during which a series of workshops that involves all the stakeholders is held to map out the technical and business requirements for the new SAP IS-U System and lay the groundwork for all the design work to follow;
Realization Phase – this phase, which was estimated to last 54 weeks, includes configuration, design and building of the enhancements and interfaces for the SAP IS-U System. Several activities take place during the Realization Phase, including testing the configuration developed in the Blueprint Phase; change management activities, such as developing a strategy for Enbridge end users; integration testing; and data conversion design and development;
Final Preparation – estimated to be 13 weeks during which user acceptance testing, dress rehearsals of data conversion and end user training would occur; and
Go-Live and Support – planned for 14 weeks during which a two week cut-over period (from the Legacy Systems to the SAP IS-U System) would occur, followed by a 12 week warranty period.
[53] The organizational chart for the Project was large and contained many levels. At the top were two committees established by Enbridge and Sapient that met regularly to review the status of the Project, the OSC and the ESC.
[54] To oversee and direct the Project, both Enbridge and Sapient appointed Program Managers. Enbridge’s Program Manager was Greg Wilson. During the Project, Sapient had three Program Managers. Initially it was Mike Rose, who had previous SAP implementation experience. Mr. Rose was replaced early on by Kumar Piraviperumal (“Kumar P”). Finally, in February 2009, Kumar P was replaced by Robert Child (“Child”). Child had extensive experience in project management but no prior SAP implementation experience.
[55] In addition, each track had a program manager who, in turn, reported to the Program Manager.
b) The Project Phases
[56] The initial Project Plan provided that the Project Preparation Phase would begin on June 4, 2007 (the day the Prime Contract was signed) with a Go-Live date of April 3, 2009 (21 months). The Blueprint Phase was scheduled to begin on July 3, 2007 and be completed in November 2007.
[57] By the end of the Project Preparation Phase, several major Milestones, including the Project Work Plan, the Project Charter and the Project Management Standards, Controls and Procedures were already late.
[58] The Blueprint Phase was also delayed and was not completed until February 2008, some three months beyond the originally scheduled completion date. As a result of the delays to the Blueprint Phase, the Realization Phase did not begin until the winter of 2008. Further, as noted by TMG in its reports, the delay to the Blueprint Phase had the effect of using up all of the contingency time that had been built into the Project Plan.
c) Data Conversion
[59] The kick-off for Data Conversion was in June 2007. Data Conversion involved extracting the required data from Enbridge’s Legacy Systems and then converting that data to the SAP IS-U System. As noted, under the agreements, Enbridge was responsible for extracting the data from the Legacy Systems.
[60] The Data Conversion Amendment involved three different steps:
The presence of Siemens Data Conversion team in Toronto to work with the Functional Team once the functional specifications were completed;
The Data Conversion team at Siemens Austria would then design the specifications for the computer program that would convert Enbridge’s legacy data into the SAP IS-U System;
The specifications would then be utilized by Siemens Austria’s colleagues in Romania to create the computer code for Data Conversion.
[61] In the overall organization chart, Data Conversion was part of the Technical Team.
[62] The individual at Siemens Canada responsible for the Subcontract and its representative on the ESC was Holger Kormann. Mr. Kormann’s counterpart at Sapient was Mudit Kapur (“Kapur”), a Sapient Vice-President who was Sapient’s liaison/client representative for Enbridge and a member of the PMO. Siemens project managers were Monahan on site and Bernard Kappel (“Kappel”) in Austria.
[63] The Prime Contract provided that Enbridge was responsible for extracting the data from the Legacy Systems to a staging area. Sapient, subcontracted to Siemens, was responsible for converting that data to the SAP IS-U System.
[64] Siemens Data Conversion team participated in the workshops with Enbridge during the Blueprint Phase in order to obtain the information necessary to prepare the design specifications for Data Conversion. None of the delays in the Blueprint Phase were attributable to Siemens work on Data Conversion.
[65] Section 3A of Schedule 13.2 of the Data Conversion Amendment provides that the first payment of 10% of the Data Conversion fee was due to Siemens on December 7, 2007 following successful completion of all services and deliverables of the Blueprint Phase. The payment was not made until March 22, 2008.
[66] Problems with Data Conversion began to arise during the Realization Phase. Siemens development of the Data Conversion code fell behind schedule in the spring/summer of 2008 due primarily to personnel issues with Siemens’ Data Conversion Team in Romania.
[67] In April 2008, Monahan and Peterson traveled to Romania to meet with the development team. Following the visit, Monahan sent an email to Kappel. Although he noted he had a good impression of the team, he made a number of constructive comments including that he felt the team lacked motivation and had no sense of urgency. Kappel agreed.
[68] As time went on, Monahan became more and more critical of the progress and more specifically of the lack of progress by Siemens’ development team. In particular, he raised lack of resources, resource allocation, more focus on reconciliation development, lack of technical unit testing and the continuing lack of a sense of urgency of the team.
[69] Thomas Standhartinger (“Standhartinger”) joined Siemens in March 1988. He is the Program Manager in Energy and Utilities for Atos IT Solutions and Services GMBH located in Graz, Austria. Up to the time of the Subcontract, Standhartinger held a similar position with Siemens Austria and had significant experience in implementing SAP IS-U for utilities in Europe and specifically data conversion. Standhartinger was responsible for the data conversion portion of the Subcontract at Siemens Austria.
[70] As a result of the problems that Monahan was raising, Standhartinger became more actively involved in the Project in the summer of 2008. Following a review of the status, he directed that certain people be removed from the development team and additional resources added in Romania. He also directed that the working hours be increased to improve performance. As a result of his assessment, Standhartinger also concluded that the issues surrounding the progress of the development of the Data Conversion code were not solely attributable to Siemens but also arose from delays in business data mapping, functional specifications and data process mapping, all of which were the responsibilities of Sapient’s functional team.
[71] Notwithstanding Standhartinger’s changes, issues concerning development of the Data Conversion code continued into the fall of 2008. Siemens fell behind in completion of the core development and the reconciliation control development.
[72] In the fall of 2008, Standhartinger travelled to Toronto. On September 25, 2008, he and Kormann presented an integration plan to Enbridge that set out the steps required to remedy the problems that had arisen with Data Conversion. The plan included improving communications; adding to Siemens personnel onsite at Enbridge; improving Siemens management on the Project and retaining an SAP expert to review the issues concerning the development of Data Conversion code and the reconciliation tool. The plan was well received by Enbridge.
[73] In early October, 2008, Siemens retained Fritz Keller (“Keller”), a SAP employee with significant SAP expertise, to review Siemens’ Data Conversion program. Keller noted, among other things, that the data conversion issues were being caused by continued development/corrections and inadequate preparation of the SAP system to support a large data load.
[74] Also in October 2008, Sapient issued change orders to Siemens for the assistance it had provided in respect of Data Conversion. Siemens disputed the change orders.
[75] In its October 29, 2008 memorandum for the ESC, TMG noted a number of risks facing the Project including Integration Testing; Conversion; OCM; and Leadership and Resource Management. Specifically, it noted that completion of ITC 1 was delayed for six days mainly for three reasons: 1) sub-standard quality of converted data for testing; 2) in-effective resource allocation for testing; and 3) sub-standard quality of test scripts.
[76] In respect of Conversion, TMG noted a number of issues, including a delay to Mock 1. It referred to Siemens plan and other initiatives to address the issues and indicated that it was not certain at that time whether Go-Live would be delayed. In relation to Leadership, TMG observed ambiguities around accountability and leadership for key project activities, which it believed was hampering the effectiveness of the Project’s execution and delivery. It also noted significant issues surrounding resource management.
[77] On November 5, 2008, Siemens received its second and last payment under the Data Conversion Amendment. Pursuant to Section 3A of Schedule 13.2 of the Data Conversion Amendment, the payment was due on June 13, 2008.
[78] In the late fall of 2008, Kappel left the Project due to illness. In his place, Siemens brought in Michael Kelble (“Kelble”) to be the Data Conversion project manager and appointed Martin Stengel (“Stengel”) as the technical lead.
[79] In its December 10, 2008 memorandum to the ESC, TMG set out its top five issues/risks: Data Conversion, Overall Project schedule, OCM, accountability and leadership.
[80] In respect of Data Conversion, TMG stated:
Data conversion challenges lead to a majority of the delays incurred during integration test cycles 1 & 2. These were mostly due to challenges associated with coordinating the teams in Europe. This was negated by co-locating the conversion with the rest of the CIS team. Also, there are some issues around skill-set of some of the conversion team members. Sapient and Siemens are jointly addressing this issue.
Data release for integration test cycle 3 is delayed significantly from the original plan. The plan was to have the data to start integration cycle 3 on Nov/17/’08. This date was changed to December/05/’08 approximately three weeks ago. When this report was written, the Dec/05/’08 due date could not be met and the project team does not know the estimated completion date for the data release for ITC3. Also, the project team has recently discovered some issues with code in the regional data structure. This has further delayed the release of data.
[81] At the ESC meeting on December 10, 2008, it was acknowledged that the April 3, 2009 Go-Live date was not achievable. The reports for the meeting note that there were multiple work streams behind schedule.
[82] In December, 2008, Child joined the Project as an engagement manager. His presence created issues for Kumar P.
[83] In its memorandum dated December 19, 2008, TMG noted that the Project was behind schedule in all areas/tracks. Tracks mentioned were Data Conversion, OCM, Project planning and co-ordination (Project Management), delays in business decisions and issues with the Functional Teams’ readiness. The ESC report of the same date listed the same concerns.
[84] On January 9, 2009, John Motherwell, the Enbridge Technical lead on the Project, sent an email to numerous Enbridge, Sapient and Siemens personnel working on the Project entitled “Conversion Team — A Note of Thanks.” He stated in part:
Folks, over the past month and a half, the Conversion team has gone through a marathon of defects, test runs and more in an effort to achieve improved quality and completeness of SAP Converted Data. Compounding the challenge was the need to simultaneously execute both ITC3 data conversion and Mock 2 data conversion, preparations and execution of which occurred largely in parallel. Much of this has required significant professional and personal sacrifices from each of you that Ramesh and I recognize, respect and thank you for making on behalf of the project. So we would like to personally THANK YOU for those great efforts.
I am sure as well that you are interested to hear how things are going with the SAP converted data – Early reports from our integration test team on ITC3 is that the converted data quality is much, much improved and your efforts lead us to believe that we have removed data quality as a concern for ITC3. Let me and Ramesh be the first to congratulate you on this great effort and result – it is very much appreciated.
[85] In the January 28, 2009 TMG memorandum, it noted that the Project team had concluded that June 15, 2009 would be the new proposed Go-Live date. TMG listed the top five issues/risks in achieving a June Go-Live date: overall project schedule, data conversion, OCM, cut-over planning and project planning, management and coordination. All of the issues/risks were classified as “red” except data conversion which was classified as “yellow” and “steady”. In respect of data conversion, TMG stated in part:
Mock 2 was completed as per plan and data release for ITC3 met quality criteria as planned. Based on our findings, TMG feels that this data is useable for testing purposes. The accuracy of the data is also improving quite significantly.
[86] On January 29, 2009, the PMO officially changed the April 3, 2009 Go-Live date to June 7, 2009.
[87] Also in January 2009, Child conducted a review of Sapient’s resources on the Project. As part of the review, Jason Paau (“Paau”), a Sapient employee whose role on the Project included staffing, advised Child that Sapient was short on resources both on the technical team (32 people) and the functional team (20 people) for the month of February alone.
[88] In early February, Child reported that Sapient was significantly short on resources. He recommended the removal and replacement of certain project managers and the possible hiring of a further project manager to manage defects. He stated, in part: “current projections show us missing the June date by between 4-8 man weeks.” Child raised a number of critical issues including that the OCM track which he described as “on fire” and the need for a number of senior managers/managers.
[89] In early February 2009, Sapient brought in Sanjay Thomas (“Thomas”), a Sapient director from Chicago, to evaluate the Project. Thomas raised a number of concerns in respect of Sapient’s management and the lack of resources similar to Child. One of the issues Thomas raised was replacing Kumar P as Program Manager. Thomas’ view was that the June Go-Live date was not achievable.
[90] Later in February 2009, Child became Project Manager taking over from Kumar P. He remained as Project Manager until the end of the Project.
[91] On February 12, 2009, Mock 3 was completed. While the reconciliation results were improved over Mock 2, they were still below the targets set out in the Reconciliation Approach Document.
[92] In responding to the reconciliation results, the Data Conversion Team raised with Sapient a number of issues that impeded its progress. These issues included environment constraints, the use of the existing environments by other teams that was preventing Data Conversion from access, lack of a frozen environment, as well as continued functional and configuration changes.
[93] In the February 25, 2009 TMG memorandum, TMG noted in the executive summary: “Almost all tracks are behind schedule – without a resource loaded plan, it is difficult to ascertain if June 2009 Go-Live date is viable.”
[94] Senior representatives of Sapient and Enbridge had a meeting on March 5, 2009, to discuss and attempt to resolve some of the financial issues that had arisen during the Project from Sapient’s viewpoint. In preparation for the meeting, Kapur sent an internal email within Sapient listing talking points for the Sapient participants which stated in part that the Project “is really not a commercially appealing proposition for us any longer.”
[95] Following the meeting, Hank Summy (“Summy”), a Senior Vice President of Sapient who was Sapient’s lead on the Project and who was at the meeting, sent a short email to Kapur and Child that concluded: “Keep our team positive and out of the commercial weeds and focused on getting our tracks rock solid and proud of their performance but highlighting every point of failure outside of SAPE [Sapient].”
[96] On March 5, 2009, Mock 4 was completed. The reconciliation results were better but still significantly below targets. Also on the same date, Siemens (Kelble) asked Sapient for a code freeze, noting that change requests and external changes to the SAP IS-U program continue to impact the Conversion team’s ability to solidify the conversion code.
[97] On March 9, 2009, Siemens raised with Enbridge the need for a dedicated client environment in order to carry out reconciliation discrepancy analysis. With the high use of the system by the various tracks, there were not enough environments to enable the conversion team to carry out its work.
[98] In its March 10, 2009 memorandum, TMG identified the key risks for the Project. They were: 1) UAT – timeline and resources; 2) OCM; and 3) Resources. In respect of resources, TMG noted the departure of Kumar P and that Child would be taking over as PM. It commented that there was insufficient SAP expertise in the PMO.
[99] For the March 25, 2009 ESC meeting, TMG’s memorandum noted that the risks included the overall project schedule; data conversion (due to low results from Mock 4 reconciliation); OCM; cutover planning and departmental readiness. It further noted that, among other things, project management was leading to delays in all aspects of the Project.
[100] On March 26, 2009, the Data Conversion team (Kelble) made a presentation to the OSC concerning the environmental constraints and the external changes by the functional team that were impacting on Data Conversion.
[101] By mid to late March, concerns began to again rise with respect to Data Conversion as a result of it not meeting the quality metrics for the Mocks. Sapient (and Enbridge) began to be more critical of the Data Conversion team’s work based largely on the results of the reconciliation tool during the Mock tests.
[102] In early April 2009, Sapient (Child) asked Siemens for a concrete plan to improve the results for data conversion. In response, Siemens retained Christopher Compeggie, a senior consultant with Quintel to provide a quality assessment of the Data Conversion team’s work and a plan for Data Conversion. Mr. Compeggie has extensive experience in relation to SAP-ISU implementations with data conversion and data conversion code experience in particular. In carrying out the work, Mr. Compeggie involved associates from Quintel who also had extensive experience in relation to SAP IS-U implementations, including data conversion and data conversion code experience.
[103] Mr. Compeggie’s initial mandate was to review the Data Conversion specifications and code, the defects associated with Data Conversion and the reconciliation program.
[104] Based on the review, Mr. Compeggie’s overall conclusion was that the Data Conversion specifications and code were of good quality. The Data Conversion defects he and his associates saw were typical for an SAP IS-U project at that stage. The defects had reduced significantly from January to April 2009.
[105] The same was not true, however, with respect to reconciliation. In that regard, it was Mr. Compeggie’s view that the reconciliation program was not providing accurate results in respect of the quality of data conversion.
[106] Following his review, Mr. Compeggie prepared a “Go Forward” Plan which set forth his views as to the steps required for Data Conversion to meet the June Go-Live date. Those steps included committing more resources to testing both on the Data Conversion and the functional side and more hardware; “rapid-fire loading” (conducting tests more rapidly using small batches of data); and a freeze change to prevent any further changes to the SAP IS-U program from the Functional Team.
[107] The minutes of the April 8, 2009 OSC meeting show Data Conversion as red for the first time due to issues with reconciliation. At the same time, ITC 3, cut over and support readiness were also shown as red.
[108] The Go Forward Plan was presented to Child on April 17, 2009 and quickly rejected by him as not being detailed enough. Mr. Compeggie subsequently amended the Plan a couple of times to address some of Child’s concerns by providing more detail and a time line but each revision was rejected by Child.
[109] Subsequently, Mr. Compeggie and his associates prepared a final audit report to Siemens dated May 15, 2009 that concluded that Siemens Data Conversion specifications and code were of good quality and were not the fundamental source of the data quality errors. Further, the reconciliation program was not an appropriate measure of the quality of the converted data. It was not designed to measure data quality but rather business readiness.
[110] In its Memorandum dated April 29, 2009, TMG stated that the overall status of the Project was “Red” and “Deteriorating”. It listed the top 5 issues/risks that may adversely impact the quality, timeline and budget of the Project, all of which it noted as “Red”: 1) Overall project schedule; 2) Conversion; 3) Cut-over Planning; 4) Financial Reconciliation Testing; and 5) Department Readiness.
[111] With respect to Overall project schedule, TMG noted as follows:
o Current Go-Live date is Jun/15/’09. This date may not be possible for the following reasons:
o More than one track lies on critical path. Conversions, UAT, Parallel test, Integration Test Cycle 3-Extension all lie on the critical path. Any delay in each of these tracks may ultimately impact in the Go-Live date.
o There is virtually no time contingency left in the plan. There is no slack in the timeline that can forgive slight delays or set-backs.
o Some of the tracks are behind schedule. UAT progress is gated due to outstanding defects. ITC3-X will not be completed in time (May 1/’09) due to number of defects yet to be fixed and many defects that were fixed but not integration tested.
o There are environment and resources constraints that are limiting options. Due to double-stacking of activities, both environments and resources (especially functional team) are stretched thin and multi-tasked. This also makes the timeline flexible.
o The team is unable to identify root-cause for conversion issue and hence cannot estimate time and/or number of mocks required to fix the defects. This is gating the Go/No-Go decision for Go-Live and will ultimately impact project schedule no matter if the rest of the tracks are ready for cut-over.
o Based on these observations, the most optimistic timeline for Go-Live is Jul/’09. This assumes that all conversion issues are identified and measures will be in place by the end of Apr/’09.
o TMG considers this risk to be “Red” and “Deteriorating”.
[112] On May 7, 2009, the PMO decided to delay the June 7, 2009 Go-Live date to September 7, 2009.
[113] On May 27, 2009, TMG reported that Go-Live was further postponed due to chronic conversion issues. It noted that the conversion induced Project delay has improved the status of many tracks.
[114] The June 24, 2009 Mock 7 results were favourable.
[115] On July 24, 2009, Go-Live was again deferred from August to September 2009 due to a few outstanding items which made cut-over in August premature. It was also noted that a number of other areas would benefit from the delay.
[116] On July 29, 2009, the ESC minutes note that the Mock 8 results were better than Mock 7 and met targets. Billing success and accuracy indices for Mock 8 were in the high 99th percentile. The governance team agreed that conversion was ready for cut-over. At the same time, the other issues that existed were cut-over planning, Financial Analysis and Comparison testing, departmental readiness and OCM. TMG noted that the delay to Go-Live in September would help OCM and the Business Readiness tracks.
[117] Go-Live occurred on September 12, 2009.
AMS
[118] As noted, the AMS portion of the Subcontract required Siemens to implement and operate a 24/7 toll free call center to respond to questions or concerns from Enbridge’s IT help desk in respect of the New System. The Subcontract provided that the AMS services were to begin immediately following Go-Live.
[119] Schedule 1.1.99 of the Subcontract sets out two Milestones concerning AMS that Siemens had to meet before Go-Live: Milestone #47, which provides for a “Transition to Application Support Plan” on December 18, 2008 and Milestone #64, which provides for the successful completion of the transition to “Application Support team for Rollout 1 Functionality” on March 20, 2009 (two weeks before the original Go-Live date of April 3, 2009).
[120] The Transition to Application Support Plan is a detailed plan addressing the methodologies used by Sapient, Enbridge and Siemens to accomplish handover and knowledge acquisition/transfer necessary to prepare the AMS team for its post Go-Live work. The second Milestone was closely linked to the initial Go-Live date of April 3, 2009 and was to ensure the AMS team’s readiness for Go-Live.
[121] The AMS track was part of the CIS Support Readiness Track that was overseen by representatives from Enbridge, Sapient and Siemens who attended weekly meetings. The Track produced weekly status reports detailing the status of each track, including AMS (the “Support Readiness Status Report”).
[122] In addition, the Support Readiness track reported weekly to the OSC, whose reports contained a summary of the status and issues in each track.
[123] Mr. Steve Carrington (“Carrington”), Director of Professional Services for Siemens, was an active member of the AMS track and attended the weekly CIS Support Readiness Track meetings on behalf of Siemens. Daniel Ornstein (“Ornstein”) was Sapient’s lead for the CIS Support Readiness Track and also attended the meetings. Carrington testified. Ornstein did not.
[124] The Support Readiness Track’s kick-off was on July 31, 2008.
[125] In September 2008, Enbridge representatives travelled to Bangalore, India to view Siemens support facilities for AMS.
[126] On September 15, 2008, Leonardo Fernandez joined Siemens as the Project Manager for AMS. Pursuant to Milestone 47, Mr. Fernandez delivered the final draft of the Transition to Application Support Plan on December 23, 2008, following discussions with and approvals of the document from both Sapient and Enbridge.
[127] In early November 2008, Sarah El Sadat joined Siemens’ AMS team.
[128] While the payment provisions for AMS in the Subcontract reflected that the Siemens’ AMS team would start one month before Go-Live, at the request of Enbridge and Sapient, in early January 2009, Siemens agreed to have its AMS personnel onsite 90 days prior to Go-Live.
[129] Carrington testified that because of the nine-week delay in the Go-Live date from April 3, 2009 to June 7, 2009, which was announced at the end of January 2009, Siemens adjusted the timing of its hiring to coordinate it with Go-Live.
[130] On February 18, 2009, Siemens Canada provided a letter of intent to Siemens IT Solutions and Services Limited India (“Siemens India”) to retain their services to support AMS.
[131] Siemens’ plan for staffing AMS called for it to have five people onsite at Enbridge, including Mr. Fernandez, and eight offshore in India. By late February 2009, Siemens had commenced interviewing candidates and extending offers of employment for the positions. Throughout, Siemens kept both Sapient (Ornstein) and the Support Readiness Track apprised of its staffing progress.
[132] The Support Readiness Status Report dated February 25, 2009 noted that the AMS track was interviewing for positions.
[133] In early April 2009, Ornstein raised a concern with respect to the slowness of Siemens staffing of the AMS track. Siemens responded on April 14, 2009, providing Ornstein with its then current staffing status.
[134] The April 29, 2009 Support Readiness Status Report indicates that for the onsite positions, Siemens had staffed one, had an offer accepted for another, had one offer pending and had identified two candidates (who were Sapient resources). Offsite in India it had staffed five positions and had three still open. The critical issues listed were delay in ensuring that project documentation met the requirements for knowledge transfer and the operations run book, both of which were Sapient responsibilities. AMS staffing was not listed as a critical issue.
[135] On May 7, 2009, the Go-Live date was again moved from June 7, 2009 to September 7, 2009.
[136] The May 13, 2009 Support Readiness Status Report noted that in respect of AMS, for the onsite positions, Siemens had three positions in place, one scheduled to start in early May and one offer outstanding. For the offshore positions, three positions were in place, two more were starting in early to mid-May and for one position Siemens was still looking for a candidate. The critical issues identified remained the same as in the April 29, 2009 Support Readiness Status Report.
[137] Both the May 27 and June 10, 2009 Support Readiness Status Reports indicate that of 10 positions required, AMS had staffed only two positions and had two more pending. The Status Reports for June 17 and 24, 2009 indicate that of 11 positions needed for AMS, only one was staffed and one was still pending.
[138] On June 19, 2009, Child asked Paau to provide him with a list of Siemens personnel working on the Project. By return email, Paau sent Child a list that noted that in respect of AMS, Siemens had nine people in place: four onsite and five offshore.
[139] The reason for the difference in staffing status from the earlier Status Reports was not provided. Carrington testified that the later Status Reports were wrong in setting out the state of Siemens AMS staffing.
Resolution
[140] In or around July 2008, Sapient advised Siemens that it had been approached by Enbridge with a request to renegotiate the AMS portion of the Prime Contract on account of budget approval issues. Siemens agreed to renegotiate the AMS portion of the Subcontract (the “Resolution”).
[141] Through the early fall of 2008, as a result of the Sapient/Enbridge request, Siemens conducted extensive internal detailed cost/price reviews that were followed by detailed negotiations with Sapient.
[142] In January 2009, the Resolution was agreed upon in principle by both Siemens and Sapient and sent to Enbridge for review. The agreement provided for reduced fees based on reduced services. It was also agreed that Siemens’ share of the onetime fee that Sapient had negotiated with Enbridge for the Resolution was $400,000, payable $80,000 on the signing of the revised contract and $320,000 no later than September 30, 2009. Thereafter, Siemens heard nothing further from Sapient concerning the status of Sapient’s discussions with Enbridge concerning the Resolution.
[143] Notwithstanding that Siemens heard nothing further from Sapient concerning the Resolution, it continued to prepare for AMS as noted.
[144] Sapient continued to negotiate with Enbridge concerning amending the AMS portion of the Prime Contract. An agreement was reached between Sapient and Enbridge in the spring of 2009 and signed on June 30, 2009.
The May 5, 2009 Agreement
[145] In April 2009, in light of the issues concerning Data Conversion, Sapient pressed Siemens to take over the lead of the Data Conversion team. Siemens ultimately agreed to Sapient’s proposal with a view to maintaining a good relationship and getting the SAP IS-U System to Go-Live.
[146] At a meeting between the principals of Siemens and Sapient on May 5, 2009, it was agreed that Sapient would assume overall responsibility for Data Conversion. Further, Siemens’ leadership would stay involved and Siemens Data Conversion team members would continue to work on the Data Conversion track under the direction of Sapient management.
[147] The parties further agreed that the provisions of the Subcontract in respect of Data Conversion would remain in force. Sapient requested that Siemens consider concessions on the fixed price for Data Conversion in the Subcontract and it was agreed that the request would be discussed and mutually agreed to.
[148] At the meeting, Sapient also requested that it take over full control of the AMS portion of the Subcontract as well. Siemens rejected this request and Sapient reserved its rights to open contract restructuring discussions in the future.
[149] Following May 5, 2009, Siemens’ Data Conversion team continued to work on the Project under Sapient management. Although the parties met to discuss and agree on the terms of the continued involvement of Siemens’ Data Conversion team after May 5, 2009, no agreement was reached.
Sapient’s Termination of the Subcontract
[150] On June 22, 2009, Sapient made the decision to terminate the Subcontract.
[151] On June 29, 2009, Sapient delivered a letter to Siemens terminating the Subcontract (the “Termination Letter”).
[152] The Termination Letter provided as follows:
Sapient hereby notifies Siemens that Sapient is terminating the Subcontract, pursuant to section 17.2 of the Subcontract, for material breaches by Siemens. These breaches are not capable of being cured, therefore Sapient is terminating the Subcontract immediately.
Despite Sapient’s efforts to get Siemens to perform, Siemens does not perform conversion services with sufficient skill and quality to meet the requirements set out in the Subcontract. Notably, testing of Siemens’ data conversion code (through various “Mocks”) has revealed that the code has failed to convert data at a level of accuracy that is even close to the expected performance requirements or industry standards.
We have been in discussions with Siemens for several months and exchanged several written proposals in an attempt to mitigate the damage done by the Subcontract breaches. Siemens has failed to remedy the situation or even acknowledge the gravity of the situation. It is now too late for Siemens to alleviate the damage done to the project.
[153] On June 30, 2009, Sapient executed a new agreement with Enbridge for the provision of AMS services.
[154] Also on June 30, 2009, Enbridge approved Milestone 54 and paid Sapient $7,796,250, which was the full amount of the payment due in respect of that milestone. Sapient paid no monies to Siemens.
The Experts
[155] Both sides called experts to give evidence in respect of the quality of Siemens’ Data Conversion code, Siemens work on Data Conversion, the reasons for the delays to Go-Live, Sapient’s management of the Project and Siemens preparedness for AMS.
[156] Siemens called Mr. David Rienhart and Mr. Eric Kimberling. Sapient called Mr. Peter Blackmore and Mr. William Marsh. All four were qualified by me to give expert evidence in respect ERP and ERP-SAP implementations and in particular data conversion.
a) David Rienhart
[157] Mr. Rienhart has extensive experience in SAP implementation projects and in all aspects of Data Conversion from a technical perspective, including writing and analyzing conversion design specifications, writing conversion code, writing reconciliation programs and conducting code reviews. He also has experience in project management.
[158] In preparation for his opinion, Mr. Rienhart examined a broad range of documents including the Data Conversion design specifications, unit test results, the results of various other tests and email correspondence. In addition, he examined and compared the most recent version of the Data Conversion code produced prior to May 5, 2009 and the Data Conversion code used for Go-Live.
[159] Mr. Rienhart testified that he did not observe any significant changes to the Data Conversion code as at May 5, 2009 and the Data Conversion code used for Go-Live. His opinion was that Siemens’ deliverable quality in respect of the Data Conversion code was of an adequate standard and conformed to best practices. He was also of the opinion that Siemens’ technical competency was of an adequate standard.
[160] Mr. Rienhart testified that while there was a high number of Data Conversion defects reported after May 5, 2009, many were either misclassified or duplicates. After removing those, Mr. Rienhart was of the view that the majority of the defects that remained were not attributable to workmanship problems on the Data Conversion team. In his opinion, the defects that remained were a reasonable number.
[161] Mr. Rienhart also reviewed the conversion design specifications generated by the Data Conversion team, including the version control history, which documents the changes and the reason therefore. He testified that although there were changes to the specifications after June 29, 2009, in his opinion, those changes were for the most part for new requirements or additional features and were not to correct any defect in the Data Conversion program.
[162] Mr. Rienhart further testified that based on his review of the Project, it was his opinion that the chief cause of the delays on the Project was Sapient’s project management. He identified a number of factors that caused significant problems for the Data Conversion team, including issues with the cleanliness of the data; lack of access to available environments; lack of access to functional resources; insufficient time to conduct testing; and poor project management generally.
[163] Mr. Rienhart testified that one of the primary problems that he identified was the high degree of functional changes on the Project both up to May 5, 2009 and thereafter, which in turn required changes to the Data Conversion program. These changes resulted from either new business requirement changes or changes by the Functional Team and were not caused by the Data Conversion Team. In his opinion, the high degree of functional changes resulted from project management.
b) Eric Kimberling
[164] Mr. Kimberling has extensive experience in ERP implementations, including SAP implementations. He has been involved both as a consultant and a project manager on ERP projects for close to 20 years and has performed 20 to 25 SAP implementations, including three or four SAP-ISU implementations.
[165] Mr. Kimberling reviewed the OSC status reports and the TGM reports for the period of September 2008 to September 2009. His evidence addressed two areas: the causes for delay and the status of AMS as at June 29, 2009.
[166] Mr. Kimberling testified that as at September 2008, the Project was behind in several areas. He considered the problem to be one of lack of Project resources. He did not agree that it was possible to catch-up once the Project fell behind.
[167] In his opinion, while there were delays in Data Conversion track, Data Conversion was not the only cause of delay to the Go-Live dates. Other streams of work had issues resulting in delays to not only themselves but also to other streams, including Data Conversion. It was Mr. Kimberling’s view that it was inaccurate to attribute the cause of the delay in the Go-Live dates to any one stream of the Project, including Data Conversion.
[168] It was Mr. Kimberling’s view that while no single stream could be blamed for the delays to Go-Live, Sapient bore the overall responsibility for the delays as project manager. In his view, Sapient failed to deal effectively with the issues contributing to the delays.
[169] In respect of AMS, Mr. Kimberling was of the opinion that as of June 29, 2009, Siemens had taken sufficient steps to provide AMS by a Go-Live date of August 15, 2009 (the possible Go-Live date as at Termination).
[170] Given the uncertainty surrounding Go-Live in the spring of 2008, Mr. Kimberling was of the view that Siemens was doing everything in its control to prepare for Go-Live and had adequately staffed AMS as at Termination.
c) Peter Blackmore
[171] Mr. Blackmore has extensive experience in implementing computer software, including 11 years with SAP Canada. Since 2004, he has been engaged in advising customers on SAP implementation, including data conversion.
[172] Mr. Blackmore testified both in respect of project management issues and the causes for delay. Specifically, he addressed four issues: Sapient’s management of the Project; Siemens’ management of Data Conversion; which streams of work caused the delays to Go-Live; and whether, as at June 29, 2009, Siemens had taken sufficient steps to provide AMS by the projected Go-Live date of August 15, 2009.
[173] It was Mr. Blackmore’s opinion based on his review of the reports over time that Sapient had the necessary skill to be engaged on the Project and that it executed its required activities with the care and diligence expected of a systems integrator. It was his opinion, however, that Siemens performance in respect of Data Conversion fell well short of industry standards. He was of the view that Siemens did not demonstrate the technical skills and tools required to develop the Data Conversion program.
[174] Mr. Blackmore further testified that after reviewing all of the reports, it was his opinion that the root cause of the delays to both Go-Live dates was Data Conversion. Finally, Mr. Blackmore testified that in his opinion, having regard to the staff in place as noted from the OCM reports, Siemens was not in a position on June 29, 2009 to provide AMS by the projected Go-Live date of August 15, 2009.
d) William Marsh
[175] Mr. Marsh has an extensive background in business/IT project consulting. Specifically, he has been involved on the project team of 11 SAP implementations. Six of those implementations involved significant data conversion efforts in which he had various roles including programmer, tester, analyst, architect, team lead and project manager. He has also developed and provided training on SAP data conversion methodology and development techniques to project team members.
[176] It was Mr. Marsh’s opinion that Siemens deliverables in respect of Data Conversion under the Subcontract (conversion design specifications, reconciliation design specifications, core conversion objects) were not up to industry standards. He was critical of the lack of documentation of changes/defects and the high number of defects. In his view, Siemens Data Conversion code and Reconciliation code were not up to standard.
The Issues
[177] The main issues that arise in both Siemens’ claim and Sapient’s counterclaim, as framed by the parties are:
Did Sapient breach the Subcontract by terminating it in the manner in which it did on June 29, 2009?
Was Siemens in breach of the Subcontract?
Were the delays to Go-Live caused by Siemens’ breach of the Subcontract?
If Sapient was not entitled to terminate the Subcontract in the manner in which it did, what are Siemens’ damages? and
If Siemens was in breach of the Subcontract, what are Sapient’s damages?
Breach of Contract
Sapient’s Breach of Contract
[178] Siemens submits that Sapient breached the Subcontract by improperly terminating it on June 29, 2009. Siemens claims damages in respect of both the Data Conversion portion of the Subcontract and the AMS portion.
[179] In response, Sapient submits that it had a clear contractual right to terminate the Subcontract for cause in accordance with its terms. In that regard, it relies on Section 17.2.2 of the Subcontract in respect of the ground set out in the Termination Letter (failure of Siemens’ Data Conversion code to convert data at a level required by the Subcontract or industry standards) and on the fact that Siemens was also in breach of the AMS provisions of the Subcontract. Sapient submits that both breaches are “material” and were incapable of being cured.
[180] Sapient also relies on Section 17.2.4 of the Subcontract in respect of Siemens’ failure to complete Project Milestone 54 within 90 days of the date set out in the Subcontract.
[181] Finally, Sapient submits that Siemens committed other material incurable breaches of the Subcontract including failing to complete the six mocks by the milestone deadlines, failing to meet the required reconciliation metrics for the six Mocks, failing to supply converted data of sufficient high quality to other tracks of work, failing to comply with applicable industry standards and failing to comply with applicable project standards.
[182] Sapient’s rights of termination for cause are set out in Section 17.2 of the Subcontract:
17.2 Sapient may terminate this Agreement for cause by providing notice to Subcontractor of such termination if:
17.2.1 Subcontractor commits a material breach of its obligations under this Agreement and, subject to Section 17.2.2, fails to cure such breach within 30 days of receipt of notice of such breach by Subcontractor provided that Sapient’s sole termination rights with respect to Subcontractor’s failure to achieve Application Support Service Levels will be set out in Schedule 8.1;
17.2.2 Subcontractor commits a material breach of its obligations under this Agreement and such breach is not capable of being cured;
17.2.3 Subcontractor commits an Act of Insolvency; or
17.2.4 Sapient exercises its rights of termination pursuant to any provision of this Agreement (including its Schedules) that provides for a specific termination right of Sapient.
- Material Breach
[183] As noted, Sapient submits that it was entitled to terminate the Subcontract pursuant to s. 17.2.2 based on Siemens’ material breach which was not capable of being cured.
[184] The term “material breach” referred to in Section 17.2 of the Subcontract is not defined. Siemens submits that a material breach is a breach which is substantial or goes to the root of the contract: Guarantee Company of North America v. Gordon Capital Corporation, [1999] 3 S.C.R. 423 at para. 44. That terminology, however, is synonymous with the now discarded doctrine of fundamental breach. See: Bhasin v. Hrynew, 2014 SCC 71, 3 S.C.R. 494. Further, in Spirent Communications, 2008 ONCA 92, 88 O.R. (3d) 721 at paras. 38-39, the Court of Appeal held that a “material breach” was one that has material consequences but “does not rise to the level of one that has deprived the innocent party of substantially the whole benefit of the contract.”
[185] In John McCamus’ Law of Contracts, 2nd ed. (Toronto: Irwin Law, 2012) at p. 687, the learned author states: “There is no standard use of the term material breach in the context of the Anglo-Canadian doctrine of repudiatory breach. Rather, the terms ‘material’ or ‘materiality’ must be carefully construed in light of the particular doctrinal or contractual context in which the terms are being employed.”
[186] While material breach is not defined, Section 9.4.6 of the Subcontract provides in part as follows:
Subcontractor acknowledges that it is a requirement of the Prime Agreement that if Sapient becomes aware of any actual or suspected breach of this Agreement that may affect the ability of Sapient to perform its obligations under the Prime Agreement in a material respect, or if Sapient reasonably believes that any such breach may occur, Sapient will: (i) immediately notify EGD [Enbridge] in writing and provide EGD with such information relating to the breach or alleged breach as EGD may request; and (ii) use commercially reasonable efforts to ensure that the Subcontractor remedies such breach in accordance with the provisions of the applicable Vendor Subcontract (which commercially reasonable efforts will include the delivery of default notices, use of prescribed governance and dispute resolution and escalation processes, resort to available contractual remedies and other available commercially reasonable steps). …
[187] Accordingly, having regard to the words themselves, the contractual context and the provisions of the Subcontract as a whole, I conclude that the term “material breach” in Section 17.2 means a non-trivial breach that affects or may affect Sapient’s ability to perform its obligations under the Prime Contract in a material respect and which can either be cured within 30 days of notice or is incapable of being cured.
- Data Conversion
[188] In the Termination Letter, Sapient stated that it was terminating the Subcontract for material breach under Section 17.2 because the conversion code failed to convert data at a level of accuracy that is even close to the expected performance requirements or industry standards.
[189] Based on the evidence which I accept, I conclude that both as at May 5, 2009 and June 29, 2009, Siemens’ Data Conversion software (specifications and code) was of adequate quality to convert data to the SAP IS-U System and accordingly met Siemens deliverables in that regard under the Subcontract. I therefore find that Siemens was not in breach of the Subcontract in respect of Data Conversion specifications and code. In reaching this conclusion, I accept the evidence of Mr. Rienhart and Mr. Compeggie in that regard. Correspondingly, I do not accept Mr. Marsh’s opinion.
[190] Mr. Rienhart’s opinion that Siemens’ Data Conversion software (design specifications and code) was of adequate quality and met Siemens deliverables under the Subcontract was based on his review of the Data Conversion code, both as it existed prior to May 5, 2009 and as it was at Go-Live. In contrast, Mr. Marsh’s opinion to the contrary was reached based on an entirely different approach. Mr. Marsh undertook no analysis of any operative portions of the Data Conversion code nor did he look at or compare the code at any given time or times. As a result, he could not provide any opinion as to whether on May 5, 2009 or June 29, 2009; the Data Conversion code was able to properly convert Legacy Data into the SAP IS-U System.
[191] Rather, Mr. Marsh looked at the development of the Data Conversion code throughout the Project as reflected by the version histories and the noted defects. Based on the high number of defects he observed (he noted 2,350 from September 2008 to Go-Live), along with Siemens failure to properly document the defects and their repair during the development process, he was of the opinion that the Data Conversion program was of poor quality.
[192] I do not consider that Mr. Marsh’s approach to determining the quality of the Data Conversion code addresses the question of whether, either on May 5, 2009 or on June 29, 2009, the Data Conversion code was of sufficient quality to properly convert the Legacy Data into the SAP IS-U System. Mr. Marsh’s opinion was based upon non-compliance with standards and the number of defects and design changes throughout the development process. The fact that the version histories of the Data Conversion code may have been incomplete or inaccurate and that there were a significant number of defects during the development period of the Data Conversion code, does not address, in my view, the quality of the Data Conversion code at the time of termination.
[193] Mr. Compeggie, along with his associates from Quintel, reviewed the Data Conversion specifications and code in April 2009 and concluded they were good quality products.
[194] Sapient submits that Mr. Compeggie’s evidence should not be accepted on the basis that both he and his team were not independent from Siemens. It further submits that the opinions expressed by Mr. Compeggie were not his own but those of his associates who actually conducted the review. Finally, it submits that the Quintel report was not prepared with anything like the rigor required to make it of any value.
[195] I accept Mr. Compeggie’s evidence and reject all of Sapient’s submissions as to why it should not be accepted. Mr. Compeggie was involved in the review. While various parts of it were undertaken by his associates, that does not, in my view, diminish his opinion. He reviewed their work and accepted it. He clearly had the qualifications to express the opinions he did. Experts often rely on associates to conduct the background work required. The fact that they rely on that background work does not diminish their opinion.
[196] Further, while Mr. Compeggie did become part of the Data Conversion team following his review, I do not consider that as a result, either he or his associates became insufficiently independent from Siemens, making his opinion tainted or unreliable. Quintel is an independent consulting firm with expertise in SAP installations. Its expertise was recognized by Sapient who listed it as a proposed team member in its response to the Enbridge RFP. Further, Quintel had not done any prior work for Siemens nor had Mr. Compeggie worked with anyone from Siemens who was engaged in the Project. Finally, Quintel’s review was not of such a cursory nature as to render it of no value. Rather, it was more than sufficient to enable Mr. Compeggie to reach the conclusions that he did.
[197] Notwithstanding Sapient’s position on July 29, 2009 that Siemens was in “material” breach of the Subcontract concerning its data conversion code, at no time did Sapient either provide notice to Enbridge or provide any notice of default to Siemens as it was required to pursuant to Section 9.4.6 of the Prime Contract with Enbridge.
[198] In finding that Siemens Data Conversion specifications and code were of sufficient quality to not be in breach of the Subcontract, either on May 5, 2009 or June 29, 2009, I also rely on the fact that Sapient has provided no evidence that it was required to make any changes to the Siemens’ Data Conversion program either subsequent to May 5, 2009 and prior to June 29, 2009 or afterwards, in order to be able to Go-Live.
[199] Sapient took over the Data Conversion lead on May 5, 2009. To the extent that it was required to make changes to the Data Conversion code in order for it to produce sufficient quality data for the SAP IS-U System, it could easily have (and would have) documented such changes. The fact that it presented no evidence at trial of any such changes speaks volumes. In my view, the lack of such evidence confirms the opinions of both Mr. Rienhart and Mr. Compeggie that Siemens Data Conversion specifications and code were of sufficient quality to meet its deliverables in that regard under the Subcontract.
[200] To the extent therefore that Sapient submits that Siemens was in material breach of the Subcontract because its Data Conversion code was unable to produce good quality data, I disagree. The evidence that I accept confirms that Siemens’ Data Conversion code was sufficient to produce good quality data both on May 5, 2009 and June 29, 2009. I find, therefore, that Siemens was not in breach of its obligations under the Subcontract in that regard.
- Reconciliation
[201] In its reply submissions, Sapient focuses on the allegation that Siemens was in material breach of its obligations under the Subcontract in respect of reconciliation. Specifically, it submits that Siemens was in breach of the Data Conversion provisions of the Subcontract for failing to meet the required control points set out in the Conversion Approach Document.
[202] As noted, reconciliation is the process of proving that the data which has been converted from the Legacy Systems to SAP IS-U is of good quality. It was and remains Siemens’ position that its Data Conversion software was producing good quality data. The issues that arose in the late winter and early spring of 2009 concerning the quality of Data Conversion were the result of the problems with the reconciliation program and not the Data Conversion program.
[203] It is clear from the evidence of both Siemens and Sapient that there were issues with the reconciliation program from early 2009 onward. While Siemens identified and worked on the problems with reconciliation in January 2009, they remained unresolved by April 2009. During that period, Siemens raised with both Sapient and Enbridge that it required assistance to enable it to address the reconciliation issues, including the necessity for a dedicated environment and a code freeze, but received no assistance in that regard.
[204] When Sapient (Child) began to push Siemens to come up with a plan to resolve the reconciliation issues in April 2009, Siemens hired Quintel. In short order, Mr. Compeggie and his team prepared the Go Forward Plan. As part of his review, Mr. Compeggie identified issues in respect of the reconciliation program. It was his conclusion that the reconciliation program had two fundamental issues: it did not provide a final result and the logic that it used to determine the control points was not consistent with SAP logic.
[205] While Siemens submits that it met all of the data loading objectives provided for each Mock, it does not dispute that it was not meeting the reconciliation control points for data matches for the Mocks that had been completed up to April 2009. It was of the view, however, that with the implementation of the Go-Forward Plan, it could resolve the reconciliation issues in time to meet the June Go-Live date. Sapient, however, rejected the Plan out of hand despite the fact that it had developed its own plan that was similar in many ways to the Go-Forward Plan.
[206] Notwithstanding that Siemens had failed to match the control points for the Mocks that had been completed prior to May 5, 2009, I do not consider that it was in “material” breach of the Subcontract in respect of reconciliation as at that date. As noted, the DC Statement of Work, which formed part of the Data Conversion Amendment, provides, among other things, that “[t]he final mock must result in no control point having a matching result outside of its pre-determined threshold.” Simply put, as of May 5, 2009, the final Mock had not been completed.
[207] The Data Conversion Amendment together with the Document and the Reconciliation Approach document make it clear, in my view, that the Mocks were run to validate the accuracy of the converted data and the conversion process. Issues which arose with respect to reconciliation were to be identified and corrected during the process culminating with the requirement that the control points must be met by the final Mock. Accordingly, the control points set out for all of the Mocks leading to the final Mock were effectively targets as opposed to specific contractual requirements that had to be met for each of the Mocks.
[208] Nor, in my view, did Sapient treat Siemens as if it was in “material” breach of the Subcontract as of May 5, 2009. Had that been the case, it was required pursuant to Section 9.4.6 of the Prime Contract to, among other things, immediately provide Enbridge with notice in writing of such breach. It was further required to provide notice of default. It provided neither notice to Enbridge nor notice of default to Siemens.
[209] There is another issue that must be addressed when determining whether Siemens was in “material” breach of the Subcontract in respect of reconciliation. As the evidence establishes, Siemens had been actively engaged for some time prior to May 5, 2009 in trying to correct the reconciliation program. Specifically, Stangl had been engaged full time on resolving the reconciliation issues. Some of the problems that Siemens was having in resolving the issues in the late winter and early spring of 2009 resulted from a lack of support and/or interference it was receiving from Sapient as Project Manager and to a lesser extent Enbridge. The evidence establishes Siemens was impacted in its Data Conversion progress by the following issues:
a. Ongoing changes to the SAP IS-U System by the Functional Team;
b. The lack of dedicated computer access (environment) to run the Data Conversion programs;
c. The lack of access to Functional resources; and
d. The lack of time between Mocks to correct defects.
[210] The above issues, in my view, arose principally from the failure of Sapient’s management to manage the Project and assist Siemens with the required resources and environment it required to succeed. The issue had been present for some time but became more apparent in the late winter and early spring of 2009. I refer specifically to the lack of communication between the Data Conversion Team and the Functional Team. Further, Sapient was not prepared to institute a code freeze to prevent further changes to the SAP IS-U System by the Functional Team, which directly affected the resolution of reconciliation issues. The culmination came when Sapient refused to allow Siemens to implement Mr. Compeggie’s Go Forward Plan, notwithstanding that it had been developing a similar type of plan to deal with Data Conversion issues.
[211] Once Sapient took over the Data Conversion lead on May 5, 2009, it became responsible for all of Data Conversion, including reconciliation. Sapient took a number of steps under Child’s direction to resolve the Data Conversion issues, many of which had been previously raised by Siemens or recommended by Mr. Compeggie in the Go Forward Plan but rejected by Sapient. These included adding additional resources to the Functional Team; facilitating communication between the Data Conversion Team and the Functional Team; providing access to isolated environments, large and small; conducting raid-fire tests; instituting a change order freeze and a code freeze; and allowing more time between Mocks to analyze and fix defects. In addition, Sapient approached Enbridge to obtain its agreement to eliminate some of the control points which measure reconciliation. Stangl’s evidence, which I accept, is that the results for Data Conversion improved rapidly through May and June 2009.
[212] The evidence establishes that following May 5, 2009, both Siemens and Sapient personnel were working hard on reconciliation. The only evidence of the status of the reconciliation program as at June 29, 2009, is the results of the testing. In that regard, the OSC status report for June 25, 2009 reported billing accuracy at 99.58% for large volume billing and 96.85% for mass market billing, both of which were within the control point matches for the final Mock as set out in the Conversion Reconciliation Approach document.
[213] What is clear is that until the reconciliation results demonstrated that the converted data was of satisfactory quality, Enbridge would not permit the SAP IS-U System to Go-Live.
[214] Sapient concedes that it succeeded in resolving all Data Conversion issues on or around July 19, 2009. Further, Child admitted that the Project was ready for Go-Live at the end of July 2009. The delay of the actual Go-Live to September 12, 2009 was at the request of Enbridge and not due to any Data Conversion issues. I conclude therefore that all Data Conversion issues, including reconciliation, had been resolved to Enbridge’s satisfaction at the very least by July 29, 2009 – i.e. within 30 days from the Termination Letter.
[215] For the above reasons’ therefore, I do not consider that Siemens was in material breach of the reconciliation portion of the Subcontract as at May 5, 2009. Nor was it in material breach of the Subcontract following May 5, 2009. Although Siemens personnel continued to work on Data Conversion after May 5, 2009 up until July 29, 2009, Child conceded that nothing Siemens did during that period constituted a material breach of the Subcontract.
[216] Finally, and even if the issues with reconciliation constituted a material breach of the Subcontract by Siemens as at May 5, 2009, they had been identified and were being worked on as of June 29, 2009. While they may not have been completely resolved by that date, I conclude from the evidence that they were capable of being cured and in fact were cured within 30 days of the date of termination. Accordingly, in such circumstances, by relying on Section 17.2.2 of the Subcontract to terminate without notice, Sapient was in breach of the Subcontract.
- AMS
[217] By purporting to terminate the Subcontract for cause pursuant to Section 17.2.2, Sapient also terminated the AMS portion of the Subcontract.
[218] Sapient submits that at the time of termination, Siemens was also in breach of the AMS portion of the Subcontract because “the lack of urgency Sapient was observing on AMS resembled what it had seen on data conversion, and so Sapient believed that if it continued with Siemens on AMS, it risked not meeting its contractual commitments to Enbridge.”
[219] That evidence of Sapient’s concern was provided by Child. I do not accept his evidence in that regard. Child stated that he was not involved in Sapient’s decision to terminate the Subcontract. The documents show that as the Program Manager, he was part of Sapient’s senior management team. He was involved in all aspects of the Project and was particularly involved with Data Conversion. He was directly involved in leading Sapient’s plans for taking over Data Conversion. Child’s evidence that he was not involved in the termination decision is not credible.
[220] As noted, AMS was part of the Support Readiness track. Any information Child had concerning Siemens’ preparations for AMS would have come from Ornstein, who was Sapient’s lead on that track, or from the Support Readiness Status Reports. Ornstein didn’t testify and the Support Readiness Status Reports do not make note of any issues concerning AMS.
[221] In addition, Child received an email from Paau on June 19, 2009, 10 days before the termination, which advised that Siemens had nine staff in place in respect of AMS.
[222] The evidentiary record does not support Sapient’s allegation of lack of urgency.
[223] There is no substance to Sapient’s reason why it terminated the AMS portion of the Subcontract. Siemens met Milestone 47 which was the only Milestone applicable to AMS prior to termination. Further, the evidence, which I accept, establishes that Siemens had been taking steps to staff the required resources necessary for it to provide AMS services both on site and offshore as was agreed.
[224] Neither the Support Readiness Status Reports nor the OSC meeting reports raise any concerns about Siemens’ AMS staffing. It was never listed as a critical issue.
[225] In cross examination, Paau agreed that Siemens had a support group in place for AMS as of June 19, 2009, when he sent Child an email containing a list of Siemens personnel. In re-examination he said that he couldn’t recall if any of the AMS staff he had listed were present at Enbridge. I do not consider that answer to diminish in any way Paau’s evidence in cross-examination. As noted, Paau was in part responsible for staffing on the Project. I find that Siemens AMS staffing was as set out in Paau’s email to Child on June 19, 2009 and that it met Siemens requirements under the Subcontract as at that time.
[226] Nor do I consider Ornstein’s escalation of Siemens AMS staffing in early April 2009 to have been bona fide. By that time, Sapient was considering termination of the Subcontract. It is clear from an internal email Ornstein sent back on February 12, 2009, that he was of the view, as early as then, that Siemens should not be paid. Further, on March 19, 2009, Kapur wrote him an email that stated in part: “Am assuming that you are keeping a detailed track of all of the exchanges and escalations that you have done with Siemens on AMS (planning, staffing et al)…will likely come in handy later.” Given the timing of Ornstein’s escalation of the AMS staffing, I consider it to have been tactical as opposed to bona fide.
[227] I accept Carrington’s evidence that as at the end of June 2009, Siemens would have been able to provide AMS services as specified in the Subcontract for an August 15, 2009 Go-Live date (or September 12, 2009, which was the eventual Go-Live date).
[228] As noted, Eric Kimberling testified that as of June 29, 2009, Siemens had taken sufficient steps to provide AMS by the then scheduled Go-Live date of August 15, 2009. In reaching that opinion, Mr. Kimberling was aware of the accurate level of staffing of the AMS track at the time of termination.
[229] In contrast, Mr. Blackmore’s opinion was that as of June 29, 2009, Siemens would not have been in a position to provide AMS by an August 15, 2009 Go-Live. Mr. Blackmore testified that in his experience, the AMS team would require two to three months prior to Go-Live to learn the SAP IS-U System from the Project team in order to properly provide the AMS services. It was his opinion, based on his review of the Support Readiness Status Reports during the relevant period prior to June 29, 2009, that the AMS team was nowhere near fully staffed by the end of June 2009. Importantly, in reaching his conclusion, Mr. Blackmore did not review any of the correspondence or documents concerning AMS that were exchanged by Siemens and Sapient internally and among each other.
[230] I prefer the evidence of Mr. Kimberling concerning Siemens’ readiness for AMS as of June 29, 2009 over that of Mr. Blackmore.
[231] I am unable to accept Mr. Blackmore’s opinion concerning Siemens inability to provide AMS services for a Go-Live date of August 15, 2009. Mr. Blackmore formed his opinion concerning AMS without reviewing the entire record to determine the readiness of Siemen’s AMS team. As a result, in reaching his opinion, Mr. Blackmore did not have a complete picture of Siemens’ AMS staffing as at termination.
[232] It is clear from Mr. Blackmore’s evidence that, in addition to not reviewing the correspondence between Siemens and Sapient concerning AMS as well as their internal communications, he also did not review the Support Readiness Status Reports prior to May 27, 2009. Those reports clearly indicate a much higher level of the AMS staffing than the later reports. The reason for the staffing reduction in the Support Readiness Status Reports after May 27, 2009 was not explained. Carrington’s evidence was that the information in the Reports concerning the level of AMS staffing after May 27th was wrong. That is confirmed by the internal emails of both Siemens and Sapient. Had Mr. Blackmore reviewed the earlier Reports or the internal emails, the discrepancy in staffing would have been apparent.
[233] Sapient submits that Siemens preparations for AMS were “persistently” behind schedule. It acknowledges, however, that the Subcontract does not provide a date when Siemens’ AMS resources were required to be on site prior to Go-Live. Siemens did agree, however, to have its team in place and onsite 90 days before Go-Live. The timing of staffing did become an issue for Siemens in light of the changing Go-Live dates. The Subcontract provided for the first payments in respect of AMS to begin shortly before Go-Live. As a result, Siemens would not be reimbursed for the cost of early staffing. Nevertheless, as the evidence indicates, and I have found, Siemens was diligently working to staff the AMS team in the face of changing Go-Live dates and would have been in a position to provide the AMS services in advance of the actual Go-Live date of September 12, 2009.
[234] Sapient’s submission that it effectively feared liability to Enbridge if Siemens continued with AMS strains credibility in the face of the Joint Liability Letter that both Siemens and Sapient entered into with Enbridge in connection with the AMS portion of the Subcontract.
[235] As noted, Sapient entered into a new AMS agreement with Enbridge on June 30, 2009. Go-Live was on September 12, 2009, approximately two and a half months later. Sapient has provided no evidence as to how, in that time period, it was able to provide the AMS services at Go-Live when Siemens, who had hired staff and arranged for offshore services from Siemens India, could not.
[236] In my view, and I so find, Sapient did not terminate the AMS portion of the Subcontract as a result of any breach by Siemens of its deliverables in the AMS portion of the Subcontract. The Termination Letter referred only to Data Conversion. But in terminating the Subcontract in the manner in which it did, Sapient clearly intended to terminate the AMS portion of the Subcontract. As set out in more detail below, it did so in my view in order to further its own financial position. In light of what it considered to be the poor financial results under the Prime Contract and having renegotiated the terms of the AMS services with Enbridge, Sapient’s intent in terminating the Subcontract was to terminate AMS in order to ensure it retained a larger portion of the AMS contract going forward.
[237] Further, the timing of the termination was dictated by Enbridge who was pushing Sapient to sign the new AMS agreement by June 30, 2009. On June 25, 2009, Enbridge sent Sapient an email advising it that it would make full payment of the Notice of Readiness Payment Milestone if two conditions were met: Regression Test 7 quality criteria were met and the amendment to the AMS portion of the Prime Contract was finalized and signed. In order for Sapient to be in a position to sign such amendment, it had to ensure that the AMS portion of the Subcontract was terminated prior to such signing.
[238] Accordingly, I find, as at June 29, 2009, Siemens was not in breach of the Subcontract concerning its deliverables for AMS.
- Milestone 54
[239] Sapient submits that it was entitled to terminate the Subcontract due to Siemens’ failure to meet Milestone 54 “Acceptance of Notice of Readiness for Rollout 1 Functionality” within 90 days of the date set out in the Data Conversion Amendment.
[240] Section 4 of Schedule 10A of the Data Conversion Amendment (DC Statement of Work) provides as follows:
If Subcontractor fails to complete any Termination Milestone within 90 days following the applicable deadline for the completion of such Termination Milestone set forth in the Project Plan, Sapient may, in its discretion and in addition to all other remedies available to it, terminate this Agreement for cause forthwith upon notice to Subcontractor and without further obligation to Subcontractor for the data conversion.
[241] The Subcontract defines “Termination Milestone” as any event designated as such in the Project Plan. The “Project Plan” is defined as the Project Plan attached as Schedule 1.1.99. The Project Plan sets forth the Project Milestones, Payment Milestones and Termination Milestones. Milestone 54 is designated a “Termination Milestone” and has a deadline date of December 29, 2008.
[242] Milestone 54 was not completed until June 30, 2009. Because Milestone 54 was not completed by Siemens within 90 days of its December 29, 2008 deadline, Sapient submits that it had the right to terminate the Subcontract upon notice pursuant to Section 17.2.4 of the Subcontract. Sapient relies on the Termination Letter as notice.
[243] In my view, Sapient cannot rely on Siemens failure to meet Milestone 54 within 90 days of December 29, 2008 as a basis for terminating the Subcontract for a number of reasons.
[244] First, the termination right in Section 4 of Schedule 10A relating to failure to complete a Termination Milestone requires that notice be given to Siemens. Given the nature of the termination right (forthwith) and the fact that the Data Conversion Amendment contains a number of Termination Milestones, in my view, the notice required in Section 4 of Schedule 10A must be specific to the failure being relied upon. The Termination Letter makes no reference to the failure to meet Milestone 54. Although it relies on Section 17.2, it references only material breaches which cannot be cured (17.2.2). There is no reference to Section 17.2.4, which Sapient now relies upon.
[245] In the absence of notice, therefore, Sapient cannot rely upon its right to terminate in Section 4 of Schedule 10A of the DC Statement of Work.
[246] Further, Section 4 of Schedule 10A gives Sapient the right to terminate “in its discretion”. Given that Sapient has a discretion to terminate, it follows that such discretion must be exercised in good faith: Greenberg v. Meffert, 1985 CanLII 1975 (ON CA).
[247] In my view, Sapient’s purported exercise of its discretion to terminate the Subcontract for failure to meet Milestone 54 was not done in good faith. I have reached that conclusion for the following reasons.
[248] It is clear from the facts I accept that Sapient had no intention of relying on Milestone 54 when it terminated the Subcontract on June 29, 2009. Apart from no mention of it in the Termination Letter, Sapient did not rely on it in its pleadings as a ground for termination. The first time Sapient relied on Milestone 54 was on the eve of trial, when it amended its statement of defence in response to Siemens’ consent amendment to substitute Atos as plaintiff following Atos’ acquisition of Siemens Canada and Siemens Austria. Needless to say, that amendment was made well after discoveries.
[249] Further, Sapient was well aware on March 29, 2009 (90 days after the date of completion of Milestone 54) that Siemens had not met Milestone 54 as required by the Subcontract. Rather than terminate the Subcontract, however, it actively encouraged and cajoled Siemens to complete its Data Conversion work under the Subcontract.
[250] Sapient submits that it communicated its dissatisfaction to Siemens and that its delay in exercising its termination rights was in the hope that Siemens performance would materially improve. While that may be so, it is clear that they actively encouraged Siemens to continue acting under the Subcontract. Sapient’s interaction with Siemens subsequent to both December 29, 2008 and March 29, 2009 and its re-affirmation of the Data Conversion Amendment on May 5, 2009, clearly communicated to Siemens that it did not intend to rely on the failure to meet Milestone 54 to terminate the Subcontract. In response to Sapient’s encouragement/affirmation, Siemens continued to commit significant resources to fulfil the Subcontract, both in respect of Data Conversion and AMS.
[251] Sapient relies on Section 22.5 of the Subcontract which provides as follows:
Section 22.5 Time of Performance
When a Party has a right to performance by the other Party or a right to terminate this Agreement as of a particular date, that right may be enforced or exercised notwithstanding any principles of equity, and the Party will be entitled to that performance or to terminate this Agreement on or after such date.
[252] That provision deals with time of performance. It does not apply to the manner of termination. It does not assist Sapient.
- Other Breaches Prior to May 5, 2009
[253] Sapient further submits that it was entitled to terminate the Subcontract for cause pursuant to Section 17.2.2 thereof as a result of a number of breaches, which it alleges were “material” and incapable of being cured. Specifically, Sapient relies on Siemens’ failure to complete the Mocks by the milestone deadlines or to meet the required reconciliation metrics; its failure to supply converted data of sufficiently high quality to other tracks of work; its failure to comply with applicable industry standards; and its failure to carry out data conversion with the skill, diligence and care required.
[254] The Data Conversion portion of the Subcontract was to take place from the outset through to Go-Live (September 2008 to April 2009). Throughout that period, Siemens was required, among other things, to develop the Data Conversion program that would accurately convert the Legacy Data into the SAP IS-U System. The quality of the converted data was to be tested over a number of test runs (Mocks) beginning in September 2008 and ending in April 2009.
[255] The Data Conversion Amendment provided for certain Data Conversion milestones (dates) which correlated to the milestones in the Prime Contract.
[256] With the delays in the Project, deliverable dates, including payment milestones shifted. Sapient recognized that Project milestones shifted with Project delays. Specifically, Milestone 2, re Blueprint services was scheduled to be completed in the Data Conversion Milestones on December 7, 2007. It was not completed until March 12, 2008. Further, Milestone 6, “Successful completion of the development of the interface components for the New Solutions System for Rollout 1 Functionality” was to be completed on June 13, 2008 and was not completed until November 5, 2008. Further, and as noted, the two Data Conversion payment milestones that were paid by Sapient to Siemens were paid long after the milestone dates set out the Data Conversion Amendment.
[257] Further, both the dates and the control point matches were expressed in the Conversion Reconciliation Approach document as “targets”. Further, it is clear from the evidence that while the targets were important, the fact that they were not met was not treated by either Enbridge or Sapient as a material breach. Nor in my view was it expected to be. The wording of the Data Conversion provisions in the Subcontract and the conduct of the parties throughout makes it clear that the purpose of the testing was to identify issues with Data Conversion (and other tracks) that needed to be resolved before the next Mock and in any event before Go-Live.
[258] As I have already discussed, Section 10A.1.1 of the Subcontract requires Siemens to provide the Data Conversion services in accordance with the DC Services Statement of Work (Schedule 10A) and the Project Plan. Section 10A.1.2 of the Subcontract provides:
10A.1.2 Subcontractor will provide to Sapient Data Conversion Services in a manner that meets the milestones, Deliverables and other requirements set out in the Data Conversion Statement of Work, the New Solution System Specifications, and the relevant milestones set out in the Project Plan.
[259] The Data Conversion Statement of Work specifically provided that the final Mock must result in no control point having a matching result outside of its predetermined threshold.
[260] Finally, Section 5 of the Conversion Reconciliation Approach document sets out, among other things, the target dates and the individual control point target matches for each of seven Mocks.
[261] The evidence establishes that none of the seven Mocks were completed by the target dates set out in the Conversion Reconciliation Approach document. Nor were the target matches for the defined controls achieved for each of the first six Mocks.
[262] I have already discussed the reasons for the failures to meet both the target dates and the target matches. Needless to say, they are complex and many. I do not consider that they arose solely due to the fault of Siemens and Data Conversion. The target dates remained the same throughout the Project notwithstanding the lengthy delay in the Blueprint Phase and the decision to extend the Go-Live date from April to June 2009. All the contingency time in the Project Plan was used up leaving no time between Mocks to analyze and fix defects prior to the next Mock. There were issues with the testing caused by the Functional Team which in turn impacted on the Data Conversion team. Further, while Go-Live was extended twice, the dates for the Mocks were not altered from the original schedule.
[263] Accordingly, while the target dates and data matches were not met by Siemens as set out in the Subcontract, I do not consider that Siemens failure to meet those dates or control points constituted a “material” breach of the Subcontract. The target dates and data matches were not “material” in that they did not prevent Siemens from performing its obligations under the Prime Contract in a material respect. Rather, they were in the form of progressive goals to enable a successful final outcome for Data Conversion.
[264] Further, and as noted in respect of Data Conversion, Sapient never considered Siemens failures to meet dates and the targets to be “material” breaches. At no time did it give notice to Enbridge of such breaches as it was required to do under Section 9.4.6 of the Prime Contract.
[265] Siemens further submits that even if it was in material breach of the Subcontract prior to May 5, 2009, based on the doctrine of election, Sapient cannot now rely on the breach or breaches to terminate the Subcontract pursuant to Section 17.2.2.
[266] The doctrine of election in contracts was recently reviewed by the Court of Appeal in Charter Building Company v. 1540957 Ontario Inc., 2011 ONCA 487, 107 O.R. (3d) 133. The Court described the election as follows at para. 19:
Election at common law takes place where a party is faced with a choice between two inconsistent courses of action that affect another party’s rights or obligations, and knowing that the two courses of action are inconsistent and that he or she has a right to choose between them, makes an unequivocal choice and communicates that choice to the other party. The doctrine provides that the party making the election is afterwards precluded from resorting to the course of action that he has rejected. The election is effective at the point of communication on the basis that the parties to any ongoing relationship are entitled to know where they stand...
[267] Sapient submits that for the doctrine of election to apply, the rights in question must be clearly inconsistent with each other and there must be an unequivocal act or communication indicating the election to pursue one of those rights. It submits that neither of those requirements is present in this case.
[268] Sapient submits that none of the steps it took in relation to Siemens’ breaches both before and after May 5, 2009 were inherently inconsistent with its right to terminate the Subcontract. It was always clear in its discussions with Siemens that it did not waive any of its rights to terminate.
[269] Sapient’s submission misses the point. It clearly had two courses of action in the face of the alleged Siemens’ breaches – it could terminate the Subcontract or it could affirm it. Those two courses of action are clearly inconsistent.
[270] I do not agree that the evidence establishes that Sapient made it clear to Siemens that it was not waiving its right to terminate. In my view, there was never a specific reservation to that effect by Sapient. But even if that was the case, that course of action remained open to it and was clearly inconsistent with affirming the Subcontract.
[271] In my view, what Sapient is really submitting is that it did not communicate an unequivocal choice. I find however that it did by its actions. By exhorting Siemens to continue its work under the Subcontract and clearly re-affirming the continuation of the Subcontract on May 5, 2009, Sapient communicated its decision to affirm the Subcontract as opposed to terminating it on the basis of earlier breaches by Siemens.
[272] Prior to May 5, 2009, Sapient was well aware that Siemens had failed to meet the reconciliation targets set out in the Data Conversion Statement of Work for the Mock tests. In fact, Sapient raised what it considered to be Siemens’ failures of performance with Siemens on more than one occasion. Rather than terminating the Subcontract or the Data Conversion portion of the Subcontract, however, Sapient exhorted Siemens to continue its work under the Subcontract.
[273] Further, the agreement reached on May 5, 2009, when Sapient took over the Data Conversion lead, was a clear affirmation of the Subcontract. While Sapient did request that Siemens consider concessions on the fixed price scope of the Subcontract, which was to be discussed and agreed, there was no reservation of the right to terminate. Sapient further submits that the doctrine of election is not applicable, given Section 22.5 of the Subcontract. As previously noted, Section 22.5 deals with the time of performance and provides that where a right to terminate in the Subcontract is as of a particular date, the right may be exercised at any time on or after the date.
[274] In my view, Section 22.5 has no application to the issues being discussed. None of the alleged “other breaches” that Sapient relies on involve termination rights which must be exercised on or within certain time periods. Rather, Sapient relies on its right to terminate for cause under Section 17.2.2.
[275] Nor do I find on the evidence that Siemens was in “material” breach of the Subcontract in failing to supply converted data of sufficient quality for the testing that was carried on by both the Functional and Technical teams. There is no question that the delay to ITC 1 and 2 in the fall of 2008 was due, in part, to the poor quality of the converted data. However, that issue was quickly resolved.
[276] Given the issue, the Data Conversion team instituted a data quality test in advance of ITC 3 to ensure the converted data was of high quality. In the result, the Integration Test Cycle 3 Data Quality Report, which was provided to the OSC, concluded: “it has been determined that the statistical analysis of the master data converted exceeded the standards required to execute the Integration Test Cycle 3.”
[277] At the same time, there were other issues, not related to the quality of converted data that also contributed to the delay. Those issues resulted from problems that originated from the Functional and Technical teams. Given that the issues contributing to the testing delay at that time were more than just Data Conversion, I am not prepared to conclude that Siemens was in “material’ breach of the Subcontract at that time.
[278] Further, in its memorandum dated January 28, 2009, TMG reported that the quality of the converted data “is useable for testing purposes.” There is no evidence that the subsequent testing carried out by the Functional and Technical teams was impacted by the quality of converted data. The converted data that was supplied for the tests was of sufficient quality.
[279] Nor do I find that Siemens’ failed to comply with applicable industry standards or failed to carry out the data conversion portion of the Subcontract with the skill, diligence and care required. Although Siemens had its issues during the course of the Project, those issues were resolved.
[280] Mr. Blackmore testified that in his opinion, Siemens performance fell well short of industry standards. He testified that during the realization phase, Siemens did not demonstrate the technical skills and tools required to develop the conversion programs. Once again, I am unable to accept Mr. Blackmore’s opinion.
[281] In providing his views as to whether Siemens met appropriate standards, Mr. Blackmore did not rely on any written standards. He acknowledged that he was applying his own view of applicable standards. He also conceded that he was not an expert on the creation of data conversion code or reconciliation. Nor was his experience comparable to the Project. He agreed that he had never managed a project of the size and complexity of the Project. Nor had he reviewed any of the email correspondence, particularly the correspondence about issues raised by the Siemens Data Conversion team and the responses by the Sapient project managers.
[282] As a result, I do not consider that Mr. Blackmore had either the qualifications or sufficient knowledge of what transpired in respect of Siemens Data Conversion efforts to provide the opinion that Siemens did not meet appropriate industry standards.
[283] Mr. Marsh’s opinion was that Siemens’ documentation in respect of conversion design specifications, reconciliation design specifications and core conversion objects was not up to industry standards. He agreed, however, that the problems he identified in the conversion design specifications did not in any way impact on whether the conversion design specifications were an appropriate document to develop code. Although he was critical of the “comments” in the Data Conversion code, he acknowledged that those comments were non-operative portions of the code and they played no role in actually converting data. I am also of the view that Mr. Marsh’s criticism of the “version histories” in the Data Conversion code is misplaced. He criticized the manual version of the histories prepared by the Data Conversion team members. But SAP has a built in version history which enables earlier versions and changes to be easily reviewed.
[284] Accordingly, I do not find that Siemens was in breach of the Subcontract for failure to follow industry standards. Alternatively, to the extent that Siemens’ failure to keep proper documentation to track the development of the code constitutes a breach of the Subcontract, it was clearly not a “material” breach. Having regard to the Data Conversion deliverables under the Subcontract and the nature of the breaches, they were trivial at best. Nor has Sapient lead any evidence to say it was materially affected by such breach.
[285] For the above reasons, therefore, I find that Sapient breached the Subcontract by wrongfully terminating it on July 29, 2009.
Plan “B”
[286] Siemens submits that Sapient’s actions in terminating the Subcontract in the manner in which it did constituted bad faith. Specifically, Specifically it submits that beginning sometime in March 2009, and unbeknownst to it, Sapient developed plan to terminate the Subcontract in order to improve its financial position on the Project..
[287] Sapient’s internal emails confirm that in late March/early April 2009, Sapient began to make plans to take over Data Conversion based on two options: retaining key Siemens’ employees and using a Sapient only team. I do not have any concern with such steps by themselves. They represent contingent planning in the event that Sapient determines, as it ultimately did, that it should take over Data Conversion from Siemens.
[288] In my view, however, Sapient’s contingency plans for Data Conversion cannot be viewed in isolation. They were part of a larger plan to terminate not only the Data Conversion portion of the Subcontract but also the AMS portion in order to improve Sapient’s profitability on the Project.
[289] From at least early March 2009, Sapient was aware that the Project was no longer economic for it. Sapient had a meeting with Enbridge on March 5, 2009, to attempt to resolve some of its increased costs. Summy’s email following the meeting indicates that it did not go well. The direction was to keep the Sapient team positive and focused on performance but to highlight every point of failure outside of Sapient. As a result, rather than treat Siemens as a partner and take steps to facilitate its success in the Project, Siemens, led by Child, did the opposite. Siemens’ requests to the PMO for required assistance to resolve its Data Conversion issues, including the need for a dedicated environment for Data Conversion, eliminating or reducing the functional and configuration changes that were impacting on Data Conversion and the need to facilitate communication, specifically with the functional team, were all either rejected or not acted upon.
[290] The culmination of what I would consider Sapient’s unhelpful actions came in mid-April 2009, when, after insisting that Siemens do a “deep dive” to determine the root cause of the problems facing Data Conversion, Child rejected Mr. Compeggie’s Go-Forward Plan essentially out of hand. In response to Child’s criticisms of the Plan, Mr. Compeggie amended it a couple of times to try and address Child’s concerns but each time the Plan was given short shrift.
[291] At the same time, Sapient had put together a team to look at Data Conversion and had come up with a draft plan. In my view, Sapient (Child) had no intention by the middle of April, 2009 of continuing with Siemens.
[292] Child testified that he wanted to work with Siemens. His actions in my view indicate otherwise. I do not accept his evidence.
[293] When Sapient made the decision by late April, 2009 to take over control of Data Conversion, it recognized that it did not have the resources to resolve the Data Conversion issues without the continued involvement of key Siemens personnel. Accordingly, it elected to take over the lead of Data Conversion on May 5, 2009 in the absence of either terminating either the entire Subcontract or the Data Conversion portion of it. Why then did Sapient terminate the Subcontract on June 29, 2009?
[294] After Sapient took over the Data Conversion lead on May 5, 2009, the Sapient led team instituted effectively what Mr. Compeggie and Siemens had recommended: access to isolated environments (large and small); a change order freeze; a code freeze; mini Mocks; more resources on the functional and technical side for Data Conversion; improved communication between Data Conversion, the functional and technical teams and the business side; and more time between Mocks to analyze and fix defects.
[295] It is clear in my view that the Data Conversion portion of the Subcontract was not the driving force behind the termination. By the end of June the Data Conversion issues had been virtually resolved. Further, had Sapient just wanted to terminate the Data Conversion portion of the Subcontract, it could have done so by using the termination for convenience provision set out in Section 17.4 of the Subcontract (Section 2.5 of the Data Conversion Amendment). Utilizing that Section, however, would not terminate the AMS portion of the Subcontract.
[296] In my view, and I so find, the reason why Sapient proceeded to terminate the Subcontract in the manner it did on June 29, 2009, was to terminate the AMS portion of the Subcontract to enable it to take over AMS and improve its financial position under the Prime Contract. Internal Sapient emails as far back as April 2009 demonstrate that Sapient was focused on terminating the AMS portion of the Subcontract to enable it to improve its financial position.
[297] There is another aspect of Sapient’s conduct in terminating the Subcontract in the manner it did that concerns me.
[298] Section 20 of the Subcontract sets out a procedure for resolving, among other things, disputes arising under the Subcontract concerning performance. The Section requires the parties in good faith to attempt to resolve any dispute promptly following an informal dispute resolution procedure which involved the Presidents of both Siemens and Sapient and a Dispute Resolution Committee.
[299] On June 26, 2009, Siemens sent notice to Sapient pursuant to Section 20 of the Subcontract to resolve the stalled discussions following Sapient’s assumption of the Data Conversion lead on May 5, 2009. Sapient never responded to the letter. Nor did it invoke the dispute resolution procedure set out in Section 20 of the Subcontract prior to terminating the Subcontract on June 29, 2009.
[300] I conclude, therefore, that in terminating the Subcontract in the manner it did and for the reasons I have found, Sapient was not acting in good faith as required by Section 20 of the Subcontract.
Siemens Breach of Contract
[301] Sapient submits that Siemens’ breach of its deliverables under the Subcontract in respect of Data Conversion was the root cause in the delays to Go-Live first during the period from April 3, 2009 to June 7, 2009 and then from June 7 to September 12, 2009.
[302] While I have concluded that Siemens was not in “material” breach of the Subcontract at the time of or prior to the termination, I find that it was in breach of the Subcontract in respect of Data Conversion deliverables in the fall of 2008 and again in the spring of 2009.
a) Fall 2008
[303] Specifically, I find that Siemens was in breach of the Subcontract in October/November 2008. The evidence of both Siemens and Sapient establishes that Siemens clearly fell behind the Project’s timelines in respect of its development of the Data Conversion code. The result was a delay to ITC’s 1 & 2 and the start of ITC 3 due in part to sub-standard quality of converted data. Siemens problems emanated from issues with Siemens Austria and with its code developers in Romania. As noted, however, the delay was short lived.
[304] Siemens recognized the problems and took specific steps to address them in the fall of 2008. In addition, Sapient supplied Siemens with resources to help it address the problems. In the end, Siemens, with Sapient’s help, was able to bring Data Conversion back onside its contractual requirements by the end of 2008.
[305] Sapient submits that Siemens breach of the Subcontract in the fall of 2008 was the root cause of the decision to delay Go-Live from April to June 2009 in January 2009. I disagree. While I agree that the issues with Data Conversion were one of the causes that contributed to the delay, the evidence, which I accept, clearly establishes that there were other significant issues in other tracks of the Project that impacted directly on the first decision to delay Go-Live.
[306] While the delays to ITC’s 1 & 2 were in part caused by substandard data, TMG noted that they were also caused by in-effective resource allocation — a PMO responsibility, and substandard test scripts — a Functional team responsibility. Further, in its December 19, 2008 memorandum, TMG noted that the Project was behind schedule in all areas/tracks. In addition to Data Conversion, TMG listed OCM, Project management, delays in business decisions (Enbridge), and issues with the Functional team’s readiness.
[307] In support of its position that Data Conversion was the root cause of the delay to the April 3, 2009 Go-Live date, Sapient relies on the expert opinion evidence of Mr. Blackmore. I am unable to accept Mr. Blackmore’s opinion to that effect for a number of reasons.
[308] First, Mr. Blackmore agreed that he did not review any of the correspondence (emails) emanating from the Project. Had he done so, he would have clearly seen that Data Conversion was only one of many tracks that were behind schedule in the fall of 2008, resulting in the first delay to Go-Live. In cross-examination, Mr. Blackmore agreed that he did not analyze the reasons for OSC’s decision to delay Go-Live from April to June 2009. He further agreed, after being taken to the documents leading up to the decision and specifically TMG’s memorandum of December 19, 2008, that his opinion was not borne out by the facts. Although he testified that he had reviewed the TMG reports, it is clear he didn’t look at them very carefully. Finally, he agreed that the decision by Project management was a multifactorial decision based on a number of factors.
b) Spring 2009
[309] I am also of the view that in the late winter and early spring of 2009, Siemens was in breach of the Subcontract’s requirements in respect of reconciliation. Siemens was responsible for the design and development of the reconciliation code. While the reconciliation specifications were designed by Monahan who was a Sapient employee, it was Siemens responsibility under the Subcontract.
[310] The Quintel report clearly indicates that there were significant problems with the reconciliation program as of April 2009. The reconciliation problems in turn led to the Mocks being delayed and the control point targets set out in the Conversion Reconciliation Approach Document not being met.
[311] While I consider that Siemens was in breach of the Subcontract by not being able to deliver a proper reconciliation program, I do not consider that breach to be a “material” breach. As noted, Siemens was working hard to resolve the reconciliation issues. Further, as I have already indicated, in my view, Sapient’s actions impacted its performance.
[312] Sapient submits that the root cause of the second decision to extend Go-Live from June to September 2009 was because of Data Conversion. Once again, I reject Sapient’s submission. Simply put, while the evidence indicates that Data Conversion was one of the factors causing the delays to Go-Live, it was not the root cause. The evidence, and particularly the TMG reports, clearly indicate that there were other causes affecting the Project that contributed to the delay. Indeed, even after Data Conversion’s issues were resolved in July 2009, Go-Live was not completed until September 2009 for reasons other than Data Conversion.
[313] The decision to delay the June 2009 Go-Live was made on May 7, 2009. In its report to the ESC on April 29, 2009, TMG noted that most of the tracks were behind schedule and may not be completed before the current Go-Live date. Further, to the extent that some of the reports and minutes focus in on Data Conversion as the cause of the delay, I still conclude that other tracks were not ready for Go-Live as well.
[314] Sapient again relies on Mr. Blackmore’s opinion to support its position that Siemens breach of the Subcontract was the root cause of the second delay to Go-Live. In his report, Mr. Blackmore concluded that the root cause to the delay to the second Go-Live date was Data Conversion. In his evidence in chief, however, he testified that Data Conversion was not the root cause but one of the root causes for the delay. He did not correct that statement prior to cross-examination. When he was reminded of his evidence in cross-examination, he agreed he said Data Conversion was one of the root causes but that he had “misspoke”.
[315] Once again, I am not prepared to accept Mr. Blackmore’s opinion. Apart from his misstatement, it is clear that he did not thoroughly review the record concerning the Project to understand all of the factors affecting the delays to the Project.
[316] On the other hand, both Mr. Rienhart and Mr. Kimberling, whose evidence I accept, were of the opposite opinion.
[317] Mr. Rienhart reviewed the record and concluded that the chief cause of delay on the Project was Sapient’s project management. That opinion is supported by TMG’s reports throughout the Project that continually raise Project management concerns relating in particular to scheduling issues and resource allocation. It is also consistent with the fact that Sapient had never done an SAP installation before and, particularly in the last part of the Project, had no one with SAP experience in the PMO.
[318] In addition, Mr. Kimberling’s opinion that there were delays in many streams or tracks, including Data Conversion that lead to the delays, is also supported by the record and the evidence of what happened on the Project. I accept Mr. Kimberling’s evidence that it is inaccurate to attribute the cause of the delay to the Go-Live dates to any one stream or track in the Project. Given the multi steam, interdependent nature of the Project, there are a number of factors which can and did concurrently affect Go-Live.
[319] Mr. Kimberling’s view was that while no single stream can be blamed for the delays that occurred to Go-Live on the Project, Sapient, as the project manager, bears the overall responsibility. I agree with that viewpoint.
Damages
Siemens’ Damage Claim
[320] Siemens’ claim for damages arising from Sapient’s wrongful termination of the Subcontract on June 29, 2009 engages both the Data Conversion and the AMS portions of the Subcontract. Siemens’ claim is as follows:
I. Data Conversion
a) $2,404,000 for the balance owing under the Subcontract for Data Conversion;
b) $311,690 for change requests approved by Sapient but not paid; and
c) $1,011,874.44 for time and materials for May 5, 2009 to June 29, 2009.
II. AMS
a) $3,575,990 in respect of the estimated loss of profit from AMS for the three year period of the Subcontract for AMS; or, in the alternative,
b) $543,548.89 for the costs incurred in respect of AMS to the date of termination.
Data Conversion
a) Balance Owing under the Subcontract for Data Conversion
[321] The Data Conversion Amendment of the Subcontract provides for a fixed fee for Data Conversion of $4,370,000. Siemens claims damages of $2,404,000, which is the balance owing for Data Conversion under the Subcontract after deducting $1,966,000, which it was paid during the course of the Subcontract.
[322] Sapient submits that payment to Siemens of the balance of the Subcontract price for Data Conversion “dramatically over-compensates” Siemens because it would ignore the significant costs that Siemens would have incurred to complete the Data Conversion portion of the Subcontract if it had not been terminated. Sapient submits that Siemens is only entitled to the difference between the contract price and its costs to complete, which it has not provided.
[323] It is a fundamental principle of damages in contract law that a plaintiff is entitled to be placed in the position he or she would have been in if the contract had been performed: Wertheim v. Chicoutimi Pulp, [1911] A.C. 301 at 307. As discussed by the Supreme Court of Canada in Bank of America Canada v. Mutual Trust Co., 2002 SCC 43, [2002] 2 S.C.R. 601 , damages for breach of contract are either expectation damages or restitution damages. Restitution damages are based on the advantage gained by the defendant by its breach of contract. Expectation damages, which is the more common form of damages awarded, focuses on the loss suffered by the plaintiff as a result of the breach, including loss of profits.
[324] Siemens is claiming expectation damages. While I agree with Sapient’s submission that the proper measure of the damages for breach of the Subcontract is the balance of the contract price less the costs to complete – i.e., loss of profits, in the circumstances, I do not consider that approach to be the proper measure of Sapient’s damages in respect of the Data Conversion portion of the Subcontract.
[325] As I have found, at the time Sapient terminated the Subcontract on June 29, 2009, the Data Conversion portion was almost, if not entirely, complete. Indeed, Sapient concedes that Go-Live (which equates to the successful completion of Data Conversion) could have been achieved on or around July 19, 2009, less than three weeks after termination. Siemens had not been paid by Sapient for Data Conversion since November 5, 2008. Since then, Siemens incurred significant costs in carrying out the Data Conversion work under the Subcontract through to May 5, 2009. It also incurred significant costs after that date to June 29, 2009, as set out in its claim for in excess of $1 million for costs incurred between May 5, 2009 and termination, following Sapient’s assumption of the track lead in Data Conversion.
[326] Having regard to the above circumstances, I consider that Siemens’ claim for the balance owing under the Subcontract for Data Conversion is appropriate and a proper measure of its damages arising from Sapient’s breach of the Data Conversion portion of the Subcontract. Given the costs Siemens clearly had incurred prior to termination without compensation and the fact that the Data Conversion portion of the Subcontract was very close to completion at the time of termination, I do not consider that such an award “dramatically over-compensates” Siemens. Rather, it puts it in the position it would have been in had Sapient not terminated the Subcontract.
[327] Sapient further submits that even if it did not have the right to terminate the Subcontract for cause, it had the right to terminate the Data Conversion portion of the Subcontract for convenience pursuant to Section 17.4 of the Subcontract. Accordingly, it submits that Siemens’ damages in respect of Data Conversion should be limited to the amount provided for in Section 17.4 in accordance with the rule confirmed by the Supreme Court of Canada in Hamilton v. Open Window Bakery Ltd., 2004 SCC 9, [2004] 1 S.C.R. 303. According to that rule, where there are several ways in which a contract may be performed, damages are awarded based on the mode of performance that is least profitable to the plaintiff and least burdensome to the defendant.
[328] Section 17.4 of the Subcontract (Section 2.5 of the Data Conversion Amendment) provides:
Sapient may terminate the Data Conversion Services for convenience by providing notice to the Subcontractor of such termination, effective as of the date set forth in the notice of termination. Subcontractor shall receive payment for the last milestone preceding the termination plus the lesser of (a) a time and materials rate of $1450 per person (not to exceed 12 people) per day for each day of Data Conversion Services provided following the last completed milestone until the effective date of termination, plus a one time charge of $50,000 and (b) the amount due at the next milestone, had the Data Conversion Services not been terminated.
[329] Sapient submits that, given the termination date of June 29, 2009, the amount that would be owing to Siemens in accordance with the formula set out in Section 17.4 is $622,725.
[330] In my view, the rule in Open Window does not apply to Sapient’s termination of the Subcontract having regard to its terms. Simply put, given Sapient’s intention to terminate the entire Subcontract pursuant to Section 17.2, Section 17.4 is not an alternative mode of performance permitting Sapient to terminate the entire Subcontract.
[331] Section 17.2 of the Subcontract permitted Sapient to terminate the entire Subcontract, including AMS. As I have found, that is exactly what Sapient intended to do. It had no intention of terminating just the Data Conversion portion of the Subcontract. On the other hand, Section 17.4, the termination for convenience provision, applies only to the Data Conversion portion of the Subcontract. Accordingly, termination for convenience is not an alternate mode enabling Sapient to terminate the entire Subcontract. It follows that because Sapient intended to terminate the entire Subcontract, it cannot rely on the termination for convenience provision to limit Siemens’ Data Conversion damages.
[332] In the event that I am wrong in my conclusion that Sapient cannot rely upon Section 17.4 of the Subcontract to limit its damages in respect of the Data Conversion portion of the Subcontract, it is necessary to determine what damages Sapient would owe to Siemens if the termination for convenience provision of the Subcontract applies.
[333] Section 17.4 provides a formula for Siemens’ compensation in the event of termination of the Data Conversion Services for convenience. It provides for payment of the sum of two amounts: First, payment of the last milestone preceding the termination and second, the lesser of (a) time and materials at a rate of $1450 per person (not to exceed 12 people) per day for each day of Data Conversion Services provided following the last completed milestone until the effective date of termination, plus a onetime charge of $50,000 and (b) the amount due at the next milestone, had the Data Conversion Services not been terminated.
[334] As noted, Sapient submits that the total amount owing to Siemens pursuant to Section 17.4 is $622,725, made up of $655,500 being the lesser of the daily rate and the amount due at the next milestone (the second part of the payment formula) less a penalty of 5% ($32,775) in respect of Milestone 54 being more that 21 days late (Schedule 10A, Section 4). In respect of the first item in the payment formula in Section 17.4, Sapient submits that because Siemens was paid for the last milestone preceding termination, no amount is owing in respect of that item.
[335] Siemens agrees that the lesser of the daily rate and the amount due at the next milestone is $655,500. It also does not contest the Milestone 54 late delivery penalty. It submits, however, that it would be entitled to a further $437,000, which is the payment due for the last milestone preceding termination (10% of the total Subcontract price).
[336] The issue is what is meant by the words “for the last milestone preceding termination” in Section 17.4. The plain language of the words in that Section provides that Sapient must pay Siemens for the last milestone preceding the termination in the event of termination. Significantly, the words do not provide that payment in respect of the last milestone is only to be made if it has not yet been paid.
[337] Further, it is reasonable to conclude that at the time the termination for convenience provision is invoked, Sapient’s obligation to pay the previous milestone would have already crystallized and been paid. Consequently, the provision in Section 17.4 to pay for the last milestone preceding termination is not to ensure that Siemens was paid for that previous milestone but rather to provide an additional level of compensation to Siemens given that termination was for convenience and not cause.
[338] I conclude, therefore, that Section 17.4 requires Sapient to pay to Siemens the amount owing for the last milestone preceding termination regardless of whether that amount has already been paid, together with the lesser of the two amounts set out for services since the last completed milestone.
[339] Accordingly, if Siemens’ damages for breach of the Subcontract in respect of Data Conversion are calculated in accordance with the termination for convenience provision in the Subcontract, I assess Siemens’ damages in that respect at $1,059,725 ($622,725 plus $437,000).
b) Unpaid Invoices
[340] Siemens claims $311,690 in respect of change requests that were invoiced by Siemens to Sapient but not paid. Sapient submits that Siemens lead no evidence to explain the nature of the charges or to establish that the invoices were delivered in accordance with the Subcontract and particularly Sections 13.6.3 and 2.3.6.1.
[341] Mr. Kormann’s evidence, which I accept, is that the invoices in respect of the amount claimed were approved by Sapient. That evidence was not contradicted. Approval infers knowledge of the nature of the charges. Nor has Sapient established any failure of delivery in accordance with the Subcontract. Accordingly, Siemens is entitled to payment of $311,690 in respect of the invoices.
c) Time and Materials between May 5 and June 29, 2009
[342] Finally, Siemens claims $1,011,874.44 in respect of invoices rendered to Sapient for time and materials spent by it from May 5 to June 29, 2009 following Sapient’s assumption of the Data Conversion lead.
[343] The parties agreed on May 5, 2009 that the Subcontract would continue. Further, while they agreed to meet and agree on the basis upon which Siemens would be compensated in respect of its involvement going forward, no agreement in that regard was ever reached. Accordingly, the Subcontract, including its provisions with respect to payment, continued.
[344] In light of the fact that I have held that Siemens is entitled to the balance of the amount owing under the Subcontract for Data Conversion, I do not consider that Siemens is entitled to be paid for its services between May 5, 2009 and June 29, 2009. I consider the amounts claimed to be part of Siemens services under the Data Conversion portion of the Subcontract. Given I have awarded Siemens the full amount of the balance owing to it under the Data Conversion portion of the Subcontract, payment for time and materials after May 5, 2009 would effectively amount to double compensation.
[345] In summary, therefore, Siemens is entitled to damages for Sapient’s breach of the Subcontract in respect of Data Conversion in the amount of $2,715,690 ($2,404,000 plus $311,690).
i. AMS
[346] Siemens claims damages for loss of profit arising from Sapient’s wrongful termination of the AMS portion of the Subcontract in the amount of $3,575,990. In the alternative, Siemens claims $543.548.89 for the costs incurred in respect of AMS prior to termination.
a) Claim for Loss of Profit
[347] As noted, at the beginning of March 2009, as a result of a request from Enbridge, Siemens and Sapient reached an agreement on resolutioning of the AMS portion of the Subcontract. Although there was no formal signed document, I am satisfied from the evidence of Carrington that the agreement was reached. Further, Sapient introduced no evidence to contradict it.
[348] Siemens’ claim of $3,575,990 represents the total gross profit Siemens estimates it would have earned from the AMS portion of the Subcontract had it remained in force for the full three year period following Go-Live and not been terminated. It is based on the amounts agreed to by Siemens and Sapient in the resolution and includes the resolution amount of $400,000 agreed to with Sapient in early 2009 as part of the resolutioning.
[349] The amount of $3,575,990 represents Siemens’ gross profit calculated from its reasonable estimate of revenues and costs. The estimated amount was based on Siemens’ prior experience in providing AMS services and subjected to a rigorous in-house review. Based on the process Siemens followed and its experience in providing such services, I am satisfied that the estimate, which was compiled and verified by Siemens in a manner similar to its initial pricing of the Subcontract for AMS, is both accurate and reliable. I accept it.
[350] Sapient submits that Section 18.6 of the Subcontract operates to exclude Siemens’ claim for loss of profits arising from the termination of AMS portion of the Subcontract.
[351] Section 18.6 of the Subcontract, which is entitled Limitation of Liability, provides, in part:
18.6.1 SUBJECT TO SECTION 18.6.2, NOTWITHSTANDING ANYTHING TO THE CONTRARY HEREIN, EACH OF SUBCONTRACTOR AND SAPIENT WILL BE LIABLE TO THE OTHER WITH RESECT TO THIS AGREEMENT AND ANY OTHER OBLIGATIONS RELATED THERETO ONLY FOR DIRECT DAMAGES AND FOR AN AMOUNT THAT WILL NOT EXCEED, IN THE AGGREGATE
FOR GREATER CERTIANTY, SUBJECT TO SECTION 18.6.2, NEITHER SUBCONTRACTOR NOR SAPIENT WILL BE LIABLE TO THE OTHER TO THE OTHER FOR INDIRECT, SPECIAL, CONSEQUENTIAL OR PUNITIVE DAMAGES OR FOR LOSS OF PROFITS (COLLECTIVELY, “EXCLUDED DAMAGES”), EVEN IF THE PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
18.6.3 THIS SECTION 18.6 WILL APPLY IRRESPECTIVE OF THE NATURE OF THE CAUSE OF ACTION, DEMAND OR CLAIM, INCLUDING BUT NOT LIMITED TO, BREACH OF CONTRACT (INCLUDING FUNDAMENTAL BREACH), NEGLIGENCE, TORT OR ANY OTHER LEGAL THEORY, AND WILL SURVIVE A FUNDAMENTAL BREACH OR BREACHES AND/OR FAILURE OF ESSENTIAL PURPOSE OF THIS AGREEMENT OR OF ANY REMEDY CONTAINED HEREIN.
[352] The reservation concerning Section 18.6.2 in the first two paragraphs of Section 18.6.1 above refers to certain claims set out in that Subsection which do not apply to Siemens’ claim.
[353] In Tercon Contractors Ltd. v. British Columbia (Minister of Transportation & Highways), 2010 SCC 4; 1 S.C.R. 69, at paras. 122 and 123, Binnie J. set out the three-stage test for dealing with the exercise of what the learned Judge referred to as the court’s “narrow jurisdiction” to give relief against exclusion or limitation of liability clauses:
- The first issue, of course, is whether as a matter of interpretation the exclusion clause even applies to the circumstances established in evidence. This will depend on the Court’s assessment of the intention of the parties as expressed in the contract. If the exclusion clause does not apply, there is obviously no need to proceed further with this analysis. If the exclusion clause applies, the second issue is whether the exclusion clause was unconscionable at the time the contract was made, “as might arise from situations of unequal bargaining power between parties” (Hunter, at p. 462). This second issue has to do with contract formation, not breach.
123 If the exclusion clause is held to be valid and applicable, the Court may undertake a third inquiry, namely whether the Court should nevertheless refuse to enforce the valid exclusion clause because of the existence of an overriding public policy, proof of which lies on the party seeking to avoid enforcement of the clause, that outweighs the very strong public interest in the enforcement of contracts.
[354] In my view, when the words in Section 18.6.1 are read both on their own and in the context of the Subcontract as a whole, the limitation of liability set out in Section 18.6.1 does not apply to Siemens damage claim for loss of profits in respect of AMS.
[355] In Sattva Capital Corp. v. Creaston Moly Corp., 2014 SCC 53, [2014] 2 S.C.R. 633, Rothstein J., on behalf of the court, discussed the current approach to contractual interpretation at paras. 47 and 48:
- … the interpretation of contracts has evolved towards a practical, common-sense approach not dominated by technical rules of construction. The overriding concern is to determine "the intent of the parties and the scope of their understanding" (Jesuit Fathers of Upper Canada v. Guardian Insurance Co. of Canada, 2006 SCC 21, [2006] 1 S.C.R. 744, at para. 27 per LeBel J.; see also Tercon Contractors Ltd. v. British Columbia (Minister of Transportation & Highways), 2010 SCC 4, [2010] 1 S.C.R. 69, at paras. 64-65 per Cromwell J.). To do so, a decision-maker must read the contract as a whole, giving the words used their ordinary and grammatical meaning, consistent with the surrounding circumstances known to the parties at the time of formation of the contract. Consideration of the surrounding circumstances recognizes that ascertaining contractual intention can be difficult when looking at words on their own, because words alone do not have an immutable or absolute meaning:
No contracts are made in a vacuum: there is always a setting in which they have to be placed.... In a commercial contract it is certainly right that the court should know the commercial purpose of the contract and this in turn presupposes knowledge of the genesis of the transaction, the background, the context, the market in which the parties are operating.
(Reardon Smith Line, at p. 574, per Lord Wilberforce)
- The meaning of words is often derived from a number of contextual factors, including the purpose of the agreement and the nature of the relationship created by the agreement (see Geoffrey L. Moore Realty Inc. v. Manitoba Motor League, 2003 MBCA 71, 173 Man. R. (2d) 300, at para. 15, per Hamilton J.A.; see also Hall, at p. 22; and McCamus, at pp. 749-50). As stated by Lord Hoffmann in Investors Compensation Scheme Ltd. v. West Bromwich Building Society, [1998] 1 All E.R. 98 (H.L.):
The meaning which a document (or any other utterance) would convey to a reasonable man is not the same thing as the meaning of its words. The meaning of words is a matter of dictionaries and grammars; the meaning of the document is what the parties using those words against the relevant background would reasonably have been understood to mean. [p. 115]
[356] Turning first to the wording of Section 18.6, the wording in Section 18.6.1, which limits damages to direct damages only, includes loss of profits under the Subcontract. As previously discussed, expectation damages, which are direct damages, include loss of profits.
[357] Section 18.6.1 goes on, however, “for greater certainty” to provide that neither Siemens nor Sapient will be liable to the other for “indirect, special, consequential or punitive damages or for loss of profits (collectively, ‘Excluded Damages’), even if the party has been advised of the possibility of such damages.”
[358] Given the above grouping and inclusion of “loss of profits” as Excluded Damages along with “indirect, special and consequential damages”, in my view the reference to “loss of profits” in Section 18.6.1 refers to consequential or indirect lost profits, i.e., a breach that causes either Siemens or Sapient to lose profit from other work forgone as a result of the breach. Consequential lost profits do not include profits under the Subcontract but rather are indirect losses which are only recoverable when they are foreseeable or communicated to the defendant: Hadley v. Baxendale (1854), 9 Exch. 341, 156 E.R. 145 (Eng. Ex. Div.) at para. 3. My conclusion that the provision of “loss of profits” in Excluded Damages relates to consequential or indirect profits is further confirmed by the concluding words of the paragraph which provide: “even if the party has been advised of the possibility of such damages.” That language is in accordance with the Hadley recovery principle for consequential damages.
[359] In my view, the above interpretation of “loss of profits” in s. 16.1 is also confirmed when considering the context of the Subcontract. The AMS portion of the Subcontract is a fixed price commercial contract for services. It is reasonable to assume that parties who enter into such a contract would rely on the fact that they would receive the loss of profit component of the price in the event of a breach. As stated by Professor Waddams in the Law of Contracts, (6th ed.), at pp. 523-524, the main purpose of contracts in a commercial context is to allow and protect reliance. The learned author goes on to state:
Thus… reliance can only be fully protected, at least in a commercial context, by a rule that measures damages by the value of performance, enabling the plaintiff to recover what has been called the “expectation” interest or damages for “the loss of bargain.”
[360] Further, there is no evidence surrounding the formation of the contract that would support a finding that it was the intention of the parties at the outset of the Subcontract that the limitation of liability clause would apply to prevent the recovery of loss of profits in the event of a breach of the Subcontract.
[361] For the above reasons, therefore, I conclude as a matter of interpretation that the limitation of liability clause in Section 18.6 of the Subcontract does not apply to Siemens’ claim for loss of profits arising from Sapient’s breach of the AMS portion of the Subcontract. The claim for lost profits is a direct damage claim and does not come within the exclusion in Section 18.6.1 of the Subcontract. As a result of my conclusion, as noted above by Justice Binnie in Tercon, there is no need to proceed further with the Tercon analysis.
a) Costs Incurred in Respect of AMS
[362] Siemens claim for $543,548.89 in respect of costs it incurred in staffing and getting prepared for AMS prior to June 29, 2009 is an alternative claim.
[363] In light of my conclusion that Siemens is entitled to damages of $3,575,990 arising from the breach of the AMS portion of the Subcontract, it is not necessary to deal with this claim. In the event that I am wrong in my interpretation of the application of Section 18.6 of the Subcontract, I am satisfied that Siemens has established that it incurred $543,548.89 in costs in connection with staffing and getting prepared for AMS. Further, Sapient does not take issue with the calculation of those costs.
Sapient’s Damage Claim
[364] Sapient’s damage claim has four components:
Unplanned costs attributable to Siemens’ delays $7,994,785.78
Repair costs 1,924,009.88
Unpaid Invoices 249,312.01
Enbridge Penalty 1,978,000.00
$12,146,107.67
- Unplanned Costs
[365] Sapient’s claim for unplanned costs is based on its claim that Siemens’ breach of the Data Conversion portion of the Subcontract was the root cause of the delays to the Go-Live dates resulting in increased costs to Sapient.
[366] As noted, I have rejected that position. In my view, Siemens breaches of the Subcontract were not the root cause of the delays to Go-Live. While Data Conversion was one of the factors which led to the delay to the initial Go-Live date in April 2009 and then the second date in June 2009, it was only one of many other factors that were the responsibility of Sapient.
[367] Sapient’s claim for increased costs of $7,994,785.78 covers the period from September 2008 to September 2009. It is based on the difference between its projected costs over that period compared with its actual costs.
[368] Based on its initial projections of costs versus revenues, Sapient expected to earn a gross margin under the Prime Contract for “Rollout 1 Functionality” of 31%. As a result of what Sapient submits was its initial managing of costs, the projected margin actually improved to 32.4% as of June 2008.
[369] Sapient’s final damages summary indicates that its total projected costs including independent resources from the week of September 9, 2008 (the start of integration testing) to the April 6, 2009 (the original Go-Live date) were projected to be $7,672,686.11. Further, Sapient’s total projected costs from April 6, 2009 to the end of the original warranty period were $819,674.30. The total of the two cost estimates is $8,492,360.41.
[370] By contrast, Sapient submits that its total actual costs from the week of September 9, 2008 to the actual Go-Live on September 12, 2009 were $17,541,481.77. As a result, Sapient submits that it incurred unplanned additional costs from September 2008 to September 2009 of $9,868,795.66 ($17,541,481.77 – 7,672,686.11). From that amount, Sapient subtracts the repair costs its claims separately of $1,924,009.88 to bring its unplanned costs claim to $7,944,785.78.
[371] Sapient’s claim for damages of $7,944,785.78 for unclaimed costs fails for a number of reasons.
[372] First, it is based on the assumption that Siemens was solely responsible for the delays to Go-Live, initially from April 3 to June 7, 2009 and then from June 7 to September 12, 2009. As I have held, however, the evidence clearly indicates that while part of the delay in respect of the delays to Go-Live from April 2009 to June 2009 and then from June to September 2009 can be attributed to Siemens, there were other causes for the delays, not the least of which was the failure of Sapient’s management.
[373] Further, to the extent that some of the delay can be attributed to Data Conversion, that delay was further impacted by other streams of work on the Project, which in turn impacted Data Conversion, and also by Sapient’s project management. Sapient has made no effort to focus its claim on the actual delays caused by Siemens but rather has elected to blame all of its increased costs on Siemens.
[374] I also have serious concerns with the credibility of Sapient’s claim for unplanned costs based on its late delivery. Although the parties had agreed to a couple of timetables providing for production deadlines, discovery dates and dates by which answers to undertakings were to be answered and refusals dealt with, all well before trial, particulars of the claim were not produced to Siemens until three business days before trial (notwithstanding an undertaking at discovery to provide them in advance of trial). I permitted Sapient to introduce its claim at trial but not without reservations.
[375] Further, the claim appears to have been compiled by someone in Sapient’s lawyers’ office. The Sapient witnesses who testified to it at trial (Kapur and Paau) had no direct knowledge of how it was compiled. They testified to the source documents being Sapient’s records of the projected costs and the actual costs as set out in various spreadsheets.
[376] Further, Sapient’s claim is premised on a number of assumptions, many of which I do not accept. For instance, it presumes that Sapient is experienced in projecting costs. But the evidence is that Sapient had never before engaged in an SAP implementation project nor an SAP IS-U implementation, let alone a major large scale implementation the size of the Project. The unreliability of Sapient’s cost estimating is demonstrated by the warranty period, which is not claimed against Siemens, where Sapient’s projected costs were $819,674.30 versus its actual costs of $1,532,551.16 – almost double what it projected. Sapient presented no evidence to satisfy me that its cost projections were compiled in a manner that ensured their accuracy and/or reliability. I am not satisfied therefore that Sapient’s initial cost projections as at September 9, 2008 represent an accurate estimate of costs going forward.
[377] Further, even if I had found that Siemens was the sole cause of the delays to Go-Live, I cannot accept that all of Sapient’s increased costs from September 2008 to September 2009 are attributable to Siemens. By way of example, Sapient concedes that the Project was ready to Go-Live as at July 31, 2009 but was delayed to September 12, 2009 at Enbridge’s request. Notwithstanding that Siemens had no involvement in that delay, part of Sapient’s claim, which is calculated to the September 12 2009 Go-Live date, incorporates those extra costs and attributes them to Siemens.
[378] Further, there is no detailed analysis of what the extra costs for every employee related to. Based on the claim as presented, it is impossible to know what a particular employee or consultant was doing and why that resulted in the alleged increased costs. For example, in January/February 2009, Childs and Paau confirmed that Sapient had a significant resource issue on both the functional and the technical tracks that required it to hire additional resources. There is no evidence that issue related to Data Conversion, yet those additional costs form part of Sapient’s claim. Further, if Sapient estimates an employee will take two hours to perform a task but in fact he or she takes five hours through no fault of Siemens, those additional hours form part of Sapient’s claim based on the global way in which it has chosen to approach its claim.
[379] I find therefore for all of the above reasons that Sapient has failed to adduce either accurate or reliable evidence from which I can assess its damages arising from Siemens’ breach of the Subcontract.
[380] In its submissions, Sapient relies on the principle that where damages are by their inherent nature difficult to assess, the court must do the best it can in the circumstances to determine such damages. A litigant is not relieved, however, from his or her duty to prove the facts upon which damages are estimated. Where an absence of evidence makes it impossible to assess damages, the litigant is entitled to nominal damages at best: Martin v. Goldfarb, 1998 CanLII 4150 (ON CA) ; TMS Lighting Ltd. v. KJS Transport, 2014 ONCA 1, 314 OAC 133.
[381] The onus is on Sapient to prove its damages. In my view, it has not provided the court with either adequate or appropriate evidence to enable the court to make a proper determination of its damages. As a result, any determination of its damages other than as can be obtained from the evidence will be based on pure guess work. It is not sufficient to effectively dump a compilation of records on the court without a proper foundation and say, effectively, you must do the best you can in the circumstances.
[382] For the above reasons, I consider Sapient’s evidence of damages to effectively amount to an “absence of evidence” entitling it to nominal damages at best. Although I have found that Siemens breach of the Subcontract was not the root cause of the delays to Go-Live, in the event that I am found to be wrong in that conclusion, I assess Sapient’s damages in that regard nominally at $150,000.
[383] As noted, I have concluded that Siemens was in breach of the Subcontract in the fall of 2008, when its issues surrounding the completion data conversion code contributed, in part, to a delay of the Go-Live date for the Project and again in the spring of 2009, when its reconciliation issues contributed to but were not the only cause for the delay of Go-Live past June 7, 2009.
[384] Siemens’ breach of the Subcontract in the fall of 2008 was short lived. Although delays were occasioned to ITC’s 1 & 2 and ITC 3, Siemens addressed the issues directly and by December, 2008 the problems were solved.
[385] Sapient has provided no evidence of damages arising from Siemens’ breach of the Subcontract in the fall of 2008. The only evidence of damages are the invoices that it sent to Siemens for work done by its staff during the period September to December 2008 in respect of the completion of Mock 1, including management and assistance activities. Those invoices total $306,687.83. Siemens disputes the invoices and they form part of Sapient’s “repair costs” claim.
[386] In the absence of my finding of Siemens’ breach, I would not have allowed Sapient’s claim for the work done without Siemens’ agreement to the invoices. There is no provision in the Subcontract that permits it. In my view, however, given the connection between the work done by Sapient and Siemens’ breach, I allow Sapient’s claim for $306,687.83 as damages arising out of Siemens breach of the Subcontract in the fall of 2008.
[387] The assessment of damages in respect of Siemens’ breach of the Subcontract in the spring of 2009 is not as straight forward. As noted, I have found that Sapient was in breach of the Subcontract in the spring of 2009 in respect of the reconciliation requirement. Once again, the breach contributed in part to delay. While Siemens’ breach in the spring of 2009 had more of an impact on the delay to Go-Live than the one in the fall of 2008, it was still only one of a number of other contributing factors that caused that delay. Further, the delay attributable to Data Conversion was at most only for a month given that the reconciliation targets were being met by early July.
[388] Apart from the above noted factors, there is another matter that needs to be taken into account when assessing Sapient’s damages arising out of Siemens’ breach of the Subcontract in the spring of 2009 – Sapient’s contribution to that breach. As I have found, Sapient’s actions in the spring of 2009 as Project Manager directly inhibited Siemens ability to perform its obligations under the Subcontract.
[389] The Negligence Act, R.S.O. 1990, c. N.1 and the principle of contributory negligence do not apply to contract actions. Nevertheless, the principle that a person who is part author of his own injury should not receive full compensation from the other party has been accepted by the courts as being equally applicable in cases of contract as well as tort. The principle has been called “contributory fault”: see Tompkins Hardware Ltd. v. North Western Flying Services Ltd. (1982), 1982 CanLII 3160 (ON SC), 139 D.L.R. (3d) 329 (Ont. H.C.); Treaty Group v. Drake International, [2005] O.T.C. 1044 (Ont. S.C.J.).
[390] In my view, in light of its actions that inhibited Siemens’ ability to perform its obligations under the Subcontract in the spring of 2009, I would further reduce Sapient’s damages arising from Siemens’ breach at that time by 30%.
[391] Unlike the invoices in the fall of 2008, I do not consider Sapient’s invoices for work done by its resources between May 5 and September 2009 in the amount of $1,617,322.05 to be an appropriate measure of its damages. Sapient elected to take over Data Conversion on May 5, 2009 while at the same time confirming the Subcontract. In my view, therefore, the costs incurred by Sapient in respect of Data Conversion after May 5, 2009 are its responsibility solely and cannot be recovered from Siemens.
[392] As discussed above, Sapient has provided no analysis of its damages to enable me to accurately determine its damages arising out of Siemens breach in the spring of 2009. In my view, it could have done so. Having failed to provide such a breakdown, taking into account the above noted factors, I assess Sapient’s damages for the spring 2009 breach in the amount of $100,000 which I reduce by 30% to $70,000 based on my assessment of Sapient’s contributory fault.
- Repair Costs
[393] Sapient’s claim of $1,924,009.88 for repair costs is made up of two amounts: the above mentioned $306,687.83 for Sapient resources assigned to work on conversion during September to December 2008; and $1,617,322.05 for Sapient resources assigned to work on data conversion from May 2009 to September 2009.
[394] Having found that the amount of the 2008 invoices is equivalent to Sapient’s damages from Siemens’ breach of contract in the fall of 2009, I do not need to further deal with its claim in that regard.
[395] Nor am I prepared to allow Sapient’s claim for its costs incurred on data conversion between May 5, 2009 and September 2009. As noted, Sapient elected to take over data conversion on May 5, 2009. Although the parties agreed to discuss the basis upon which Siemens resources would be compensated, there was no agreement concerning Siemens paying Sapient for its resources.
[396] In the absence of agreement, Sapient is not entitled to be reimbursed for those costs. Once again, there is nothing in the Subcontract that provides for such payment.
- Unpaid Invoices
[397] Sapient’s claim for unpaid invoices of $249,312.01 relates to two invoices: Invoice 8382 for $79,545.38 and Invoice 8871 for $169,766.63. The invoices were in respect of the services of Monahan and Peterson, Sapient resources that were provided to Siemens under the Subcontract.
[398] Siemens conceded at the outset of the trial that it owed the amounts set out in the invoices in accordance with the Subcontract. Accordingly, Sapient is entitled to $249,312.01.
- Enbridge Penalty
[399] Sapient claims $1,980,000 from Siemens in respect of a penalty Enbridge assessed against it under Section 3.12.3 of the Prime Contract because of the delay in the Go-Live date (the “Penalty”).
[400] Section 3.12.3 of the Prime Contract provides that if Sapient fails to complete any activities required to enable Enbridge to issue an Acceptance Notice for the Rollout 1 Functionality or Rollout 2 Functionality within 30 days of the of the deadline for completion of the Payment Milestone set forth in the Project Plan, then the amount owing to Sapient will be reduced by an amount determined by the length of the delay.
[401] The Penalty was based on the fact that the Rollout 1 Functionality was more than 90 days late and in accordance with Section 3.12.3.
[402] Sapient’s claim is for the entire amount of the Penalty. As I have found, however, Siemens was not the root cause of the delay to Go-Live. While Siemens’ issues with Data Conversion contributed to the delays, much of cause lies at the feet of Sapient and its poor project management.
[403] As part of the financial negotiations between Enbridge and Sapient at the end of the Project in September 2009, Enbridge offered to walk away from any penalties if Sapient agreed to forgo its claim for change orders which was $2.375 million and which Enbridge valued at $1.3 million. Child agreed that in the end Sapient agreed to pay the penalty rather than off-set it against the change orders. There is no evidence as to how the change orders were ultimately resolved.
[404] Siemens submits that Sapient is not entitled to claim the Penalty against it given that it elected to pay the Penalty rather than settle its claim for change orders. While the issues surrounding Enbridge’s assessment of the Penalty and its true value concern me, I accept that the Penalty was owed under the Prime Contract and that Sapient paid it to Enbridge. I do not consider that Siemens is required to reimburse Sapient in respect of the Penalty.
[405] As I have held, the delays to the Project, including for the Acceptance Notice of Readiness for the Rollout 1 Functionality, were the result of many factors, Data Conversion being only one. Further, Sapient, as the Project Manager, bears the overall responsibility for the delay.
[406] Just as the Prime Contract has penalty provisions in it concerning Sapient’s performance, so too does the Subcontract in respect of Siemens’ performance. Rather than apportion some part of the Penalty to Siemens arising from its delay, in my view, the better approach is to look to the Subcontract and what the parties agreed to in respect of late delivery.
[407] Specifically, Section 4 of the DC Statement of Work of the Subcontract provides for late delivery penalties payable by Siemens to Sapient in respect of Data Conversion. In particular, section 4(a)(ii) provides, in part, that failure to meet the “Acceptance Notice of Readiness for the Rollout 1 Functionality” milestone by more than 21 business days gives rise to a penalty of 5% of the payment amount associated with the milestone.
[408] The Penalty was imposed by Enbridge in respect of its failure to meet the Acceptance Notice of Readiness for the Rollout 1 Functionality. Siemens failed to meet date required for the Acceptance of Notice for the Rollout 1 Functionality as set out in the Subcontract. As a result, in accordance with the terms of the Subcontract, it is liable to pay Sapient a penalty of 5% of $2,404,000.00 or $120,200 on account of such failure.
[409] Accordingly, I am not prepared to award Sapient any amount in respect of the Penalty it paid to Enbridge pursuant to the Prime Contract. I find, however, that Siemens is liable to Sapient for a penalty of $120,200 under the Subcontract on account of its late delivery of the Acceptance Notice of Readiness for the Rollout 1 Functionality requirement in the Subcontract.
Conclusion
[410] For the above reasons, Siemens action is allowed. Sapient breached the Subcontract by wrongfully terminating it on June 29, 2009. As a result, Siemens is entitled to damages in the total amount of $6,291,680 made up as follows:
$2,404,000 on account of the balance owing under the Subcontract for Data Conversion;
$311,690 on account of change requests;
$3,575,990 on account of lost profits under the Subcontract for AMS.
[411] Siemens Austria’s (Atos IT Solutions and Services GMBH) claim is dismissed.
[412] Sapient’s counterclaim in respect of Siemens’ breach of the Data Conversion portion of the Subcontract is allowed and Sapient is entitled to damages in the total amount of $746,199.84 made up as follows:
$306,687.83 on account of Siemens breach of the Subcontract in the fall of 2008;
$70,000 on account of Siemens breach of the Subcontract in the spring of 2009;
$249,312.01 for the unpaid invoices; and
$120,200 in respect of Siemens’ penalty for late delivery.
[413] The parties are encouraged to agree on costs. In that regard, they shall circulate bills of costs to each other and meet to discuss a resolution within 30 days of these reasons.
[414] In the absence of an agreement, the parties shall make brief written submissions of no more than 10 pages, not including their bills of costs as follows:
Siemens shall deliver their submissions by January 20, 2017. Siemens shall provide a separate bill of costs in respect of any extra work done in relation to Sapient’s counterclaim between September 25, 2015 and December 8, 2015 as a result of my ruling of October 6, 2015.
Sapient shall deliver its submissions by January 30, 2017.
There shall be no reply submissions.
L. A. Pattillo J.
RELEASED: December 7, 2016
CITATION: Atos v. Sapient, 2016 ONSC 6852
COURT FILE NO.: CV-10-8845-00CL
DATE: 20161207
ONTARIO
SUPERIOR COURT OF JUSTICE
COMMERCIAL LIST
BETWEEN:
ATOS IT SOLUTIONS AND SERVICES GMBH and ATOS INC.
Plaintiffs
– and –
SAPIENT CANADA INC.
Defendant
REASONS FOR JUDGMENT
PATTILLO J.
Released: December 7, 2016