The Building Blocks of a Project Schedule

Project Schedule

In this article, we have a look at some of the important aspects that must be kept in mind when drafting a Project Schedule

Introduction

What is a Project Schedule?

A project schedule is a detailed timeline outlining the key tasks, milestones, and deadlines associated with project. It is an essential component of the contract, as it helps both parties – the customer and the provider – to manage expectations, allocate resources, monitor progress, and ensure that the project stays on track.

The project schedule typically includes the following elements:

Project phases: These are the high-level stages of the project, such as planning, design, development, testing, and deployment.
Milestones: Significant events or checkpoints in the project that mark the completion of tasks.
Tasks and Deliverables: A list of specific activities and their corresponding outputs that need to be completed as part of the milestone.
Customer Dependencies: Relationships between tasks that indicate how one task’s completion affects the start or end date of another task

Building Blocks

Project blocks

Phases

Generally a Project will have several phases. Each phase with its own milestones, deliverables and commercials.

As an example, consider a Software Development Agreement-

Design and prototyping: This phase may entail the design and prototyping, which involves creating mockups, wireframes, and prototypes to provide a visual representation of the software’s user interface and user experience. This phase also typically includes defining the software architecture and the overall system structure.
Development: The development phase can be broken down in multiple phases and involves the actual coding and implementation of the software.
Deployment and launch: This phase covers the deployment and launch, which involves deploying the software to the production environment and making it available for end-users. This includes server setup, installation, configuration, and migration of data.

Milestones

Milestones refer to predefined, significant events or checkpoints in the Project that indicate progress towards completing the Project.

These milestones are often tied to specific deliverables, such as a completed feature, a working prototype, or the final product.

Milestones serve several purposes:

Project Management: They help both the development team and the client track progress, identify potential issues, and ensure the project is on schedule. By dividing the project into smaller, manageable phases, milestones make it easier to plan and allocate resources effectively.
Accountability: Clearly defined milestones provide a basis for evaluating the performance of the team. They allow the client to assess whether the team is meeting expectations and delivering on their commitments.
Payment Structure: Milestones are often used as triggers for payment. Upon the successful completion and approval of a milestone, the client releases a pre-agreed portion of the total payment to the provider. This approach helps mitigate risks for both parties and ensures that payments are tied to demonstrable progress.
Client Involvement: By incorporating regular reviews and approvals into the milestone process, clients have the opportunity to provide feedback and request changes as needed. This collaborative approach helps ensure that the final product aligns with the client’s vision and requirements.

Deliverables

Deliverables refer to the outputs or results that the Provider is expected to produce and deliver to the Client during or at the end of the Project. These deliverables serve as evidence of progress, help measure the success of the Project.

As an example, take a Software Development Agreement, which may include the following deliverables-

Documentation: This may encompass requirements documents, design specifications, user manuals, or technical documentation that provide detailed information about the software and its components.
Source Code: The human-readable code written by developers, which can be compiled or interpreted to create the executable software. Clients may require the delivery of source code to maintain or modify the software in the future.
Executable Code: The compiled or interpreted version of the software that can be run on a specific platform or operating system. This is often the primary deliverable in a software development project.
Test Plans and Reports: These documents outline the testing procedures, test cases, and results, providing evidence that the software meets its requirements and functions correctly.
Installation Scripts and Deployment Packages: These components facilitate the installation, setup, and deployment of the software on the target environment, ensuring a smooth transition to production use.
Training Materials: Manuals, videos, or other instructional resources that help users understand and effectively use the software.
Progress Reports: Periodic updates that detail the project’s status, completed tasks, and any challenges or issues encountered.

When defining deliverables in a project schedule, it is crucial to be specific about what is expected, the format, and the deadlines for delivery.

Specifications

Specifications refer to detailed descriptions of the features, functionality, and requirements of the deliverables. They serve as a blueprint for the provider, guiding their work and ensuring that the final product aligns with the client’s expectations.

For example, specifications in software development agreements can include the following aspects:

Functional Requirements: These specifications define what the software is expected to do, describing the features, user interactions, and overall functionality. Functional requirements can be expressed as use cases, user stories, or system requirements.
Non-functional Requirements: These specifications describe the quality attributes or characteristics of the software, such as performance, scalability, security, maintainability, and usability. Non-functional requirements help ensure that the software meets the desired level of quality and operates effectively in its intended environment.
Technical Requirements: These specifications outline the technical aspects of the deliverables, such as programming languages, platforms, frameworks, libraries, or standards that the development team must adhere to during the project.
Design Constraints: These specifications define any limitations or constraints on the software’s design or architecture, such as specific technologies, compliance with industry regulations, or compatibility with existing systems.
Format and Presentation: Deliverable specifications may also include requirements related to the format and presentation of the deliverables, such as document templates, file formats, or naming conventions.

By providing clear and detailed deliverable specifications, both Parties can establish a shared understanding of the Project’s goals and expectations. This helps mitigate risks, reduce misunderstandings, and ensure that the development team’s efforts align with the client’s vision and requirements.

Dependencies

Customer dependencies refer to the tasks, inputs, resources, or actions that the client is responsible for providing. These dependencies are crucial for ensuring that the project progresses smoothly and meets the agreed-upon milestones. Failure to fulfill customer dependencies in a timely manner can lead to delays, increased costs, and even Project failure.

As an example, typical customer dependencies that are included in Project Schedules for Software Development Agreements include:

Access to Resources: The client may need to grant the development team access to specific resources, such as software, hardware, tools, or existing systems, to facilitate development and testing.
Subject Matter Expertise: The client may need to provide subject matter experts or dedicated personnel who can answer questions, clarify requirements, or validate the software’s functionality.
Test Environments and Data: The client may be responsible for providing test environments or realistic test data for the development team to validate and verify the software’s functionality, performance, and compatibility.

Assumptions

From a Provider’s perspective, especially when a phase will be done at a fixed fee, it is important to clearly provide assumptions which were relied on when determining the fee and the scope of the work that will have to be done.

The Project Schedule also needs to be clear what needs to happen if the assumptions are found to be untrue. Generally, if assumptions are found to be untrue, the Provider would want to have the right to cease work and start the processes of negotiating a change order.

Importance of working with accurate assumptions from both the provider’s and the client’s perspective:

Clear communication: Accurate assumptions enable clear communication between the provider and the client, ensuring that both parties have a shared understanding of the project’s goals, requirements, and constraints. This reduces the risk of miscommunication and helps avoid potential conflicts.
Scope management: Documenting accurate assumptions helps to define and manage the project’s scope effectively. It prevents scope creep, which occurs when the project’s objectives or deliverables expand beyond the original agreement, leading to increased costs, delays, or even project failure.
Risk management: Identifying and documenting assumptions enables both parties to anticipate potential risks and challenges, and to develop strategies for mitigating or addressing them. This proactive approach to risk management helps ensure project success and timely delivery.
Resource allocation: Accurate assumptions enable the provider to allocate appropriate resources, including personnel, time, and budget, to complete the project successfully. This also allows the client to better understand the cost and timeline associated with the project.
Accountability: Accurate assumptions help establish clear expectations and responsibilities for both the provider and the client. This fosters a sense of accountability, ensuring that each party is held responsible for their respective roles and obligations.

In summary, working with accurate documented assumptions in a software development agreement is crucial for clear communication, effective scope and risk management, proper resource allocation, performance measurement, and accountability. Both the provider and the client benefit from having a shared understanding of the project’s objectives and constraints, ultimately contributing to the project’s success.

Out-of-scope services

Expressly stipulating out-of-scope services in your project schedule is important for several reasons. Out-of-scope services refer to tasks, features, or functions that are not included in the agreed-upon scope of the project.

Clearly defining these out-of-scope services can create clarity on the project’s scope and help manage expectations for both the client and the development team. Here’s why it’s crucial to include them in your project schedule:

Clear communication: Explicitly stating out-of-scope services helps both parties to have a shared understanding of what is not included in the project. This ensures that there is clear communication between the client and the development team, reducing the risk of misunderstandings or disputes.
Scope management: By defining out-of-scope services, you can prevent scope creep, which occurs when the project’s objectives or deliverables expand beyond the original agreement. Scope creep can lead to increased costs, delays, or even project failure. Identifying out-of-scope services helps maintain control over the project scope, ensuring that it remains within the agreed-upon boundaries.
Resource allocation: Defining out-of-scope services helps the development team allocate appropriate resources, including personnel, time, and budget, to complete the project successfully. It ensures that the team focuses on the agreed-upon deliverables and doesn’t inadvertently allocate resources to tasks that are not part of the project scope.
Cost management: Including out-of-scope services in the project schedule allows the client to understand which services are not included in the project’s cost, helping to manage their expectations and avoid potential disputes over additional charges. If the client decides to include any out-of-scope services later, both parties can negotiate the additional costs and update the project schedule accordingly.
Performance measurement: Clearly defining out-of-scope services allows both parties to measure the project’s performance accurately. It enables them to assess whether the agreed-upon deliverables are achieved within the specified timeframe and budget, without any confusion regarding tasks or features that were not part of the original scope.
Change management: Explicitly listing out-of-scope services can make it easier to manage changes to the project scope. If the client requests additional services, both parties can refer to the out-of-scope list to determine whether the new request is within the original scope or requires a scope change and additional negotiation.

In summary, expressly stipulating out-of-scope services in your project schedule is crucial for clear communication, effective scope and cost management, proper resource allocation, performance measurement, and change management. By defining out-of-scope services, both the client and the development team can have a shared understanding of the project’s boundaries and avoid potential conflicts, contributing to the project’s overall success.

