Schedule Blocks

Project schedule

This guide explains the different parts that make up the project schedule block.

Introduction

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:

  1. Project phases: These are the high-level stages of the project, such as planning, design, development, testing, and deployment.

  2. Milestones: Significant events or checkpoints in the project that mark the completion of tasks.
  3. Tasks and Deliverables: A list of specific activities and their corresponding outputs that need to be completed as part of the milestone.

  4. Customer Dependencies: Relationships between tasks that indicate how one task’s completion affects the start or end date of another task

Parts (project)

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-

  1. 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.

  2. Development: The development phase can be broken down in multiple phases and involves the actual coding and implementation of the software.

  3. 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

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.
 

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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 and 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).

Parts (financial)

Fees

Fee structures are crucial to ensure both the client and the software developer have a clear understanding of the project’s cost and how payments will be made.

There are various types of fee structures that can be used, often combining different approaches to accommodate the specific needs of a project. Two common fee structures include fixed fees and time and material fees, which can be applied to different phases of a project.

Fixed fees: In a fixed fee structure, the developer charges a set amount for specific phases or milestones of the project. This approach is often used when the scope of work is well-defined, and the requirements are clear, reducing the likelihood of significant changes or additional work. Fixed fees offer the advantage of better cost control and predictability for the client. For example, a software development project might be divided into the following phases, each with a fixed fee:

  1. Discovery and requirements gathering: The developer conducts research, interviews stakeholders, and documents the project’s requirements.
  2. Design and prototyping: The developer creates wireframes, mockups, and prototypes to demonstrate how the software will look and function.
  3. Development and coding: The developer writes the code, builds the software, and integrates it with existing systems.
  4. Testing and quality assurance: The developer tests the software, fixes bugs, and ensures it meets the project’s requirements.
  5. Deployment and launch: The developer deploys the software, makes it live, and provides any necessary training or support.

Time and material fees: In a time and material fee structure, the developer charges the client based on the actual time spent and resources used during a project phase. This approach is more flexible and better suited for projects with uncertain or evolving requirements, as it allows for adjustments to the scope of work without renegotiating the entire agreement.

For example, a project might use time and material fees for the following phases:

  1. Ongoing support and maintenance: The developer provides technical support, updates, and bug fixes after the software has been deployed.
  2. Feature enhancements and customizations: The developer adds new features or customizes the software based on the client’s changing needs and feedback.

In some cases, a hybrid approach that combines fixed fees for certain phases and time and material fees for others may be the best fit. This allows for a balance between cost predictability and flexibility, ensuring that both the client and the developer can effectively manage their resources and expectations throughout the project.

Payment

Invoice requirements

As the Customer, you want to ensure that the Provider invoices you correctly so that your financial department can process payment without further information that may be required.

As the Provider, clarity on the invoicing requirements helps ensure you receive timeous payments.

Certain Customers would also require a more detailed invoice separately stipulating:

  • the Services performed
  • the fees related to the Services performed
  • any reimbursable expenses
  • etc.

Different jurisdictions deal with taxes in different ways. For example, some jurisdictions will have GST applicable, and others may impose some form of VAT.

In general, and in most B2B contracts, the Agreement will provide that all amounts payable under the Agreement are exclusive of any form of sales tax.

Another important aspect often missed is the process related to any Taxes that a Customer needs to withhold or deduct from the amount payable. Be clear on when these Taxes can be withheld and what happens when the Provider can produce documentation that substantiates an exemption from such Taxes.

Payment terms & method of payment

How long after an invoice is rendered will the Customer have to make payment?

When using a Master Agreement and statements of work, the payment terms can also be diverted to the statements of work. If this is the case, make sure to also include fallback payment terms in your Master Agreement. 

Also, what is the payment method that needs to be used? These days, electronic funds transfer is the obvious method, but businesses still use other methods.

As the Provider, you also want to ensure that payment needs to be made without deducting any bank charges. In other words, the amount that ends up in your account needs to be the amount per the invoice.

