In our previous blog entitled "Statement of Works - Drafting Tips" we looked at the key requirements for an effective Statement of Works ("SOW"). In this blog we explore some of the post contract activities the parties should undertake to ensure that, even when the lawyers are no longer directly involved, the parties' operational teams are still able to comply with and implement the scope, activities and responsibilities agreed as part of the SOW.
Scope of Services
The scope of the services should hopefully have been clearly and accurately documented in the contract/SOW. The operational teams of both parties should then begin working closely together to ensure the solution is delivered in accordance with the SOW terms and agreed methods of delivery. It should also be noted that any changes to the scope which could impact the deliverables, project schedule and/or pricing are only agreed by the parties using the contract change control procedure.
A point to note about scope is that the parties may have agreed in the SOW that certain elements of the scope of service are to be agreed after signing. This is not ideal because it is advisable to agree all aspects of the scope prior to signature of an SOW. However, for some complex deals this may not always be possible, in which case other more creative methods for contractually agreeing the scope and the price may be required. For instance the parties could document in the SOW a process by which, using the contract's change control procedure, the delivery schedule and pricing can be objectively adjusted within "x" period of time following the SOW start date. It should also set out the options in the event agreement cannot be reached, such as triggering the contract's dispute resolution mechanism, or in extreme cases, permitting the client to terminate the SOW.
From the supplier's perspective care should be taken to ensure that the method of delivery aligns with its internal operational processes, policies, tools and procedures. The risk for the supplier of not doing so is that any deviation from its standard operational processes, not agreed through the contract change control procedure, could lead to the supplier missing key deadlines, breaching its contractual obligations (e.g. service levels), regulatory obligations (e.g. GDPR), as well as incurring additional costs which it may not be able to recover under the contract. This is because quite often to produce the business case or risk profile underpinning its solution the supplier has used input costs associated with the implementation of its standard operational processes, policies and procedures (e.g. number of personnel, equipment, security protocols, software, sites, facilities, usual business hours etc).
From the perspective of the supplier, it is important to keep in mind that its performance is likely to be dependent on the client fulfilling certain responsibilities. It was noted in the previous blog that those responsibilities should be appropriately drafted and set out in the contract/SOW. Where such an express provision granting the supplier the right to delay performance or increase its charges exists, the operational teams should agree a process for monitoring compliance/non-compliance, as well (where possible) a process for defining and agreeing the monetary impact of a specific instance of non-compliance by the client. For example, through the use of the contract change control procedure. This will benefit both parties in the long run by minimising the potential of a commercial dispute arising.
In our earlier blog, we also discussed the importance of including in an SOW a clear and objective acceptance process, which should be the sole method for determining the successful achievement by the supplier of its obligations. However, it is not unusual in poorly managed, but time critical development projects, for both parties to abandon the contractually agreed acceptance procedure, because it involves too much management time and paperwork. This would be a mistake. The operational teams should agree a process for ensuring that no deliverables are put into use by the client prior to formal sign off under the agreed acceptance procedure. To do so would not be in the interests of either party, because it could lead to uncertainty as to which defects fall inside or outside any agreed warranty periods, and runs the risk of the supplier becoming liable for defects under the warranty which would have been identified had the acceptance process been followed.
Finally, it is often the case that the parties, for very good reasons, choose to defer the finalisation of the specific acceptance criteria for each deliverable to the post SOW phase. Where this is the case the operational teams should be aware of the obligation on both parties to agree using - the contract change control procedure - the relevant acceptance criteria by the dates set out in the SOW.
Long term transactions should contain governance provisions that guide how the parties will work together to manage the contract and the relationship. The governance process must be collaborative and should clearly set out the parties responsibilities and areas of control. The “Project Plan” discussed in the earlier blog should detail the activities, roles and responsibilities to be performed by each party at each stage of the project lifecycle. The risk of not having a good governance model is that a party could inadvertently become responsible for a commercial or legal risk that ought properly to be the responsibility of the other party.
Where a good SOW has been drafted and agreed it is in neither parties' interests to ignore their obligations as set out within it. The negotiation and subsequent signature of an SOW requires much skill and effort on the part of the stakeholder professionals involved. It is not surprising therefore that once completed the parties may be tempted to "take their foot of the pedal" when in fact this - the delivery phase - is precisely the moment at which the parties ought to be paying maximum attention to their obligations as described in the SOW. A good way to ensure that this is the case is to have a good joint supplier-client project team, with clearly defined roles and responsibilities, working in a spirit of collaboration and cooperation.
Statement of Works ("SOW") are often used as part of master technology service agreements to describe the scope of services to be provided by a supplier and to fix the price for those services. However the parties to the contract often fail to clearly describe the services to be provided, or the timescales for service delivery. This often leads to delays and arguments during the service provision phase, which in the worst cases can lead to litigation.
Whether you are a supplier keen to avoid "scope creep", or a customer wishing to avoid the inadequate delivery of a critical project, the following issues should as a minimum always be addressed in an SOW:
Scope of Services
The work that the supplier is contracted to perform should be clearly and accurately described. Any gaps between the supplier’s services and the customer's business and technical requirements should be discussed and addressed.
Technical Requirements & Specifications
The SOW should clearly describe the customer's business and technical specifications and requirements. A clearly defined set of specifications will make it difficult for a supplier to avoid their obligations, whilst protecting the supplier from an increase in its budgeted project delivery costs due to a required increase in scope by the customer.
A project plan is essential for ensuring clarity with respect to the parties' obligations to perform certain activities by agreed timescales. The project plan should clearly describe the scope, timescales and framework for the project. A key issue about project plans that is often forgotten, particularly in the case complex projects, is that the SOW should contain an obligation on the parties to agree a project plan by a set deadline, for example, within six weeks of the contract signature date. Alternatively, the parties could agree that the delivery of the project plan itself becomes a deliverable to be achieved by a milestone in the "design" phase.
Deliverables and Acceptance Testing
All deliverables should be clearly described, with any "key" or critical deliverables identified and milestone dates for each deliverable allocated and agreed within the project plan. An agreed acceptance process should be detailed in the SOW (it could also be agreed at the MSA level to save time). However it is to be incorporated into the agreement it should be made clear that the method for determining the successful achievement by the supplier of a particular deliverable will be solely by the application of the acceptance procedure and associated acceptance criteria.
Customer's Obligations and Project Assumptions
A supplier will often require the inclusion in the SOW of a list of customer obligations and/or project assumptions. The supplier should carefully consider the list of customer obligations and/or project specific assumptions it wishes to include, to identify those obligations which if not performed, or assumptions which if proven to be invalid, could lead to changes to the project schedule, project deliverables and project costs. The Customer should also pay attention to the list of customer obligations and assumptions to ensure that they only contain obligations for which it is right and proper to assign responsibility for performance to the customer, and in the case of any assumptions, only those that are fundamental to the operational and commercial profile underpinning the deal.
This will not always be the case, but generally speaking a choice should be made between a "fixed fee arrangement" or for fees to be calculated on a "time and material" basis. If the services are to be performed for a fixed fee the SOW should include all expenses to be incurred and any applicable taxes. The Supplier will only be able to invoice the customer for the fixed fee amounts. In the case of a time and material arrangement the Supplier will perform the services on a time and materials basis at the rates agreed and detailed in a rate card set out in either the MSA or in an annex to the SOW.
The above list is not exhaustive by any means and there are many other issues to consider depending on the type, size and complexity of a particular technology services project. Nevertheless, if the above issues are addressed during the negotiation phase of a SOW this will increase the chances of the project not only being delivered on time and on budget, but also in accordance with the customer's requirements.
Cookies (or similar technologies) are usually placed on an individual user's device by either the website publisher or by an advertising network organisation ("ad network") that is permitted by the website publisher to place cookie, to collect data in order to build a profile of that individual user based on their online search history. This profile of the individual can be used to target them with advertising relevant to their preferences and interests. This is known as targeted advertising or online behavioural advertising ("OBA").
The relevant provisions of the Privacy and Electronic Communications (EC Directive) Regulation 2003 (PECR 2003), which governs the position in the UK as to when and how a website publisher can place a cookie on an individual user’s device states that a person shall not store or gain access to information stored, in the terminal equipment of a subscriber or user unless the subscriber has given their consent, after being provided with "..clear and comprehensive information.." about the purposes of the storage of or access to that information.
The Regulation also introduces the concept of profiling or automated decision making, which is relevant to the functioning of OBA. In essence, individuals now have the right to be informed about the existence of automated decision making and subject to certain exceptions, the right not to be subject to automated decision making or profiling.
However, the fact is many ad networks are active on multiple websites; collecting, using, storing, aggregating and then transferring huge amounts of data to each other and this is often not made clear to users, in violation of the Regulation and its principles. The net effect is that users may have no idea who is collecting, using or storing their personal and non-personal data and in many cases are not even aware that their data is being used to build profiles about them. If they are made aware of collection of personal data, it is presented as a positive, to enable the website publisher to provide the user with a more personalised service. This is potentially risky for users, because profiles are generated by mathematical and statistical modelling of the information collected about users and are not infallible. The results of such modelling can therefore potentially lead to inaccurate and/or misleading results about an individual.
In the new world of online privacy regulation, it is no longer enough to simply have policies in place, without operational compliance. To minimise their risk of non-compliance with the law website operators should as a minimum ensure that:
Further, where a joint controller relationship between the website publisher and an ad network could or does exist, the user must be made aware of the conditions of that collaboration. This not only allows the user to understand who is responsible for protecting their data, it is also beneficial for website publishers and their ad network partners to understand in the context of their commercial relationship which party is legally responsible for compliance with the relevant privacy regulations.
Much of the discussion to date around blockchain and distributed ledger technology (DLT) has been about making data more secure. This is unsurprising given that the technology is designed to ensure:
Further, it is not always clear whether the application environment in which DLT is intended to operate enables compliance with related privacy regulation. For example, GDPR Articles 12 – 22 set out data subject rights including rights of access, rectification, erasure, restriction and portability. The blockchain principle of immutability referenced above would seem to run contra to these data subject rights, if personal data is included in the blocks that make up the chain.
The use of "on-chain and off-chain" deployment models, is an example of how areas of potential regulatory non-compliance can be addressed. This type of hybrid deployment model could be used to keep part of the transaction on-blockchain and any personal data processing off-blockchain. One possible use of on-chain off-chain blockchain technology is identity verification. Where an organisation is subject to know your customer (KYC) regulations, blockchain and DLT technology could be used to verify a prospective customer's identity, without the need to collect, store or process any personal data to verify such identity.
In this case, the personal data required to validate an individual’s identity, will be confirmed by a trusted third party and held by the individual in an encrypted digital wallet. The organisation wishing to verify the customer’s identity for the purpose of KYC, would use public key/private key authentication to verify the individual’s identity, without ever having to further process this personal data in the form of identity checks with for example, credit reference agencies.
A digital identity solution of this kind would be very attractive to organisations who might wish to supply or market goods and services to consumers, but who are also keen to ensure, to the greatest extent possible, that their KYC processes remain outside the scope of the GDPR and other related data privacy legislation. However, this would require the organisation to "trust" the validity of the personal data held in the digital wallet, so some form of authentication or certification of trusted third parties would be required.
Does this not then defeat the purpose of blockchain and distributed ledger technology if not all data is stored on the blockchain and the very information that is most important to protect i.e. personal data for the purposes of identity verification, still sits on a centralised database albeit with a ‘trusted third party’?
When embarking on a software or application development project, a key consideration should be the development methodology to be used. Generally, the commissioning party ("the customer") will have the choice of an "Agile" or "Waterfall" style of development. The methodology selected by the customer will often depend upon whether the customer wishes to have flexibility during the development cycle, or whether it wishes to agree a detailed set of business specifications and technical requirements before the developer begins work. The choice made will of course inevitably have legal and commercial implications. These implications should be identified and addressed in a software development agreement between the customer and the developer. Some of the factors to consider in making the decision are set out below.
Agile software development methodology allows the customer to develop its requirements during the project phase in short, frequent development cycles. Agile development is flexible and scalable; it enables the scope of a project to be changed based on feedback received during these short development cycles. In short, the specifications can be changed post contract signature, without the need to follow a strict and potentially time consuming change control process. However, this does not mean that the parties should abandon recording any agreed changes to the high level specifications agreed at the very beginning of the project.
Therefore, if you are a customer thinking about using Agile you should ask yourself:
Waterfall software development methodology is focused on agreeing a detailed set of business requirements and technical specifications prior to the commencement of work. Detailed documentation is required for each project phase, including technical specifications, which set out measurable deliverables and performance criteria.
If you are a customer thinking about using Waterfall you should ask yourself:
It is also possible to use a mixture of Agile and Waterfall during the development. For example, the early scope and analyse phase of the project could be completed using Waterfall, whilst Agile development principles are applied to later or selected phases of the build. In these circumstances care must be taken to ensure that the correct contracting principles are agreed and applied at the appropriate stages of the development. For example, the point at which testing and acceptance should occur may differ depending on which methodology is used.
Although, Agile is flexible and collaborative, it does not equal "zero paperwork". It is still advisable (for both parties) to agree: a contract, project plans, interface designs and technical specification documents. After all, you would not embark on a software development project based on the Waterfall methodology without addressing issues concerning project governance, deliverables, testing and acceptance, warranties, cost and IP ownership - to name just a few. Agile is not a "free for all" in terms of scope and scope change, so organisations should still consider all of the above even when using the Agile methodology.
GDPR Article 35: Pop up Quiz! Do you know what this section of the new Regulation requires companies to do if developing new products and services (including software) could result in a "high risk" to individuals?
To find out or to arrange your free one hour initial consultation please contact us.
The introduction of Regulation (EU) 2016/679, otherwise known as GDPR ("the Regulations") has resulted in significant changes to the UK and European data protection landscape.
As businesses large and small consider the practical and operational implications of these changes, an interesting aspect might be the relationship between the providers of cloud services and their clients. An example, of this can be seen in Article 28 of the new Regulations, which sets out a prescriptive and detailed set of data protection obligations that controllers are required to contractually impose on their processors.
Of course, under GDPR the client would normally be the controller of personal data, and the cloud provider its processor. At a time when businesses are increasingly reliant on cloud computing services, the provisions of Article 28 will create an interesting challenge for small businesses who as controllers, are now required to ensure the detailed list of obligations required under Article 28 are included in their cloud services contracts.
One particular obligation under Article 28(2), is that the processor must provide the controller with notice of any sub-processors it wishes to appoint and the controller will have the right to object. Typically, large cloud providers are reluctant to move away from their standard terms of business, and many adopt a "take-it-or-leave-it" position in contract negotiations, in particular with respect to their preferred sub-processors. However, European data protection supervisory authorities have indicated that an inequality in the bargaining position between a cloud client and its supplier will not release the small cloud client from its obligations under Article 28.
Therefore, a careful review of the terms of their cloud services contracts by all cloud service clients is strongly recommended. It also goes without saying that as a result of Article 28 of the Regulations, cloud providers used to operating under their standard terms, will in future be required to display a greater degree of flexibility when negotiating contracts with prospective smaller clients.
Please contact us if you require legal advice or would like to find out more information about our services.
Blockchain or distributed ledger technology, has the power (its supporters say) to transform the processes traditionally used by banks, power supply companies and logistics providers to name but a few.
In fact, the technology is potentially suitable for any business process which operates in a pre-arranged, methodical and organised basis. Transacting in real estate and securities would be other good examples. It even has its uses in intellectual property as a method of verifying the authenticity and ownership of works of art, authorship, creation and design. From a data privacy perspective there is potential for application of blockchain technology to verify an individual’s identity, without the need to process that individual’s personal data.
The reported key benefits of blockchain technology include:
Despite these benefits, blockchain technology is still viewed with a mixture of caution, and interest by many regulators. Particularly sectoral regulators in the areas of data privacy and financial services. For example, when used as the underlying technology for processing bitcoin payments, the non-application of existing regulations such as the Electronic Money Directive and the Payment Services Directive (which only applies to "real" money such as banknotes and even electronic money as defined by the EMD) raises real consumer and business protection concerns.
From a data privacy perspective, it is not always clear whether the distributed nature of blockchain servers/nodes across multiple jurisdictions, enables or facilitates compliance with international personal data transfer requirements under GDPR and related data privacy legislation.
From a business technology perspective, any organisation considering utilising blockchain technology as a means of working with its customers and suppliers, will have to commission the development of systems be it with a blockchain development company or by sourcing “Blockchain-as-a-Service”.
In either case consideration needs to be given to the contracts entered into with the service providers to ensure that requirements are clearly identified and linked to a business goal, liability appropriately limited, privacy issues addressed and intellectual property position in terms of ownership agreed. As you can imagine these considerations will differ depending on whether an organisation sources to develop its own blockchain solution or utilises a cloud service.
In summary, as sexy as blockchain technology sounds with its many potential applications and ability to disrupt traditional business processes, organisations wishing to transition to blockchain technology should still consider the usual run-of-the-mill, but indescribably important contract, legal and regulatory matters forming part of any well-run IT transformation project.
Please contact us if you require legal advice or would like to find out more information about our services.