Acceptance testing

Acceptance testing is a process where the client evaluates the milestone deliverables against predetermined acceptance criteria to determine if it meets their requirements.

Important aspects to address in the Project Schedule include-

Acceptance criteria: What the acceptance criteria is for each deliverable. For example, must the deliverable be accepted if it is in accordance with the specifications? Or a more provider friendly criteria may be that the deliverable must be accepted if it materially conforms to the specification based on the client’s reasonable opinion.
Process participation by the developer: Developers may play an active role in the acceptance testing process. Be clear on whether the developer must support the execution of tests and whether any fees are payable for the developer’s participation.
Suspension of acceptance tests due to non-conformity: If Non-Conformities (generally a defined term) are discovered during the acceptance testing, the client may suspend the testing process until the developer addresses and resolves the issues.
Correction of non-conformity: Upon identifying any non-conformities, the developer is responsible for correcting them within a specified timeframe, as agreed upon in the Project Schedule. The milestone deliverable should then be retested to ensure the non-conformities have been resolved.
Required notices and timeframes: The Project Schedule should define the required notices and timeframes for various stages of the acceptance testing process, including notification of test completion, reporting of non-conformities, and deadlines for correcting them.
Repeated failures of acceptance tests and termination rights: If the milestone deliverables repeatedly fails to pass the acceptance tests after multiple rounds of testing and corrections, the client may have the right to terminate the development agreement if specified in the Project Schedule.
Deemed acceptance: It is also important to be clear on what happens if the client does not provide any notice of non-conformities or rejection within a specified timeframe after the completion of the acceptance tests. Generally, this will be regarded as a deemed acceptance of the milestone deliverable. This approach helps prevent delays in the project and ensures that both parties can move forward with implementation or deployment.

Financial blocks

Fees, rates and payment

Making provision for a deposit in the project schedule is a good idea for several reasons:

Financial commitment: A deposit demonstrates the client’s commitment to the project, ensuring that both parties have a vested interest in the project’s success. This financial commitment can motivate both the client and the service provider to collaborate effectively and work towards achieving the project’s goals.
Risk mitigation: Deposits help mitigate financial risks for the service provider, particularly during the initial stages of the project. In case the client decides to cancel the project or fails to fulfill their obligations, the deposit provides a degree of financial protection to the service provider, allowing them to cover any costs incurred up to that point.
Cash flow management: Receiving a deposit at the beginning of the project helps service providers manage their cash flow more effectively. It enables them to allocate resources and personnel to the project without facing financial strain, ensuring that they can deliver the project on time and within budget.
Trust-building: A deposit can serve as a trust-building mechanism between the client and the service provider. By agreeing to provide a deposit, the client demonstrates their confidence in the service provider’s ability to deliver the project successfully. In return, the service provider is more likely to prioritize the client’s project and work diligently to meet their expectations.
Facilitate project planning: A deposit can also facilitate more effective project planning. With a deposit in place, the service provider can be confident that the client is serious about the project and committed to its success. This allows the service provider to allocate resources, schedule tasks, and plan for contingencies with greater certainty.

In summary, incorporating a deposit provision in the project schedule offers several benefits, including demonstrating financial commitment, mitigating risks, managing cash flow, building trust, and facilitating project planning. It serves as a safety net for the service provider while also ensuring that the client is committed to the project’s success.

Deposit

Milestones refer to predefined, significant events or checkpoints in the Project that indicate progress towards completing the Project.

These milestones are often tied to specific deliverables, such as a completed feature, a working prototype, or the final product.

Milestones serve several purposes:

Project Management: They help both the development team and the client track progress, identify potential issues, and ensure the project is on schedule. By dividing the project into smaller, manageable phases, milestones make it easier to plan and allocate resources effectively.
Accountability: Clearly defined milestones provide a basis for evaluating the performance of the team. They allow the client to assess whether the team is meeting expectations and delivering on their commitments.
Payment Structure: Milestones are often used as triggers for payment. Upon the successful completion and approval of a milestone, the client releases a pre-agreed portion of the total payment to the provider. This approach helps mitigate risks for both parties and ensures that payments are tied to demonstrable progress.
Client Involvement: By incorporating regular reviews and approvals into the milestone process, clients have the opportunity to provide feedback and request changes as needed. This collaborative approach helps ensure that the final product aligns with the client’s vision and requirements.

Recoverable expenses

Third-party costs, sometimes referred to as external costs or pass-through costs, are expenses incurred by a service provider or contractor for goods, services, or resources provided by external entities or suppliers that are necessary for the successful execution of a project. These costs are separate from the service provider’s own fees for their work and are typically charged back to the client.

Some common examples of third-party costs include:

Subcontractors or consultants: Fees paid to external experts or specialists who are brought in to assist with specific aspects of the project, such as specialized engineering, design, or consulting services.
Software licenses and subscriptions: Costs associated with obtaining software licenses, online services, or subscriptions necessary for the project’s execution, which are not included in the service provider’s own fees.
Equipment rental or purchase: Expenses related to renting or purchasing equipment, tools, or machinery required for the project, which are not part of the service provider’s standard resources.
Permits and fees: Charges for obtaining permits, licenses, or certifications required for the project, such as building permits, environmental permits, or inspection fees.

It is important for both the service provider and the client to have a clear understanding of which third-party costs will be incurred during the project, and how they will be managed, documented, and billed. To ensure transparency and avoid disputes, third-party costs should be explicitly addressed, including any limitations, caps, or approval processes that may apply. By properly managing and documenting third-party costs, both parties can avoid unexpected expenses and maintain better control over the project’s budget.

Third-party costs

For example, specifications in software development agreements can include the following aspects:

Functional Requirements: These specifications define what the software is expected to do, describing the features, user interactions, and overall functionality. Functional requirements can be expressed as use cases, user stories, or system requirements.
Non-functional Requirements: These specifications describe the quality attributes or characteristics of the software, such as performance, scalability, security, maintainability, and usability. Non-functional requirements help ensure that the software meets the desired level of quality and operates effectively in its intended environment.
Technical Requirements: These specifications outline the technical aspects of the deliverables, such as programming languages, platforms, frameworks, libraries, or standards that the development team must adhere to during the project.
Design Constraints: These specifications define any limitations or constraints on the software’s design or architecture, such as specific technologies, compliance with industry regulations, or compatibility with existing systems.
Format and Presentation: Deliverable specifications may also include requirements related to the format and presentation of the deliverables, such as document templates, file formats, or naming conventions.

Liquidated damages

Liquidated damages are predetermined, mutually agreed upon amounts of compensation that a party is obligated to pay if they fail to fulfill certain contractual obligations or meet specific performance criteria.

They are designed to provide a reasonable estimate of the potential damages a party may suffer due to non-performance or delay and are typically included in a contract as a means of managing risk and encouraging timely completion of a project.

Generally, where there is a significant delay in the project, and the parties agree to make use of liquidated damages provisions, the following aspects will need to be addressed-

Long stop date: A long stop date is a deadline set in the contract by which a specific phase of the project must be completed. Failure to complete the phase by this date may trigger liquidated damages, as it represents a breach of the contractual obligation to deliver the project within the agreed-upon time frame.
Types of liquidated damages for late delivery: Liquidated damages for late delivery can be structured in various ways, depending on the nature of the project and the potential impact of delays. Some common types include:
a. Per day/week/month: A fixed amount is charged for each day, week, or month that the project phase remains incomplete beyond the long stop date. This approach provides a clear and straightforward calculation of the damages.
b. Percentage of contract value: A percentage of the total contract value or the value of the specific phase is charged as liquidated damages for late delivery. This approach ties the damages to the overall project’s financial impact.
c. Milestone-based: Liquidated damages are applied when specific milestones tied to the phase are not met by the long stop date. The damages can be calculated as a fixed amount or a percentage of the milestone value.
Caps on liquidated damages: It is common for contracts to include a cap on liquidated damages, limiting the total amount that can be claimed by the other party. Caps are typically set as a percentage of the total contract value or the value of the specific phase, ensuring that the potential damages remain proportional to the project’s overall financial scope. Caps on liquidated damages help strike a balance between compensating the the party for losses and avoiding excessive penalties that may disproportionately impact the defaulting party.

In conclusion, liquidated damages serve as a means to manage risk, provide compensation for delays or non-performance, and encourage timely completion of projects. When including liquidated damages provisions in a contract, it is essential to consider the long stop date for each phase, the types of damages for late delivery, and any applicable caps on damages to ensure a fair and reasonable approach to managing project risks.

Also, certain legal jurisdictions may have certain requirements around liquidated damages provisions, which, if not met, may invalidate these provisions. It is, therefore, important that you understand exactly how liquidated damages are treated with due regard to the contract’s governing law before inserting any such provisions.

Early completion bonus

Early completion bonuses are financial incentives offered to a provider for completing a project or a specific phase of the project ahead of the agreed-upon schedule.

These bonuses serve as a motivator for the provider to deliver the project more efficiently and rapidly, which can be advantageous for the client.

When considering early completion bonuses, it is essential to keep the following factors in mind:

Realistic expectations: Ensure that the early completion bonus is tied to a realistic and achievable schedule. Setting overly ambitious targets may lead to shortcuts or compromised quality in the project.
Quality assurance: Implement proper quality assurance measures and performance criteria to ensure that the provider does not sacrifice the quality of the work to meet the early completion bonus requirements.
Bonus structure: The early completion bonus can be structured as a lump sum, a percentage of the total contract value, or a tiered system based on the degree of early completion. It is important to determine an appropriate bonus structure that provides adequate incentives while maintaining a balance between cost and benefits.
Contractual clarity: Clearly outline the terms and conditions for the early completion bonus in the project contract, including the deadlines, performance criteria, and the calculation of the bonus. This will help avoid misunderstandings or disputes between the client and the provider.

