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