England and Wales High Court (Technology and Construction Court) Decisions
You are here: BAILII >> Databases >> England and Wales High Court (Technology and Construction Court) Decisions >> Topalsson GmbH v Rolls-Royce Motor Cars Ltd [2023] EWHC 1765 (TCC) (12 July 2023)
URL: http://www.bailii.org/ew/cases/EWHC/TCC/2023/1765.html
Cite as: [2023] EWHC 1765 (TCC)
[New search] [Printable PDF version] [Help]
BUSINESS AND PROPERTY COURTS OF ENGLAND AND WALES
TECHNOLOGY AND CONSTRUCTION COURT (KBD)
Rolls Building London, EC4A 1NL |
||
B e f o r e :
____________________
| TOPALSSON GmbH | Claimant |
|
| - and - |
||
| ROLLS-ROYCE MOTOR CARS LIMITED | Defendant |
____________________
Alex Charlton KC & Iain Munro (instructed by Clarkslegal LLP) for the Defendant
Hearing dates: 5th, 6th, 10th, 11th, 12th, 13th, 17th, 18th, 19th, 20th,
24th, 25th, 26th, 27th, 31st October 2022
1st, 2nd and 15th November 2022
____________________
Crown Copyright ©
- This matter concerns claims and counterclaims for damages arising out of the termination of an agreement for the development and supply of digital twin software for a new car configurator.
- A digital twin is a virtual model of a physical object, existing or yet to be built. Engineers create a computer model of an object, expressed in geometrical and mathematical terminology. The engineering model is converted into a visual representation of the object by a process known as rendering. Software development by written source code enables the visual models to be manipulated using the engineering model data to produce different configurations of the object.
- The claimant ("Topalsson") is a company incorporated in Germany, a specialist supplier to the automotive industry of digital twin engine ("DTE") and configurator software, which allows prospective customers of an automotive manufacturer to configure and see photo realistic renderings of the vehicles they are considering purchasing.
- The defendant ("RRMC") is a wholly-owned subsidiary of BMW that manufactures and sells luxury motor cars.
- By a services agreement dated 11 October 2019 ("the Agreement"), RRMC engaged Topalsson to design, build, implement and maintain digital visualisation software to replace its existing car configurator landscape, in order to improve its customers' configuring and commissioning experience by allowing real-time generation of images from 3D models and to support the company's growth.
- RRMC intended to use the new configurator landscape for the launch of the new Rolls-Royce Ghost model in Spring 2020, and thereafter for sales activities in respect of that model and for the configuring and ordering of other existing models.
- Delays occurred to the development and supply of the software. The causes of such delays are disputed and each party blames the other for the same.
- It is said by Topalsson that RRMC imposed on it an implementation methodology that was ill-suited to achieving results in the compressed timescales required, the scope of the project expanded and RRMC refused to agree a billing plan to provide Topalsson with adequate funding for the extensive work required.
- It is said by RRMC that Topalsson obtained its appointment by misrepresenting its experience and expertise, failed to resource the project adequately, performed poorly and was significantly in delay by 2020. In particular, RRMC's case is that Topalsson failed to achieve 'Technical Go-Live' for: (i) the Closed Room Configurator ("Closed Room"); (ii) Imagery Validation Tool, a tool used to validate imagery before release to the configurators ("IVT"); and (iii) Colouring System (CoSys) Replacement Imagery Service ("CRIS") by the dates agreed in March 2020 ("the March Plan").
- By letter dated 16 April 2020 ("the First Termination Notice"), RRMC purported to terminate Topalsson's engagement under the Agreement at common law. Topalsson rejected the First Termination Notice as ineffective and affirmed the Agreement.
- By letter dated 22 April 2020, without prejudice to the First Termination Notice, RRMC served a further notice ("the Second Termination Notice"), purporting to terminate at common law; alternatively, under clause 13.11.3 of the Agreement. By letters dated 1 May 2020 and 9 June 2020, Topalsson purported to accept RRMC's alleged repudiatory breach.
- Topalsson ceased working on the project from the end of May 2020.
- Topalsson claims damages for unlawful termination, quantified as lost profits in the sum of 6,420,793; alternatively, 2,420,793 in respect of work carried out and/or invoiced as at the date of termination as sums to which it is contractually entitled. It also seeks a declaration that RRMC is not entitled to make use of deliverables for which it has not paid and/or an order for delivery up or destruction of Topalsson's software.
- RRMC counterclaims damages flowing from the alleged repudiatory breach and damages for misrepresentation. It claims that it suffered loss and damage amounting to 20 million in respect of replacement software, lost profits and other heads of claim. It also seeks delivery up or destruction of software that incorporates RRMC's confidential information and data.
- It is common ground that there is an effective contractual limitation of liability; save for the misrepresentation claim, both parties' contractual claims are capped at 5 million by clause 20 of Section 7 of the Agreement.
- In about September 2018 RRMC recognised that its current configurator technology was outdated and should be replaced. Although there was no fixed timeline at that stage, particularly because pending the outcome of the exploration phase no decision had been taken as to precisely what was required, the indicative internal timeline for the project was that it should be ready for the launch of the new Ghost Rolls-Royce model, including:
- The RRMC Board approved a budget for the exploration phase, which took place between December 2018 and February 2019.
- On 11 April 2019, RRMC issued a Request for Information ("the 'RFI") for the future configurator landscape project to potential bidders, including Topalsson. The RFI contained a general description of the project, divided into thirteen delivery packages ("the Delivery Packages" or "DPs"), the purpose of which was to achieve the following:
- Those responding to the RFI were required to provide a proposal for each of the identified Delivery Packages but were free to propose the method of delivery.
- On 30 April 2019 Topalsson provided its response to the RFI, identifying that its selected delivery approach would be the agile development method.
- In internal discussions, RRMC considered that the framework conditions for an agile project were not available, although an agile implementation model might be appropriate, and therefore decided that the tender process should be started on a classic waterfall model.
- On 21 May 2019 a formal invitation to tender ("the ITT") was issued to potential bidders, including Topalsson. The ITT included a list of 'Detailed Business Requirements' that bidders would be required to deliver as defined in the Delivery Packages, some of which were described as optional.
- The bidders were invited to provide a fixed price for all necessary activities and phases needed to deliver and operate the end product, including IT Design, IT implementation and roll out according to the BMW Group ITPM guidelines.
- As set out in the ITT, RRMC was considering two potential options against which the bidders were invited to provide alternative prices. One option was the BMWRRMC hybrid implementation scenario, whereby the software application design to be carried out as part of Delivery Package 2 ("DP2") (Initial Back-End and Rule Engine) would deliver the integration of RRMC requirements into the existing BMW unified configurator platform ("UCP"), connection of its data sources to the UCP and integration of the RRMC rule interpreter into the UCP. Under the hybrid scenario, the service provider would be responsible for the delivery of DP2 but the technical implementation work for DP2 would be provided by third parties. The alternative option, which was ultimately selected, was the RRMC standalone scenario, a new online configurator using RRMC back-end systems. Under the standalone scenario, the service provider would be responsible for both the delivery of DP2 and implementation of the DP2 scope.
- There are two principal approaches to software development projects, known as 'agile' and 'waterfall'. The agile approach involves incremental development taking place through an iterative process of software development by the supplier and feedback from the customer in ongoing cycles. The process requires a high level of collaboration and interaction between the supplier and customer. This can be contrasted with the traditional, sequential or waterfall approach to software development, in which each stage of specification, software development, configuration or testing is completed before the next stage starts.
- In respect of the delivery approach, bidders were informed in the ITT that:
- The appendix, 'ITPM Agile Project Phase Approach', identified mandatory artefacts to be produced as part of the project, including IT risk management, data protection and test plans. It also included the following:
- The ITT also contained a document described as the 'High level Project Roadmap/Anticipated Timeline' ("the Implementation Plan"). The Implementation Plan set out the framework for the detailed planning required to be carried out as part of Delivery Package 1 ("DP1"). The plan identified the periods within which Delivery Packages needed to be delivered, which for the DPs ultimately ordered by RRMC were as follows:
- Section 6.3 of the ITT stated:
- Section 10.4 of the ITT provided that invoicing and payments would be linked to progress of the project:
- On 22 May 2019 Topalsson gave a pitch presentation to the RRMC team, supported by a PowerPoint presentation, the slide deck for which was provided by Topalsson as part of its tender response.
- On 3 June 2019 Topalsson submitted its tender response to RRMC. At paragraph 1.1.1, it stated:
- In the DP1 Delivery Package Summary at 1.1 of the response, Topalsson stated:
- The programme proposed for delivery of the DPs by Topalsson was as follows:
- Section 7 of the tender addressed the approach to quality management:
- The price tendered for the hybrid scenario was 15,016,019 (including options of 1,561,408) and for the stand-alone scenario was 12,685,082 (including options of 1,243,057). Following further negotiations, those tender prices were reduced and on 2 July 2019 Topalsson submitted its best and final offer ("BAFO") in the sum of 9,050,000.
- In the technical assessment carried out by RRMC, Topalsson's bid was the lowest in price of the three technically acceptable bids (the remaining three bids not being technically compliant) and was selected as the winning bidder.
- By email dated 18 July 2019 Laura Clowsley, purchasing manager at BMW, notified Topalsson that it had been awarded the contract for the RRMC car configurator landscape.
- On 19 July 2019 RRMC issued a purchase order No. 4700058414 in the sum of 7,740 (referable to a WLTP Emission Service Connection) to enable Topalsson to start work.
- A further purchase order No. F3GMHIX dated 31 July 2019 was raised in the sum of 2,009,897 in respect of the RRMC car configurator landscape, although it was not sent to Topalsson until 6 September 2019.
- At the end of July 2019 a draft contract was sent by RRMC to Topalsson and the parties entered into discussions regarding the terms and conditions of the same.
- The Agreement was signed by the parties on 11 October 2019, incorporating the following sections:
- The Agreement incorporated the ITT document:
- Clause 2.1 of Section 7 stated:
- Section 1 (the Key Terms) provided that the commencement date was 11 October 2019 and the expiry date was 31 December 2024, subject to the right of either party to terminate for convenience on six months' notice.
- Clause 5.2 of Section 7 stated:
- Clause 1 of Section 2 defined the services as comprising:
- Clause 5 of Section 2 defined Supplier Software:
- Clause 6 of Section 2 defined Bespoke Software:
- Bespoke TWIN RRMC Plugin/extension to read RRMC data
- Bespoke DTE RRMC POS Plugin/extension for specific RRMC POS use
- Bespoke SOLOGIC RRMC Plugin/extension to read RRMC data.
- Clause 3 of Section 2 stated that the Specification and Deliverables were as set out in the ITT, chapter 6 and the appendices.
- Deliverables were defined in Section 6 of the Agreement as:
- Services were defined in Section 6 of the Agreement as:
- Clause 23 contained provisions regarding intellectual property rights:
- Clause 5.1 of Section 7 stated:
- The Charges were defined in Section 6 as:
- Section 5 specified the following charges for each Delivery Package (in addition to 2 million in respect of the optional packages):
- Clause 14.1 of Section 7 stated:
- Clause 14.3 of Section 7 stated:
- Section 1 (Key Terms) provided that payment terms were within 30 days of the date of receipt of a correct and verifiable invoice.
- Clause 14.6 of Section 7 stated:
- Clause 14.8 of Section 7 stated:
- Clause 14.9 of Section 7 stated:
- Clause 5.3 of Section 7 stated:
- Good Industry Practice was defined in Section 6 as:
- Clause 5.4 of Section 7 stated:
- Clause 5.6 of Section 7 stated:
- Clause 5.8 of Section 7 stated:
- Clause 7.2 of Section 7 contained warranties on the part of Topalsson, including that:
- Time for delivery obligations were contained in clause 13:
- Clause 9.5 provided for performance reporting during the project:
- Clause 13.10 of Section 7 stated:
- Clause 13.11 of Section 7 contained provisions for termination by RRMC in the event of Topalsson's default:
- Clause 25 of Section 7 provided that either party could terminate the Agreement at its convenience (in whole or part) by exercising their Termination at Convenience Rights set out in the Key Terms, namely, six months' prior written notice.
- Clause 26.1 of Section 7 stated:
- Clause 26.4 of Section 7 stated:
- Clause 26.6 of Section 7 stated:
- Clause 20 of Section 7 stated:
- Clause 40.4 of Section 7 stated:
- An initial 'kick-off meeting' was held at Goodwood on 6 and 7 August 2019, attended by representatives of RRMC, Topalsson and the Retail Performance Company ("RPC"). RPC is a German consultant company which was set up as a joint venture between BMW Intech, a subsidiary company of BMW AG, and a third-party company. It is not part of the BMW Group. Initially, RPC was a potential supplier for the project but, after responding to the RFI, it approached RRMC and asked whether there was another supplier with whom it might collaborate to submit a joint bid. RRMC put RPC in contact with Topalsson, they collaborated on the bid and RPC were appointed by Topalsson as its sub-contractor to manage the project.
- A further workshop was held on 27 and 28 August 2019, at which responsibilities were allocated as between the parties and target dates set for initial tasks.
- From September 2019 weekly project meetings, referred to as 'Jour Fixe meetings' were held.
- Delivery Package 1 (DP1) included the preparation of an overall project plan, design concept and business requirements based on the information contained in the Agreement, including the ITT. It was described in section 6.5 of the ITT as follows:
- The timescale for delivery of DP1 as set out in the ITT and Topalsson's tender was 30 September 2019. There was no refined Implementation Plan agreed by that date but Topalsson prepared a first draft project plan which was produced at a planning meeting held on 7 October 2019.
- The draft plan showed the milestone dates from the Implementation Plan contained in the ITT and indicated that the final Roadmap / Project Plan would be produced by 31 October 2019. However, the estimated dates for the DPs in the draft plan departed from the ITT milestones and showed planned sprints leading to completion of the DPs significantly later in 2020.
- The draft plan was not acceptable to RRMC. Ida Biot, RRMC's Project Lead and Head of Process Management at BMW AG, RRMC's parent company, was concerned that Topalsson should start from the agreed milestones and work backwards, setting out completion dates for each delivery package.
- Topalsson raised its first invoice in October 2019 for 757,028, which invoice RRMC paid in full.
- One of the issues that was discussed on a regular basis throughout the project was whether delivery should be in accordance with the waterfall approach (as contended by RRMC) or the agile approach (as contended by Topalsson).
- The minutes of the meeting on 7 October 2019 recorded Ms Biot's position that waterfall gateways were necessary to evaluate progress and for audit purposes:
- Kubilay Topal, founder and CEO of Topalsson, was of the view that an agile approach would be more productive. By email dated 25 November 2019 Mr Topal expressed his views to Ms Biot:
- The implementation has been planned as desired on Waterfall with the associated ITPM structures.
- The requirements need a "released status" in order to plan a valid statement about their implementation.
- In the Agile implementation approach, however, this would not be necessary; user stories and the tasks derived from them would be sufficient here to start programming.
- We see it as realistic to better meet the tight desired schedule if we were allowed to work agilely here. I share your concerns about a basic waterfall approach. (including those expressed by Jan today).
- Following further discussions, on 27 November 2019 Topalsson produced a revised draft plan, which was presented to RRMC at a planning meeting on 28 November 2019, attended by Jόrgen Brzank (Chief Finance Officer of RRMC), Ms Biot, Jan-Hendrik Hoffmann (Manager in the Process Management Integration Team at RRMC), Mr Topal, Hans Mokrush (freelance Chief Finance Officer at Topalsson), Florian Reichl and Jens Wiedow (software developers at Topalsson).
- At that meeting, Topalsson's position was that the original plan set out in the tender could no longer be met, as a result of delays to the commencement of the project. It was necessary to divide the content between different releases and postpone the delivery dates for the full IVT and Content Management System (used to manage the visibility of the data contained within IVT) ("CMS") so as to enable a minimum viable product to be delivered for RRMC's critical business events.
- The revised plan showed the following Go Live dates:
- It was agreed at the meeting that, subject to verification by the parties that the revised implementation plan was feasible, it would be put before the RRMC Steering Committee for approval on 11 December 2019. Mr Brzank circulated a memo dated 28 November 2019, recording the discussion at the meeting:
- On about 6 December 2019 Topalsson produced an MS Excel version of the plan ("the December Plan") and uploaded it to the Panama drive. The December Plan contained a detailed breakdown of the project programme and included the following further revised Go Live dates:
- Ms Biot's evidence is that the December Plan was presented to the RRMC Steering Committee at the meeting on 11 December 2019 and approved by the Committee.
- In her witness statement Ms Biot stated:
- The Business Proposal dated 18 December 2019 was prepared by RRMC with Topalsson input. Section 3 contained a description of the Delivery Packages, including the following:
- Section 10 of the Business Proposal incorporated the high-level programme forming the basis of the December Plan and the following summary:
- Pre-Release of Imagery Validation Tool Early Review & CMS (IVT/CMS) in February 2020
- Pre-Release Closed Room (Closed Room) in April 2020: Configurator ready for RR2x Closed Room Event on 13th April 2020
- Release PoS Configurator (POS) in May 2020: Configurator ready for all models with RR2x SOC on 4th May 2020
- Release Web Visualiser (Visualizer) in May 2020: Web Visualiser ready on 25th May 2020
- Release Final Imagery Validation Tool and Completion of the PoS Configurator & Web Visualiser (IVT Final & Completion POS/VIS) in July 2020
- Release Ordering & Pricing Integration (Ordering/Pricing) in November 2020."
- At the Jour Fixe meeting on 18 December 2019, it was recorded that the Business Proposal was available for review on Confluence. It received conditional approval by RRMC following a Gateway Review Meeting in January 2020, as confirmed by Mr Hoffmann in his email dated 22 January 2020:
- During this period Topalsson endeavoured to agree the basis on which payments would be made under the Agreement. On 5 December 2019 Hans Mokrusch of Topalsson sent a project and billing schedule to RRMC for discussion, stating:
- Ms Biot did not agree the proposed billing schedule on the ground that Mr Topal then said that he could not deliver in accordance with the project plan.
- On 20 December 2019 Ms Biot and Mr Hoffmann attended a meeting at Topalsson's office with Mr Topal and Mr Mokrusch to discuss delay to progress of the project. Mr Topal expressed his view that delay was caused by RPC's inadequate performance, a view with which RRMC disagreed. Mr Topal stated that the December Plan was no longer feasible but agreed to provide additional staff resources for the project from January 2020.
- Internally, Topalsson employees considered that the timetable for delivery of the project was too tight given their resources. Dr Reichl expressed reservations to Mr Wiedow as to whether the deadlines were achievable as set out in his message dated 13 January 2020:
- On 17 January 2020 Mr Topal held a further discussion with Ms Biot regarding the risks to the project and reasons for the ongoing delay. She responded:
- Mr Mokrusch was anxious to agree a billing timetable but on 22 January 2020 Ms Biot sent an email to Mr Mokrusch, stating:
- On 24 January 2020 Mr Topal raised with Ms Biot difficulties in delivering the project in accordance with the Implementation Plan and proposed revisions to the milestones:
- In response, Ms Biot stated:
- There was no response to this question. However, Mr Hoffmann recognised that delay was inevitable and expressed his opinion to Mr Wiedow that they needed to discuss postponing some of the functionality and find an alternative plan for delivery of the full solution.
- In January 2020 Johann Valentinitsch, an independent consultant, was engaged to review the project. He produced a report (Bestandsaufnahme) dated 24 January 2020, which concluded that the project was not progressing smoothly, although he identified the limitations of the review carried out:
- His findings included:
- "Realisation process or procedure model not explicitly defined and accepted by both sides ...
- No transparency for RRMC on the current development status in each sprint
- No agreed acceptance/presentations of functional product increments
- Requirements management not clearly regulated / defined (solution in progress)
- Sprint length of 3 weeks
- Content sprint planning is only done by Topalsson
- Sprint review takes place without customer (PO)
- No presentation and acceptance of the results on the configurator
- No participation from the PO (client side) in the Daily Scrum
- Organisational and administrative tasks are managed via an LOP list."
- He made a number of recommendations to recover the project but warned that there was a high risk that the project would not be completed by April/May 2020:
- "In my view, a realignment of the project organisation and the process model is indispensable for the completion of the overall project.
- Such a change initially leads to a slower development speed and thus also to a limited delivery performance.
- For the implementation and establishment under the current framework conditions, I estimate a time expenditure of at least 6 up to 8 weekly sprints.
- In addition to the time component for realignment, the effort required to determine the degree of completion of the overall project in advance should also not be underestimated.
- The risk of jeopardising the completion date in April/May 2020 is therefore extremely high.
- Therefore, I can only recommend and accompany a reorientation if significantly more time would be available for its completion.
- Unfortunately, I cannot offer another alternative to the previous approach and to my recommendation for action."
- Ms Biot arranged a meeting with Mr Topal on 30 January 2020. In advance of the meeting, in an email to Ms Biot, Mr Hoffmann set out the available options for the project:
- At the meeting with Mr Topal, Ms Biot showed him a copy of Mr Valentinitsch's report, although she did not give him a copy of the same. They discussed the options outlined by Mr Hoffmann and Mr Topal was requested to produce a revised plan for the project.
- On 14 February 2020 Topalsson put forward a revised programme that would prioritise key deliverables but defer others beyond the dates set out in the December Plan:
- "IVT Release at the beginning of March 2020
- Safeguard Closed Room Release at the beginning of April 2020 (Closed Room Event 15th April 2020)
- Safeguard CRIS (CoSY Replacement Image Service) Release at the beginning of May 2020 (SOC 4th May 2020) in case of a shift of the PoS Release
- Provide a China Fallback solution in case of a shift of the PoS Release at the latest by end of May due to the decommissioning of the RRMC Offline Configurator
- Show a planning scenario for a PoS solution at the beginning of July 2020."
- Mr Topal put forward three alternative scenarios for consideration:
- RRMC was unable to agree to the revised proposals set out in Topalsson's February proposal but arranged a meeting to consider potential acceptance of late deliveries.
- On 4 March 2020 a meeting took place between Mr Topal, Mr Biot, Mr Poser (Chief Financial Officer of RRMC) and Henrik Wilhelmsmeyer (Director of Sales and Brand at RRMC), at which the parties discussed revised dates for Technical Go-Live of three key components of the solution, namely IVT, Closed Room and CRIS.
- Following the meeting, by email dated 5 March 2020 Ms Biot confirmed to Mr Topal the revised delivery dates agreed (the March Plan):
- Mr Topal sent an email later that day, which he confirmed in cross-examination was not in reply to Ms Biot's earlier email, stating:
- Although Mr Topal did not confirm to Ms Biot the revised dates as set out in her email, those dates were reflected in Topalsson's February proposal, a presentation made by Ms Biot to the RRMC Board on 17 March 2020 and in Topalsson's summary on the Confluence space as at 3 April 2020.
- On 12 March 2020 the RRMC Board decided to maintain the planned start of production for the Ghost model in August 2020 but to cancel the World Dealer Conference event in Miami and postpone the Closed Room events to June/July 2020 as a result of the COVID pandemic, although it did not at that stage notify Topalsson of the same.
- On 17 March 2020 a meeting of the RRMC Board took place at which Ms Biot made a presentation on the state of the project, in which she explained that the project had not progressed as expected, milestones had not been delivered as planned and the new plan did not appear to be achievable; the test for first release IVT was amber and Go-Live was at risk due to technical issues. The Board approved steps to implement a fall-back solution and decided that if Topalsson failed to meet any of the deadlines contained within the March plan, RRMC would have authority to terminate the Agreement.
- By email dated 7 April 2020 Ms Biot notified Mr Topal that RRMC had lost confidence in Topalsson's ability to deliver the project:
- In a meeting on 8 April 2020, Topalsson was told to concentrate on CRIS and IVT, rather than Closed Room:
- On 8 April 2020 Mr Topal responded to Ms Biot, rejecting her criticism and the proposal:
- By letter dated 16 April 2020 (sent by email on 17 April 2020) RRMC served the First Termination Notice on Topalsson:
- By email dated 17 April 2020 Topalsson rejected the First Termination Notice as invalid and affirmed the Agreement:
- By letter dated 22 April 2022 RRMC served the Second Letter of Termination on Topalsson, without prejudice to its contention that the First Notice of Termination was valid and effective:
- By email dated 1 May 2020 Topalsson disputed that RRMC was entitled to terminate the Agreement and treated the Second Notice of Termination as repudiation of the Agreement. Topalsson's responses to the allegations of delay included the following:
- By letter dated 9 June 2020, CMS, then Topalsson's solicitors, confirmed its position:
- Topalsson ceased working on the project at the end of May 2020.
- Topalsson issued these proceedings on 15 September 2020.
- Topalsson's primary case is that it achieved Technical Go-Live for the Closed Room and IVT tools, and it would have achieved the same for CRIS had RRMC not terminated the Agreement unlawfully. Topalsson delivered in line with the operational dates agreed in the March Plan. However, by this stage, RRMC had already decided that it would use an alternative supplier and chose not to progress any outstanding integration issues. Topalsson fulfilled its side of the bargain. RRMC's termination of the Agreement was therefore unlawful.
- Topalsson's secondary case is that it was not in anticipatory and/or repudiatory breach of the Agreement. Time was not of the essence as there was no agreed programme; hence, Topalsson's obligation was simply to deliver within a reasonable time. RRMC introduced significant delay to an already tight timeline before Topalsson became involved in the project by its delay in getting to tender, hindered Topalsson in adopting its preferred agile approach to the development of the software (which Topalsson was contractually entitled to do), and failed to agree a billing schedule for the project. As a result, blame for delays to the project does not lie with Topalsson.
- RRMC's case is that under the Agreement Topalsson agreed to complete the services and deliver each of the software Delivery Packages at a fixed cost by the milestone or delivery dates identified in an agreed programme ("the Implementation Plan"). Topalsson was responsible for delays to the analysis and detailing of RRMC's business requirements specified in the ITT, with the result that the user stories which should have been generated were not available either for planning or for the development required by subsequent DPs. In late November 2019, Topalsson produced a plan spreading the DPs over software releases, including pre-releases of critical functionality, representing a reduction in scope, which RRMC accepted and which was approved by the project Steering Committee on 11 December 2019 (the December Plan).
- RRMC's position is that delays occurred against the December Plan and in February 2020, Topalsson proposed further reductions in the scope of software releases to be delivered in time for the launch of the new Ghost by April/May 2020, with later delivery dates for the remaining software releases and associated artefacts. At a meeting in March 2020 the parties agreed the March Plan, pursuant to which Topalsson would deliver IVT by 9 March 2020, Closed Room by 1 April 2020 and CRIS by 23 April 2020. RRMC's case is that Topalsson failed to deliver and/or achieve Technical Go-Live of those components by the agreed dates in the March Plan and RRMC lost confidence in Topalsson's ability to perform.
- The key issues can be summarised as follows:
- Topalsson relied on evidence from the following factual witnesses:
- RRMC relied on evidence from the following factual witnesses:
- Some of the witnesses gave their evidence by video-link from Austria. It had been intended that they should give their evidence from Germany but the defendant had failed to follow the guidance in Practice Direction 32 Annex 3, which includes a reminder that not all foreign governments are willing to allow those within their jurisdiction to be examined before a court in England by means of video conference and advises that checks on this should be addressed to the Foreign, Commonwealth and Development Office. It transpired that the necessary permission had not been obtained from the German Court.
- Fortunately, confirmation was obtained that it would be possible for the witnesses to travel to Austria and give evidence from that jurisdiction. Article 8 of the Austro-British Convention on Mutual Legal Assistance BGBI 1932/45 allows for evidence to be taken on Austrian territory without the intervention of state authorities, provided that a "Commissioner" in charge of the taking of evidence is appointed as a person authorised by the Court. The Court can "commission" the presiding Judge for this purpose, as explained by Joanna Smith J in Dana UK Axle Ltd v Freudenberg FST GmbH [2021] EWHC 1751 (TCC).
- Accordingly, by order dated 17 October 2022, I was commissioned to take evidence to be given in these proceedings from within the territory of the Republic of Austria and authorised such evidence to be given remotely by video link. In this case it did not cause any insuperable difficulties but parties are reminded of the necessity of considering these issues well in advance of the trial, at the latest by the time of the PTR.
- Topalsson's experts were:
- A failure on the part of the claimant to comply with the procedural timetable set by the court (caused by two changes of solicitors), resulted in orders made by Veronique Buehrlen KC, sitting as a deputy high court judge, dated 30 June 2022 and 29 July 2022 respectively, debarring Topalsson from adducing expert evidence on a number of IT expert issues and the counterclaim quantum. I acknowledge that this has hampered the experts, who bear no responsibility for any of the claimant's defaults, in the extent of evidence covered by their reports. I am grateful to them for their efforts to assist the court in difficult circumstances.
- RRMC's experts were:
- The experts have produced helpful joint statements:
- Clause 5.3.7 of Section 7 of the Agreement required Topalsson to complete the Services and deliver the Deliverables by any applicable milestone date or delivery date; or, if not specified, within a reasonable time as specified by RRMC. Clause 5.8 of Section 7 stipulated that time was of the essence in respect of any date for delivery specified in the Agreement.
- RRMC's case is that Topalsson was obliged to comply with the milestones or delivery dates set out in: (i) the Implementation Plan contained in the ITT appendix; (ii) the December Plan, pursuant to its obligation to deliver DP1; and/or (iii) the March Plan, as applicable or reasonable delivery dates notified by RRMC; further, that time was of the essence in respect of those plans under the Agreement.
- Topalsson's case is that there was no binding programme and its obligation was limited to performance within a reasonable time; (i) the Implementation Plan was not a contractually binding programme; (ii) the December Plan was not agreed; and (iii) the March Plan set out dates proposed by Topalsson as operationally viable and were adopted by RRMC but they were not contractually binding.
- The Implementation Plan was defined in Section 6 of the Agreement as: "the time schedule and sequence of events for the performance of this agreement set out in Section 2 and in accordance with BMW ITPM." Section 2 contained a reference to 'Implementation Plan' and stated: "Refer to Tender Document and appendices. This will be refined further in DP1."
- The only document that could be the Implementation Plan is the 'High level Project Roadmap/Anticipated Timeline' contained in an appendix to the ITT and referred to in section 10.4 of the ITT as "the milestone plan", set out below:
- The Implementation Plan contained activity bars for each mandatory Delivery Package with symbols indicating the end of each time period. In my judgment it did not contain contractual milestones or delivery dates for the following reasons.
- Firstly, the timeline was, as stated, "high level" and was not sufficiently defined to impose contractual deadlines. There were no specific dates (days or months) inserted on the roadmap. The end of any activity bar, although indicative, could not be linked to any specific date with any degree of certainty; the start or finish of an activity bar at the beginning or end of a relevant quarter, or part-way through a relevant quarter, did not indicate any particular date.
- Secondly, the Implementation Plan in the ITT appendix was described as an "Anticipated Timeline" and not a fixed programme. In its tender response, Topalsson proposed dates for DP1, DP3 and DP10 that aligned with the Implementation Plan but stated that DP1 (which included the development of a refined Implementation Plan) would affect all subsequent packages and all other DPs would be confirmed in DP1. There is nothing indicating that the parties agreed Topalsson's proposed dates, or imposed any other dates, as fixed milestones. It would have been open to the parties to insert into Section 1 of the Agreement as key terms any fixed milestones but no key dates were specified.
- Thirdly, clause 8 of section 2 of the Agreement and the description of DP1 expressly required the Implementation Plan to be refined. One of the main purposes of DP1 was to define in detail the scope of each Delivery Package. In those circumstances, it must have been contemplated by the parties that the delivery dates and sequencing might require adjustment. Although it is likely that it was anticipated that the refined programme would be in general alignment with the Implementation Plan, the Agreement did not stipulate that the delivery dates must fall within the parameters of the indicative bar lines in the same. On the contrary, section 10.4 of the ITT explicitly stated that the milestone plan might be amended based on the initial analysis phase (Delivery Package 1).
- Finally, the software delivery and installation dates were defined in section 6 of the Agreement as estimated, rather than fixed, dates in the Implementation Plan. This was a strong indication that those dates were not considered by the parties to be fixed and binding.
- In summary, the Implementation Plan set out a high level, indicative framework for the detailed planning required to be carried out as part of DP1 but did not impose on Topalsson a contractual obligation to deliver the DPs within the timeline shown in the ITT document.
- RRMC's case is that the December Plan was an agreed project plan as part of the completion of DP1. The December Plan was prepared by Topalsson, approved by the RRMC Steering Committee, incorporated into the Business Proposal and thereafter used by both parties as the agreed implementation plan.
- Topalsson's case is that the December Plan was not agreed and did not constitute a contractually binding implementation plan pursuant to DP1. It was simply a working planning document with no formal contractual status.
- I am satisfied that there is ample evidence demonstrating that the December Plan constituted the refined implementation plan for the purpose of DP1 for the following reasons.
- Firstly, the December Plan was the first and only detailed implementation plan setting out the dates for commencement and completion of all relevant activities through delivery of releases, in sequence and with clear milestones for each Delivery Package.
- Secondly, the December Plan was produced by Topalsson and submitted to RRMC as the "Roadmap", i.e. the revised implementation plan for the purpose of DP1. The proposed plan was presented to RRMC at the meeting on 28 November 2019, which had been convened specifically for that purpose, as explained by Mr Brzank in his evidence. RRMC required Topalsson to check its feasibility with stakeholders but, subject to such checking, agreed to submit it for approval in the Steering Committee on 11 December 2019. In cross-examination, Mr Mokrusch agreed that the milestones set out in the Roadmap were agreed at the 28 November meeting. Subsequently, the MS Excel version of the revised plan dated 6 December 2019 was submitted by Topalsson as its project plan.
- Thirdly, Ms Biot's evidence is that the December Plan was accepted and approved by the Steering Committee. Although, as noted by Topalsson, there are no minutes of the Steering Committee meeting on 11 December 2019, the slides prepared for the meeting stated that the Project Plan and milestones were detailed and aligned for DP1 and incorporated the Roadmap and release scopes proposed by Topalsson. Ms Biot's evidence is supported by Mr Brzank, who recalls that Ms Biot presented the December Plan to the Steering Group as the acceptable and only option that would enable the new configurator to be available for the Ghost model events. Her understanding that it was an agreed plan is consistent with RRMC internal communications, such as Ms Biot's email to Dr Poser dated 2 February 2020.
- Fourthly, the December Plan was incorporated into the Business Proposal which was produced as part of DP1 and approved in January 2020 as set out above.
- Fifthly, the parties used the December Plan as the agreed timeline against which subsequent discussions regarding progress and delay took place. Although there were disagreements as to the causes of delay and necessary steps to recover or revise the programme, there was no suggestion by either party that the December Plan was not agreed. Topalsson produced its status reports against the December Plan, its re-planning proposals in February 2020 were against the "Roadmap" forming the basis of the December Plan, and internal Topalsson discussions on Slack referred to the Roadmap in the Business Proposal as the agreed plan.
- It is said by Topalsson that, even if the December Plan constituted an agreed plan, time was not of the essence under the Agreement.
- Clause 5.3.7 of Section 7 of the Agreement provides that Topalsson is obliged to:
- The key provision making time of the essence is clause 5.8 of Section 7 of the Agreement:
- Topalsson's case is that the words "specified in this agreement" refer back to the words "any date for delivery" and RRMC has not established that any of the dates relied on were specified in the Agreement. In particular, it is said that this provision could not relate to dates or programmes agreed subsequent to the date of the Agreement.
- The principles applicable to contractual interpretation are well established. When interpreting a written contract, the court is concerned to ascertain the intention of the parties by reference to what a reasonable person, having all the background knowledge which would have been available to the parties, would have understood them to be using the language in the contract. It does so by focussing on the meaning of the relevant words in their documentary, factual and commercial context. That meaning has to be assessed in the light of (i) the natural and ordinary meaning of the clause, (ii) any other relevant provisions of the contract, (iii) the overall purpose of the clause and the contract, (iv) the facts and circumstances known or assumed by the parties at the time that the document was executed, and (v) commercial common sense, but (vi) disregarding subjective evidence of any party's intentions: Arnold v Britton [2015] UKSC 36 per Lord Neuberger at [15]-[23]; Wood v Capita Insurance Services Ltd [2017] AC 1173 at [11]-[15]; Rainy Sky SA v Kookmin Bank [2011] UKSC 50 per Lord Clarke at [21]-[30]; Chartbrook Ltd v Persimmon Homes Ltd [2009] UKHL 38 per Lord Hoffmann at [14]-[15], [20]-[25].
- The starting point is the meaning of the express words used in clause 5.8. The words "specified in this agreement" immediately follow the words "good or service" rather than "any date for delivery". Therefore, the natural and ordinary meaning is that the words "specified in this agreement" are descriptive of the "good or service" and not the "date for delivery". Read in this way, the date for delivery must be any applicable milestone date or delivery date referred to in clause 5.3.7 of Section 7.
- Topalsson's interpretation assumes that delivery dates could not amount to specified dates in the Agreement unless they were fixed at the date of the Agreement. However, that ignores the other provisions which made it clear that the delivery dates were to be fixed as part of the first phase of work under the Agreement.
- The parties' common understanding was that the nature of the project required development work to be carried out to finalise the scope, timing and sequencing of the releases within the Delivery Packages. As set out above, clauses 1 and 8 of Section 2 of the Agreement provided that the dates for delivery of the Services were set out in the high-level Implementation Plan but to be further specified in DP1.
- An objective meaning of those provisions is that the specified dates for delivery were to be agreed as part of DP1. Once the December Plan was agreed under DP1, the milestone dates it contained became the specified dates under the Agreement.
- The material provisions must be construed against the relevant factual matrix. It was clear from the outset of the project that the new configurator was required to be functional for the launch of the new Ghost model. Key dates were the Closed Room preview events from 13 April 2020, the World Dealer Conference on 15 April 2020, Start of Communications for the new Ghost model from 4 May 2020 and Start of Ordering for the Ghost from 15 June 2020.
- Those commercially sensitive dates were identified in the Implementation Plan contained in the ITT appendix and in all subsequent versions of the Roadmap and other plans produced by Topalsson. Against that background, the parties' common understanding was that strict compliance was required with the agreed milestone dates.
- In summary, the December Plan was agreed between the parties as the refined Implementation Plan under DP1. As such, it imposed on Topalsson a contractual obligation to deliver the DPs in accordance with that plan and time was of the essence in respect of the milestone dates for each Delivery Package in the December Plan.
- RRMC's case is that at the meeting on 4 March 2020 the parties agreed that, pending a revised plan to be proposed to recover delays, a reduced scope of key functionality would be delivered by the following dates:
- RRMC's position is that the dates in the March Plan were contractually specified dates and that time was of the essence in respect of the same.
- Topalsson's case is that the March dates were agreed but they were not contractually binding dates. They were not specified in the Agreement; nor were they the subject of any variation; nor did they appear in any agreed Implementation Plan. Rather, they were proposed by Topalsson as operationally viable and adopted by RRMC.
- The context in which the meeting on 4 March 2020 took place is significant. Mr Topal had informed Ms Biot that Topalsson could not meet the timetable in the December Plan. The revised proposals that Topalsson put forward in February 2020 signalled a dramatic slippage to the project, including the deferral of substantial functionality, a partial release of the POS configurator from September 2020 and overall delayed delivery of the project to 2021. However, it is clear that Topalsson recognised the importance to RRMC of delivering sufficient functionality that would enable the new configurator to be used for the Ghost launch in April/May 2020. A general departure from the December Plan was not acceptable to RRMC but, against the delay that had already occurred, it acknowledged the value in agreeing a limited scope of delivery that would meet the needs of the Ghost launch.
- The key dates identified by Topalsson in the February proposal were:
- These dates were agreed by RRMC at the meeting on 4 March 2020, confirmed as specific dates in Ms Biot's email of 5 March 2020 and promised by Mr Topal in his email of 5 March 2020.
- Contrary to Topalsson's contention, the March Plan was not simply a non-binding, operational plan. Although the causes of delay are in dispute, it is common ground that Topalsson had failed to meet the milestone dates in the agreed December Plan there had been no application for, or grant of, an amendment to the December Plan under clause 13.7 of the Agreement. The more limited scope and later dates for delivery constituted a relaxation and/or extension of time under the December Plan. It was explicitly stated by Ms Biot in her email of 5 March 2020 that:
- In summary, the March Plan was contractually binding on Topalsson and it made time of the essence in respect of the revised dates agreed.
- Topalsson's case is that it achieved Technical Go Live in respect of IVT and Closed Room and would have achieved Technical Go Live in respect of CRIS but for RRMC's termination.
- RRMC's case is that Topalsson did not achieve Technical Go Live in respect of IVT, Closed Room or CRIS and failed to meet the milestones agreed in the March Plan.
- It is common ground that the March Plan (which, I have found above, imposed contractually binding obligations on Topalsson) required Technical Go Live to be achieved: (i) in respect of IVT by 9 March 2020; (ii) in respect of Closed Room by 1 April 2020; and (iii) in respect of CRIS by 23 April 2020. However, Technical Go Live was not a defined term in the Agreement and the parties are in dispute as to what was required to achieve it.
- Topalsson's case is that in the absence of any contractual definition or evidence of common understanding between the parties as to what the term meant, what amounts to Technical Go-Live is an expert issue. Mr Britton's view is that Technical Go-Live is typically used to mean the point at which a software application has been installed on the production hardware and left in an operational state, available for restricted use. It does not require all testing to have been completed and it is not precluded by the existence of open defects. Mr Britton's view is that in the case of each of the deliverables, it can be seen that most of the functionality was working and could be used.
- RRMC's case is that as a matter of contractual interpretation under the March Plan Topalsson was required to achieve Technical Go Live which included successful completion of systems integration testing ("SIT") and user acceptance testing ("UAT"). To the extent that this raises an issue of expert evidence, Dr Hunt's view is that in order to achieve Technical Go-Live the system needed to complete SIT and UAT successfully with no blockers or high defects and be deployed onto the intended infrastructure ready for use by the business. The test strategy required successful execution of the user acceptance tests, approval from management to stop UAT, business requirements fulfilled, no critical defects left out and sign off in respect of acceptance testing.
- The starting point is analysis of the contractual documents to consider whether, in the absence of an express definition, the proper meaning of Technical Go-Live can be ascertained.
- Clause 7 of section 2 of the Agreement expressly stated that section 8.1 of the ITT contained applicable provisions for acceptance and pre-installation testing. Section 8.1 provided:
- The ITT appendix identified as applicable the document 'Phase Result in Agile Project', which provided that the BMW Group Test Handbook applied to agile and waterfall projects, although in agile projects the various test levels would apply to each sprint.
- The BMW Group Test Handbook, another ITT appendix document, identified different models of testing, some of which incorporated testing as each part of the system was completed. However, each model included SIT and UAT before Go-Live was achieved.
- The Test Plan produced for the project set out the test strategy, namely, to verify that the functionality of the system met all specified criteria, and contained the following provisions:
- The draft implementation plan produced by Topalsson in November 2019 contained a 'Roadmap' gantt chart that showed sequential bars for Development, Testing and Go-Live in respect of each software release.
- Technical Go-Live was identified as a specific milestone against each software release in the December Plan. The December Plan was a detailed MS Excel spreadsheet that showed a breakdown of each Delivery Package into detailed components. It included, in respect of each software release, the start and end dates for each sprint, followed by the start and end dates of SIT, followed by the start and end dates of UAT. Technical Go-Live was identified as a separate bar starting on the last day of UAT, followed by Business Go-Live, followed by Go-Live Check for each release.
- The status reports prepared by Topalsson showed progress and planning using the start and finish dates, and the sequencing of activities as set out in the December Plan, including the start and finish of SIT and UAT prior to Technical Go-Live.
- The February 2020 proposal by Topalsson for deferred delivery contained a Roadmap gantt chart that showed sequential bars for Development, Testing and Go-Live in respect of each revised software release scope, including a reference to SIT/UAT against the key for Testing.
- Consideration of the above documents leads me to draw the following conclusions on this issue:
- Those conclusions are supported by the evidence of Mr Wiedow in cross-examination, who accepted that SIT and UAT were formal gateways that had to be passed before Technical Go-Live could be achieved.
- As to the level of testing that was required, the experts reached a degree of agreement in their Joint Statement:
- Mr Britton's view is that the existence of open defects would not necessarily preclude the achievement of Technical Go-Live. Dr Hunt's view is that no critical or high level defects could persist. They are both correct. The Test Plan agreed by the parties identified the criteria against which defects or bugs in the software would prevent any release from passing.
- The severity of defects identified during testing was classified in the Test Plan as follows:
- The default SIT exit criteria were agreed by the parties and set out in the Test Plan as follows:
- Likewise, the UAT exit criteria were agreed as set out in the Test Plan:
- Against that contractual and factual background, the reference to Technical Go-Live in the meeting on 4 March 2020 and the agreed March Plan must be interpreted as a requirement for the relevant release to be delivered and installed, having completed successfully SIT and UAT in accordance with the agreed Test Plan and running on a production environment that has technically gone live.
- Imagery Validation Tool (IVT) comprises a web-based user interface that allows a user to select models and features of cars and view the resulting 3D images. It is a standalone tool, allowing RRMC to review and validate the rendered 3D models of the vehicles and their mapping to configurator options, and was intended to replace RRMC's existing review configurator.
- IVT was described in the ITT as follows:
- Further details were set out in the Detailed Business Requirements:
- The December Plan showed IVT delivered in stages:
- The March Plan contained a date for Technical Go-Live in respect of IVT of 9 March 2020. The version of IVT that was scheduled for Technical Go-Live in the March Plan was the pre-release version forming part of Release 3a, rather than the final version containing full functionality. It included business integration but data generation for the new POS configurator and a user interface to allow RRMC to manage configuration data within the CMS module of Topalsson's software were deferred to a later release.
- It is common ground that Topalsson did not achieve Technical Go-Live in respect of pre-release IVT by 9 March 2020. Topalsson's case is that it was achieved on 20 March 2020, as confirmed by Mr Wiedow's email dated 20 March 2020 and the RRMC status report dated 24 March 2020.
- SIT was completed by 26 February 2020 and UAT was completed by 9 March 2020, although there remained a number of outstanding tasks to enable technical deployment of the software, as set out in Mr Wiedow's email to Mr Hoffmann dated 9 March 2020.
- Topalsson's case is that the delay between 9 March 2020 and 20 March 2020 was caused by a failure on the part of RRMC to grant access rights to BMW's proxy servers, so as to enable Topalsson to install and integrate the IVT software in the cloud server. RRMC's case is that Topalsson failed to request the reverse proxy and web set-up in time and therefore caused the delay.
- Mr Hoffmann explained in his evidence that it had originally been intended that IVT would be deployed on BMW's Amazon Web Service ("AWS") Cloud, but because IVT only needed to be used by a small group of users at RRMC, and it needed to hold strictly confidential data, the costs of appropriately secure Cloud storage would have been very high. It was therefore agreed in DP1 that IVT would instead be deployed on a physical server at Topalsson's premises. However, in order for RRMC to be able to access the IVT servers on Topalsson's network, appropriate connection mechanisms needed to be put into place, for which Topalsson needed to set up a reverse proxy, an application which handles communications between systems. In order to set up a reverse proxy, Topalsson needed to order it and liaise with BMW's Web Ops team to install it.
- Topalsson did not order the reverse proxy until 24 February 2020, as evidenced by Mr Reichl's email of that date, and Mr Wiedow accepted in his witness statement that Topalsson made mistakes in its initial requests. Mr Hoffmann explained in cross-examination that it then took some time to set up the reverse proxy:
- Mr Reichl and Mr Wiedow of Topalsson sent emails on 10 March 2020, requesting access and noting that the reverse proxy and subsequent configuration were the only tasks outstanding that were blocking Technical Go-Live for IVT. As recorded in the minutes of the Management Status Meeting held on 10 March 2020, it is clear that by this stage the reverse proxy issue had become urgent. However, that does not explain the failure on the part of Topalsson to start this process earlier so as to ensure the relevant application was in place when needed. It was unreasonable for Topalsson to assume that an immediate solution could be provided by RRMC at the eleventh hour. In those circumstances, Topalsson was responsible for any delay caused by the reverse proxy issue.
- The technical experts agreed in their Joint Statement that IVT completed SIT and UAT. Notwithstanding that agreement, there is a dispute as to whether Technical Go-Live was achieved. RRMC relies on a number of persisting defects in the IVT as installed, namely: (i) the absence of more than one model; (ii) crashing when swapping between models; (iii) the failure to support use by multiple users; and (iv) the absence of TISAX security certification.
- The technical experts agreed that IVT was deployed with only one model, for the Ghost, and did not support more than one user at a time. Further, they agreed that where a user started to configure a model and switched to another model, the DTE became unresponsive. I do not consider that these issues were a barrier to Technical Go-Live in respect of IVT. It is clear that they amounted to outstanding defects and/or limitations on the use of IVT but, as set out above, it was not intended to be the final release; it was limited to the early review IVT. Of significance, the defects did not prevent SIT exit, RRMC conducted UAT and was satisfied that it had been completed.
- Likewise, although Topalsson was obliged to obtain TISAX security certification, as set out in section 7.8 of the ITT and confirmed in the Business Proposal, this was not identified as a pre-condition for early review IVT, as opposed to a separate contractual obligation. On that basis, I do not accept RRMC's argument that the absence of TISAX certification precluded the achievement of Technical Go-Live for IVT.
- The contemporaneous documents are clear on this issue. Mr Wiedow's email dated 20 March 2020 and the RRMC status report as at 24 March 2020 both confirm that Technical Go-Live was achieved in respect of IVT on 20 March 2020.
- I find that Topalsson was under a contractual obligation to achieve Technical Go-Live in respect of early review IVT by 9 March 2020. Technical Go-Live in respect of IVT was not achieved until 20 March 2020, in breach of the March Plan. RRMC was not responsible for such delay.
- The Closed Room configurator was a pre-release version of the Point-of-Sale ("POS") configurator, a software tool that would allow potential customers to configure cars in showrooms. Closed Room was intended to allow RRMC dealers to demonstrate the Rolls-Royce Ghost car to invited audiences.
- The December Plan showed the POS configurator delivered in stages:
- Mr Wiedow described Closed Room as follows:
- The March Plan contained a date for Technical Go-Live in respect of Closed Room of 1 April 2020.
- Topalsson's case is that it achieved Technical Go-Live in respect of pre-release Closed Room by 1 April 2020 and this was unaffected by RRMC's arbitrary decision not to proceed with UAT. RRMC's case is that it was not achieved because SIT and UAT were incomplete and the software was not properly functional.
- Mr Scott of RRMC explained in his witness statement the difficulties he encountered in installing Closed Room:
- Mr Britton's view is that Topalsson delivered a working installer for the Closed Room configurator on or before 1 April 2020. RRMC either did or could have installed a version of the Closed-Room Configurator on to a machine similar to those that would be use for the Closed Room event by 1 April 2020. His evidence was that the maturity of the configurator was sufficient to achieve Technical Go-Live and the outstanding issues were mainly associated with the model and other data deliverables.
- Dr Hunt's view is that the Closed Room version delivered on 1 April 2020 had not been adequately tested; in particular it had not been properly tested with the intended hardware. There were numerous problems with both the software and the CMS content that meant this version was not ready for UAT. Subsequent versions provided on 17 and 21 April 2020 were significantly improved in terms of performance, completeness of the CMS content and the reliability of the user interface. However, they contained significant issues and would have failed UAT if that had been performed.
- The contemporaneous documents show clearly that Closed Room did not complete SIT or UAT by the beginning of April 2020.
- At the Jour Fixe meeting held on 25 March 2020 it was recorded that Closed Room progress was as follows:
- In a Slack message on 3 April 2020 Mr Wiedow informed Mr Topal that SIT Exit/UAT Entry was still pending in respect of Closed Room:
- The minutes of the Management Status Meeting held on 7 April 2020 recorded:
- That was reflected in the status report for 7 April 2020 which showed that SIT and UAT had not been achieved and the dates for Technical Go-Live and Business Go-Live had been missed without any revised target date.
- There were significant defects in the Closed Room version delivered on 1 April 2020. By email dated 1 April 2020 Mr Scott identified a number of defects which he confirmed in cross-examination:
- Dr Hunt installed the Closed Room version provided by Topalsson on 1 April 2020 on a laptop meeting the criteria specification provided by Topalsson for the purpose of reviewing it. The defects identified were set out in Appendix C to her first report and summarised as follows:
- A number of the defects were apparent from the videos/slides prepared by the technical experts and produced in court.
- In cross-examination, Mr Britton did not accept the extent of the defects identified by Dr Hunt but agreed that some of them, including unreliable operation of hotspots, would need to be fixed in UAT prior to Go-Live:
- The incomplete and unsatisfactory state of Closed Room was recognised internally by Topalsson. In a slack message dated 16 April 2020 Mr Weiss suggested that a product review for Closed Room was required to discuss what needed to be done to get it into a releasable state and within Confluence on 5 May 2020 Topalsson employees set out their assessment of the current status of product completion, including Closed Room:
- The incomplete state of Closed Room was recognised by Topalsson in communication with RRMC. On 23 April 2020 Topalsson's Schedule of Deliverables included against DP3 Closed Room Pre-Release: SIT 95% achieved; Go-Live 80% achieved.
- I find that Topalsson was under a contractual obligation to achieve Technical Go-Live in respect of Closed Room by 1 April 2020. Topalsson failed to achieve satisfactory completion of SIT or UAT in respect of Closed Room and there were critical defects in the software release as at the beginning of April 2020. Indeed, on Topalsson's own assessment at 23 April 2020, Technical Go-Live had not been achieved. As a result, Technical Go-Live in respect of Closed Room was not achieved by 1 April 2020 or thereafter.
- CRIS was a software component for rendering photorealistic images when demanded by other RRMC IT systems. It consisted of Topalsson's Digital Twin Engine (DTE) with interface software and customisation for integration with various RRMC systems that required 2D image rendering services that previously relied on RRMC's existing image service API, CoSy.
- The replacement of CoSy formed part of the POS configurator as set out in Topalsson's November 2019 proposed plan. The December Plan showed that the full POS configurator would be delivered through Release 3a by 25 May 2020.
- The March Plan contained a date for Technical Go-Live in respect of CRIS of 23 April 2020.
- The Joint Statement produced by the technical experts states:
- Mr Britton's view is that CRIS could have achieved Technical Go-Live by 23 April 2020 as it was reasonably functional and was installed on the BMW AWS infrastructure. Screenshots of CRIS being used show that it was operational and available on BMW's AWS servers, albeit these appear to be intended for testing rather than production. Although Mr Britton accepts that the software was not deployed on production hardware, his view is that it could easily have been so deployed by repurposing the existing testing environment or by creating a new one and deploying to it. Technical Go-Live could then have been achieved within a matter of moments by reconfiguring the reverse proxies and repurposing the AWS instance on which it was running.
- Dr Hunt's view is that CRIS did not achieve Technical Go-live because it had yet to undergo SIT and had not in fact been deployed on a production instance prior to termination. By 22 April 2020 CRIS was undergoing internal testing and bug-fixing at Topalsson but had not entered SIT. In order to proceed into SIT Topalsson needed to resolve the remaining defects identified in their internal testing, deploy a revised version to BMW's AWS and coordinate integration testing with RRMC's existing supplier of the ordering configurator, Sulzer. On the reported progress of these tasks, her view is that it was not possible for CRIS to achieve Technical Go-Live by 23 April 2020.
- Simon Kottenhagen accepted in cross-examination that CRIS was not working at the beginning of April 2020.
- At the Management Status Meeting on 7 April 2020 Topalsson reported that it would be unable to conclude all tasks by the due dates for CRIS. The status report of 7 April 2020 stated that CRIS was in delay. Sprints 9, 10 and 11 were still open and Sprint 12, to deal with functionality spill over from these sprints, was in progress. It had not yet entered SIT and Topalsson proposed revised dates for (a) SIT entry on 19 April 2020; (b) UAT entry on 24 April 2020 and (c) Technical Go-Live on 27 April 2020. Thus Topalsson's projected timeline was later than the agreed date in the March Plan of 23 April 2020.
- At the Jour Fixe meeting on 8 April 2020, Ms Biot suggested that work should stop on Closed Room and all efforts should be concentrated on CRIS and open DP10 issues.
- At the Management Status Meeting on 14 April 2020 it was recorded that Sprint 12 had not been completed, test planning and preparation did not take place and had not been aligned, and therefore test entry was not yet possible.
- At the Jour Fixe meeting on 15 April 2020 Mr Kottenhagen explained that testing had not started because the software for CRIS has not been deployed to the test system, as the architecture still had to be prepared. The SIT entry criteria required test cases for all user stories but the user stories and test cases remained outstanding.
- During a Slack chat on 20 April 2020 Mr Kottenhagen noted that they had missed the window for SIT in respect of CRIS because of an incorrect request for access.
- The status report dated 21 April 2020 reported that Confluence pages for ITPM documentation were nearing completion, SIT test cases were specified and they were undergoing review.
- On 21 April 2020 Mr Topal sent an urgent internal email identifying missing features for CRIS and stating:
- On 23 April 2020 Topalsson's Schedule of Deliverables included against DP4 CRIS Release: SIT 75% achieved; Go-Live 50% achieved.
- I find that Topalsson was under a contractual obligation to achieve Technical Go-Live in respect of CRIS by 23 April 2020. Topalsson failed to enter SIT or UAT in respect of CRIS and acknowledged in its internal discussions that it was far behind the deadline. Indeed, as at 7 April 2020 it informed RRMC that it would not meet the 23 April 2020 date. By 23 April 2020 Topalsson accepted that SIT and Technical Go-Live had not been achieved. On that basis, Technical Go-Live in respect of CRIS was not achieved by 23 April 2020 and would not have been achieved even if there had been no termination.
- In conclusion as at the date of termination, Topalsson had failed to comply with the March Plan:
- Topalsson's case is that it was impeded in its performance by delays at the start of the project, including difficulties in obtaining access to RRMC infrastructure, lack of the necessary licences, changes to requirements and RPC's poor performance. Further, it is said that delay was caused by imposition of the waterfall methodology on Topalsson.
- RRMC's case is that Topalsson was responsible for delays to the project through inadequate resourcing, management, planning and testing.
- Ms Biot agreed in cross-examination that there was considerable delay to the project before any involvement on the part of Topalsson. The launch date for the Ghost model of May 2020 was fixed as early as 2017 but the RFI for the project was not issued until April 2019, by which time the project was already months behind the original timeline. The anticipated timeline contained in an appendix to the ITT showed the start of DP1 in Q3 2019 but it did not in fact start until later and the first purchase order in respect of the project was not issued until 18 July 2019, when RRMC awarded the contract to Topalsson. Even then, as Mr Topal correctly pointed out in cross-examination, until the Agreement was in place on 11 October 2019, he was entitled to limit the time and resources allocated to the project. Hence, the timeline for the project was very tight from the outset.
- Topalsson needed access to RRMC's networks. Confluence was used to document meetings, ideas, technical drawings and processes. Jira was used to store user stories and sprint data. Mr Hoffmann's evidence was that he supplied Topalsson with three BMW laptops in July 2019 and with virtual desktop instance ("VDI") from about 18 September 2019, pending set up of a leased line, which gave direct access to RRMC Jira and Confluence systems and was available on around 10 October 2019. In cross-examination he accepted that initially Topalsson encountered difficulties in using the leased line but explained that this was not caused by lack of access to Jira and Confluence but rather because Topalsson used the wrong URLs (web addresses).
- Topalsson needed licences for the DeltaGen tools used to create the digital twin models. Mr Mokrusch accepted in cross-examination that Topalsson included prices for the necessary DeltaGen licences in its tender but they were removed for the purpose of reducing its bid in the BAFO and did not form part of the agreed price within the Agreement. Therefore, Topalsson was not entitled to payment for the licences. It agreed to bear those costs (in return for RRMC agreeing to bear the costs of the project management office) but took the decision to work on version 12 of DeltaGen, rather than version 13, which increased the time required to create each model. Notwithstanding that difficulty, 3D models were delivered by mid-October 2019.
- Topalsson complains that there were changes to the requirements and/or scope creep in October/November 2019. Mr Hoffmann's understanding was that this was part of the exercise in detailing the Business Requirements. Mr Wiedow accepted in cross-examination that the task of refining the Business Requirements into user stories was part of Topalsson's responsibility under DP1 and that the generation of multiple user stories did not necessarily indicate any scope increase. Mr Kottenhagen accepted that he did not identify any scope creep against the Business Requirements or raise any change requests. Topalsson has failed to provide details of the alleged scope changes or to explain any impact they had on progress of the project. It is significant that it did not use the contractual change control mechanism and such claims are not supported by the contemporaneous documents.
- At the outset of the project RPC was the project manager, responsible for setting up and agreeing a project timeline, with agreed milestones, with all relevant stakeholders, together with overall planning and control of the project plan. Mr Schemuth's evidence is that although RPC initially submitted a response to the RFI, following a discussion with RRMC it agreed that, because of the size and nature of the project, it might be better for it to join forces with Topalsson in submitting a tender. It was agreed with Topalsson that RPC would be a sub-contractor with responsibility for the Project Management Office and requirements management.
- Three different staff members were appointed to the PMO role, namely, Martin Schnebbe, Alexandra Zoeller and Paolo Bassi, and Mark Thilo of RPC was brought in to oversee their work. RPC's involvement in the project was not a success. Mr Topal considered that RPC failed to refine the business requirements to produce user stories, failed to provide adequate staffing of the PMO and caused delay. The relationship between Topalsson and RPC broke down in November 2019 and RPC left the project.
- Mr Topal's evidence is that he agreed to work with RPC because Ms Biot told him that if Topalsson engaged RPC as a sub-contractor for the project, it would win the tender. Regardless whether he felt under any pressure to collaborate with RPC, it was a commercial decision for him. For the purposes of the Agreement, RPC was Topalsson's sub-contractor and Topalsson remained responsible for RPC's performance.
- As referred to earlier in this judgment, a recurring complaint raised by Mr Topal during the project was his desire to adopt an 'agile' approach to development and delivery of the software. Topalsson's case is that RRMC's insistence on a 'waterfall' straitjacket impeded progress and caused delay.
- It is clear from Mr Topal's evidence and the contemporaneous documents that he holds genuine and strong views as to the merits of the agile methodology. He was convinced that it was the appropriate method for both development and delivery of this project and that it was the only way in which the December Plan could be achieved.
- The difficulty Mr Topal faces is that his preferred methodology was not reflected in the Agreement as executed by the parties. The ITT invited Topalsson to propose an agile or waterfall delivery approach as long as the Business Requirements in each specified Delivery Package were met and it was compliant with the relevant ITPM standards, in particular the ITPM Agile Project Phase Approach, an appendix to the ITT. That appendix set out the model approach that was required to be followed, including the development of user stories that met the Definition of Ready before the sprints could commence and Definition of Done after testing and implementation criteria were satisfied. It also stipulated the testing strategy that required SIT and UAT to be carried out and fully documented in order to complete each Delivery Package. The ITT was clear that binding milestone dates would be fixed for the Delivery Packages and that the payment schedule would be based on the defined milestone plan.
- In its ITT response, Topalsson confirmed that the software development would follow an agile process but it agreed to comply with the requirements of the ITPM. Ms Biot clarified the requirement for a waterfall approach to delivery at the meeting on 7 October 2019 and Mr Topal agreed to implement waterfall gateways.
- This hybrid agile/waterfall methodology was reflected in the contractual framework by the mandatory ITPM processes, staged delivery and payment structure linked to an agreed delivery plan.
- Despite Mr Topal's persistence in trying to persuade RRMC as to the superiority of the agile methodology, Topalsson took steps to follow the hybrid approach specified in the Agreement by developing plans incorporating the ITPM phases, gateways and artefacts, including the December Plan, the February proposal and the March Plan. At the meeting on 28 November 2019 it was confirmed that this was a waterfall fixed price project, as set out in Mr Brzank's memo circulated after the meeting. On 5 December 2019, Mr Mokrusch confirmed when submitting proposed billing plans to RRMC that the project was: "Waterfall Approach + ITPM artefacts with the Agile Dev approach."
- Although Topalsson's case is that the imposition of waterfall artefacts acted as an artificial constraint on its ability to progress development and delivery of the project, when on 25 January 2020 Ms Biot challenged Mr Topal to specify the elements of the waterfall approach that were impeding or preventing Topalsson from achieving the milestones, there was no reply. The pleaded case amounts to no more than assertion that an alternative approach would have been better. Against the express terms of the Agreement, that is not sufficient to establish a claim that RRMC, rather than Topalsson, impeded progress or was responsible for the delay.
- RRMC's case is that Topalsson failed to apply and maintain sufficient numbers of appropriately qualified and experienced personnel for the project, and did not have the expertise, ability and resource to perform the Agreement. Topalsson's position is that turnover and absence on the project were not excessive. Some turnover of personnel and absences on a project of this scale were to be expected. Insofar as they were greater than expected, at least in part this was the result of RRMC's micromanagement and increasing demands.
- There is ample evidence that resources were very tight on this project and there were continuing concerns raised by Topalsson employees, such as Mr Wiedow, Ms Von Schwichow, Mr Zlatev, Mr Kottenhagen and Dr Reichl, that additional resources were necessary. This was exemplified by Mr Wiedow's email to Mr Topal on 29 February 2020:
- I accept Topalsson's case that there was some initial delay to progress caused by the late start of the project. It does not follow from the initial delay that Topalsson was exonerated from any subsequent failure to meet the agreed delivery milestones. Under the terms of the Agreement executed by the parties, Topalsson undertook to provide the services and deliverables for the project in accordance with the agreed milestones. Mr Hoffmann assisted Topalsson in producing the December Plan, which implicitly acknowledged the impact of early delay by splitting delivery of the POS configurator into separate releases and deferring some of the functionality for IVT and CMS. This approach extended the project by months but enabled RRMC to benefit from delivery of the early releases so as to meet the planned launch date of the Ghost. Having submitted the December Plan and received approval of the same, Topalsson was obligated to comply with it.
- I reject the other complaints made by Topalsson for the reasons set out above. The most likely reason for the delay to progress was the lack of appropriately skilled resources, either because Topalsson took on a project that simply was beyond its capabilities, or because it struggled to recruit and retain the necessary staffing levels.
- In conclusion, on this issue I find that Topalsson was not impeded in its progress, or prevented from performing its obligations by RRMC. In particular, Topalsson has not established any delay for which RRMC was responsible, that caused or contributed to Topalsson's failure to meet the December Plan or the March Plan.
- It follows that Topalsson was in breach of its obligation to meet the dates for delivery set out in the March Plan.
- RRMC relies on further alleged breaches which, on analysis, do not amount to breaches that go to the root of the contract so as to constitute repudiatory breaches, namely, hosting confidential information on the public cloud and using sub-contractors without permission.
- RRMC complains that Topalsson hosted RRMC's confidential information, RRMC data and/or RRMC materials on the public cloud, including highly confidential 3D models for the new Ghost, without RRMC's knowledge or consent. Reliance is placed on the evidence of Mr Weise, who explained that he was instructed to set up infrastructure that was capable of hosting the Ghost model on the Topalsson AWS infrastructure. By implementing a custom configuration directly on Topalsson's firewall, although the DTE was run on Topalsson's AWS account, the stream received at RRMC appeared to come from one of Topalsson's internally hosted DTE machines.
- In cross-examination Dr Hunt confirmed that AWS installed in a client's own premises is private; therefore, hosting on Topalsson's AWS rather than the BMW AWS was not the public cloud. Further, she confirmed that AWS infrastructure was not inherently insecure and did not in itself pose any additional risk, compared to storing data on Topalsson's premises. On that basis, even if this amounted to a technical breach of the Agreement, it would not constitute repudiatory breach.
- RRMC complains that Topalsson subcontracted parts of its obligations to third parties without obtaining RRMC's consent. Daniel Plonus of Solvin was engaged by Topalsson to configure the MS project system for transferring Excel files into readable format, Frog Design was engaged to create presentation templates, including vehicle models, and Uwe Zahn was engaged to create background 3D environments that could be used in the configurator. Mr Topal's evidence was that, although formal consent was not sought, Ms Biot was aware of the use of third parties on the project and no objection was made. I note that Frog was identified as part of Topalsson's 'partner portfolio' in the pitch presentation in May 2019. Regardless whether the use of sub-contractors amounted to a technical breach of contract, or not, there is no evidence that it had any impact on the progress or quality of the software solution.
- As set out above, clauses 5.3.7 and 5.8 of section 7 of the Agreement imposed on Topalsson an obligation to meet the agreed milestone dates in the December Plan and made time of the essence in respect of the same.
- Further, RRMC explicitly made time of the essence in respect of the revised dates for delivery set out in the March Plan, pursuant to which RRMC agreed to accept delivery of a reduced scope by later dates.
- The First Termination Notice sent on 17 April 2020 relied on repudiatory breach on the part of Topalsson by reference to its failure to meet the December Plan dates. That notice was erroneous because RRMC had already agreed to the revised dates in the March Plan and, as a result, was not entitled to rely on breaches of the December Plan as repudiation by Topalsson.
- A party who is alleged to have repudiated a contract, by purporting to terminate at common law in reliance on mistaken reasons, can subsequently rely on another defence that would have been available to justify retrospectively what would otherwise be an unlawful termination: The Mihalis Angelos [1971] 1 QB 164 (CA) per Lord Denning at 195-196.
- In this case, it is immaterial that the First Termination Notice was erroneous, whether or not it could have been justified on grounds other than those articulated at the time. Topalsson rejected the notice as invalid, affirming the contract, and RRMC served the Second Termination Notice on 22 April 2020.
- Clause 13.11 of the Agreement gave RRMC an express contractual right to terminate the Agreement if Topalsson failed to meet the agreed delivery or milestone dates:
- That provision would not entitle RRMC to terminate for any breach, no matter how trivial or inconsequential: Rice (t/a The Garden Guardian) v Great Yarmouth Borough Council [2003] TCLR 1 per Hale LJ at [17]-[24]; Obrascon Huarte Lain SA v Her Majesty's Attorney General for Gibraltar [2014] EWHC 1028 (TCC) per Akenhead J at [323]. What would amount to a significant or substantial breach justifying termination under the Agreement must depend on the factual circumstances at the time of termination.
- If Topalsson had missed the delivery dates in the March Plan by a few hours but otherwise achieved Technical Go-Live in respect of the software deliveries, it is unlikely that RRMC could justify reliance on clause 13.11. However, Topalsson's failure to satisfy the March Plan could not be described as a 'near miss'. Technical Go-Live for IVT was achieved 11 days late but it was not achieved for Closed Room or CRIS and Topalsson's own reporting indicated that slippage to the sprints and testing meant that the delivery dates would not be met. When considered against the earlier slippage from the December Plan, Topalsson's failure to meet the March Plan dates was a material breach going to the root of the contract.
- Further, it is open to parties to agree that, as regards a particular obligation, any breach shall entitle the party not in default to treat the contract as repudiated: Bunge Corporation v Tradax Export SA [1981] 1 WLR 711, per Lord Wilberforce at 715E.
- Where, as in this case, time is of the essence, it is a condition of the contract and therefore delay in performance is treated as going to the root of the contract without regard to the magnitude of the breach: Lombard North Central Plc v Butterworth [1987] QB 527 CA per Mustill LJ at 535-6:
- In such circumstances, the innocent party is not obliged to accept a late tender of performance, absent any waiver or estoppel: Union Eagle Ltd v Golden Achievement Ltd [1997] AC 514 per Lord Hoffmann at p.518:
- The Second Termination Notice relied on Topalsson's failure to comply with the March Plan, in support of RRMC's position that it was entitled to terminate under clause 13.11 of the Agreement and/or at common law.
- In my judgment the Second Termination Notice was valid in terminating Topalsson's appointment as supplier under the Agreement. The March Plan was binding on the parties. The express terms of the Agreement and Ms Biot's email of 5 March 2020 made time of the essence. Topalsson failed to meet the delivery dates set out in the March Plan. That failure amounted to a breach of condition, entitling RRMC to terminate under clause 13.11 of the Agreement or at common law for repudiatory breach.
- The allegations of misrepresentation are set out in paragraphs 81 to 84 of the Re-Amended Defence and Counterclaim. The representations relied on are as follows:
- It is pleaded at paragraph 82 that in reliance on the Audi Representations, RRMC was induced to enter into the Agreement.
- At paragraph 83 it is alleged that the representations were false:
- At paragraph 84 is it pleaded that the Audi Representations were made without reasonable belief in their truth and/or negligently.
- RRMC relies on the succinct summary of the legal principles set out in Burrows: A Restatement of the English Law of Contract (2nd Ed., 2020) at paragraph 36:
- The representations relied on are said to have been made by Topalsson in a pitch presentation meeting to RRMC on 22 May 2019, at which Mr Topal showed RRMC 3D models to demonstrate the capability of Topalsson's software and a PowerPoint presentation, copies of which were sent subsequently to RRMC with Topalsson's tender.
- Present at the pitch presentation were Mr Topal, Dr Reichl, Mr Mokrusch and Oliver Meister from Topalsson; Jasmine Perera, Mr Schemuth and Mr Eigenstetter from RPC; Ms Biot, Mr Hoffmann, Mr Scott, Mr Litster, and Daniel Cabanillas from RRMC; Laura Clowsley (BMW Group's Purchasing team), Holger Hansmann (BMW Group's IT team) and Paul Comper (Product team).
- Ms Biot's understanding of the pitch presentation meeting is set out in her first witness statement:
- Little can be gleaned from the slides. On page 22, there are tiles stating: "Audi City Partner", "Audi Digitalisation Strategy Partner since 2010" and "Audi Training Center Airport Munich". On page 26 the caption reads: "All 3D Model Deliveries for AUDI AG" and on page 29 the caption reads: "Audi City 3D Real Time 12K Powerwall". No details or further information on these topics are contained on the slides.
- Mr Topal's evidence is that the written representations on the slides were true. Regarding the statement "Audi City Partner", he stated that Topalsson had been involved with Audi City since 2012:
- Mr Topal stated that the statement "Audi Digitalisation Strategy Partner since 2010" did not have any specific meaning but that Topalsson had been supporting Audi on digitalisation strategy, especially in relation to Audi Cities, at the time, and at a FMX convention. Audi's sponsorship materials described Topalsson as an "Audi official partner".
- Regarding the statement "Audi Training Center Airport Munich", Mr Topal explained that Topalsson was heavily involved in the Audi Training Centre, working on planning the Power Wall and projection areas at the Audi Training Centre, as well as the visualisation and demonstration of new product hubs. When challenged in cross-examination he stated:
- Mr Topal explained that Topalsson developed multiple digital products for Audi, including the first real-time configurator in 2014 for Audi's sport models. Topalsson also built Audi's 'used car' configurator which rendered in real-time and showed second hand cars, together with virtual reality real-time configurator for Audi whereby there was a configurator in the virtual reality headset. He stated that Topalsson's 3D data was used by Audi in configurators across the world.
- In his witness statement, Mr Teschner of Audi (who was not called to give oral evidence but in respect of whom a Civil Evidence Act notice was served) confirmed in general the connection between Topalsson and Audi set out in the pitch presentation slides. He stated that in 2014 he became involved in a substantial project in which Topalsson examined how Audi created its models to build a virtual car. From November 2016, he was involved in setting up a framework agreement involving the appointment by Audi of third-party agencies to produce new virtual models for Audi (the process for model creation having been delivered by Topalsson) and that Topalsson was selected as one of the framework third parties.
- Documents produced by Topalsson demonstrated that Topalsson was indeed working with Audi in 2014 on visualisation of Audi RS models, providing consultancy work with a value of at least 535,000, and further, that it continued to work with Audi in 2019.
- Although not referred to in her witness statements, in cross-examination Ms Biot stated that the oral statement alleged to have been made by Mr Topal at the meeting was made outside the main presentation:
- She could not recall whether any of the other bidders said that they supplied 3D models to Audi but accepted that they might have said it.
- Mr Hoffmann's evidence in his statement was:
- However, when he was challenged in cross-examination, he could not recall those words:
- Messrs Brzank, Scott and Litster were unable to recall any specific details as to what was said at the pitch presentation or other early meetings.
- Mr Topal stated in cross-examination that he did not make the oral statement attributed to him by Ms Biot:
- Drawing together the available evidence, I find that the statements set out in the slides used at the pitch presentation on 22 May 2019 were substantially true. The slides provide scant information on which to build a case of misrepresentation. Mr Teschner's statement and the contemporaneous documents produced by Topalsson support Mr Topal's account of his historic and ongoing work for Audi. Ms Biot's recollection of what was said at the meeting must be faulty; the account in her oral testimony was not in her written statements, it is not supported by any other witness and was contradicted by Mr Topal in his written and oral evidence. On that basis, I find that Mr Topal did not make the oral statement now attributed to him, namely, that Topalsson had rolled out worldwide a configurator for Audi.
- In any event, there is no evidence that RRMC was induced to enter into the Agreement in reliance on the alleged Audi Representations. On 21 May 2019, just before the pitch presentation meeting, the formal ITT was issued. On 3 June 2019 Topalsson submitted its formal tender response to RRMC. Each bid was assessed against specific weighted criteria by the RRMC team and Topalsson scored highly over a number of categories. The Technical Recommendation stated that all offers and delivered visual material had been considered for the purpose of selecting the technically compliant bidders, who were then ranked based on price. Topalsson's bid was the lowest in price out of the technically compliant bids. As Ms Biot agreed in cross-examination, the final decision to award the contract to Topalsson was made by the purchasing department, following commercial negotiations, and she had no involvement in that process.
- In conclusion on this issue, RRMC has failed to establish any case of actionable misrepresentation.
- RRMC claims damages for repudiatory breach; alternatively termination claims under the Agreement.
- The established principle on which damages are awarded for breach of contract is that they are compensatory, intended to give effect to the contractual bargain as set out in Robinson v Harman (1848) 1 Exch 850 per Parke B p.855:
- This principle has been re-affirmed in many cases, including: The Golden Strait Corporation v Nippon Yusen Kubishika Kaisha [2007] UKHL 12 (HL) per Lord Bingham at [9] and Lord Scott at [29]; Morris-Garner v One Step (Support) Ltd [2018] UKSC 20 per Lord Reed at [35].
- The usual basis on which such damages are calculated is a 'net loss' approach, whereby any gains resulting from the breach (such as savings made as a result of release from future performance) must be set off against expenses caused by the breach (such as cost of replacement) and gains prevented by the breach (such as loss of profits).
- The 'net loss' approach is reflected in Section 7 of the Agreement, which contains express provisions for ascertaining the sums due to each party on termination, including the following:
- The Agreement contains a complete scheme for allocating liabilities and entitlements as between Topalsson and RRMC on termination. Thus, the express terms of the Agreement require the parties to carry out the following accounting exercise:
- Topalsson seeks to argue that the set-off exercise to establish the net sum due should be carried out after the application of the cap on liability to the sums calculated as due to either party. In this case the effect would be that if RRMC established an entitlement to damages in excess of the cap of 5,000,000, that sum could then be reduced by any sums found to be due to Topalsson. I reject that argument because it is contrary to the express provisions in the Agreement.
- Reliance is placed on the rationale explained in The Tojo Maru (No.1) [1969] 2 Lloyd's Rep 193 per Denning MR at 203:
- In in that case, the limitation on liability was expressed as applicable to any article that was damaged or lost. Therefore the cap was required to be applied separately to each article damaged or lost. In contrast, under the Agreement, the cap on liability is applicable to the total liability of either party to the other in aggregate for all claims no matter how arising. The total liability of either party to the other requires the application of the above provisions to ascertain the balance of sums due or payable. On a proper construction of the express terms agreed between the parties, under the Agreement the accounting exercise to determine the net sum due to or from each party must be carried out before the cap is applied.
- Under clause 26.1 of Section 7, Topalsson is entitled to the proportion of the Charges applicable to the Services carried out prior to termination. I accept Topalsson's argument that on a plain and natural meaning of the words used in the clause, it is entitled to a proportionate payment in respect of partially and fully completed Delivery Packages.
- Topalsson's case is that it completed, and therefore is entitled to payment for, the following proportions of each Delivery Package based on an assessment of work done carried out by Mr Mokrusch as at 23 April 2020:
- It is recognised that the exercise carried out by both parties was a difficult one, based on qualitative assessment rather than precise measurement. This is a result of limited or incomplete evidence in Jira and the division of functionality to be delivered under the March Plan which was not reflected in sub-divisions of the Delivery Packages by value.
- I accept Mr Mokrusch' assessment that DP1 was achieved in full, as evidenced by section 3.1.2 of the Business Proposal and the reliance placed by RRMC on the fixed milestone dates set out in the December Plan. However, the remaining assessments are wildly over-optimistic as to the extent of completion achieved. For the reasons set out in Issue 1 above, Topalsson was obliged to comply with the requirements for testing as set out in the ITPM documents but failed to satisfy those requirements in respect of many of the deliverables. Therefore, I am unable to accept the assessment by Mr Mokrusch as reliable.
- Dr Hunt carried out a similar but more detailed exercise, set out in Appendix D to her first report. She has explained the evidence which she used to reach her assessment as to the extent of completion of each Delivery Package. With the exception of DP1 which, as set out above, I consider was completed in full, I accept Dr Hunt's assessment as the best evidence before the court.
- Accordingly, I find that the extent of completion of each delivery package and Topalsson's entitlement to payment under clause 26 of the Agreement are as follows:
- From that sum must be deducted the sum of 757,028 paid to Topalsson against the invoice of October 2019, leaving a balance due of 794,759.
- It is unnecessary to bring into account the unpaid invoice submitted to RRMC, invoice 1013919 in the sum of 180,744, because it related to work done on DP1 and DP10, the value of which has been included in the assessment set out above.
- As set out above, the Agreement contains a cap on liability in the sum of 5 million. Therefore, RRMC does not have to prove the full value of every item in its quantum claim, provided that it establishes an entitlement to damages of at least that sum.
- The quantum of RRMC's claim for damages is set out in Appendix 1 to its pleaded case, as amended by Mr Osborne's expert report, and comprises the following claims:
- As a matter of principle, reasonable costs incurred in mitigating the loss suffered as a result of the breach are recoverable. Clause 13.11.5 expressly entitled RRMC to recover any loss and additional costs incurred in performing the relevant services or purchasing substitute services from a third party. Mr Osborne has checked and confirmed that the sums claimed were in fact incurred. Ms Biot has explained the basis on which the sums are claimed as damages and confirmed that any costs relating to work for BMW that were initially included erroneously have now been removed.
- The stabilisation and upgrading of the existing Configurator landscape was carried out by Sulzer, supplier of the same, to ensure that RRMC could continue to use it until a permanent alternative system could be developed. The work included security updates and support upgrades, front end updates, performance updates, back end charges, CoSy imagery preparation for all models, PuMa updates, and 3D modelling and CoSy preparation for all model feature updates for 2021 and 2022.
- The fallback solution, an alternative launch Configurator tool, EVE, was based on a visualiser tool developed for BMW and mini dealers by Mackevision, who were existing suppliers of 3D models to RRMC prior to the Agreement and continued to work as suppliers of 3D models to BMW Group. EVE was not a full Configurator but was used at the postponed Ghost launch events which took place at the end of May and June 2020 and was subsequently rolled out to dealers worldwide. Topalsson objects to such claim on the basis that RRMC committed to incur at least part of these expenses before terminating the Agreement. I reject that argument. RRMC was entitled to take steps at its own risk to ensure that it had a fallback position in the event that Topalsson failed to deliver the software in accordance with its obligations under the Agreement. As recognised by RRMC, if Topalsson had complied with the March Plan, such costs would not have been recoverable. In the event, Topalsson failed to deliver in accordance with the March Plan and these costs are recoverable as reasonable steps taken in mitigation of its loss.
- The internal staff costs relate to Ms Biot's assessment of the costs of RRMC staff diverted from revenue-generating activities to implement the fallback solution. Ms Biot and Dr Poser confirmed that the costs of BMW staff were recharged to RRMC.
- I am satisfied that these costs were incurred by RRMC in reasonable steps of mitigation and therefore are recoverable as damages or termination costs.
- Mr Osborne's estimate of the additional costs of the replacement solution is based on the second lowest technically compliant bid, as identified in the Technical Recommendation, less the value of the Agreement, to which a discount rate of 5.18% must be applied to determine the net present value of the loss. This gives a loss of 5,055,796. Using Ms Biot's estimated costs of a replacement system, based on RRMC's target solution, would give a higher total of 6,790,880.
- Pending the replacement solution, RRMC will incur ongoing costs in maintaining and upgrading the fallback solution, EVE. Ms Biot's estimate of these ongoing costs, after applying the discount of 5.18%, gives a figure of 5,966,570.
- Ms Biot has calculated the internal staff costs of re tendering and setting up the replacement solution. The figures have been checked and corrected by Mr Osborne to give the figure of 359,362.
- Ms Biot has explained the new solution in her second statement:
- There are a number of difficulties with this part of the claim.
- Firstly, the new solution is not comparable to the project which Topalsson agreed to undertake; it is more comparable to the hybrid solution, which would have been more expensive and which was not selected by RRMC. The proposed replacement is not a standalone configurator but will be integrated into the BMW/Mini system landscape. Clearly this will involve significant betterment but insufficient details are available for any assessment to be made in this regard.
- Secondly the new solution will not be available until 2025, in circumstances where the Agreement imposed a compressed timetable for delivery in 2019-2020, termination occurred in April 2020 and the term of the Agreement would have ended, if not terminated, on 31 December 2024. Although this is not an automatic barrier to recovery of damages based on a replacement solution, it is relevant that the delay in implementing the solution has not been caused by Topalsson or any impecuniosity on the part of RRMC. The reason for delay is the strategic decision to adopt a different approach by finding a solution that can be integrated with the BMW landscape. In those circumstances, it is not open to RRMC to claim all its losses during the full period of this delay.
- Thirdly, the costs of maintaining and further developing the EVE visualizer are needed to support the launch of the new Spectre model but only as a result of the strategic decision to invest in a new solution that is not yet implemented. Recovery of these costs in addition to the costs of replacement would amount to double recovery; alternatively these costs do not constitute reasonable mitigation of RRMC's losses.
- Weighing up the evidence on this issue, I conclude that RRMC has established a good case for recovery of the estimated costs of a replacement system that is comparable to the solution which Topalsson undertook to supply. However, it would not be reasonable for RRMC to recover the costs of a replacement system that is substantially different from the benefit expected under the Agreement. Therefore, Mr Osborne's estimate based on the second lowest technically compliant bid is appropriate. Further, it would not be reasonable for RRMC to recover the estimated costs of maintaining and further developing the EVE visualiser fallback solution in addition to the costs of a replacement system as that would go beyond compensation for losses caused by the termination.
- For those reasons, RRMC's entitlement under this heading is limited to the estimated costs of replacement, together with the associated internal tendering and project costs, a total of 5,415,158.
- I address these additional costs briefly because, having regard to my findings above, they do not affect the financial outcome of this case. Mr Osborne has checked and confirmed that the sums claimed were in fact incurred. The costs at items (a) to (d) are recoverable as costs incurred by RRMC for which they received no benefit as a result of the termination. RRMC's wasted internal project costs are not recoverable because they would amount to double recovery, given the damages for a replacement system. Payments to Topalsson have been brought into account in assessing the sums due to Topalsson as set out above. Therefore, I find that RRMC is entitled to 159,979.
- I address this claim briefly because, having regard to my findings above, it does not affect the financial outcome of this case. Mr Scott explained that it was very difficult to estimate the impact of the lack of a new state of the art Configurator on overall sales of vehicles but RRMC endeavoured to assess the area of most impact, the loss of sales of new options launched in May which entered production in August 2020 and calculate losses until April 2021.
- Mr Scott stated that although RRMC put a fallback visualiser tool in place following termination of the Agreement, it did not incorporate imagery for significant new options launched at the start of May 2020 across the Rolls-Royce model range. The lack of a configurator meant that dealers were unable to demonstrate to customers how their vehicle would look with these various new available customisable options, and were unable to hit the targets which RRMC had set for sales of these options. He measured the impact of the lack of the new configurator by comparing the profit contribution made on RRMC's actual sales on the new options in the three months following the launch of those options with the sales targets for that period.
- Mr Gellatly, whose role involves the management of the team responsible for the marketing and sale of bespoke features available on Rolls-Royce vehicles, supported RRMC's claim that sales figures of the options were lower in 2020 because dealers could not show the new features to customers when they were purchasing a new vehicle. The sales figures for 2020/2021 showed that sales of the options started to pick up in the quarter following August-September 2020, once RRMC was able to put in place the fallback solution demonstrating these features.
- In cross-examination Mr Osborne agreed that the planned take rates were projections or estimates and therefore subject to error. The relatively low volumes of vehicles sold would increase the risk of error and exacerbate the sensitivity of the projections to external factors, making it very difficult to predict with any accuracy. He accepted that it would have been preferable to have tested the accuracy of the business target rates by reference to historical data but such data was not available. He also agreed that potentially there were other factors that could affect the take rates but for the purpose of his report he assumed that all effects were caused by the lack of a configurator.
- Topalsson raises a number of objections to this claim which I find are well made. RRMC has failed to provide accounting information, such as management accounts, which Mr Osborne agreed could support the lost profit assessment. Further, Mr Gellatly accepted in cross examination that setting the planned take rates was not a science and he struggled to explain the fact that take rates for several of the options fell within the set margin of +/- 10% despite the absence of the configurator. Finally, it was conceded, properly, that it is likely that COVID affected customer behaviour in 2020-2021 but RRMC has not produceD any analysis of this impact.
- These difficulties lead me to find that on the balance of probabilities this claim has not been established.
- From the above findings, the net sum due to RRMC as termination damages is: (i) interim measures in mitigation of 2,387,186; (ii) estimated replacement costs of 5,415,158; and (iii) wasted costs incurred in respect of the project of 159,979; a total of 7,962,323; less the sum due to Topalsson of 794,759, leaving a balance of 7,167,564.
- The sum due to RRMC is in excess of the contractual cap of 5 million. The cap applies and therefore, RRMC is entitled to damages in the sum of 5 million.
- Clauses 14.11 and 14.12 of Section 7 of the Agreement stipulate:
- Clause 14.11:
- Clause 14.12:
- On their face, these provisions are in wide terms, they apply to both parties and are apt to cover all payments due under the Agreement, including termination costs. The court has now determined that payments are due to RRMC as set out above. For those reasons, the agreed interest provisions are the appropriate basis on which to award interest in this case.
- The following matters arise for determination by the court:
- Topalsson seeks a declaration that on a proper construction of clause 13.10 of section 7 of the Agreement, RRMC is not entitled to make any use of any documents, products or materials developed by Topalsson, including any drawings, plans, diagrams, pictures, computer programmes, data, reports or specifications, save for those limited artefacts for which RRMC has paid.
- RRMC's position is that clause 23.1 of Section 7 prevails and provides that all right, title and interest including all intellectual property rights to the Deliverables and any other product of the services shall immediately upon their creation vest in RRMC.
- Deliverables were defined in Section 6 of the Agreement as:
- It is apparent from the above definition that Deliverables comprised the documents, goods, materials and information to be provided by Topalsson under the Agreement. It does not appear to include software developed by Topalsson, whether falling within the definition of Supplier Software or Bespoke Software.
- Regardless whether Supplier Software or Bespoke Software might fall within the definition of Deliverables, intellectual property rights in such software is expressly covered by the provisions set out in clauses 5 and 6 of Section 2 which take precedence and are addressed below.
- Clause 23.1 of Section 7 provided:
- Clause 13.10 provided that:
- That must be a reference to payment in accordance with the terms of the Agreement. In the quantum section above, I have set out my findings as to the value of work done by Topalsson as at the date of termination and that value has been included in the accounting exercise required under the Agreement. It follows that payment in accordance with the Agreement has been made in respect of the Deliverables provided to RRMC and title has passed to RRMC.
- Topalsson's case is that on termination of the Agreement, RRMC's right to make any use of the Supplier Software ceased. Clause 24.7 of section 7 of the Agreement prohibited RRMC from making any adaptations or variations to the Supplier Software without consent and clause 24.8 prohibited any disassembly, de-compilation, reverse translation or any other form of decoding save as permitted by law. It follows that RRMC has no legitimate use for any copies of Topalsson's software in its possession and any copying of the same would amount to infringement of its copyright. On that basis, an order for delivery up or destruction of all copies of Topalsson's software in RRMC's possession is sought.
- Clause 5 of Section 2 defined Supplier Software as follows:
- RRMC's position is that the software supplied by Topalsson is not functional and none of it is of use. It has admitted that RRMC is not entitled to make use of or copy the Supplier Software and RRMC confirmed by letter dated 12 August 2020 that it is not using, and does not intend to use, the Supplier Software.
- In paragraph 77.5 of the Re-Amended Defence and Counterclaim RRMC has offered the following undertaking:
- On the basis of the above, there is no dispute about the status of the Supplier Software. RRMC's undertaking can be incorporated into the final order made in these proceedings.
- RRMC's case is that it has retained all right, title and interest, including all intellectual property rights in Bespoke Software, the Deliverables and any other product of the Services. It seeks orders for delivery up and/or destruction of the property requested by letter dated 3 September 2020 and all copies of RRMC's software in Topalsson's possession. It has confirmed that it does not seek destruction or delivery up of any Supplier Software.
- I have found that payment in accordance with the Agreement has been made in respect of the Deliverables provided to RRMC and title has passed to RRMC. Therefore, it is entitled to delivery up or destruction of any such material held by Topalsson.
- Clause 6 of Section 2 defined Bespoke Software as follows:
- Bespoke TWIN RRMC Plugin/extension to read RRMC data
- Bespoke DTE RRMC POS Plugin/extension for specific RRMC POS use
- Bespoke SOLOGIC RRMC Plugin/extension to read RRMC data.
- Clause 23.8 of Section 7 provided:
- Clause 26.4 of Section 7 provided:
- It is admitted by Topalsson that it is not entitled to make use of or copy the Bespoke Software, including the data and materials identified in clause 23.8 of section 7.
- In paragraph 143.1 of the Reply Topalsson has offered the following undertaking:
- In its closing submissions, it goes slightly further, accepting that it has no right to use RRMC-specific data. On the basis of the above, an appropriate undertaking can be incorporated into the final order made in these proceedings. However, there is a dispute as to the categorisation of software as Bespoke Software (as distinct from Supplier Software or Deliverables).
- Bespoke Software does not automatically cover all Deliverables within the meaning of the Agreement but also is not confined to the specific software identified in clause 6 of section 2 above, which was expressed to be an inclusive, rather than exclusive list.
- Dr Hunt performed a code review to try and identify code that was bespoke for RRMC's use or contained RRMC data or intellectual property. The results of this exercise are set out in Appendix F of her first report. However, in cross-examination, she confirmed that she did not ask for, or have access to the source code and therefore her review was limited to identified items that contain Bespoke Software and RRMC data or intellectual property; that description did not necessarily apply to the whole folder.
- This was not the subject of discussions or joint statements between the IT experts and there has been no detailed investigation at trial as to which sections or lines of code were Bespoke Software or Supplier Software. As a result, the court is not in a position to make any order for delivery up or destruction of specific software and the remedy is confined to a declaration.
- For the reasons set out above:
- Following hand down of this judgment, the hearing will be adjourned to a date to be fixed for the purpose of any consequential matters, including any applications for interest, costs or permission to appeal, and any time limits are extended until such hearing or further order.
Mrs Justice O'Farrell:
Background
i) 'Closed Room' preview events for dealers, special guests and customers, which were planned to take place from 13 April 2020;
ii) the World Dealer Conference, then planned to take place in Miami on 15 April 2020, where RRMC anticipated that it could showcase the new Ghost model;
iii) 'Start of Communications' for the new Ghost model, the date on which RRMC would begin to communicate a new model to the general public, in the press, at events and at the dealerships, from 4 May 2020;
iv) 'Start of Ordering' for the new Ghost model, the date from which orders could be placed by dealers in the system, from 15 June 2020.
The RFI
"- Visualisation:
Comprehensive, individualised, high-quality photo realistic and high-performance real-time visualisation.
- User experience journey:
Open, organic configuration flow and intuitive user experience journey based on modular elements.
Functional elements and contents should be related to individual business needs of consumers and dealers.
- Process integration:
Streamlined, adapted and automated processes throughout the customer journey to increase efficiency.
These are enabled and supported by the following:
- System Integration and Back-End Integration:
The Rolls-Royce Motor Cars configurators (online, showroom, review and ordering configurator) should be replaced.
The full end-to-end integration for a seamless configuration and ordering process covers all newly provided system from front-end to configurator back-ends but also all other relevant RRMC and BMW Group back-end systems
- Advanced Analytics:
Advanced analytics capabilities leveraging actionable insights.
The project scope contains the replacement of the following configurator "front-ends":
... Rolls-Royce Ordering Configurator (RROC) used as the dealer-facing configurator integrated into the ordering systems
... Rolls-Royce Marketing Configurator (also abbreviated RRMC) used as the customer facing configurator in the Rolls Royce website
... Rolls-Royce Offline Marketing Configurator (RRMC offline) used by dealers as a customer facing configurator in the showroom or at events
... Rolls-Royce Review Configurator used by the product management team to review the results of the CoSy imagery process (Imagery Validation Tool) but also used by the Bespoke Design team to produce customer facing documentation of bespoke offers in a flexible way."
Invitation to Tender (ITT)
"The working method or approach of delivery (for example: agile vs. waterfall) is free to choose by the bidder as long as the Business Requirements in the specified Delivery Packages are met. However, the bidder must outline a quantity structure how the project timeline could look like. In case an agile delivery model is proposed, this should be based on the information given in appendix "ITPM Agile Project Phase Approach".
Nevertheless, as long as this is compliant with BMW ITPM standards, the bidder is free to propose a different project approach or a combined approach, considering the benefits and achievements for the project (e.g. reduced timeline, flexibility in delivering requirements). In that case, the bidder will be requested to justify his approach, to detail the effect on collaborative work with other external partners and to clearly mention potential effect on risks and pitfalls. In case of uncertainty on the bidder's side to the implication of this paragraph it is the bidder's responsibility to clarify these fully before submitting their fixed price offer."
"User Stories
A User Story is the central element for describing requirements. It is a defined software requirement in plain language. The User Story is deliberately kept short and normally contains not more than two sentences. User Stories are used in combination with acceptance criteria for the specification of requirements. The User Story is the most important method to control the agile development.
Definition of Ready, Definition of Done
The DoD is a quality assurance instrument for the implementation of User Stories. It describes general criteria for controlling the completion of User Stories and is checked by the agile team. User Stories are not fulfilled until the DoD criteria are met. The DoD is the requirement of the Product Owner (and the compliance requirements of the company) to the quality of the implementation. The DoD is created jointly between the agile team and the Product Owner and develops together.
The DoR describes the entrance criteria for implement User Stories in Sprints. So it is about the quality of the User Story. Only if the criteria are met, the team can estimate the effort and plan for the next iteration. The DoD is created jointly between the agile team and the Product Owner and develops together.
Test Plan
The current Test Plan template is valid for waterfall and agile projects. The following topics need to be addressed during Exploration Phase:
1. Test Scope, incl. test goals, test basis and test objects
2. Test strategy (i.e. test approach), including planned test types, test levels, test automation and test data
3. Test schedule with milestones. ITPM mandatory topics are considered and mapped to the project schedule
4. Estimation of test effort
5. Initial planning for resources, agreed with Project Lead
6. Acceptance criteria (as part of the test exit criteria for Acceptance Test)
7. Responsibilities for test activities
8. Organisation and meetings (including collaboration with interfacing partners)
9. Planning of test environments and test tools."
i) DP1: Analysis and Alignment production of details for project governance, a refined Implementation Plan, a design concept for the configurator user experience and refined business requirements end Q3 2019;
ii) DP2: Initial Back-End and Rule Engine the core engine used to define the rules for possible configurations and interface with RRMC product data Q3 2019 to Q1 2020;
iii) DP3 Point of Sale Configurator a configurator situated within the dealer showroom or event space Q3 2019 to end Q1 2020;
iv) DP4 Web Configurator user interface and related functionality for configurations over the internet, including the development of an Application Programming Interface ("API") for use by other RRMC systems Q4 2019 to Q2 2020;
v) DP6 Ordering Integration to allow orders to be placed through RRMC's order management system, SAP Q2 2020 to and Q4 2020;
vi) DP7 Pricing Integration price management and price calculation functionality to provide configuration specific prices to dealers in the POS Configurator and to SAP Q2 2020 to end Q3 2020;
vii) DP10: 3D Data Preparation conversion of engineering models and physical samples into data that was suitable for 2D and 3D imagery Q3 2019 to Q1 2020; and
viii) DP13 Operation and Maintenance Q3 2019 to Q4 2020 and ongoing throughout the term of the Agreement.
"Delivery Packages are separate modules of the configurator landscape that are independent from each other if not indicated otherwise. As a result from the initial RFI phase we have removed certain delivery packages from this ITT because they seem to be not refined enough at this point in time Other delivery packages are now clearly indicated as "optional". This indicates that they are part of the offer, so maximum fixed price has to be indicated. However, it remains to the discretion of RRMC if and when they will be ordered.
Each delivery package contains a description of the outcome of the delivery package and the Business Requirements, which must be taken into account. The Business Requirements within each Delivery Package chapter only give an initial overview of the content. The relevant detailed Business Requirements for each Delivery Package can be found within the document in the appendix "Detailed Business Requirements mapped to Delivery Packages"
The scope to be considered by the service provider for each Delivery Package is defined by the detailed Business Requirements.
Each of the defined Delivery Packages must be delivered in a way the result is usable by itself, with the only exception that it is assumed that DP1, DP2, DP3 and DP10 are implemented first. All other DPs then define additional scope on top of those DPs listed above. This means that each DP will deliver a defined scope of new systems and will integrate or replace existing systems or parts of their functionality. The details how each DP affects the systems is contained in the appendix 'Mapping Delivery Packages and Systems' "
"The payment schedule will be defined based on the defined milestone plan for the project (see appendix ""). This milestone plan might be amended based on the initial analysis phase (Delivery Package 1). Periodically incurring invoicing rates are not permitted."
Tender
"Software development will follow an agile process. All feature requirements will be converted into user stories and added to the project backlog, which is visible to RRMC if desired. The scope of the project and user stories will be fixed in DP1 alongside with a story-point based estimation of efforts. As assumed any agile workflow, changes to those stories are expected and accepted. Additional efforts due to change requests can be handled in one of two ways:
1. The additional effort is priced and ordered individually, based on the story-point value in relation to the whole project.
2. A story of equal value is de-scoped, or existing stories are altered to maintain the total story point value of the project.
Requested improvements of the software during maintenance that change the initial scope agreed on after DP1 are classified as new stories and treated as described above. Defects and performance issues are adjourned to in the next sprint / maintenance release."
"This delivery package lays the foundation for the whole project and has a major influence on the following delivery packages. It defines the execution of next steps based on the defined business requirements and the to-be decided implementation scenario and approach. Thus, it is not independent of but a prerequisite for all other Delivery Packages, besides of DP10. Some of the following delivery packages can start before DP1 is completed
The assumed timeline to deliver the project as well as the respective project organisation for each offered implementation scenario has followed your proposal. We have fitted the project organisation in your implementation timeline request. We have adjusted the Pre-milestone of the POS Configurator from end of December 2019 to end of October 2019."
i) Delivery Package 1 (Analysis and Alignment) Sign Off by 30 September 2019;
ii) Delivery Package 3 (Point of Sale Configurator) Go Live by 31 March 2020;
iii) Delivery Package 10 (3D Data Preparation for RR21 and RR22 models) published by 31 January 2020;
iv) Delivery Package 13 (Operation and Maintenance) to start in the Quarter after the first technical DP Go Live and ongoing;
v) All other DPs to be confirmed in DP1.
"Our internal QA is based on agile methodologies and relies and automated testing on different levels
All acceptance criteria are derived from user stories delivered by the PO [Process Owner] or the customer directly, and are detailed by the PO and the team before work on a user story can begin. Reporting is done by automated frameworks and formatted by the PO for customer review if desired.
In addition, the current BMW ITPM quality are adhered to and will be implemented as requested in the ITT document referenced on the front page."
Purchase Orders
The Agreement
i) Section 1 Key Terms;
ii) Section 2 Services, Specification, Deliverables, Service Credits, Exit Plan and Business Continuity Plan;
iii) Section 3 RRMC Materials;
iv) Section 4 Use of Confidential Data;
v) Section 5 Changes;
vi) Section 6 Definitions; and
vii) Section 7 General Terms.
"For the avoidance of doubt the Tender Document titled TE4427 Invitation to Tender: Future Configurator Landscape, issued on 21.05.2019 is also deemed incorporated into this Agreement save where expressly excluded, amended or varied."
"This Agreement is formed of and incorporates its Sections, the Tender Document and any Purchase Orders."
"This Agreement is for the benefit of RRMC and any relevant BMW Group Companies."
Services
i) Supplier Software (clause 5);
ii) Bespoke Software (clause 6); and
iii) Provision of Services and Deliverables as set out in the Tender Document (the ITT), to be further specified in DP1.
"Supplier Software (all of which shall be deemed to be "Licenced Software" pursuant to clause 22 of Section 7 of this Agreement) means all hardware and software provided by the Supplier to RRMC to provide the Services including the Supplier Hardware, Supplier Standard Software, Third Party Software, Modified Software (Supplier), Modified Software (Third Party) and Supported Software including but not limited to those listed below:
5.1 DTE (Digital Twin Engine) Software Version 2019 (R6)
5.2 TWIN Software Version 2019 (R6)
5.3 SOLOGIC Software Version 2019 (R6)
For the avoidance of doubt and notwithstanding any other provision of this Agreement the Intellectual Property Rights in any Supplier Software used or created by the Supplier in providing the Services, including but not limited to any modifications or improvements to such Supplier Software, will be owned by the Supplier or any relevant third party licensor.
The Supplier hereby grants a non-exclusive, revocable, global licence to BMW Group to use the Supplier Software for the Term for usage solely in connection with the design of Rolls Royce model vehicles (and not for the avoidance of doubt for vehicles in the wider BMW Group that are not branded as Rolls Royce)."
"Bespoke Software means any software created pursuant to the terms of this Agreement to be used by RRMC solely in relation to RRMC products, including but not limited to those software listed below:
For the avoidance of doubt, and notwithstanding any other provision of this Agreement, the Intellectual Property rights in any Bespoke Software shall be owned by RRMC and RRMC shall grant the Supplier an exclusive licence to use the Bespoke Software for the purpose of providing the Services for the duration of the Term of this Agreement."
"the goods or services or other things to be delivered to RRMC or BMW Group as deliverables as a product of the Services, with such deliverables including RRMC data and those deliverables set out in Section 2 and all documents, products and materials developed by Supplier or its agents, contractors, consultants and employees in relation to the provision of the Services in any form, including drawings, plans, diagrams, pictures, computer programs, data, reports and specifications (including drafts of the same)."
"the Services to be provided by the Supplier under this Agreement and the delivery of the Deliverables with such services being specified in Section 2: Services, Specification, Deliverables, Service Credits, Exit Plan and Business Continuity Plan and any Additional Services."
i) Clause 23.1 of Section 7 stated:
"All right, title and interest including all Intellectual Property Rights that are legally capable of being assigned under Applicable Law in and to the Deliverables and any other product of the Services shall immediately upon their creation vest in RRMC. Accordingly the Supplier hereby assigns to RRMC with full title guarantee all such Intellectual Property Rights that the Supplier has now or may have in the future throughout the world to RRMC absolutely so far as possible in perpetuity."
ii) Clause 23.3 of Section 7 stated:
"The Supplier hereby waives or it shall procure the waiver of all moral rights anywhere in the world that may subsist in and to the Services, the Deliverables and any other product of the Services "
iii) Clause 23.8 of Section 7 stated:
"All right, title and interest including Intellectual Property Rights in and to all BMW Group background IPR, RRMC materials and RRMC Data is vested in and shall remain vested in BMW Group."
Charges
"In consideration of the Charges the Supplier shall provide the Services and Deliverables throughout the term in accordance with the terms of this Agreement."
"the fees charges or other amounts that are payable by RRMC to the Supplier for the Services with such fees and charges being specified in Section 5: Charges or in any Purchase Order."
| Package | Charge () |
| DP1: Analysis and Alignment | 272,903 |
| DP2: Initial Back-end / Rule Engine | 885,749 |
| DP3: Points of Sale Configurator | 1,314,025 |
| DP4: Web Configurator | 970,151 |
| DP6: Ordering integration | 257,736 |
| DP7: Pricing integration | 161,234 |
| DP10: 3D-Data Preparation Process | 2,393,318 |
| DP13: Operation and Maintenance | 2,794,885 |
"RRMC shall pay the Charges with such Charges being the only, full and fixed remuneration of the Supplier for the Services."
"The Supplier shall promptly invoice RRMC in accordance with the agreed milestones set out in the Tender Document and appendix "
"RRMC shall pay the Charges Due in accordance with the Payment Terms specified in the Key Terms. Unless the Parties otherwise agree, [RRMC] shall pay any sums properly due to [the Supplier] within thirty (30) days from the date of receipt of a properly verifiable Supplier's invoice. Unless otherwise provided under this Agreement, Charges shall be payable only upon acceptance by RRMC of the Services or Deliverables to RRMC's satisfaction."
"RRMC shall be entitled to set off any Charges due to the Supplier under this Agreement against any amount owed by the Supplier to RRMC under this Agreement."
"RRMC shall be entitled to withhold payment of any Charges in whole or in part without breaching this Agreement where it determines that there is a dispute regarding the Services or Deliverables or if any invoice is inaccurate. RRMC shall pay the balance of any invoice which is not disputed by RRMC. "
Performance obligations
"In performing this Agreement the Supplier shall:
5.3.2 provide the Services and Deliverables faithfully, diligently with skill and care to a standard of Good Industry Practice, the BMW ITPM and any other reasonable written instructions of RRMC
5.3.5 allocate and apply sufficient resources
5.3.7 complete the Services and deliver the Deliverables on time and in full and by any applicable milestone date or delivery date, if delivery dates or milestones are not specified, within or by any reasonable delivery date or time period that is specified by RRMC."
"the exercise of skill, care prudence, diligence and foresight to a standard that would ordinarily be exercised by skilled, experienced and competent businesses seeking in good faith to comply with their contractual obligations to provide services that are of the nature of the Services and complying with Applicable Laws."
"The Supplier shall promptly notify RRMC if it is unable or envisages that it may become unable for any reason to perform the Services or deliver the Deliverables in accordance with this Agreement providing RRMC with the reasons for such inability and all other relevant information."
"The Supplier agrees:
5.6.1 to deliver and install the Supplier Software at the Site(s);
5.6.2 to carry out, in conjunction with RRMC, the Acceptance Tests; and
5.6.3 to provide the Supplier Software Ready for Service by the Completion Date
5.6.4 on the terms and conditions set out in this Agreement."
"Time shall be of the essence regarding any date for delivery by the Supplier of any good or service specified in this agreement and the Completion Date."
" 7.2.2 The Services and Deliverables will conform with the standard of quality and will be fit for any purpose held out by the Supplier or made known to the Supplier by RRMC under this Agreement.
7.2.3 The Services and Deliverables will be free from defects in design, material and workmanship.
7.2.4 It has the expertise, ability and resource to provide the Services and perform this Agreement "
i) Clause 13.1 of Section 7:
"The Supplier shall deliver each Software Module to the Site(s) by the applicable Software Delivery Date."
ii) Clause 13.4 of Section 7:
"The Supplier shall deliver each software module to the Site(s) on or before the Software Delivery Date for that item."
iii) Software Delivery Date was defined in Section 6 of the Agreement:
"the estimated delivery date specified in the Implementation Plan on which the Supplier will deliver a Software Module to the Site(s)."
iv) Clause 13.5 of Section 7:
"The Supplier shall complete installation of each software module at the Site(s) by the Installation Date for that Software Module."
v) Installation Date was defined in Section 6 of the Agreement:
"the estimated date by which the Supplier will complete installation of a specified Software Module as specified in the Implementation Plan."
vi) The Implementation Plan was defined in Section 6 of the Agreement:
"the time schedule and sequence of events for the performance of this agreement set out in Section 2 and in accordance with BMW ITPM."
vii) Clause 8 of Section 2 was headed "Implementation Plan" and stated:
"Refer to Tender Document and appendices. This will be refined further in DP1."
viii) Clause 13.7 of Section 7:
"If any delivery is delayed at the request of, or because of the acts or omissions of RRMC, the Implementation Plan shall be amended to take account of such delay in accordance with clause 9.5."
"The Supplier shall produce and deliver to RRMC monthly performance reports and RRMC shall review the performance of the Supplier on a monthly basis against any Service Levels and any Acceptance Gateways as defined in the Tender Document. "
Termination
"RRMC may reject any of the Deliverables which in its reasonable opinion do not conform with the Specification or Purchase Order or are otherwise incomplete, delivered late or damaged or do not comply with the terms of this Agreement. Title to the Deliverables passes to RRMC on payment."
"If in the reasonable opinion of RRMC the Supplier fails to perform the Services in accordance with this Agreement or to deliver Deliverables by the applicable delivery dates or milestone dates or if RRMC rejects the Deliverables, without limitation to any other of its rights or remedies, RRMC shall have the following rights:
13.11.3 to terminate this Agreement in whole or part with immediate effect by giving written notice to the Supplier;
13.11.4 to refuse to accept any subsequent performance of the Services or Deliverables which the Supplier attempts to make;
13.11.5 to perform the relevant Services itself or purchase substitute services from a third party and recover from the Supplier any loss and additional costs incurred in doing so;
13.11.6 to have all relevant Charges associated to the specific failure to supply the Deliverables or perform the Services previously paid by RRMC to the Supplier under this Agreement refunded by the Supplier.
13.11.8 to hold the Supplier accountable for any costs, loss or expenses incurred by RRMC "
"Upon termination of this Agreement by RRMC for any reason:
26.1.1 RRMC's sole liability shall be to pay the Supplier the proportion of the Charges applicable to the Services carried out prior to termination and any outstanding unavoidable commitments necessarily and solely incurred in performing this Agreement prior to termination that are not reflected in such Charges.
26.1.2 RRMC shall not be obliged to pay any Charges for Services which at the date of termination RRMC is entitled to reject or has already rejected."
"Unless otherwise expressly authorised by RRMC the Supplier shall cease using, return and deliver to RRMC all physical and non physical property that belongs to RRMC including all RRMC's Confidential Information, RRMC Materials, all RRMC Data, all RRMC Personal Data and all other documents and materials and copies thereof in the possession, power, custody or control of the Supplier."
"Upon expiry or termination of this agreement for any reason the provisions of Section 6: Definitions, the following clauses of Section 7: General Terms; 1 (Interpretation) 13 (Charges Payments and Expenses) 22 (Intellectual Property Rights), 25 (Consequences of Termination) 32 (Dispute Resolution Procedure) 39 (Entire Agreement) 43 (Governing Law and Jurisdiction) and any clause expressed to have effect after expiry or termination of this Agreement shall continue to have effect."
" the total liability of either Party to the other under this Agreement shall be limited in aggregate for all claims no matter how arising to the amount of 5m (five million euros)."
"Nothing in this Clause shall limit or exclude either Party's liability for fraud or for any statements made fraudulently or negligently prior to the Commencement Date."
Progress of the project
"This Delivery Package will lay the foundation for the whole project and influence the following Delivery Packages. It defines the execution of next steps based on the already defined detailed Business Requirements and the decided implementation scenario and implementation approach. Thus, it is not independent of but a prerequisite for other Delivery Packages although some of the following delivery packages will start before DP1 is completed. As part of the offer, the service providers are expected to present e.g. the assumed timeline to deliver the project as well as the respective project organisation for each offered implementation scenario. This delivery package will refine the service provider's approach and align the RRMC and service provider project organisation and project delivery model based on the selected implementation scenario
The delivery package creates the following deliverables:
... A refined roadmap and project plan aligned with RRMC and BMW in case of a Hybrid scenario or stand-alone scenario (also in case we only utilise the garage of UCP)
... Decision if VPP.Next will be re-used in the selected implementation scenario
... The target IT landscape detailed between service provider and RRMC / BMW
... Implications to "how" some of the business requirements are delivered in the now known target landscape (no scope change foreseen, but refinement of timing and approach)
... The setup and ramp-up of the project organisation
... Inclusion of first result from a BMW security requirements assessment in the target IT landscape
... Establishment of systems access and data access as preparation step for DP2
... Establishment of the test and development environments and connections for DP2 and following DP's
... Defined Roadmap and sequence for DP4 in regards to the platforms/devices to release the configurator
... Provision of VPP hardware if hybrid scenario includes this (for service provider and for RRMC) to support development and test for DP3."
"Ida summarized that for project steering and audit reasons we need to commonly agree some waterfall gateways that need to be shown and tracked. It does not matter whether we run the actual implementation of the systems
Jan suggests to put together mandatory deliverables as a preparation for the planning document.
Kuby suggested the implementation of a Gateway. Jan supports that idea.
Ida repeated the overall Project approach has to be waterfall as the set-up was discussed with BMW before... "
"The desire to proceed fully with the waterfall approach in this project entails the following risks:
How do we fundamentally want to deal with the shift due to the known issues and their effects in the whole context? (Today we have presented Jan with a possible approach )
How do we want to deal with the budget for 2019? (Enclosed you will find a proposal that I would like to adapt together with you)
How do we want to regulate the acceptance for 2019? We would suggest linking the project plan with the payment plan "
The December Plan
i) an early release of IVT/CMS by 17 February 2020;
ii) Closed Room configurator by 31 March 2020;
iii) the full Point of Sale ("POS") configurator by 27 April 2020;
iv) the Web Visualiser by 18 May 2020; and
v) IVT final and complete POS by July 2020.
"The project is a waterfall fix price project set up as fixed Service Agreement. The actual Software Development can proceed in an agile approach, therefore a tailored Quality Plan with respective ITPM Milestones will be set up by RRMC. The payment schedule will have to be adapted to this tailored QA Plan.
The original time plan for the deliverables as stated in the tender can no longer be met. An alternative deliverable plan was presented by TPLSN. The feasibility of this plan needs to be checked and confirmed with all stakeholders (business, IT, third parties) (TPLSN). Feasible plan needs to be presented and agreed in the Steering Committee 11/12/19 (RRMC).
The plan seems very ambitious therefore the project needs to pick up speed and the schedule needs to be very closely managed and steered. Any risk are to be flagged immediately.
An overview of the possible alternatives with cost estimation for required Dealer Infrastructure will be provided (TPLSN) and presented in the Steering Committee (RRMC).
Business Requirements need to be discussed and fixed in order to not jeopardise the plan further. Any requirements which could increase the risk of late delivery have to be flagged immediately.
Following requirements need to be fixed with business colleagues before the Steering Committee: Digital Take Home, Content of visualiser (as ordered), alternative visualiser for earlier SOC.
Adherence to BMW Group rules and regulations (e.g. ITPM, IT Security) will be ensured for all contracted deliverables (TPLSN). Where allowed by BMW Group rules and regulation a tailored approach can be agreed (before substantial work has been executed) with the Rolls-Royce project management to increase efficiency and deliver solutions in time with the business milestones."
i) early release of IVT/ CMS by 2 March 2020;
ii) Closed Room configurator by 9 April 2020;
iii) full POS configurator by 25 May 2020;
iv) Web Visualiser by 16 June 2020; and
v) IVT final and complete POS by 17 August 2020.
"After the December Implementation Plan had been approved, both we and Topalsson proceeded on the basis that the milestones included within it were agreed, contractual and binding. At no time did Kuby or anyone else from Topalsson indicate to me that they had not agreed to the December Implementation Plan, or that they saw it as informal or non-binding. Had they done so, I would have immediately discussed this with them and ensured that we had a formal agreement in place.
The first important milestone from the December Implementation Plan was to achieve the Business Proposal gateway, my memory of this is confirmed by reviewing an email of 12 December 2019 sent by Jan to internal colleagues from RRMC and to Topalsson on that date. The Business Proposal was an agreed step in the December Implementation Plan, the purpose of which was to provide an overview of the project, the requirements and targets of the project, its key features and timelines, and any issues or risks identified, to stakeholder teams within the wider business on whom the project would have some impact."
"3.1.2 Delivery Package 1:
Analysis and Alignment This Delivery Package will lay the foundation for the whole project and influence the following Delivery Packages. It defines the execution of next steps based on the already defined detailed Business Requirements and the decided implementation scenario and implementation approach. Thus, it is not independent of but a pre-requisite for other Delivery Packages although some of the following delivery packages will start before DP1 is completed. The outcome of this Delivery Package is a profound target picture for all relevant processes, systems, and business requirements etc. of the new configurator landscape delivered in the selected and aligned implementation scenario.
Delivery Package 1 has already been conducted and this Business Proposal document contains the resulting solution approach for the project.
3.1.3 Delivery Package 2: Initial Back-End and Rule-Engine
This Delivery Package will lay the foundation for the work on the system and process landscape. Thus, it is partially dependent on the Analysis and Alignment Delivery Package 1 and a prerequisite for other Delivery Packages.
The package should include the development of the configurator back-end and its integration into the overall configurator landscape. This should include interfacing a back-end service into the necessary existing BMW/RR data services (i.e. product and emission data), establishing the necessary functional landscape (i.e. cloud based microservices) and development of the core configuration engine (i.e. data generation and rule engine).
The goal of DP2 is to deliver the configurator back-end and rule engine required to implement DP3 but not for all requirements of subsequent delivery packages.
DP2 has to be completed before DP3 can be completed, but DP3 can start before DP2 has ended.
DP2 does includes the scope to lay the foundation of DP3 and DP10, it does not contain the necessary changes required by other delivery packages. In case the configurator back-end needs to be extended e.g. for pricing integration or analytics, the necessary configurator back-end changes are considered scope of the respective delivery package.
3.1.4 Delivery Package 3: Point of Sale Configurator
This Delivery Package will lay the foundation for any configuration solutions at dealerships. Thus, it is not independent of but a prerequisite for other related Delivery Packages.
Additionally it is expected that the configurator control front-end for the 3D image service will lay the foundation for all other configurator front-ends from a technical and a general user experience approach to maximise every possible synergy but without detrimental effect to the use-case specific requirements for each configurator front-end. Therefore RRMC assumes that the control front-end will not be a native app but a standardised web interface. The web interface needs to be able to be used via a normal desktop or via a large screen tablet (IOS, Android, Windows 10) depending on the actual customer situation.
The Point of Sale Configurator provides a configurator solution for Rolls-Royce Motor Cars dealerships. It must provide the functionality to fully configure a car, which must be buildable and must provide high definition photorealistic vehicle imagery. As basic functionality there must be the possibility to save and handover the configuration to different processes (e.g. ordering configurator), thus reducing the risk of lost configurations.
The Point of Sale configurator must offer a superior user experience in keeping with Rolls-Royce CI and brand strategy, regardless of the implementation scenario. The emphasis should be on an organic and flexible configuration flow, with consideration of different use cases based on time availability of each user.
The Point of Sale configurator should include a dual screen approach including a fixed customer facing configurator front-end, and a mobile control front-end. The control front-end, should be capable of driving the customer facing configurator, as well as working independently. The control front-end should include an Expert mode (for dealer use), allowing access to expert options/features, and a simplified navigation approach for faster configuration.
3.1.10 Delivery Package 10: 3D-Data Preparation Process
This Delivery Package will lay the foundation for a new visualisation engine. Thus, it is not independent of but a prerequisite for the whole new configurator.
The 3D-Data Preparation Process provides the basis for photorealistic visualisations. It must provide the functionality to visualise car configurations in the highest quality standards. Additionally, the specific Rolls-Royce Motor Cars flexible colouring approach must be integrated.
Functionality is required to allow the business to validate the imagery outside of the configurator. This is to ensure the imagery is accurate and correctly mapped prior to releasing to the live configurator. This tool is referred to as the Imagery Validation Tool throughout the document."
"The following release schedule is foreseen for the project:
"We are very pleased to announce that the gateway participants have released the deliverables, albeit with an amber traffic light
We are planning to provide an updated Business Proposal Document on 28/01/2020 including adjustments to the comments provided during the guided review session. Most of these changes have already been pre-aligned with the originator "
"The plan combines the waterfall approach + ITPM artefacts with the Agile Dev approach and the delivery of features + releases."
"I see some light at the end of the tunnel with the people who are coming in now, but we still won't be able to keep our promises this sprint Realistically, we would have to say that we can't meet the deadlines and that we will have to postpone for two months to give ourselves some time. So we rush from deadline to deadline, deliver something that neither we nor the customer are satisfied with "
"We have already sat together several times and expressed concerns by RR regarding the timetable and status of implementation. On 20.12 we agreed that you would set up measures to bring the project forward significantly
We brought up the risk that you refer to regarding User Stories on the RR side repeatedly in November and December and TPLSN proposed making up for the lack of DoR status during the course of the sprint and that the programming can continue at your risk.
We were assured that this is not a problem. The current statement in this respect is then also surprising and not really comprehensible... Unfortunately, there is no buffer anymore in the timetable, so please do not wait until the problems actually occur. In my opinion, pro-active management is necessary "
"As discussed on 20 December and confirmed again this week in a meeting with Kuby, there is no point in discussing a new billing plan if we do not have an agreed and firmly promised feasible delivery schedule and the deliveries then also come according to plan "
" based on the current desired delivery approach "Waterfall", the corresponding milestones cannot be combined with our development approach "Agile". We have to indicate that this approach represents the following risk to deliver the POS Configurator product to the desired Milestones
We are convinced that together we can achieve RuleEngine / POS Configurator / Web Visualizer to the Business Milestones in a different collaboration model and approach.
Therefore, we propose a re-structuring workshop with you in the near future to work out and agree on appropriate measures."
"Thank you very much for the advice and the suggestion. We are currently investigating what other possibilities we have and will also take into account the results of the stocktaking. Next week there will be a vote on this at division head level. Could you please tell us specifically which elements of the waterfall approach are preventing you from achieving the milestones and in what way they are preventing you or cannot be combined with agile implementation?"
Valentinitsch Audit
"Due to the limited time available, it was not possible to fully review (analyse) all the documents provided. Possible misinterpretations and misjudgments cannot therefore be ruled out
In addition to the above-mentioned on-site meetings, there were continuous telephone consultations and web meetings with I Biot and/or K Topal.
Interviews with the development team and POs did not take place due to time constraints."
"There is only two options left as far as I understand
1. Preparing the phase out and termination of the current contract but safeguarding with TPLSN in a stripped down contract the following:
a. The provision of 3d models for RR21/RR22 and current models as input for an image server and other stakeholders that need Imagery (marketing, type approvals etc)
b. The integration of a 2d image service to replace CoSy for defined systems until a new project/provider is established to take over
2. Resetting the project with the plan to continue the partnership with the following objectives and premises
a. Objectives (objectives i-iv are to be agreed now with fixed scope and fixed timing, objectives v-vii timing will probably need the detailing of user stories and proper sprint planning, assumed not to be possible for TPLSN in their current state before end of May?
i. Go Live of IVT pre-release in March
ii. A workable solution for the closed and open rooms fulfilling the RR requirements
iii. A possible re-use of the closed room solution for China dealers
iv. 2D image server live and integrated in RROC for SOC in early May (all models)
v. A first release of the PoS integrated solution rolled out globally sometime during summer?
vi. A second release of the PoS, CMS, IVT release in autumn? Catching up on the missed userstories from DP2, DP3, DP10
vii. A third release of the PoS,CMS integration solution for DP6, DP7 preferably this year but likely to move to 2021.
b. Premises
i. The discussion about the delivery model has to stop immediately, the project team works as agreed without interference with the new objectives and agreed timing.
ii. Kuby steps back from all operative project management activities
iii. An autonomous overall project manager is established by TPLSN that has the authority to take all project decision as needed
iv. The project organisation on TPLSN side is restructured to deliver according to agreed approach
v. RRMC gets full transparency on progress of project activities timely and without fighting or arguing. Endangered deadlines are reported before they happen.
vi. Decisions are taken with RRMC and not by TPLSN trying to second guess what our priorities are
vii. The payment plan will be based on actual delivery of the objectives and will be measured based on target achievement on requirements/user story level within the agreed release "
i) Scenario 1 - Safeguard Pre-Releases and provision of China Fallback (the basic POS needed to be available for the China market to penetrate the IT firewall around China). Shift of further releases based on re-evaluation of efforts and complexity.
ii) Scenario 2 - Safeguard Pre-Releases and provision of China Fallback Shift of further releases. Split-up of PoS Release and Early PoS Release including Dealer Garage and SMS Integration.
iii) Scenario 3 Safeguard Pre-Releases and provision of China Fallback Shift of further releases. Split-up of PoS Release and Early PoS Release excluding Dealer Garage and SMS Integration.
The March Plan
"Delivery of already started products was confirmed to go ahead as planned:
Closed Room configurator: Go live 1/4/2020
IVT: Go Live 09/03/2020
CRIS: Go Live 23/04/2020
3D Imagery as planned in December to the agreed milestones (plan attached).
Based on these milestones a proposal for a payment plan will be send to you next week
The new plan provided to us on 15th February cannot be accepted as this deviates significantly from the compromise plan we have agreed and confirmed on 11th December
Measures will need to be defined to bring the deliveries forward to the agreed compromise plan from 11th December. Your achievement of completing these products within the milestones is a condition of our ongoing contractual relationship. Following successful roll-out of these products (first assessment 1st April after delivery Closed Room event) we will review the future milestones and deliverables of the plan and decide on the next steps, adjusting where necessary and appropriate."
"The working method or approach of delivery (for example: agile vs waterfall) is free to choose by the bidder as long as the Business Requirements in the specified Delivery Packages are met. However, the bidder must outline a quantity structure how the project timeline could look like. In case an agile delivery model is proposed, this should be based on the information given in appendix ITPM Agile Project Phase Approach
Since you always get a product after each sprint in an agile way of working, we can consider the output from a sprint as a fixed trade. A delivery package would then be composed of the individual sprints/trades.
There already have numerous deliveries that are a basic requirement for a configurator: All 3D data, Rejections of 3D data already provided to agencies; All Rolls-Royce; A RuleEngine that generates a correct buildable vehicle, Complete design concept for POS, Web; User stories necessary for implementation
We guarantee to secure and deliver: IVT, Closed Room Configurator, CRIS according to the replanning plan that we sent on 15 February "
"We write further to our mail dated 5th March in which we confirmed the next steps for the following weeks and informed you that the achievement of those milestones was a condition for our ongoing contractual relationship. We also informed you that we would be reviewing progress on 1st April.
Despite our repeated requests, no improvement on performance has been achieved and almost all milestones have been missed and not delivered on time
Topalsson GmbH remains in breach of its contractual obligations to deliver in accordance with the timescales required by Rolls-Royce Motor Cars
We have lost confidence in the ability of Topalsson GmbH to deliver the project, achieve the targets, and adhere to the business milestones
We see 2 possible scenarios for the conclusion of the current project:
Scenario 1 would be to stop the current project with finishing DP10 activities by the end of April.
Scenario 2 would be to continue basically with the delivery of DP10 planned for this year: Imagery including 08/20 and 12/20 measures as well as the IVT and the delivery of CRIS from DP4 by 27th April as planned
We will organise a meeting to discuss and agree on the preferred scenario and to discuss the financial impact "
"Ida explained that 2 scenarios have been proposed to Kuby how to proceed in the Project. This was planned to be discussed this morning but the meeting did not take place.
In order to secure the feasibility of both scenarios (until a decision is taken) we need to stop all activities not related to both scenarios e.g. Closed Room. All manpower will be focused on the Release "CRIS" and open topics from DP10 (e.g. IVT, DTTE, 3D-models) to deliver these functionalities in time "
" we strongly disagree with your assertion that Topalsson would be or has been in breach of the Service Agreement We are in no position to accept ending or freezing the contract at this point and find the demand to agree on this on short notice to be a calculated attempt to compel Topalsson into accepting significant losses which will leave the company in a financially tenuous situation. "
Termination
"This is formal notice terminating the contract between Rolls - Royce Motor Cars Limited ("RRMC") and Topalsson GmbH ("Topalsson" ) dated 11 October 2019, with immediate effect.
Due to the persistent failure by Topalsson to deliver in accordance with the milestones agreed in the delivery programme (proposed by Topalsson on 27th November and finally accepted in the common Business Proposal) Topalsson is in breach of clause 5.8.
"Time shall be of the essence regarding any date for delivery by the Supplier of any good or service specified in this Agreement and the Completion Date."
Time is of the essence for performing an obligation is a condition of the contract and so any failure to comply with the obligation constitutes a repudiatory breach by Topalsson. The remedy at common law for this breach is that RRMC has the ability to terminate immediately in addition to any other remedies available both in contract and at common law.
We request that you cease work on this contract immediately and do not incur any further costs. We shall be in touch in the next week to discuss the post-termination provisions, handover of materials and other ongoing contractual obligations. Please ensure you are available for a conference call with Laura Clowsley and Ida Biot as a priority."
"We note receipt of RRMC s letter dated 16 April 2020 (Notice) purporting to terminate the contract with Topalsson. We have discussed this Notice with our legal counsel. Topalsson hereby formally notify RRMC that we reject the Notice, and we advise RRMC that:
1. Topalsson consider that RRMC do not have a right to terminate the contract, neither at common law as purported in the Notice, nor in accordance with the contract itself;
2. Topalsson are not in breach of failing to deliver in accordance with agreed milestones as suggested in the Notice. RRMC and Topalsson have never agreed contractually or otherwise on the milestones of 28 November as suggested in the Notice, Topalsson are therefore not in breach of delivering to these as they are not agreed;
3. RRMC have not validly terminated the contract per its terms, and RRMC have willfully abandoned the contract and have repudiated it by doing so. Any material or persistent breach that is remediable requires a notice to Topalsson and an opportunity for Topalsson to remedy the breach within 30 days under clause 25.3.1. The breach would have to be factual and on a contractually agreed deliverable by Topalsson- the 28 November items are not agreed as stated in 2) above and there Topalsson are in any event not in breach of these items;
4. The contract provides in clause 33 for a dispute resolution procedure, which RRMC have not followed by serving the Notice. We require that RRMC follow the process as set out in clause 33 given this dispute scenario; and
5. Topalsson do not regard the contract as terminated given this incorrect Notice by RRMC and we consider that the contract continues and Topalsson hereby affirms the contract.
If RRMC do not revoke the Notice, repudiating and abandoning the contract by RRMC, Topalsson will instruct legal counsel to take all necessary action against RRMC including for damages suffered by Topalsson as a consequence of RRMC s repudiatory breach. We invite RRMC to withdraw the Notice by no later than Wednesday, 22 April 2020, failing which it will be necessary to escalate matters. In the meantime, all of Topalsson's rights are fully reserved."
" There were delays by Topalsson from the outset. The relevant Implementation Plan for current purposes was delivered to RRMC on 22nd November 2019. RRMC and Topalsson discussed and agreed a number of small changes that resulted in a final, agreed Implementation Plan. Topalsson published a final version of the plan on the project Panama drive as confirmed by Topalsson's email of 3rd December 2019. This plan was presented to RRMC Steering Committee on 11th December 2019 where it was accepted as final. Subsequently Topalsson reported progress to RRMC against these targets in its status updates presented at weekly management status meetings.
By clause 13.7, it was agreed that if any delivery was delayed at the request of or by reason of RRMC's act or omission, the Implementation Plan would be amended to take account of such delay. No such amendments have been made.
Topalsson has failed to deliver the Deliverables and Services in accordance with the contractually binding milestones in the Implementation Plan. These late deliveries are documented in the weekly Status Reports delivered by Topalsson. Topalsson has failed to deliver as follows:
9 March 2020 Technical Go-Live IVT (Image Validation Tool)
1 April 2020 Technical Go-Live of the Closed Room Configurator (incl. basic solution for CMS with Excel import)
23 April 2020 Technical Go-Live CRIS (CoSy replacement)
Time was of the essence in relation to the above milestones. That was made abundantly clear in the Contract but also in RRMC's email on 5 March 2020 in which it was stated: "Your achievement of completing these products within the milestones is a condition of our ongoing contractual relationship."
Topalsson's failure to achieve the milestones by their respective milestone dates and in respect of which time was of the essence is a breach of the Contract which goes to its root and deprives RRMC substantially of the contractual benefit to which it was entitled.
Without prejudice to RRMC's Notice of Breach dated 16 April 2020, RRMC hereby accepts Topalsson's repudiatory breach of the Contract. The Contract is now at an end.
Without prejudice to RRMC's common law right of termination and its acceptance of Topalsson's repudiatory breach, RRMC hereby gives notice that the Contract is terminated with immediate effect pursuant to clause 13.11 and clause 13.11.3 of the Contract
Time was of essence in relation to the delivery of the Deliverables under clause 5.8 as appears above. Topalsson has failed to deliver the Deliverables in accordance with the Implementation Plan as set out above. The Contract is now terminated with immediate effect in accordance with its terms.
We will be writing in due course in relation to the consequences of termination, meanwhile, all rights are reserved."
"No implementation plan in Tender Documentation, there is only anticipated timeline starting from 1 July (in the appendices). DP1 was never completed and finished no Acceptance of DP1. There was a project plan but that plan was not agreed nor accepted by RRMC. No knowledge of what was presented at steering committee by RRMC. No feedback provided by RRMC on outcome of steering committee. BMW ITPM not clear which guidelines applied
Several amendments to timelines have been made due to delays from RRMC side . Multiple times re-planned due to requests of RRMC to hold the Business milestone - ClosedRoom. No agreed implementation plan and no feedback on plan from 28 November 2019 nor replanning from 15 February 2020.
IVT Technical Go-Live was achieved on 19 March 2020 after delays due to BMW IT.
Closed Room Installer and Support subsequently delivered from 18 March 2020 until 20 April 2020. UAT blocked by Jan-Hendrik Hoffmann. Cancelled with email from Ida Biot 7 April 2020.
CRIS delivered and installed on BMW Premises on time (proof screenshot 21 April 2020) ... "
" the Agreement was not effectively terminated by either the First Termination Notice or the Second Termination Notice and RRMC was therefore in repudiatory breach of the Agreement as a result of its wrongful termination
Topalsson therefore elects to accept RRMC's repudiatory breach and hereby terminates the Agreement with immediate effect "
Proceedings
The Issues
i) whether Topalsson was obliged to deliver and install the software in accordance with an agreed programme or within a reasonable time;
ii) whether Topalsson achieved any of the milestone dates (as initially agreed or revised), or carried out its obligations within a reasonable time;
iii) whether Topalsson was impeded in its performance, or prevented from performing its obligations by RRMC;
iv) whether RRMC was entitled to terminate under clause 13.11.3 of Section 7 of the Agreement or at common law on the ground of Topalsson's repudiatory or anticipatory breach, or was in repudiatory breach by giving the Notices of Termination;
v) whether Topalsson induced RRMC to enter into the Agreement by making false representations in relation to Audi;
vi) quantum of the claims and counterclaims;
vii) whether either party is entitled to an order for delivery up or destruction, and/or declaratory relief in respect of Deliverables, Supplier Software and Bespoke Software.
Factual witness evidence
i) Kubilay Topal, the founder and CEO of Topalsson;
ii) Jens Wiedow, Topalsson's Senior Project Manager, who worked on the project from August 2019 to the end of the project;
iii) Simon Kottenhagen, the Senior Product Owner on the project from February 2020 onwards;
iv) Hans Mokrusch, a Certified Business Economist who throughout the period of the project acted as Topalsson's Chief Financial Officer;
v) Oliver Teschner, a employee of Audi AG, working in the Customer Care and the Strategic Portfolio IT-Requirement Management team.
i) Ida Biot, employed by BMW as Head of Process Management, who set up the project and as Project Lead ran it for RRMC until termination;
ii) Jan-Hendrik Hoffmann, a manager in RRMC's Process Management and Integration Team;
iii) Matthew Scott, employed by RRMC as a Process Integration Manager and Product Owner of its configuration landscape;
iv) Paul Comper, RRMC's Head of Current Vehicle Management;
v) Juergen Brzank, Chief Finance Officer of RRMC;
vi) Alexa von Schwichow, a freelance project manager retained as the Project Manager by Topalsson in August 2019;
vii) Bernd Eigenstetter, who supervised RPC's design team;
viii) Jan Schemuth, the CEO of RPC;
ix) Scott Litster, sales support manager at RRMC, responsible for the visual representation of vehicles within the pricing and online ordering configurators;
x) Lothar Dannecker, a freelance contractor, who worked on the project from early November 2019 to support the PMO and test management;
xi) Alexander Weise, who joined Topalsson as a freelance contractor at the end of February 2020 as 'DevOps Engineer';
xii) Johann Valentinitsch, an independent management consultant and author of the January 2020 audit report on the project;
xiii) Raj Sharma, employed by BMW as head of Dev Ops and Market Integration Manager;
xiv) Henrik Wilhelmsmeyer, RRMC's Director of Sales and Marketing;
xv) Dr Timo Poser, RRMC's CFO who took over from Mr Brzank on 1 February 2020;
xvi) William Gellatly, head of Sales and Marketing, Bespoke at RRMC;
xvii) Rhodri Good, Sales and Marketing at RRMC.
Expert evidence
i) Mark Britton of PA Consulting Group, who provided a first report dated 20 July 2022 and a response report dated 16 September 2022, addressing IT issues;
ii) Geoff Mesher of Tempest Forensic Accounting UK LLP, who provided a report dated 28 July 2022 on the quantum of Topalsson's claims.
i) Dr Gillian Hunt of Hunt Lancaster Limited, who provided a first report dated 17 June 2022 and a response report dated 16 September 2022, addressing IT issues;
ii) Chris Osborne of FRP Advisory Trading Limited, who provided a first report dated 17 June 2022 and a second report dated 16 September 2022 on the quantum of RRMC's claims and Topalsson's claims.
i) IT experts' joint statement dated 7 October 2022, limited to the issues covered by both experts;
ii) Forensic accountancy experts' joint statement dated 23 September 2022, limited to a consideration of Topalsson's claims.
Issue 1 Time obligation
Implementation Plan
The December Plan
"complete the Services and deliver the Deliverables on time and in full and by any applicable milestone date or delivery date, if delivery dates or milestones are not specified, within or by any reasonable delivery date or time period that is specified by RRMC."
"Time shall be of the essence regarding any date for delivery by the Supplier of any good or service specified in this agreement and the Completion Date."
The March Plan
i) 9 March 2020 - Technical Go-Live IVT (Imagery Validation Tool);
ii) 1 April 2020 - Technical Go-Live of the Closed Room Configurator (including the basic solution for CMS with Excel import); and
iii) 23 April 2020 - Technical Go-Live CRIS (CoSy replacement).
i) IVT Pre-Release at the beginning of March 2020;
ii) Closed Room Pre-Release at the beginning of April 2020;
iii) CRIS Release at end of April 2020 (SOC 4 May 2020).
"Your achievement of completing these products within the milestones is a condition of our ongoing contractual relationship."
Issue 2 Compliance with time obligations
Technical Go Live
"For a successful completion of each Delivery Package in general, the core deliverables and results of the Delivery Package need to be documented in a suitable file format and accepted and signed off by the Rolls-Royce Motor Cars project lead or a nominated representative. The specific documents and the aforementioned file format will be aligned with the Rolls-Royce Motor Cars project lead at the start of each Delivery Package.
Additionally, for all development related Delivery Packages (i.e. the Delivery Packages: 2, 3, 4, 5, 6, 7, 8, 9, 10, 13), the following acceptance criteria apply:
The deliverables per Delivery Package have to conform with BMW ITPM standards if not specified differently. Additionally, all test types (e.g. Approval test, security test, load test) and test levels (e.g. subsystem test, system integration test, acceptance test) must be successfully completed for the Configurator Development and in System Transformation. This means that no blockers or high defects may occur. The ITPM () as well as the standards defined by the BMW group () serve as the basis for the acceptance and execution of the tests. The tests must be documented according to the specifications in the ITPM as well as accepted and signed-off by the Rolls-Royce Motor Cars Project lead or a nominated representative. "
"1.2.3 Development and testing will follow an agile approach that sits between the Model 50 and Model 75 of the BMW test handbook Test Design and (partial) Integration Testing is done during the sprints (similar to Model 75), but no formal UATs will be executed during the sprints Final system integration (SIT) and user acceptance (UAT will be performed before Go-Live (as in Model 50).
2.4.1 The project is following an agile approach based on "model 50". The project is based on an agile approach in terms of roles (Product Owner, Agile Coordinator / Scrum Master, Agile Team), but the Test Execution for the Test Levels "System Integration Test (SIT)" and "User Acceptance Test (UAT)" is planned after agile sprints have been completed. In consequence the Test Processes and Test Roles of the project follow majority an classical role model and partially an agile approach - meaning the project is following a tailored waterfall approach with agile elements for SIT and UAT testing."
i) Topalsson was subject to a contractual obligation to achieve successful completion of testing, including SIT and UAT, in respect of each deliverable within a Delivery Package, and to produce test documentation which was accepted and signed off by RRMC in accordance with the ITPM standards in the ITT appendix.
ii) The test guidelines that applied to the project set out in the ITT and appendices included a requirement for SIT and UAT to be completed before Go-Live was achieved.
iii) The test strategy and procedure documents produced for the project included a requirement for SIT and UAT to be completed before Go-Live was achieved.
iv) The December Plan specified that SIT and UAT must be completed for each release before Technical Go-Live could be achieved, followed by Business Go-Live.
v) The February 2020 proposal by Topalsson to revise the December Plan sought to reduce the scope of the delivery releases and to postpone the dates by which releases would be delivered but did not seek to change the above sequencing or the requirement for SIT and UAT as a pre-condition to achieving Technical Go-Live.
"1. We agree that it is important for software to undergo a full range of tests. This range includes functional tests where:
(i) Modules of code are tested individually against their designs (Unit Testing).
(ii) The interworking of these modules of code is tested against the design for how they should interwork (Module Integration Testing).
(iii) The testing of the system as a whole against the functional specification of the system (System Testing).
(iv) The system is tested to confirm that it works as designed with the systems to which it interfaces (System Integration Testing).
(v) The system is tested by users to confirm that it delivers the business requirement (User Acceptance Testing)."
i) Critical Severity: The defect is blocking key functions or it may cause a system crash with possible data loss and / or serious inconsistency. System cannot be used in this form. Priority: Testing or project delay affects major parts of the project deliverable (e.g. several tests are blocked). If needed, a separate fix will be delivered/tested.
ii) High Severity: A fundamental function is defective or a major requirement was not implemented correctly. Fundamental function cannot be used. Priority: Testing or project delay affects a key functionality but this can be mitigated with a workaround. Fix will be delivered with the next available slot (e.g. sprint).
iii) Medium Severity: A (sub-)function is defective or a requirement was implemented incorrectly. System can be used with restrictions. Priority: Testing or project delay is limited to the linked test case(s). Defect Fix will be bundled and delivered according to plan (e.g. within the next two sprints).
iv) Low Severity: A marginal variation was observed System can be used without restriction. Priority: Testing or project delay unlikely. Defect will be fixed when time is available.
i) 100% test cases executed.
ii) 85% test cases passed.
iii) No critical/high defects.
iv) No security defects (vulnerabilities) with Severity critical or high or medium, if they fall under the scope of [IT Regulation: Security Testing].
v) Unit Test Reports for each sprint (overall for each release).
vi) Release Notes - Actual release notes & the release notes specific to the start of SIT with reference to the defects fixed - with versioning of the software delivery or similar.
i) 100% test cases executed.
ii) 85% test cases passed.
iii) No defects with Severity critical or high. Weakened criteria: impact of all critical/high defects is analysed and accepted by business and operation (does not apply to security defects - see next point).
iv) No security defects (vulnerabilities) with Severity critical or high or medium, if they fall under the scope of [IT Regulation: Security Testing].
v) 0 defects with the evaluation Medium Weakened criteria: impact of all critical/high defects is analysed and accepted by business and operation (does not apply to security defects - see next point).
vi) Defects with the evaluation Low must be eradicated and registered by the next follow-up release at the latest.
vii) Error-free deployment has been effected in test and integration.
viii) Pre-Integration tests and Integration tests have been successfully performed.
ix) Defects that have occurred have been eradicated and documented.
IVT
"Functionality is required to allow the business to validate the imagery outside of the configurator. This is to ensure the imagery is accurate and correctly mapped prior to releasing to the live configurator
Deliver an Imagery Validation Tool - a front-end view of all 3D/2D imagery generated from the visualisation engine. The tool should show all option/colour code mapping to the relevant image. No master data rules are required (e.g. no restrictions on option or colour combinations) "
"A tool is required to allow the business to validate the imagery (2D and 3D) outside of the configurator. This is to ensure the imagery is accurate and correctly mapped prior to releasing to the live configurator. The tool should provide a front-end view of all imagery generated from the visualisation engine.
The imagery validation tool should allow a user to review the mapping between model code, option code or colour code to its related imagery. This is [to] allow the user to validate the imagery is mapped to the correct product master data.
Due to the sensitive nature of the vehicle imagery, access to a validation tool must be secure and restricted to dedicated users."
i) Pre-release IVT/CMS (referred to as early review) would be delivered through Release 3a by 2 March 2020; and
ii) IVT/final/CMS/3b/4b would be delivered through Release IV by 17 August 2020.
" they needed more support than was usually expected because they couldn't get it right, and they should have basically educated themselves on the reverse proxy and web set-up earlier in order to avoid these problems that late in the project, shortly before go-live. So they hadn't done that, and yes, when they then needed support, it then took some time."
Closed Room
i) Pre-release Closed Room (referred to as Closed Room Demo) would be delivered through Release 3a by 9 March 2020; and
ii) Full POS configurator would be delivered through Release 3a by 25 May 2020.
"The Closed Room configurator was a workable solution of the Point of Sale configurator for the new Ghost model. It was a configurator for only one model of car which was developed for the Closed Room Event and it was never intended to be a fully integrated software solution, in the same way that the Point of Sale configurator was intended. Instead, it was supposed to be used autonomously on specific hardware. It therefore had a reduced scope in terms of functionality (i.e less configurability) than the Point of Sale configurator."
"We had been expecting Topalsson to deliver an installer program with Closed Room which would entirely automate the installation process (this is what they had proposed as part of their February re-planning), but the version of Closed Room which it uploaded on 18 March 2020 did not contain an installer. Instead it consisted of a number of different files all of which had to be installed manually.
I had a lot of difficulties with this process. The laptop which had been supplied to us by Topalsson for this purpose was brand new and had nothing pre-installed on it, not even the correct operating system, so the first thing I had to do was install Windows Pro, which Topalsson gave me a license key for. Once that was done I had to download the Closed Room files from RRMC's servers onto the laptop locally
Marco Weiss of Topalsson began assisting me in trying to get Closed Room installed I could see straight away that this was not a finished version of Closed Room, but rather the current state of development. The software kept crashing, some of the imagery was not working and there seemed to be a lot of missing content, although I did not have a detailed look because there seemed to be a lot of bugs
Some days later, on 25 March 2020, Marco advised me by email that a new version of Closed Room had been uploaded to RRMC's project drive and was ready to be installed Further versions were then uploaded on 1 April and 3 April 2020.
At this stage I decided to do a complete uninstall of the first version and to reinstall the latest version, because I wanted to see whether Topalsson had now delivered an automated installer as had been agreed, and whether the process would be smoother. I found that this version still did not include an automatic installer, and I needed support from Marco to complete the uninstall and reinstall.
Unfortunately, I was never able to get this version of Closed Room installed and functioning on the laptop "
i) 60 user stories were "In Review" and ready for testing; 16 user stories were "In Progress" that is, still under development;
ii) 37 Stories were covered by test cases but 39 Stories were not yet covered by test cases;
iii) SIT testing had produced 71 pass and 35 fail results, with 14 outstanding;
iv) 24 defects had been identified, of which 4 had been resolved;
As a result, the UAT entry checkpoint planned for that date could not be achieved.
"Blocker:
4 User Stories that are still in progress in the ATC
Final description of technical/operational test cases not complete, documentation and execution in XRay also still pending. "
"Pre-release Closed Room
Exit SIT still delayed.
Documentation / execution of technical test cases in JIRA expected for tomorrow SIT exit and UAT cannot be scheduled without these.
Topalsson will provide test planning."
"Installer was successful. We would need to run it on a clean computer as a next step. ...
DTE takes approximately 10mins to start up
DTE cannot be closed easily- can't access other applications during this time
DTE is approx. 0.25 sec ahead of control front end visualisation.
Sometimes the imagery on control frontend doesn't update (out of sync with DTE). The navigation still works but imagery is static.
Hotspots don't always load/appear after moving the vehicle (360 view) or selecting camera
Sometimes the interior lighting doesn't readjust correctly when moving to interior or changing backgrounds. You end up with some odd colours and textures.
It is often difficult to open the selection menu from the hotspots (they don't stay open)
If you hold finger over a selection for too long the ipad screen shot functionally kicks in and redirects away from the front-end. The config session is then lost!
Colour tile remains against a colourable feature even if it is removed from configuration (looks like the feature is selected)
Timeout I had a few instances of timeout when left on idle
You cannot deselect features!"
"a. Much of the necessary image and graphical data required is missing or wrongly configured. This means that the various colour and configuration options are unusable. Issues with camera paths linked to hotspots also mean that switching views or activating hotspots leads to some very peculiar visual effects. For example;
i. on first display the car changes colour and the doors open and close;
ii. activating the boot open hotspot causes the side door to open and the view to switch to the interior;
iii. changing orientation usually ends in a 'jump to a new position.
b. Activation of menus and hotspots is generally unreliable. It can take several taps to successfully activate a hotspot and some menus cannot be dismissed once activated. This makes navigation very awkward because iPad features, such as screenshot and copy/paste, have not been disabled, which leads to some very unexpected results. These issues suggest that the app had not been tested using a real iPad since these 'touch' related issues are not experienced when simulating an iPad through a web browser.
c. The Summary functionality is clearly a work in progress with multiple issues, in particular the summary does not reflect changes that have been made to the configuration."
"Q. At this stage, 1 April, it is also clear, isn't it, that Topalsson was still developing and fixing Closed Room on and after 1 April; you are aware of that?
A. Yes, they were still working on it. There were defects to be fixed.
Q. it would never, ever have exited UAT in the state we have just seen.
A. I think there would undoubtedly have been defects that were found and needed to be fixed during UAT, as there always are."
" we have accumulated a high amount of technical debt over the last couple of months. This technical debt can be found in almost every part of the software
As this technical debt poses huge risk for future development and documentation of quick fixes and workaround is very limited to non-existing we should put focus on stabilisation and refactoring our work. This will involve fixes, code deep diving, reworking, retesting, etc."
CRIS
"1. We agree that a version of CRIS had been installed on RRMC's AWS at termination on instances intended for use in SIT.
2. We agree that this installation does not function as intended, probably because the DTE instances that were required and had been deployed are no longer present. We agree there is no evidence that CRIS achieved Technical Go-Live on or before 23 April 2020.
3. We disagree whether CRIS could have achieved Technical Go-Live on or before 23 April 2020 had Termination not occurred."
"Currently we are far behind the deadlines And we have no time anymore. We need you to fix all these by tomorrow Latest 12am that we have any chance to deliver the product to our client."
Conclusion on status at termination
i) Topalsson failed to achieve Technical Go-Live in respect of early IVT by 9 March 2020;
ii) Topalsson failed to achieve Technical Go-Live in respect of the Closed Room configurator by 1 April 2020 or thereafter;
iii) Topalsson failed to progress the sprints and testing so as to be able to achieve Technical Go-Live in respect of CRIS by 23 April 2020.
Issue 3 Reasons for delay
Delays at the start of the project
Agile v Waterfall methodology
Lack of resourcing and planning
" Key roles were not filled (at the right time) or they have been constantly affected by loss or replacement of staff.
This staff turnover makes it impossible for expertise, responsibilities, and processes to be sustainably built up with the necessary stability.
Specialist managers with the necessary expertise are lacking (or the expertise cannot be built up) or specialist knowledge is concentrated with Florian and you, and due to our own knowledge bottleneck situation with existing expectations, it cannot be made available as necessary.
Steering and managerial rolls cannot be carried out to the extent that is necessary
For 7 months I have been constantly putting out fires to resolve all the emerging gaps and losses in this project.
Since the start of the year, and particularly over the last five weeks, the problems have got gradually worse, as the project organisation that the client wants puts all the responsibilities onto me, while at the same time the spectrum of project activities increasingly grows, the problems mentioned above largely persist or there is a renewed threat of losing yet more project staff.
Operative tasks, which really should be handled in the teams or by other staff members (who are currently lacking or have been lost), land on my desk. This means that I cannot fully take care of my actual management duties. Furthermore, in the context of the client's expectations, the existing operative tasks can only be carried out by me doing a lot of extra work, working late into evenings and at weekends, and in most cases it is still not possible to complete them.
Structures, responsibilities and processes cannot be defined and organised for the reasons listed above. These requirements are not, as originally planned, supported by the appropriate experts (e.g. IT project manager), and are also hindered and rendered impossible by the problem of staff losses and turnover mentioned above.
As I have mentioned, for several months now, my workload has consistently exceeded a reasonable maximum. Up until now, I have accepted possible adverse effects on my health and performance, but I will not be able to continue with this. This situation has now also been going on too long.
I am increasingly considering leaving my short-term position in the project and my long-term position at the company. "
Conclusion on cause of delay
Further alleged breaches
Issue 4 - Termination
"If in the reasonable opinion of RRMC the Supplier fails to perform the Services in accordance with this Agreement or to deliver Deliverables by the applicable delivery dates or milestone dates or if RRMC rejects the Deliverables, without limitation to any other of its rights or remedies, RRMC shall have the following rights:
13.11.3 to terminate this Agreement in whole or part with immediate effect by giving written notice to the Supplier."
"1. Where a breach goes to the root of the contract, the injured party may elect to put an end to the contract. Thereupon both sides are relieved from those obligations which remain unperformed.
2. If he does so elect, the injured party is entitled to compensation for (a) any breaches which occurred before the contract was terminated, and (b) the loss of his opportunity to receive performance of the promisor's outstanding obligations.
3. Certain categories of obligation, often called conditions, have the property that any breach of them is treated as going to the root of the contract. Upon the occurrence of any breach of condition, the injured party can elect to terminate and claim damages, whatever the gravity of the breach.
4. It is possible by express provision in the contract to make a term a condition, even if it would not be so in the absence of such a provision.
5. A stipulation that time is of the essence, in relation to a particular contractual term, denotes that timely performance is a condition of the contract. The consequence is that delay in performance is treated as going to the root of the contract, without regard to the magnitude of the breach.
6. It follows that where a promisor fails to give timely performance of an obligation in respect of which time is expressly stated to be of the essence, the injured party may elect to terminate and recover damages in respect of the promisor's outstanding obligations, without regard to the magnitude of the breach."
"It is true that until there has been acceptance of a repudiatory breach, the contract remains in existence and the party in breach may tender performance. Thus a party whose conduct has amounted to an anticipatory breach may, before it has been accepted as such, repent and perform the contract according to its terms. But he is not entitled unilaterally to tender performance according to some other terms."
Issue 5 - Misrepresentation
"81. At a presentation on 22 May 2019, and in order to induce the Defendant to enter into the Agreement, Mr Topal represented to the Defendant that:
81.1. The Claimant's previous experience included the 'Audi City Partner' project (see page 22 of its written presentation). At the meeting, Mr Topal said that this involved the roll out worldwide of a configurator which allowed for dynamic visualisation and real- time rendering of images.
81.2. The Claimant had been an 'Audi Digitalisation Strategy Partner since 2010' (see page 22 of its presentation). The representation was intended to give the impression of a substantial and on-going relationship with Audi and the Defendant so understood.
81.3. The Claimant had done 'All 3D Model Deliveries for AUDI AG' (see page 26 of its presentation) by which the Claimant intended the Defendant should understand (and the Defendant so understood) that the Claimant was the sole supplier, which was responsible for and had delivered all of the 3D models of Audi cars that Audi was using.
81.4. The Claimant's experience included the 'Audi Training Center Airport Munich', which involved an 'Audi City 3D Real Time 12K Powerwall' i.e. a configurator as described above (see pages 22 and 29 of the presentation).
81.5. By reference to the four sub-paragraphs above, the Claimant represented and intended the Defendant to understand (and the Defendant so understood) that the Claimant had a successful, substantial, on-going relationship with Audi, which had resulted in the worldwide (and local) roll out of a configurator which allowed for dynamic visualisation and real-time rendering of images.
Together, the 'Audi Representations'. The Audi representations were continuing representations to the date the Agreement was entered into."
"83.1. The Claimant did not deliver the Audi City Partner project worldwide. During a pre-project phase involving around 20 other suppliers, the Claimant provided a proof of concept to Audi, but its proof of concept was not taken further by Audi and the Claimant was not involved in the actual project.
83.2. The Claimant had not been and/or was no longer an 'Audi Digitalisation Strategy Partner'. The phrase was meaningless and invented by the Claimant. At the time it was made, alternatively at the date of the Agreement, the Claimant did not have any sort of relevant or meaningful relationship with Audi.
83.3. The Claimant was one of a number suppliers for the delivery of 3D images for Audi. As far as the Defendant is aware, Audi only used the Claimant for two (of many) car models as the Claimant's work was sub-standard. Audi relied upon its other suppliers for the rest.
83.4. The Claimant only provided a video for the '3D Powerwall' at the Audi Training Center at Munich Airport.
83.5. The Claimant did not have an on-going relationship with Audi of any substance or at all."
"(1) A contract is voidable where a party to the contract ('the claimant') entered into it in reliance on a misrepresentation, whether fraudulent, negligent or innocent, by the other contracting party ('the defendant') or, in certain circumstances by a third party.
(2) A misrepresentation is a false representation, by words or conduct, of present fact or law.
(3) A statement of intention contains a representation as to the present state of mind of the person making it.
(4) A statement of opinion contains a representation that the person making the statement holds that opinion; and in certain circumstances (as where the person making the statement may be expected to have special knowledge in relation to it) a statement of opinion contains a representation that the person making the statement has reasonable grounds for holding that opinion.
(5) To prove reliance it must be shown that the claimant would not have entered into the contract (whether at all or on the same terms) but for the misrepresentation unless
(a) the misrepresentation was fraudulent, in which case the misrepresentation need merely have been a reason for entering into the contract or present in the claimant's mind at the time the contract was entered into; or
(b) the misrepresentation and another factor rendering the contract voidable (for example, duress) were each independently sufficient to induce the claimant to enter into the contract."
"The slides included information about Topalsson's previous experience, and this included that they had worked on the 'Audi City Partner' project; that Topalsson had been an 'Audi Digitalisation Strategy Partner since 2010'; that Topalsson had done 'All 3D Model Deliveries for AUDI AG'; and that its experience included the 'Audi Training Centre Airport Munich', involving an 'Audi City 3D real Time 12K Powerwall'. I was not familiar with the descriptions 'Audi City Partner' or 'Audi Digitalisation Strategy Partner', but I understood them to mean that Topalsson had an important long term relationship with Audi and had done a lot of work for them.
Kuby expanded on the information provided in the slides during the presentation. I remember he mentioned that, for Audi, Topalsson were involved in the worldwide roll out of a configurator allowing for dynamic visualisation and real-time rendering of images. He specifically mentioned that they had solved the problem of scalability of this solution, which is a problem most companies struggle with. I specifically remember Kuby making this statement, because the fact that Topalsson had experience of a worldwide roll out and had solved this problem for a big car manufacturer was notable for me. It showed that Topalsson had been involved in providing not just a small project but a global configurator solution, to a large OEM comparable to the BMW Group. The project we were tendering for also included the provision of 3D models (within DP10) and therefore Topalsson's experience in providing all 3D model deliveries to Audi was also highly relevant. My clear understanding from Kuby's presentation was that Topalsson was the sole supplier of 3D models to Audi."
"Topalsson planned the Audi City in Berlin together with our partner, BB Onsite GmbH ("BB Onsite"). As part of that, Topalsson developed and installed the technology for the Ultra 3D Power Wall for the Audi City in Berlin. Topalsson also prepared strategy maps for Audi, for different Audi City projects."
"I don't accept we only provided a 3D power wall hardware. We provided software, we provided content, we provided renderings, we provided the whole imagery. We provided also software that produced realtime imagery.
all the models that we have been responsible for have been used in all configurators worldwide of Audi."
"What he said, and that was not in the actual pitch meeting but I think was either during the break or before or after the meeting but on the same day, I remember Florian Reichl was there as well, we were sort of joking about the configurator because all the bidders had mentioned that they had done work for the Audi configurator, and Mr Topal told me the big difference with Topalsson was they had actually built the configurator for Audi and that that configurator was rolled out worldwide and they had solved the problem of the scalability."
"I specifically recall that Kuby said that Topalsson had done a global roll out for Audi of a showroom configurator 3D solution."
"Q. Let me ask you a very specific question, which admits to a yes or no answer: do you specifically recall Kuby saying that Topalsson had done a global rollout for Audi of a showroom 3D configurator solution?
A. I don't remember those words."
"So I never said that we rolled out as a small company the worldwide only configurator of Audi. Even Audi has I think 18 different configurators worldwide for different stakeholders in markets, in-house and NGOs -- national sales organisations. "
Issue 6 - Quantum
"The rule of the common law is, that where a party sustains a loss by reason of a breach of contract, he is, so far as money can do it, to be placed in the same situation, with respect of damages, as if the contract had been performed."
i) Clause 13.10:
"RRMC may reject any of the Deliverables which in its reasonable opinion do not conform with the Specification or Purchase Order or are otherwise incomplete, delivered late or damaged or do not comply with the terms of this Agreement. "
ii) Clause 13.11:
"If in the reasonable opinion of RRMC the Supplier fails to perform the Services in accordance with this Agreement or to deliver Deliverables by the applicable delivery dates or milestone dates or if RRMC rejects the Deliverables, without limitation to any other of its rights or remedies, RRMC shall have the following rights:
"13.11.3 to terminate this Agreement in whole or part with immediate effect by giving written notice to the Supplier;
13.11.5 to perform the relevant Services itself or purchase substitute services from a third party and recover from the Supplier any loss and additional costs incurred in doing so;
13.11.6 to have all relevant Charges associated to the specific failure to supply the Deliverables or perform the Services previously paid by RRMC to the Supplier under this Agreement refunded by the Supplier;
13.11.8 to hold the Supplier accountable for any costs, loss or expenses incurred by RRMC "
iii) Clause 14.8:
"RRMC shall be entitled to set off any Charges due to the Supplier under this Agreement against any amount owed by the Supplier to RRMC under this Agreement."
iv) Clause 26.1:
"Upon termination of this Agreement by RRMC for any reason:
26.1.1 RRMC's sole liability shall be to pay the Supplier the proportion of the Charges applicable to the Services carried out prior to termination and any outstanding unavoidable commitments necessarily and solely incurred in performing this Agreement prior to termination that are not reflected in such Charges.
26.1.2 RRMC shall not be obliged to pay any Charges for Services which at the date of termination RRMC is entitled to reject or has already rejected."
v) Clause 20:
" the total liability of either Party to the other under this Agreement shall be limited in aggregate for all claims no matter how arising to the amount of 5m (five million euros)."
i) calculation of the sums due to Topalsson on termination;
ii) calculation of the sums due to RRMC on termination;
iii) calculation of the net sum due to Topalsson or RRMC;
iv) application of the cap on liability.
"Suppose a laundry has a clause limiting their liability to 10s. for any article that was damaged or lost, and the customer agrees to it ... The laundry washes a lot of articles in one week at a charge of £2, but during the next week loses a shirt worth £3. It seems to me that the laundry ought to be paid £2 for the work done, and to be able to limit its liability for the shirt to 10s.. Equity does not in that case require a set-off of the £3 against the £2, but only of the 10s. against the £2. Were it otherwise, the clause could be rendered useless by an adroit customer. The customer would only have to let his laundry bill fall into arrear, and he could get round the clause. I do not like these limitation clauses, but, if they are truly agreed between the parties-or provided by statute-we ought to give effect to them."
Sums due to Topalsson
| DP | Description | Contract Price | % Assessed | Value |
| 1 | Analysis and alignment | 272,903 | 100 | 272,903 |
| 2 | Initial back end and rule engine | 885,749 | 82.23 | 728,370 |
| 3 | POS Configurator | 1,314,025 | 56.27 | 739,356 |
| 4 | Web Configurator | 970,151 | 60.25 | 584,516 |
| 6 | Ordering integration | 257,736 | 10 | 25,774 |
| 7 | Pricing integration | 161,234 | 10 | 16,123 |
| 10 | 3D data preparation process | 2,393,318 | 23 | 558,921 |
| 13 | Operation and maintenance | 2,794,885 | 11 | 301,617 |
| TOTAL | 9,050,001 | 3,227,580 |
| DP | Description | Contract Price | % Assessed | Value |
| 1 | Analysis and alignment | 272,903 | 100 | 272,903 |
| 2 | Initial back end and rule engine | 885,749 | 40 | 354,300 |
| 3 | POS Configurator | 1,314,025 | 30 | 394,208 |
| 4 | Web Configurator | 970,151 | 30 | 291,045 |
| 6 | Ordering integration | 257,736 | 0 | 0 |
| 7 | Pricing integration | 161,234 | 0 | 0 |
| 10 | 3D data preparation process | 2,393,318 | 10 | 239,332 |
| 13 | Operation and maintenance | 2,794,885 | 0 | 0 |
| TOTAL | 9,050,001 | 1,551,787 |
Sums due to RRMC
i) Interim measures to the mitigate Topalsson's failure to deliver key functionality (2,387,186):
a) additional third party costs to stabilise and upgrade an existing configurator landscape pending implementation of a new system (739,572);
b) additional third party costs to create an alternative launch visualiser tool for events and dealers in place of the Closed Room Configurator that Topalsson was due to deliver (1,281,365);
c) additional internal costs to stabilise, upgrade and maintain the fall-back solution (until the new solution is available) and to use the legacy configurator landscape (366,249).
ii) Procurement of the system landscape that Topalsson contracted to deliver (13,116,776):
a) internal cost to set up and manage a new tender and set-up a new solution for the configurator landscape (359,326);
b) estimated additional costs for a replacement solution (6,790,880);
c) on-going costs to develop the EVE visualiser fallback solution (5,966,570).
iii) Sums which it is claimed should be included in assessing replacement system costs (1,564,325):
a) AWS Cloud incurred and on-going costs until 30 November 2022;
b) ordering integration;
c) penetration test;
d) CRIS/CoSy interface adaption;
e) estimated project costs of RRMC;
f) payments made to Topalsson.
iv) Loss of profits on option sales (1,601,082). As a result of the termination for repudiatory breach, it is said that there were reduced option sales (i.e. paid customisation of vehicles) because there was no new feature imagery for the dealers to use with the existing ordering configurator (period affected August 2020 through April 2021).
Interim measures (2,387,186)
Procurement of the replacement solution (13,116,776)
"The target solution is to fully include RRMC in the BMW/Mini system landscape. This will allow us to fully benefit from central IT support, future developments and make use of efficiencies. The full integration in the target solution can however (due to capacity restrictions) only start in 2025. It is therefore necessary to put in place an intermediate solution to mitigate the massive risks we have with the existing solution (which is outdated and unstable ) and to support with the launch of the new Spectre (a new fully electric vehicle due to be communicated in September 2022). The intermediate solution effectively involves building a back-end based on BMW's systems which will be fully integrated later, and a front-end which operates from the start within the BMW landscape, which I explain further below.
The back-end for the intermediate solution (which is broadly equivalent to Delivery Packages 2 and 13 as should have been delivered by Topalsson under the Contract) will be made up of the following elements, all of which are new systems, based however on existing BMW systems and implemented with support of the respective BMW departments and their suppliers.
The target is to eventually integrate RRMC into the respective BMW systems, until then we will use these 3 Back-end solutions. This is however not sustainable over a long period of time, because it would require us to keep all of these systems in sync with the parallel BMW systems, over a longer period of time as the BMW systems are regularly updated, improved and expanded. This would need very high effort, and would be very costly and error prone.
Meanwhile, the new front-end systems will be developed within the existing BMW Configurator landscape
The front-end elements described above are comparable to Delivery Packages 3, 4, 6, 7, and 13, as should have been delivered by Topalsson, but will not be built from scratch rather, the RRMC specific logic, requirements and User Interface will be integrated and/or added in the existing BMW systems. Overall all elements build on each other and there are strong interdependencies. One will not work without the other.
Due to the significant time needed to define and develop the new front- and back-end solutions, they will not be ready for Start of Communication of the new Spectre model (Sep 2022). It is therefore essential that we redesign and further develop the EVE Visualiser (the fallback solution put in place after Contract termination) to be used online to support the Spectre launch.
The anticipated timeline for the new project is as follows:
a. The go-live date for the WEB Visualiser is September 2022 to support the Spectre Launch, The Web Configurator will be released in 3 phases (March, September and December 2023), with go-live for the new ordering systems being September2023, to coincide with the Start of Ordering for a new model launch.
b. The existing legacy system and infrastructure (RROC and RRMC) will be retired in October 2023.
c. Between 2023 and 2025, there will be integration of the RRCP, RR Datafox and RR Pip Services functionality into the respective BMW systems. Between 2025-2027 the final integration in the overall BMW Configurator landscape with respective back-end systems will take place."
Costs incurred by RRMC in respect of the original project (1,564,325)
Loss of profits on option sales (1,601,082)
Net sum due to RRMC
Application of the cap
Interest
"Each Party may charge simple interest at the rate of 4% per annum above the Bank of England base rate from time to time compounded at monthly intervals from the due date for such payment until actual date of payment "
"Each Party agrees that any interest that is payable under clause [14] is a substantial remedy for late payment of any sum payable under this agreement for the purposes of section 8(2) of the Late Payment of Commercial Debts (Interest) Act 1998 and shall be the sole remedy available to the Party entitled to interest for late payment whether in contract, tort or restitution or otherwise."
Issue 7 Intellectual Property Issues
i) Topalsson's claim for a declaration that on a proper construction of clause 13.10 of section 7 of the Agreement, RRMC is not entitled to make any use of any Deliverables, save for those limited artefacts for which RRMC has paid.
ii) Topalsson's claim for an order for delivery up or destruction of all copies of Supplier Software in RRMC's possession.
iii) RRMC's claim for an order for delivery up or destruction of all copies of Bespoke Software and other property in Topalsson's possession.
Deliverables
"the goods or services or other things to be delivered to RRMC or BMW Group as deliverables as a product of the Services, with such deliverables including RRMC data and those deliverables set out in Section 2 and all documents, products and materials developed by RRMC or its agents, contractors, consultants and employees in relation to the provision of the Services in any form, including drawings, plans, diagrams, pictures, computer programs, data, reports and specifications (including drafts of the same)."
"All right, title and interest including all Intellectual Property Rights that are legally capable of being assigned under Applicable Law in and to the Deliverables and any other product of the Services shall immediately upon their creation vest in RRMC. Accordingly the Supplier hereby assigns to RRMC with full title guarantee all such Intellectual Property Rights that the Supplier has now or may have in the future throughout the world to RRMC absolutely so far as possible in perpetuity."
"Title to the Deliverables passes to RRMC on payment."
Supplier Software
"Supplier Software (all of which shall be deemed to be "Licenced Software" pursuant to clause 22 of Section 7 of this Agreement) means all hardware and software provided by the Supplier to RRMC to provide the Services including the Supplier Hardware, Supplier Standard Software, Third Party Software, Modified Software (Supplier), Modified Software (Third Party) and Supported Software including but not limited to those listed below:
5.1 DTE (Digital Twin Engine) Software Version 2019 (R6)
5.2 TWIN Software Version 2019 (R6)
5.3 SOLOGIC Software Version 2019 (R6)
For the avoidance of doubt and notwithstanding any other provision of this Agreement the Intellectual Property Rights in any Supplier Software used or created by the Supplier in providing the Services, including but not limited to any modifications or improvements to such Supplier Software, will be owned by the Supplier or any relevant third party licensor.
The Supplier hereby grants a non-exclusive, revocable, global licence to BMW Group to use the Supplier Software for the Term for usage solely in connection with the design of Rolls Royce model vehicles (and not for the avoidance of doubt for vehicles in the wider BMW Group that are not branded as Rolls Royce)."
"the Defendant undertakes to destroy all copies within its possession or control of the Supplier Software (for avoidance of doubt, subject to the preservation of the Defendant's Software) under oath, after steps have been taken to ensure to the proper preservation and inspection of evidence. Such steps should be capable of agreement by consent and are best considered during the disclosure stage. In the meantime, the Defendant undertakes not to make any commercial use of the same."
Bespoke Software
"Bespoke Software means any software created pursuant to the terms of this Agreement to be used by RRMC solely in relation to RRMC products, including but not limited to those software listed below:
For the avoidance of doubt, and notwithstanding any other provision of this Agreement, the Intellectual Property rights in any Bespoke Software shall be owned by RRMC and RRMC shall grant the Supplier an exclusive licence to use the Bespoke Software for the purpose of providing the Services for the duration of the Term of this Agreement."
"All right, title and interest including Intellectual Property Rights in and to all BMW Group background IPR, RRMC materials and RRMC Data is vested in and shall remain vested in BMW Group."
"Unless otherwise expressly authorised by RRMC the Supplier shall cease using, return and deliver to RRMC all physical and non-physical property that belongs to RRMC including all RRMC's Confidential Information, RRMC Materials, all RRMC Data, all RRMC Personal Data and all other documents and materials and copies thereof in the possession, power, custody or control of the Supplier."
"the Claimant hereby undertakes to destroy under oath all copies of materials to which clause 23.8 of Section 7 applies that are within its possession or control, after steps have been taken to ensure the proper preservation and inspection of evidence. Such steps should be capable of agreement by consent and are best considered during the disclosure stage. In the meantime, the Claimant undertakes not to make any commercial use of the same."
Conclusions
i) Topalsson was obliged to deliver and install the software in accordance with the March Plan, which was contractually binding on Topalsson and made time of the essence in respect of the revised dates agreed;
ii) Topalsson failed to comply with the March Plan:
a) Topalsson failed to achieve Technical Go-Live in respect of early IVT by 9 March 2020;
b) Topalsson failed to achieve Technical Go-Live in respect of the Closed Room configurator by 1 April 2020 or thereafter;
c) Topalsson failed to progress the sprints and testing so as to be able to achieve Technical Go-Live in respect of CRIS by 23 April 2020;
iii) Topalsson was not impeded in its performance, or prevented from performing its obligations by RRMC;
iv) RRMC was entitled to terminate under clause 13.11.3 of Section 7 of the Agreement and at common law on the ground of Topalsson's repudiatory or anticipatory breach;
v) RRMC has failed to establish any actionable claim for misrepresentation;
vi) RRMC is entitled to damages in the sum of 5 million plus interest at the rate of 4% per annum above the Bank of England base rate from time to time compounded at monthly intervals from the due date for such payment until actual date of payment;
vii) the parties are entitled to orders for delivery up and/or declaratory relief in respect of the intellectual property issues as set out above.