In conclusion, early completion bonuses can be an effective tool for motivating providers to complete projects ahead of schedule, providing benefits to the client in terms of cost savings, minimized disruptions, and reduced risks. However, it is essential to carefully consider the project’s unique circumstances and set realistic expectations, ensuring that the early completion bonus does not compromise the project’s quality or lead to unintended consequences.

Miscellaneous Blocks

Third-party materials

In the context of a software development project, third-party materials refer to software components, libraries, frameworks, or tools developed and maintained by external entities or vendors that are used by a service provider or contractor to build, enhance, or support the project.

These materials can help save time and resources by leveraging existing, proven solutions instead of building everything from scratch. Examples of third-party materials include open-source libraries, commercial software components, application programming interfaces (APIs), and software development kits (SDKs).

It is important to specifically stipulate the approved third-party materials in the project schedule for the following reasons:

License compliance: Third-party materials often come with licenses that dictate how they can be used, modified, and distributed. By specifying the approved materials, the project can ensure compliance with the relevant licenses, avoiding potential legal issues and penalties.
Compatibility: Clearly defining the approved third-party materials helps ensure that all components of the project are compatible with each other, reducing the risk of integration issues or conflicts that could result from using unapproved or incompatible materials.
Quality assurance: Specifying the approved third-party materials allows the project team to assess the quality, reliability, and performance of these components, ensuring that they meet the project’s requirements and standards.
Security: By stipulating the approved third-party materials, the project can minimize security risks associated with using unvetted components or libraries, which may contain vulnerabilities, malware, or other threats that could compromise the project’s security and integrity.
Intellectual property rights: Clearly defining the approved third-party materials helps manage intellectual property rights, ensuring that the project does not infringe on any patents, copyrights, or trademarks held by the creators of the third-party materials.
Maintenance and support: Specifying the approved third-party materials can help the project team plan for future maintenance and support requirements, as they will have a clear understanding of the materials used in the project and their respective update cycles, documentation, and support channels.
Cost management: As discussed above, some third-party materials may require licensing fees, subscriptions, or other costs. By stipulating the approved materials in the project schedule, the project team can better manage and plan for these costs.

In conclusion, specifically stipulating the approved third-party materials in the project schedule is essential for ensuring license compliance, compatibility, quality, security, intellectual property rights management, maintenance, and cost management.

Also, stipulating the approved third-party materials in the project schedule helps reduce risks, streamline development processes, and ultimately contributes to the overall success of the project.

Warranties

Warranties relating to milestone deliverables are assurances provided by a provider that the work completed during each milestone or phase of a project meets the agreed-upon specifications.

The project schedule will stipulate the period of the applicable warranties. An SLA, which is a separate document, will determine what happens if, for example, it later becomes apparent that the milestone deliverable does not meet the specifications and the timeframe within which the provider must bring the variable up to spec.

Support & maintenance

The Support and Maintenance Period typically begins following the conclusion of the Warranty Period. This period is necessary to ensure that if any errors emerge, the service provider is obligated to address and resolve them. The Project Schedule outlines the agreed duration for the support and maintenance services, while the terms and conditions governing these services are detailed in a separate Service Level Agreement (SLA).

The Building Blocks of a Contract

Building Blocks of a Contract

In this article, we have a look at the main building blocks of a contract

Introduction

Contracts can be daunting. In fact, a report by World Commerce and Contracting association reveals that almost 90% of businesspeople find contracts hard or impossible to understand.

So, before diving into the world of contracts, it’s important to get one thing straight –

When drafting a contract, your aim must be to create clarity. If your aim is to screw over the other party, the DocNinja guides are not for you.

In an article published in Harvard Business Review written by Shawn Burton, the general counsel for GE Aviation’s Business & General Aviation, Shawn writes –

However, I believe it is indeed possible—as a three-plus-year effort to promote plain-language contracts at GE Aviation’s digital-services business has demonstrated. Since this initiative began, in 2014, that unit has signed more than 100 such contracts. Those agreements took a whopping 60% less time to negotiate than their previous legalese-laden versions did. Some customers have even signed plain-language contracts without a single change. Customer feedback has been universally positive, and there hasn’t been a single customer dispute over the wording of a plain-language contract.

Main blocks

Agreement specific

The Agreement specific blocks contain information specific to the transaction, for example, the parties, the background to the transaction, definitions and the scope of the Agreement.

Core legal provisions

The core legal provisions are those where the respective legal teams like flexing their muscles.

These provisions essentially address various risks relating to the transaction.

The core legal provision blocks include limitation of liability, indemnities, term and termination, warranties, intellectual property and confidentiality.

When looking at the WCC data on most negotiated terms, it is clear that these provisions require careful consideration –

WCC ranking	Blocks
1	Limitation of liabilities block
3	Indemnities block
5	Termination block
8	Warranties block
10	Intellectual property block
15	Confidentiality and non-disclosure block

Boilerplate

It is often said that the devil is in the details – When you have been working with contracts for a while you will know this idiom rings true when building your boilerplate clause.

Boilerplate provisions are used to regulate various miscellaneous aspects of the transaction.

Often labelled as “just boilerplate” or “less important” clauses, these clauses still requires careful consideration and generally includes clauses dealing with insurance, adherence to policies, regulatory compliance, information access and management, applicable law and jurisdiction, force majeure, entire agreement and dispute resolution.

Schedules

Contract schedules generally contain information requiring additional input from non-legal business teams within the business.

For example, take a software development agreement; the first schedule may contain technical and functional specifications relating to the development, deliverables, milestones, dependencies etc. These schedules are likely the most important aspect of a contract when considering that the WCC data indicates that Scope and Goals / Specifications are considered the most important terms when negotiating a contract.

Schedules often forming part of an Agreement include schedules relating to the services / products, fees and costs, data, SLAs and change control.

Agreement specific

Parties

The block containing the Parties to the Agreement needs to detail the registered name of the contracting Parties, registration number, address, and jurisdiction within which the party is registered/incorporated in.

Background

The background block is also sometimes referred to as the recitals.

Background / recitals are not a legal requirement and do have a direct legal effect on the obligations of the Parties under the contract.

Despite the above, the background / recitals may become important when interpreting the the agreement.

Definitions

The purpose of the definition block is to provide certain assigned meanings to a specific word or phrase.

Whenever the word or phrase is used in the Contract, the first letter of the word is capitalized.

Definitions therefore assist in creating clarity in contracts. That being said, sometimes the “over use” of definitions can cause more ambiguity than clarity. As a rule of thumb, if the ordinary meaning of a word clearly conveys the meaning that you require, don’t create a definition for that word.

Scope

The scope block contains the nuts and bolds of the specific transactions. Without these provisions, the contract will not make sense.

Each contract will have a different scope. For example, the scope of a Software Development Agreement differs from the scope of Software License Agreement.

More information on the different scopes for different contracts –

Software Development Agreement
Software Licence Agreement
Services Agreement
Reseller and Distributor Agreements
Service Level Agreement / Schedule
Data Privacy and Security Agreement / Schedule
Cloud Services Agreement
API Agreement
Software Escrow Agreement
Purchasing Agreement
Non Disclosure Agreement
Subcontractor Agreement

Core legal provisions

Limitations

Part of the legal team’s responsibilities is to limit the risks of the business.

With contracts, this is done by limiting certain claims or excluding certain claims that may arise that relate to the contract.

The limitation block contains –

the types of losses and damages that a Party will not be able to claim from the other party; and
limitations places on certain types of claims.

Clauses relating to the limitation of liability are also some of the most negotiated clauses among legal teams and require careful consideration.

Learn how to build a limitation of liability clause.

Indemnities

Indemnities are used to ensure a party is not held responsible for something the other party causes.

As an example, if you licence software, you don’t want to be sued for copyright infringement when using the software.

To address the concern about being sued for something that is not your problem, you can use an indemnity block, which provides that the other party must indemnify you against claims of a certain nature.

Learn how to build an indemnity clause.

Termination

When a Party does not honour the contract terms, you must have a way out of the contract.

On the other hand, you don’t want a Party to walk away from a contract if they no longer want to be bound by the contract.

The termination block determines when a Party can terminate a contract.

Generally, if there is a material breach of the contract, the Party who is in default (in other words, the Party who committed the breach) will be provided with a number of days to fix the breach. If the breach is not fixed, the aggrieved Party’s right to terminate becomes available.

Then, there are other situations where the right to terminate may become available. For example, the Party files for bankruptcy or fails to meet a certain service level.

It is also possible to terminate a contract where nothing has gone wrong. This type of termination is commonly referred to as termination for convenience.

Learn how to a build termination clause.

Warranties

When you buy a product or ask someone to do something for you, you want to be sure the product meets certain standards or that good and proper service is provided.

In contracts, warranties ensure the product meets the requirements or the service is provided as required.

Learn how to build a warranties clause.

Intellectual property

Intellectual property is not limited to the usual suspects like copyright, patents and designs.

Intellectual property considerations are at play with every product supplied or service rendered.

The intellectual property blok generally comprises provisions relating to who owns which intellectual property.

For some businesses, their intellectual property is the most valuable asset of the business, and for this reason, careful consideration must be given when drafting intellectual property provisions.

Confidentiality