Set-off

As the Customer, if the Provider owes you an amount under the Agreement, having a set-off right may assist from a cashflow perspective.

As Provider, a set-off right can hold several risk. You do not want a Customer exercising a set-off right in respect of an amount that may still be disputed.

Refunds and disputes

As a Provider, a refund may be a last resort, and you typically want to avoid provisions that provide refunds will be provided to the Customer. On the other hand, the Customer may push for refunds in certain circumstances as this may provide the Customer with a good amount of leverage during disputes.

If the Customer believes that the Services were not rendered in accordance with the Agreement, then the Customer can always institute a claim.

To try and meet each other halfway, the Parties may agree to a dispute resolution mechanism that will apply if there are any disputes that relate to payments under the Agreement. See the below example clauses for an example of such a dispute resolution clause.

Overdue amounts & collection commissions

As a Provider, you want to make sure that you reserve the right to charge interest on overdue amounts. The interest rate that will apply may vary, with certain Providers reserving a right to claim the maximum interest allowed by law. This rate will mostly be dependent on industry practices and the negotiating power of the respective Parties.

In addition to the interest that may be charged on overdue amounts, as a Provider, you also want to reserve a right to recover reasonable collection costs from the Customer. Without reserving such rights, you may only be in the position to recover collection costs once a judgment is obtained (which can take some time).

Additional assurances & suspension rights

As a Provider, you may not always know what is going on underneath the surface with the Customer’s financial position.

Reserving the right to call for additional assurances may be a powerful tool to ensure that you do not take on disproportionate risk when waiting to be paid by the Customer.

Also, as a Provider, you want to expressly reserve the right to suspend the provision of Services if the Customer is not abiding by the Payment terms.

Most favored pricing

Where the Customer has a particularly strong negotiation position, the Customer may ask for a “most favoured pricing” clause.

As Provider, you want to keep these clauses written in general terms.

These clauses should be more than a mechanism to get you to the table to start negotiating a price change.

Recoverable expenses

Recoverable expenses, also known as reimbursable expenses or chargeable costs, are specific expenses incurred by a service provider or contractor while executing a project that can be directly attributed to the project and is eligible for reimbursement by the client. These expenses are distinct from the service provider’s own fees for their work and are often outlined in the Project Schedule.

Some common examples of recoverable expenses include:

  1. Travel and accommodation: Costs associated with travel, lodging, and meals for project-related trips, such as site visits, meetings, or conferences.
  2. Materials and supplies: Expenses for materials, consumables, or supplies directly used in the project, which are not part of the service provider’s standard resources.
  3. Printing and reproduction: Charges for printing, copying, or reproduction of project-related documents, plans, or reports.
  4. Training and workshops: Fees for training sessions, workshops, or seminars that are necessary for the project’s execution, which are not included in the service provider’s own fees.

To ensure a smooth and transparent project execution, both the service provider and the client should have a comprehensive understanding of which recoverable expenses will be incurred during the project and how they will be managed, documented, and reimbursed.

The Project Schedule should explicitly address recoverable expenses, including any limitations, caps, or approval processes that may apply. By effectively managing and documenting recoverable expenses, both parties can avoid unexpected costs and maintain a more accurate project budget.

Third-party costs

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:

  1. 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.

  2. 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.

  3. Equipment rental or purchase: Expenses related to renting or purchasing equipment, tools, or machinery required for the project which is not part of the service provider’s standard resources.

  4. 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.

Liquidated damages

Liquidated damages are predetermined, mutually agreed upon amounts of compensation that a party is obligated to pay if they fail to fulfil 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-

  1. 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.

  2. 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.

  3. 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 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 the 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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 cnclusion, 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.

Ninja holding a laptop explaining tech contracts

Interested in our Contract Builder?

Table of Contents

Master contracts now
Elevate your career!

Try for free. No credit card required.

Elevate your legal game with ContractNinja.

Form part of the spearhead movement of shaping the global standard for tech contracts.