For certain types of intellectual property (for example, trade secrets) to enjoy protection under the law, efforts must be made to protect it, for example, by concluding contracts with confidentiality provisions.

The confidentiality block contains various provisions addressing what information constitutes confidential information when it can and cannot such information be disclosed to any other parties, and what happens if someone breaches the confidentiality provisions.

Learn how to build a confidentiality clause.

Boilerplate

Boilerplate blocks

Schedules

FAQs

Which styles or fonts must I use?

Well, whatever floats your boat. However, keep in mind that more and more people view and sign contracts on mobile devices.

Articles, sections and subsections, what's the difference?

What’s the difference? Well, it depends on which jurisdiction you are based in. Clauses, articles, sections, and subsections refer to a specific place in an Agreement.

There are various numbering methodologies used in contracts. For example, some Agreements will use numerals, others will use letters, and some will use numerals, roman numerals, and letters. There is no right or wrong.

The Author

Martin Kotze is a commercial lawyer with over 10 years of experience. He specialises in transactional work within the Tech, Financial Services and Property industries.

He is also one of the co-founders at DocNinja and regularly advises companies on how to contract better with their customers and vendors.

This is a free 30min consultation to better understand your business and your needs.

Building a Service Level Agreement (SLA)

In this article, we have a look at some of the important aspects that must be kept in mind when drafting a Software / SaaS / API SLA.

Most disputed terms WCC ranking:

Most important terms WCC ranking:

Most negotiated terms WCC ranking:

Introduction

Time and time again, WCC data shows Service Levels rank within the top 5 most important and disputed terms.

However, when looking at where Service Levels rank when it comes to Most Negotiated Terms, Service Levels are not even within the top 10 of ranked terms.

The WCC Contracting Principles provide sound guidance when dealing with Service Levels and recommend:

While suppliers intend to provide high quality services, SLA Failures can occur over time given the complex nature of technology services. SLA Failures should not be deemed to rise to the level of a breach of contract.
SLAs are intended to underscore supplier’s efforts to maintain the service, proactively identify potential problems, and quickly resolve any SLA Failures.
SLA targets and SLA Credits should be set at levels that drive high performance but do not create financial windfalls for customers or unreasonable financial exposure for suppliers.
SLA performance targets should be measurable and verifiable and should reflect minimum acceptable levels of supplier performance, focusing on critical service elements that are essential to the value of the service being provided.

What is a Support SLA?

A Support SLA may substantially differ from Provider to Provider and may sometimes even contain aspects that relate to the correction of Errors and general assistance to Customer.

For purposes of this article, Support Service mainly relate to those services a Provider provides to the Customers to help them use the Product.

A Support SLA is therefore a document that details what is required (in terms resources and turnaround times) from the Provider if a user requires assistance with the Product.

What is a Error Correction SLA?

When providing Software, SaaS or an API (“Product”), there is always the possibility that there may be a couple of problems (“Errors”) that may only come to light once the Customer starts using the Product.

For the above reason, a Provider will provide the Product “as is” with a disclaimer that no warranties are made that the Product is error-free.

From a Customer’s perspective, the above may be problematic. What if the Product plays a vital role in the Customer’s business? In such a case, the Customer wants to be assured that if they come across any Errors, they will be sorted out (and sorted out quickly if they are severe) so the business can carry on with operations.

A Technical Support SLA is then used to provide certain timeframes within which any reported Errors must be acknowledged and fixed by the Provider.

What is an Uptime SLA?

Uptime SLAs usually relate to SaaS and APIs. If the Provider is required to give an Uptime service level, it means that the Provider must ensure the SaaS / API is working for a certain percentage time over a certain measuring period. For example, if a 99% uptime service level is given for SaaS, the Provider must ensure that the SaaS is working 99% of the time during a measurement period.

What is System Response SLA?

These days, businesses are relying heavily on external APIs and Cloud Services. As technology advances and new systems get introduced, the speed which systems need to function becomes vital. These APIs and Cloud Services may be an important cog in their business process, and the optimal functioning thereof is vital.

For the above reasons, businesses generally seek to impose service levels relating to the speed of the APIs and Cloud Services. A System Response SLA is therefore used to provide the service levels at which the API / Cloud Service need to respond once a System Request (for example, an API call) is made.

Building blocks

Process Block

When configuring the Process Block, the following will need to be considered –

How must the Requests for services under the SLA be submitted? Email, telephone, customer portal?
Who will be able to submit Requests for services under the SLA? Only the Customer’s Technical Contacts?
What information must be provided when submitting a Request?

Service Levels Block

The Service Levels Block is the most important Block forming part of the SLA and contains the quantifiable performance standards.

Important aspects that must be configured as part of the Service Levels Block –

Support SLA:

Available Support Services (for example, assisting users with general non-technical questions)
Time timeframes within which these Support Services must be provided
The exclusions (i.e. the situations where the Provider will not be required to provide the Support Services – for example, if the user is using the Product in a manner inconsistent with the Product’s Documentation).

Error Correction SLA:

Types of Errors (for example, Critical Errors, Urgent Errors and Service Impacting Errors)
Timeframes within which a Response must be provided if a Request is submitted to Remedy a specific type of Error
Timeframes within which a Remedy must be provided if a Request is submitted to Remedy a specific type of Error
The exclusions (i.e. situations where the Provider will not be required to provide the Error Correction Service – for example, if the Product is combined with a Third Party Product that the Provider has not approved)
The exclusions (i.e. the situations where the Provider will not be required to provide the Support Services – for example, if the user is using the Product in a manner inconsistent with the Product’s Documentation)
The Customer obligations (for example, the Customer must provide the Provider with Remote access to the extent required to Remedy the Error.)

Uptime SLA:

The Downtime brackets (for example, bracket 1 – where Downtime is between 95% and 99.99%)
The Measuring Period (i.e. over which period will Downtime be measured?)
The exclusions (for example, Scheduled Maintenance, Downtime caused by the Customer etc.)

System Response Time SLA:

The System being measured (for example, a third party applications to which API calls are made)
How will the process be measured (i.e. the technical description of the process and related metrics)
The Target System Response Time
The Measuring Period (i.e. over which period the System Responses be measured?)

Fees Block

There will not necessary be any fees for SLAs.

However, there are situations where a Provider would attach a fee to a “upgraded” SLA especially where there are certain Support Services that take up resources.

In such a case, the Provider may provide a certain number of “free hours”. Anything above the provided “free hours”, will then be billed at the relevant rates.

Important aspects to be configured as part of the Fees Block include:

The Fee amount
The frequency of payment of the Fee (for example, monthly or yearly?)
Is the Fee payable in advance or in arrears?
Are there any escalations that will apply to the Fee?
Will any escalation on the Fee be capped if there is a renewal?

Monitoring & Reporting Block

Import aspects that need to be configured as part of the Monitoring Block include:

Who is responsible for monitoring the Service Levels?
How will reporting work?
Within how many days after each Measurement Period must the report be provided?

Credits Block

Generally, the go-to remedy if the Service Levels are not complied with are Credits.

Important aspects to configure as part of the Credits Block include:

Is there a process that must be followed before Credits are issued?
Must Credits be requested within a provided timeframe?
How will the Credits be calculated?
Will Credits be the sole remedy?
Will there be any cap placed on the Credits?
Will Credits be forfeited on termination of the Main Agreement?
Which exclusions apply to the issuance of Credits? For example, Credits will not be issued if the Service Levels are not complied with in the situation where the service under the SLA was provided as a result of the Customer that was negligent.

Termination Rights Block

Hand-in-hand with the Credits Block is the Termination Rights Block.

From a Customer’s perspective, if there is constant failure of the service levels, the Customer would want to be able to terminate the Main Agreement without penalty.

Aspects that need to be configured as part of the Terminations Right Block include:

When will the termination right be available? For example, if the SLA is not complied with over 3 consecutive Measurement Periods.

Escalation Block

What if the Customer does not get any joy from the support desk? Will there be an escalation procedure where the Customer can escalate the Support Request to a more senior person?

From a Provider’s perspective, access to more senior support personnel must only be available in extreme cases and cases where the Customer has opted for a better SLA.

Out-of-scope Services Block

From a Provider’s perspective, the scope of the services available under the SLA must be as narrow as possible.

The aspects to be configured as part of the Out-of-scope Service Block include:

Which services will be regarded as Out-of-scope Service? Services outside Support Hours?
Will Services provided as the result of a Customer Cause also be regarded as Out-of-scope Service?

FAQs

Is the SLA a stand alone agreement?

SLA’s will be generally be incorporated as Schedule to a Main Agreement (for example, a SaaS Agreement) if the document is negotiated.

It is, however, also possible that a SLA takes the form of a policy that is published on the Provider’s website. In such a case, the Customer may likely agree to the SLA by way of clickwrap when subscribing to, for example, the SaaS.

Will Software Maintenance Services also be addressed in the SLA?

Software Maintenance aspects related to Updates and New Releases is generally addressed in a separate Agreement.

The Author

Martin Kotze is a commercial lawyer with over 10 years of experience. He specialises in transactional work within the Tech, Financial Services and Property industries.

He is also one of the co-founders at DocNinja and regularly advises companies on how to contract better with their customers and vendors.

This is a free 30min consultation to better understand your business and your needs.

The building blocks of an API Licence Agreement

The building blocks of a API Licence Agreement

In this article, we have a look at some of the important aspects that must be kept in mind when drafting an API Licence Agreement

What is an API Licence Agreement?

When you want different systems or applications to communicate and interact with each other you would generally use an Application Programming Interface (API). APIs typically provide a set of tools, documentation, protocols, and specifications.

For example, take Software as a Service Providers. The Provider may add additional functionality to their offering by incorporating software from a different vendor as part of their offering. To enable the SaaS Provider to use the software of the other vendor as part of their SaaS, an API will be required. The terms and conditions relating to the use of the API is then determined by the API Licence Agreement.

Building blocks

API Licence Block

Key Components

Licence grant

The licence grant is the most important provision of the Agreement. Careful consideration should therefore be given whether or not the licence granted is subject to the payment of the Fees and compliance with other terms and conditions. Consideration should also be given to whether or not the licence is:

also provided to affiliates;
provided on an exclusive basis; and
is territory bound.

Typical rights provided to the Licensee are:

use the API solely for the purposes of internally developing the Applications that will communicate and interoperate with the Licensor Offering; and
display certain Licensor Marks in compliance with usage guidelines that the Licensor may specify from time to time solely in connection with the use of the API and the Applications and not in connection with the advertising, promotion, distribution, or sale of any other products or services.

These rights, however, need to be configured specifically for the transaction at hand.

Restrictions

Next, consideration should be given to the restrictions imposed on the Licencee. The typical restriction you whould encounter are:

copy, modify, or create derivative works of the API, in whole or in part;
rent, lease, lend, sell, sublicense, assign, distribute, publish, transfer, or otherwise make available the API;
reverse engineer, disassemble, decompile, decode, adapt, or otherwise attempt toderive or gain access to any software component of the API, in whole or in part;
remove any proprietary notices from the API;
use the API in any manner or for any purpose that infringes, misappropriates, or otherwise violates any intellectual property right or other right of any person,or that violates any applicable law;
combine or integrate the API with any software, technology, services, or materials not authorsed by the Licensor;
design or permit the Applications to disable, override, or otherwise interfere with any of the Licensor-implemented communications to endusers, consent screens, user settings, alerts, warning, or the like;
use the API in any of the Applications to replicate or attempt to replace the user experience of the Licensor Offering; or
attempt to cloak or conceal the Licensee’s identity or the identity of the Applications when requesting authorization to use the API.

These restrictions must be configured to suit the particular transaction at hand.

_

Marks

Often a Licensee of an API would want to use and include some of the Licensor’s Marks, for example, to increase the credibility of their offering and marketing purposes. If this is the case, provisions must be added to regulate using the Licensor’s Marks.

Other Components

Additional components that may be added include provisions relating to:

end-user responsibility
API keys
API standards

Configuration

Provider friendly	Customer friendly
Licence grant is subject to payment of Fees and compliance with the Agreement	Licence may only be revoked if Agreement is terminated
Non-exclusive	Exclusive
Various restrictions on use of the API	No restriction relating to the use of the API

Support and Maintenance Block

The Provider may provide support and training to the Customer’s Users. If this is the case, the terms of the support and training must be detailed in this section.

If training services are included as part of the Software Licence Agreement, ensure that the commercials relating to these services are unambiguously stipulated within the Agreement.

Fees & Payment Blocks

The payment provisions will detail payment terms, overdue amounts, method of payment, setoff, taxes, payment disputes etc.

Intellectual property

Generally, the Parties will retain their intellectual property rights and the Provider will own any new Intellectual Property Rights relating to the Software.

An aspect that will, however, need to be addressed in the Software Licence Agreement is feedback rights. In other words, if the Customer provides the Provider with feedback relating to the Software, will the Provider be able to use the feedback to improve the Software and make these improvements available to other Customers?

The default position is usually that the Provider may use all feedback freely without restriction or obligation.

Confidentiality

Both Parties would generally want to protect such sensitive information, which, if disclosed to certain third parties, will be detrimental to their business. The confidentiality provisions provide which information must be regarded as confidential, obligations relating to handling confidential information, and what happens if there are unauthorised disclosures.

Limitation of liability

Unrecoverable losses and maximum liability are generally dealt with under the limitation of liability provisions. Unrecoverable losses may include, for example, consequential losses, and claims relating to breach of data protection provisions may be limited under the maximum liability amount to a fixed amount.

Reps & Warranties

The Customer and Provider will usually provide certain mutual warranties. These may include, for example, that they have the legal capacity to enter into the Agreement and that they have not offered unlawful or prohibited inducements to the other Party or any other person in connection with the Agreement.

Then there will also be warranties related to the Cloud Services that will be provided.

Typical warranties will include that no viruses will be introduced into the Cloud Services, the Cloud Services does not and will not infringe on any third party intellectual property rights, the Cloud Services will be updated as necessary to comply with applicable laws etc.

Breach of the warranties will also need to be addressed, and the disclaimers that relate to the warranties.

Indemnities

An indemnity often found in a Software Licence Agreement is an indemnity relating to Intellectual Property infringement claims that a third party may institute against the Customer.

The indemnity provisions need to identify what will be regarded as indemnified losses (what will be covered), what will trigger the indemnity and the claims procedure.

Audit rights

Where the licence is limited to, for example, the number of users, the Provider would want to have the right to conduct audits on the Customer’s use of the Software.

With the audit clause, aspects often addressed include notices of audits, the number of allowed audits, confidentiality and what happens if there is an adverse finding.

Term and termination

The Parties may conclude the Software Licence Agreement for a fixed term or it may be a perpetual licence. If it is a fixed-term period licence, there may also be auto-renewal of the Term, which must also be detailed within this section.

The termination provisions detail when a Party can terminate the Agreement before the Term ends and may also provide for termination assistance the Provider must provide if the Agreement is terminated.

Disputes

How will the Parties deal with disputes? Through a Court process or alternative dispute resolution? Are there different processes for different disputes – For example, expert determination for disputes relating to technical aspects of the Cloud Services?

Boilerplate provisions

The boilerplate clauses will include the provisions relating to public disclosure, third-party beneficiaries, how amendments will be dealt with, how notices under the Agreement must be provided, assignment etc.

FAQs

Will an API Agreement be in the form of a clickwrap agreement?

Cloud Services are usually provided under a subscription-based model where access to the Software is provided to the Customer through an online login. No copy of the Software is provided to the Customer, and there is no need for a licence.

Read more about Cloud Services Agreements.

When it comes to a Software Licence, the Software is installed on the Customer’s computers.

What is the difference between a Software Development Agreement and a Software Licence Agreement?

With a Software Licence Agreement, there may be small modifications as part of the support and maintenance services.

If new Software or extensive changes to existing Software is required, a Software Development Agreement will be a more appropriate agreement.

Read more about Software Development Agreements.

What is the difference between a End-User Licence Agreement (EULA) and a Software Licence Agreement?

A End User Licence Agreement (EULA) is for licensing a commercial or off-the-shelf (that is, without modification or customization) Software. The term “EULA” commonly refers to an agreement that is not negotiated or signed by the parties.

Must Acceptance Testing provisions be included in the Software Licence Agreement?

Generally, Software Licence Agreements do not include any Acceptance Testing provisions.

However, there are situations where a Customer may require changes to the Software. In such cases, it may be appropriate to include Acceptance Testing provisions.

Must Software Escrow provisions be included in the Software Licence Agreement?

There may be a situations where the Software is “mission critical” to the Customer. In such cases, it may be appropriate to provide for certain escrow arrangements.

The Author

Martin Kotze is a commercial lawyer with over 10 years of experience. He specialises in transactional work within the Tech, Financial Services and Property industries.

He is also one of the co-founders at DocNinja and regularly advises companies on how to contract better with their customers and vendors.

This is a free 30min consultation to better understand your business and your needs.

The building blocks of a Software Licence Agreement

In this article, we have a look at some of the important aspects that must be kept in mind when drafting a Software Licence Agreement

What is a Software Licence Agreement?

A Software Licence Agreement is, in essence, a copyright licence. The bundle of rights associated with this type of copyright generally includes the exclusive rights to:

use, copy and reproduce the Software;
distribute the Software;
modify, translate or create derivative works of any part of the Software; and
display, or perform in any media and through any technology the Software.

The Software Licence Agreement, therefore, provides the Customer with the right to do the above (subject to the restrictions as per the Software Licence Agreement).

Building blocks

Scope of Software Licence

To learn more about the specific building blocks of a Software Licence grant clause follow this link.

The Provider would want to have the narrowest grant of rights. The Customer, on the other hand, would typically want broad licence. As a result, the scope of the license is among the most commonly negotiated provisions.

Another aspect often the subject of negotiation is whether the Licence grant is subject to the payment of the license fees under the Agreement. Furthermore, the Provider may also want to make the licence grant subject to the Customer’s compliance with all terms and conditions as per the Agreement.

Support and training

The Provider may provide support and training to the Customer’s Users. If this is the case, the terms of the support and training must be detailed in this section.

If training services are included as part of the Software Licence Agreement, ensure that the commercials relating to these services are unambiguously stipulated within the Agreement.

Intellectual property

Generally, the Parties will retain their intellectual property rights and the Provider will own any new Intellectual Property Rights relating to the Software.

The default position is usually that the Provider may use all feedback freely without restriction or obligation.

Payment

The payment provisions will detail payment terms, overdue amounts, method of payment, setoff, taxes, payment disputes etc.

Confidentiality

Limitation of liability

Reps & Warranties

Then there will also be warranties related to the Cloud Services that will be provided.

Breach of the warranties will also need to be addressed, and the disclaimers that relate to the warranties.

Indemnities

An indemnity often found in a Software Licence Agreement is an indemnity relating to Intellectual Property infringement claims that a third party may institute against the Customer.

The indemnity provisions need to identify what will be regarded as indemnified losses (what will be covered), what will trigger the indemnity and the claims procedure.

Audit rights

Where the licence is limited to, for example, the number of users, the Provider would want to have the right to conduct audits on the Customer’s use of the Software.

With the audit clause, aspects often addressed include notices of audits, the number of allowed audits, confidentiality and what happens if there is an adverse finding.

Term and termination

Disputes

Boilerplate provisions

FAQs

What is the difference between a Cloud Services Agreement and a Software Licence Agreement?

Read more about Cloud Services Agreements.

When it comes to a Software Licence, the Software is installed on the Customer’s computers.

What is the difference between a Software Development Agreement and a Software Licence Agreement?

With a Software Licence Agreement, there may be small modifications as part of the support and maintenance services.

If new Software or extensive changes to existing Software is required, a Software Development Agreement will be a more appropriate agreement.

Read more about Software Development Agreements.

What is the difference between a End-User Licence Agreement (EULA) and a Software Licence Agreement?

Must Acceptance Testing provisions be included in the Software Licence Agreement?

Generally, Software Licence Agreements do not include any Acceptance Testing provisions.

However, there are situations where a Customer may require changes to the Software. In such cases, it may be appropriate to include Acceptance Testing provisions.

Must Software Escrow provisions be included in the Software Licence Agreement?

There may be a situations where the Software is “mission critical” to the Customer. In such cases, it may be appropriate to provide for certain escrow arrangements.

The Author

Martin Kotze is a commercial lawyer with over 10 years of experience. He specialises in transactional work within the Tech, Financial Services and Property industries.

He is also one of the co-founders at DocNinja and regularly advises companies on how to contract better with their customers and vendors.

This is a free 30min consultation to better understand your business and your needs.

The building blocks of a Software Development Agreement

Software Development Agreements

In this article, we have a look at some of the important aspects that must be kept in mind when drafting a Software Development Agreement

Introduction

What is a Software Development Agreement?

A Software Development Agreement is a legal contract that provides the terms and conditions between a customer and a software developer when creating a new software product.

It is important to have this agreement in place to ensure that both parties clearly understand their roles, responsibilities, and the services to be provided.

The agreement typically includes details on the project’s scope, timelines, payment terms, intellectual property ownership, warranties, confidentiality etc.

Having a Software Development Agreement can help prevent misunderstandings and disputes that may arise during the project. It provides a clear path forward for both Parties and helps ensure that the project is completed successfully and to the satisfaction of both the customer and the developer.

What are the different types of Software Development Agreements?

There are several types of software development agreements, each with its own set of terms and conditions. However, here are some common types of software development agreements:

Time and Materials Agreement: This type of agreement is based on an hourly or daily rate, and the client is charged for the time spent on the project, along with any materials or expenses incurred.
Fixed-Price Agreement: In a fixed-price agreement, the development firm agrees to complete the project for a specific price, regardless of the time or resources required.

For larger projects, it is common to have both Statements of Work, which are mainly time and materials-based, and Statements of Work, which are fixed-priced.

Ultimately, the specific type of software development agreement best suited for a particular project will depend on the nature of the project, the client’s goals, and the development firm’s capabilities.

What are the main Software Development methodologies?

Various methodologies are adopted for software development, each with its own principles, practices, and approaches. Here are some common methodologies:

Waterfall Model: This is a linear sequential approach to software development, where each phase of the development process is completed before moving on to the next one. It is a highly structured methodology for projects with well-defined requirements and a fixed budget.
Agile Methodology: Agile is an iterative software development approach emphasising collaboration, flexibility, and constant feedback. It involves breaking down the project into smaller tasks and delivering them in short sprints, with each sprint building on the previous one.

The specific methodology best suited for a particular project will depend on the nature of the project, the customer’s goals, and the development team’s capabilities.

Agreement blocks

Transaction blocks

Engagement

The typical Software Development engagement will be a work-for-hire engagement in which the Developer provides certain software development services to the Customer.

The scope of engagement can be A-Z. For example, the Developer must design, develop, create, test, deliver, install, configure, integrate, customise, and otherwise provide and make fully operational Software.

Alternatively, the Developer must integrate Software XYZ with Software DEF.

The “engagement block” creates the primary engagement. The details of what needs to be done are then added to the Schedule – Services.

Service standards

When you, as a Customer, engage a Developer, you want to be certain the Developer will do a good job.

You also want to be sure the Developer will work efficiently, especially when you engage the Developer on a time and materials basis.

Therefore, the “services standards” block is core to the engagement.

A way to further “strengthen” the Customer’s rights is to provide that the Developer will perform the services following Good Industry Practices.

What constitutes “Good Industry Practice” is often a defined term. Here’s an example –

Good Industry Practice means the exercise of that degree of skill, diligence, and operating practice which would ordinarily be expected from a skilled and experienced person engaged in the same or a similar business.

Hand-in-hand with the “services standards” block is the Schedule – Personnel. This schedule will often detail the minimum qualifications of the personnel engaged with the project.

Documentation

The purpose of the “Documentation block” is to create an obligation on the Developer to ensure good and proper Documentation is delivered with the Software.

Software Documentation plays an important role in Software Development and details how the Software works (or, more importantly, how the Software is supposed to work).

Once a project is complete, the Developer must deliver, together with the Software, Documentation, which provides a comprehensive and detailed record of a Software’s design, functionality, and operation.

The Documentation must align with the agreed Specifications, and the Developer is generally required to warrant that the delivered Software performs per the Documentation.

In addition, this Documentation serves as a reference for software developers, testers, and end-users throughout the software development lifecycle.

Here are some specific purposes of Software Documentation:

Facilitate software development: Documentation helps software developers to understand the codebase and make changes, bug fixes or add new features effectively.
Enable maintenance and support: Documentation provides clear instructions on how to maintain and support the Software after deployment.
Promote collaboration: Documentation enables efficient communication and collaboration among team members, stakeholders, and end-users, facilitating a smoother development process.
Enhance the Software’s usability: Documentation provides guidance and instructions on how to use the Software, which can improve its usability and make it more accessible to end-users.
Ensure compliance: Documentation is often required to meet regulatory and compliance standards in industries such as healthcare, finance, and government.

Overall, software documentation is essential for ensuring that Software is well-designed, well-maintained, and meets the needs of all stakeholders involved in its development, deployment, and use.

Third-party materials

If you have been involved with Software Development before, You will know there are various resources, libraries, and APIs available than can significantly speed up the Software Development process.

However, these resources, libraries, and APIs may be a two-edged sword. Firstly, there may be cost implications for the Customer. Secondly, and more importantly, there may be licence restrictions when using these Third-Party Materials (for example, you cannot use an API for commercial purposes).

Imagine spending months developing Software on top of an API to realise that the licence terms of the API do not allow you to sell your Software in the open market. That’s money down the drain and why Third Party Materials must be addressed within your Software Development Agreement.

It is important to define Third-Party Materials clearly. Here is an example –

Third-Party Materials means any materials and information, including documents, data, know-how, ideas, methodologies, specifications, Software, content, and technology, in any form or media in which any person other than the Customer or Developer owns any Intellectual Property Right, but specifically excluding Open Source Components.

If Third-Party Materials are allowed, ensure that the Developer will be required to secure, at its sole cost and expense, all necessary rights for You, the Customer, to use perpetually and throughout the world Approved Third-Party Materials.

Open-source components

The purpose of the “open-source components” block is to regulate various aspects surrounding using open-source components as part of the Software.

There is a general misconception that open-source is “free” and “we can use it as we like”. Although this is true to some extent, adopting this attitude can have disastrous consequences down the line.

From a Customer’s perspective, it is wise to provide that only approved open-source components may be used as part of the Software.

While open-source components can offer many advantages, there are also valid reasons not to use them in a software development project. Some of these reasons include:

License compatibility issues: Different open-source projects have different licenses, which may not be compatible with each other or with the intended licensing of your Software. Incompatibilities can lead to legal and intellectual property issues.
Lack of support and documentation: Open source projects vary greatly in terms of the level of support and documentation they provide. Some projects may have limited or outdated documentation, making it harder to understand and implement the components.
Security concerns: Open source components can have vulnerabilities that expose your Software to potential security risks. Ensuring the security of open-source components may require additional time and resources.
Limited control and customization: While open-source projects can be modified, you may not have complete control over the development or direction of the project. This can make it difficult to customize or adapt the component to fit your specific needs.
Maintenance burden: Open source components may not be maintained or updated regularly. If a project becomes abandoned or moves in a direction that no longer suits your needs, you may need to take on the responsibility of maintaining or forking the project yourself.
Quality and stability: The quality and stability of open-source components can vary greatly. Some projects may have high-quality code and robust development processes, while others might be less mature or have a smaller community, leading to less reliable code and potential issues.
Integration challenges: Integrating open-source components with your existing Software or other third-party components can be challenging, as compatibility issues may arise, requiring additional development work.
Potential performance issues: Some open source components may not be optimized for performance, potentially leading to slower response times or higher resource usage than desired.
Legal liability: If an open source component infringes on a third party’s intellectual property, you might be held legally liable for damages, depending on the specific circumstances and the terms of the open source license.
Reputation and branding: Using open-source components can sometimes lead to a perception that your Software is less polished or professional, especially if the open-source project has a negative reputation or if it is not well-maintained.

When deciding whether to use open-source components in your software development project, it’s essential to carefully weigh these potential downsides against the benefits and consider your project’s specific needs and goals.

Sub-contracting

A “subcontracting” block details the conditions and limitations of subcontracting work to a third party.

The key components of a subcontracting clause typically include:

Permission: The subcontracting clause should state whether or not subcontracting is allowed and under what conditions it is permissible.
Notification: The subcontracting clause should specify whether the prime contractor is required to notify the client or the other party to the contract of any subcontracting arrangements and if so, when and how.
Approval: The subcontracting clause should specify whether the client or the other party to the contract needs to approve any subcontracting arrangements and, if so, the criteria for approval.
Subcontractor qualifications: The subcontracting clause should specify the qualifications required for a subcontractor to perform the work, including the skills, experience, certifications, and licenses needed.
Liability: The subcontracting clause should specify the liability of the prime contractor and the subcontractor in case of any breaches, damages, or delays.
Confidentiality: The subcontracting clause should specify the confidentiality requirements for the subcontractor, including protecting any proprietary or sensitive information.

Financial stability

On a big software development project, especially when dealing with a newly formed dev house, you want to avoid being caught with your pants down if the dev house cannot pay their devs.

On the flip side, if the Customer’s financial position deteriorates, the Developer would want to be able to “walk away” from the contract as soon as possible to ensure resources are not used where the Developer will likely not be paid.

A financial stability block, therefore, assists with “a way out” if a Party’s financial position goes south.

The key components of a financial stability block include:

Reviews: A Party’s right to review the other Party’s books to asses their financial position.
Termination right: If the financial position deteriorates, the Party’s right to terminate the Agreement.
Confidentiality: Provisions that stipulate that any information provided as part of the financial stability assessment should be subject to confidentiality provisions.

Audits

An audit rights block gives the Customer the right to audit the Developer’s compliance with the Agreement.

Think about a situation where you, the Customer, are paying the Customer on a time and materials basis. You want to ensure the Developer only charges you for the actual work done and that full, accurate and detailed timesheets are available for inspection.

The key components of an audit rights clause typically include the following:

Scope of the Audit: This section defines the types of records the auditing party is entitled to examine.
Notice and Timing: This section stipulates the procedures for initiating an audit and the timeframes for completing it.
Confidentiality: This section addresses the information disclosed during the audit. It may require the auditor to keep the information confidential and limit the use of the information to the purpose of the audit.
Cost and Expenses: This section addresses the costs and expenses associated with the audit. It may specify who will bear the costs and whether the auditing party will be responsible for any costs incurred by the other Party.

Benchmarking

An outsourced development team can become quite entrenched in a business. A situation where outsourced development teams become core to the operations of a business may have positives but may also hold some risks.

On the one hand, an outsourced development team can develop a unique understanding of the business; however, the business may also become particularly reliant on the dev team.

From a financial perspective, the hourly rates can go through the roof, but the output may not necessarily align with the increased rates of the outsourced development team.

A benchmarking clause can be useful in the above situation.

In general, including a benchmarking clause in a software development agreement can help the Parties set clear expectations, identify areas for improvement, and ensure that the Software remains competitive and meets industry standards.

However, the specifics of the benchmarking clause should be carefully negotiated and drafted to ensure that it is fair and reasonable to both Parties and provide a clear framework for the benchmarking process.

Key components forming part of a benchmarking block include:

Definition of benchmarking: This section defines the benchmarking process and outlines the specific metrics that will be used to evaluate performance. It may also include a reference to industry standards and best practices that will be used for comparison.
Data collection and reporting: This section establishes the procedures for collecting and reporting data in the benchmarking process. It may specify the frequency of data collection, the methods for data collection, and the format for reporting the data.
Confidentiality: This section addresses the information disclosed during the benchmarking process. It may require the parties to keep the information confidential and limit the use of the information to the purpose of benchmarking.
Scope and limitations: This section outlines the scope and limitations of the benchmarking clause. It may clarify which business areas will be subject to benchmarking and which areas will be excluded.
Consequences of benchmarking: This section may outline the consequences of benchmarking, such as the requirement to implement improvements or to pay penalties if performance falls below industry standards.

Insurance

An insurance block in a software development agreement provides the insurance requirements for the Parties. The key components of an insurance block in a software development agreement typically include the following:

Types of insurance: This section specifies the types of insurance required for the software development project, such as general liability insurance, professional liability insurance, and cyber liability insurance.
Coverage limits: This section specifies the minimum coverage limits the Parties must maintain for each type of insurance. It may also specify the minimum required duration of the insurance coverage.
Additional insured: This section specifies whether one party requires the other party to name it as an additional insured on their insurance policies. It may also specify any specific requirements for the additional insured coverage.
Proof of insurance: This section specifies the procedures for providing proof of insurance, such as certificates of insurance or endorsements, and the timeframe for providing such proof.
Claims handling: This section specifies the procedures for reporting and handling insurance claims, including each party’s obligations to cooperate with the insurance company in the event of a claim.
Waivers and releases: This section specifies any waivers or releases of liability that the Parties agree to as part of the insurance clause. For example, the Parties may agree to waive their rights to sue each other for any claims covered by insurance.

An insurance block is an important component of a Software Development Agreement as it can help protect both Parties in unforeseen circumstances.

Core legal provisions blocks

Limitation of liability

Indemnities

Term and termination

Reps & Warranties

Intellectual property

Confidentiality

Boilerplate blocks

Read more on the boilerplate clauses.

Schedules

Definitions

Read more on the boilerplate clauses.

Project

Service levels

FAQs

Master Software Development Agreement vs. "standard" Software Development Agreement

A Master Software Development Agreement is a framework agreement that goes hand-in-hand with Statements of Work (SoW).

The Master Software Development Agreement contains general terms and conditions applicable to the transactions. On the other hand, the SoW contains more specific information relating to the Software that must be developed. For example, the technical and functional specifications, timeframes, fees etc.

A Master Software Development Agreement allows for a more agile process where various “sprints” are undertaken to complete a project. Each “sprint” with its respective milestones and dates are agreed and documented as separate SoWs.

With a “standard” Software Development Agreement, the specifications of the project is fixed at the signing of the Agreement or agreed during a “consultation phase” preceding the start of the project.

What is the difference between Source Code and Object Code?

“Source Code” is the code that a developer writes to program an application/website. This code is “human readable” and this is the code that you want to protect.

“Object Code” is “machine-readable”. In other words, it is numeric code made of binary numbers such as 0s and 1s and is understood by a machine.

For a more detailed explanation on Source Code vs. Object Code, have a look at this article.

Building a data protection schedule

How to build a data protection clause

In this article, we have a look at some of the important aspects that must be kept in mind when drafting data privacy and data protection provisions.

Most disputed terms WCC ranking:

Data privacy: 28

Data security: 26

Most important terms WCC ranking:

Data privacy: 8

Data security: 7

Most negotiated terms WCC ranking:

Data privacy: 17

Data security: 19

What is a Data Privacy clause?

Data Privacy clauses will generally deal with the way in which data (usually Personal Information) must be handled.

What is a Data Security clause?

Data Security clauses usually provide what the Provider must do to protect the Protected Data against unauthorised third-party access and malicious attacks.

What is a Data Protection clause then?

Data protection clauses are in a way a combination of data privacy and data protection clauses.

Do data protections apply globally?

Data protection laws do not apply globally per se, as each law is specific to a country or region. However, some laws have extraterritorial reach, meaning they can apply to organizations located outside of their respective jurisdictions if certain conditions are met. The most prominent example of this is the European Union’s General Data Protection Regulation (GDPR).

The GDPR applies to organizations located within the EU and organizations located outside the EU if they process personal data of individuals residing in the EU under certain circumstances. These circumstances include:

Offering goods or services to individuals in the EU, irrespective of whether payment is required.
Monitoring the behavior of individuals in the EU, where such behavior takes place within the EU.

Even though the GDPR does not apply globally, its extraterritorial reach means that organizations worldwide may need to comply with its provisions if they process the personal data of EU residents.

Other data protection laws, such as Brazil’s General Data Protection Law (LGPD) and the California Consumer Privacy Act (CCPA), also have provisions that can apply to organizations outside their respective jurisdictions. However, no single data protection law has a truly global application. Organizations must be aware of the data protection laws in each country or region where they operate or process personal data of residents and comply with the relevant regulations accordingly.

What is a restricted data transfer?

Building blocks of Data Privacy and Data Security clauses

What is Protected Data?

Defining Protected Data is important to ensuring balanced and fair data privacy and security provisions.

Generally, Protected Data will be personal information as defined by applicable data privacy and security laws. The aforementioned, however, does not mean that the definition of Protected Data should be limited to Personal Information. The Customer may want a much broader definition of Protected Data that includes all the data that the Customer provides to the Provider. For example:

Protected Data means all information processed or stored through the System by Customer or on Customer’s behalf, and includes, without limitation, information provided by Customer’s customers, employees, and other users and by other third parties, other information generated through use of the System by or on Customer’s behalf, and copies of all such information rendered onto paper or other non-electronic media.

If you are the Provider, you want to use a narrow definition and may even consider carving out certain types of data from the definition. For example:

Excluded Data means personal tax numbers, financial account data, and credit card and other payment card numbers;

Protected Data means personal information as contemplated under applicable data privacy and security laws, but specifically excludes Excluded Data;

If you are the Provider, you don’t want a situation where there is a Data Incident and, for example, credit card data is exposed and there was no need for you in the first place to process any such credit card data.

If you follow the approach where certain data is excluded, make sure that a warranty is included in the Data Protection Schedule where the Customer warrants that they will not provide any Excluded Data to the Provider.

It may be that you want Protected Data to be regarded as Confidential Information. If you decide to go this route make sure that you address the situation where there is a conflict between the Data Protection Schedule and the confidentiality provisions.

Handling of Protected Data - Authorised Persons

A narrow definition of Authorised Persons may favour the Customer. On the other hand, the Provider would want to make sure the definition of Authorised Persons is wide enough to include sub-contractors so that there is no need to obtain written approvals for each sub-contractor.

Authorised Persons should, however, be limited to people who need to handle the data to fulfil the Provider’s obligations under the Agreement.

Handling of Protected Data - Aggregated and anonymised data

A Provider may want to use the Protected Data for its own purposes. Generally, if the Provider wants to use the Protected Data, it needs to be anonymised first. If you are the Customer, you would want to make sure that if the Protected Data is anonymised, such a process must and cannot be reversed.

Handling of Protected Data - Personal Information requests

Privacy legislation generally provides certain rights to data subjects when it comes to their Personal Information. For example, the “right to know,” delete, or the “right to be forgotten”. As a Customer, you may want to impose certain obligations on the Provider if a personal information request is directed at the Provider.

Access, location and deletion of Protected Data

If you are the Customer, you want to control the access, location and deletion of Protected Data.

Data privacy laws may determine certain requirements if Protected Data is moved cross-border. As a Customer, you do not want to be exposed to a situation where Protected Data is moved cross-border to a jurisdiction with less stringent data privacy and data security laws than those applicable within the current jurisdiction.

As a Customer, you can also consider specifying certain data centres within the current jurisdiction where data can be stored.

As Provider, the commercials of the transaction must be kept in mind when considering access, location and deletion of Protected Data. It may be useful to reserve a right to charge fees and costs for time spent assisting the Customer with providing access, deleting and moving Protected Data.

Data security audits & certifications

Generally, the two standards that will be considered will be ISO 27001 and SOC 2.

A difference between ISO 27001 and SOC 2 is that SOC 2 is not a certification. If you pass the ISO 27001 requirements, then your business is ISO 27001 certified. However, in the case of SOC 2, the auditor issues a formal report, confirming whether or not you met the relevant criteria.

ISO 27001 is a common European procurement requirement and is internationally recognized as the highest standard in information security. In the US market, many Customers will want the reassurance that the Provider is SOC 2 compliant.

Minimum safeguards

If you acting for the Customer, especially in the situation where the Provider is not required to produce an ISO 27001 certificate or an SOC2 report, you want to place certain contractual obligations on the Provider regarding data security.

Or, if there is a requirement that the Provider produces a ISO 27001 certificate or an SOC2 report, there are situations where the Customer may require further measures to be put in place that goes beyond what is required under ISO 27001/ SOC2.

Data incidents & deletion of data

Data Incidents

When considering provisions relating to Data Incidents, the definition of a Data Incident is a good point of departure.

Generally, Data Incidents include the unauthorised disclosure of, access to, or use of Protected Data.

As Provider, you may want to consider narrowing the above broad and general definition to more specific scenarios where, for example, an unauthorised third-party obtains and threatens the distributions of Protected Data.

The obligations placed on the Provider relating to Data Incidents require detailed consideration. Examples of these obligations include:

Notifying the Customer
Cooperation with law enforcement
Assistance with notifying third parties whose data may have been exposed

Most of these obligations are generally aimed at damage control. However, a Customer may want to add obligations that require compensation, in some form, as a result of the Data Incident.

As a Customer, you want to be in control of whatever happens after the occurrence of a Data Incident. As Provider, you do not want to be subjected to obligations that will be detrimental to your business financially.

Deletion of data

As a Customer, you want to have certain rights regarding the deletion of Protected Data.

Making sure that erasure leaves no data readable, decipherable, or recoverable may be expensive. Therefore, as Provider, you may want to consider adding provisions that the data deletion will be done using commercially feasible methods.

Data protection indemnity

The remedies and relief for breach of the Data Protection Schedule or the Data Protection Laws are usually addressed by an indemnity (see How to build an indemnity clause).

Breach & equitable relief

A Customer may also want to include a provision stipulating that a breach of the Data Protection Schedule will be deemed material with the hope that this will help them terminate the Agreement for cause if there is a breach.

Measures of pseudonymization and encryption of personal data

Here are a couple of examples of measures of pseudonymisation and encryption of personal data that may be included as part of the Data Processor’s obligations when handling Personal Data-

Data Masking: The Data Processor needs to hide personal data using standard techniques, making it hard to identify the individual from the altered data.
Irreversible Masking: The Data Processor must ensure that once the data is masked, it cannot be changed back to the original form or used to identify the person it belongs to.
Tokenization: The Data Processor should use a safe system to replace sensitive data with unique, non-sensitive tokens (like codes) that don’t reveal the actual data.
Secure Tokens: The Data Processor must make sure that these tokens can’t be connected back to the original data without access to the tokenization system.
Secure Storage: The Data Processor needs to store the tokens and their corresponding data mappings separately in a safe, protected environment.
Encryption: The Data Processor must use industry-standard methods to protect personal data by scrambling it, both when it’s stored and when it’s being transferred.
Encryption Types: The Data Processor should use Advanced Encryption Standard (AES) for symmetric encryption and RSA or ECC for asymmetric encryption, or equally secure alternatives.
Key Management: The Data Processor must set up and maintain secure processes to manage encryption keys, including creating, storing, and distributing them.

Measures for ensuring ongoing confidentiality, integrity, availability and resilience of processing systems and services

Here are a couple of examples of measures of measures for ensuring ongoing confidentiality, integrity, availability and resilience of processing systems and services that may be included as part of the Data Processor’s obligations when handling Personal Data-

Access Control: The Data Processor should use appropriate methods to limit access to personal data, allowing only those who absolutely need it.
Review Access Permissions: The Data Processor should regularly check and update who has access to personal data, making sure only authorized personnel can access it.
Network Segmentation: The Data Processor should separate systems with personal data from other systems or networks to keep them isolated.
Enforce Segmentation: The Data Processor should use firewalls, virtual LANs (VLANs), or other suitable technologies to reinforce network separation and reduce the risk of unauthorized access.
Intrusion Detection and Prevention: The Data Processor should use systems that monitor and protect networks and systems containing personal data from unauthorized access or attacks.
IDPS Updates: The Data Processor should regularly update these systems with the latest threat information and make sure they’re configured to quickly detect and respond to potential security incidents.
Security Patch Management: The Data Processor should have a process to quickly find, evaluate, and apply security updates to systems handling personal data.
Prioritize Critical Patches: The Data Processor should focus on deploying important security updates first to minimize the risk of known vulnerabilities being exploited.
Backup and Disaster Recovery Plan: The Data Processor should have a plan to recover personal data and systems quickly in case of disruptions or failures.
Regular Backups: The Data Processor should frequently back up personal data and store copies in secure, geographically separate locations.
Redundancy and Fault Tolerance: The Data Processor should use measures like redundant power supplies, RAID configurations, and load balancing to keep systems handling personal data continuously available and resilient.
Test and Evaluate: The Data Processor should periodically test these measures to ensure the ongoing reliability of systems and services.

Measures for ensuring ongoing confidentiality, integrity, availability and resilience of processing systems and services

Here are a couple of examples of measures for ensuring the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident that may be included as part of the Data Processor’s obligations when handling Personal Data-

Regular Backups: The Data Processor should frequently back up personal data following a set schedule and backup retention policy.
Integrity and Confidentiality: The Data Processor should use suitable encryption and access control methods to keep backed-up personal data secure and accurate.
Off-site Storage: The Data Processor should store backup copies of personal data in safe, geographically separate locations to reduce the risk of data loss from local incidents.
Physical and Technical Security: The Data Processor should use proper security measures to protect off-site backup storage locations from unauthorized access, theft, or damage.
Disaster Recovery Plan: The Data Processor should have a plan outlining how to restore personal data and systems if there’s a disruption or failure, and they should keep this plan updated.
Testing the Plan: The Data Processor should regularly test the disaster recovery plan to make sure it works effectively, and staff know how to follow it in case of an incident.
Business Continuity Plan: The Data Processor should have a plan that addresses p

Project Schedule

Introduction

What is a Project Schedule?

Building Blocks

Project blocks

Phases

Milestones

Deliverables

Specifications

Dependencies

Assumptions

Out-of-scope services

Acceptance testing

Financial blocks

Fees, rates and payment

Deposit

Recoverable expenses

Third-party costs

Liquidated damages

Early completion bonus

Miscellaneous Blocks

Third-party materials

Warranties

Support & maintenance

Table of Contents

Building Blocks of a Contract

Introduction

Main blocks

Agreement specific

Core legal provisions

Boilerplate

Schedules

Agreement specific

Parties

Background

Definitions

Scope

Core legal provisions

Limitations

Indemnities

Termination

Warranties

Intellectual property

Confidentiality

Boilerplate

Boilerplate blocks

Schedules

FAQs

Which styles or fonts must I use?

Articles, sections and subsections, what's the difference?

The Author

Table of Contents

Building a Service Level Agreement (SLA)

Table of Contents

Introduction

What is a Support SLA?

What is a Error Correction SLA?

What is an Uptime SLA?

What is System Response SLA?

Building blocks

Process Block

Service Levels Block

Fees Block

Monitoring & Reporting Block

Credits Block

Termination Rights Block

Escalation Block

Out-of-scope Services Block

FAQs

Is the SLA a stand alone agreement?

Will Software Maintenance Services also be addressed in the SLA?

The Author

Table of Contents

The building blocks of a API Licence Agreement

What is an API Licence Agreement?

Building blocks

API Licence Block

Key Components

Licence grant

Restrictions