Project Delivery & Change Management Policy

🚀 PART A: PROJECT DELIVERY POLICY

A.1 Project Scope Definition

The Scope of work is defined exclusively by the written quotation, proposal, or statement of work accepted by Client. The Scope includes:

• Specific features, functions, and deliverables to be provided;
• Technical specifications and requirements;
• Any assumptions, dependencies, and exclusions;
• Milestones and payment schedule (if applicable).

A.2 Client Inputs and Responsibilities

Client is responsible for providing all required Client Inputs in a timely manner, including:

• Content, text, images, and branding assets;
• User lists, roles, and permissions structures;
• Access credentials for third-party systems;
• Feedback, approvals, and decisions;
• Technical documentation or specifications;
• Any other materials identified in the Scope.

A.3 The Timeline Rules

A.4 Estimates vs. Guarantees

All timelines provided are estimates only, not guarantees, unless explicitly stated in writing as "Guaranteed Delivery Date" in the quotation or proposal.

• Estimated timelines are based on full and timely Client cooperation;
• Company reserves the right to adjust estimates based on actual scope complexity discovered during work;
• Verbal timelines communicated (in meetings, calls, or chats) are non-binding;
• Only written timelines in the quotation/proposal or official email confirmation apply.

A.5 Standard Delivery Timeframes (Guideline Only)

The following timeframes are estimates for standard projects after the Timeline Start Rule is satisfied. Actual delivery may vary depending on scope complexity, integrations, data migration, and Client Inputs.

A.6 Milestones and Reviews

Where projects include milestones, the following process applies:

• Upon completion of each milestone, Company will provide deliverables for Client review;
• Client shall have five (5) business days to review and provide feedback;
• Feedback must be specific and actionable;
• If no feedback is received within five (5) business days, the milestone may be deemed accepted;
• Significant change requests during review constitute Change Requests under Part B.

A.7 Acceptance and Go-Live

The formal acceptance process is as follows:

1. UAT Period: Upon completion of all Scope items, Client receives access to a staging environment for testing;
2. Duration: Client has ten (10) business days to test and provide feedback (the "UAT Period");
3. What to report: During UAT, Client may report bugs (features not working as specified in Scope);
4. What NOT to report: New features, design preferences, or changes of mind are Change Requests;
5. Deemed Acceptance: If Client provides no written rejection within ten (10) business days, the project is deemed accepted;
6. Go-Live: System is moved to production only after acceptance or client approval.

A.8 Expedited Delivery

Requests to expedite delivery may attract additional fees and are subject to Company's capacity and written confirmation. Expedited delivery, if agreed, will be documented in a revised timeline.

🔄 PART B: CHANGE MANAGEMENT POLICY

B.1 What Constitutes a Change Request

A Change Request is any request by Client that modifies the agreed Scope, including:

B.2 Change Request Process

B.3 Emergency Change Requests

In urgent situations (e.g., regulatory deadlines, critical business needs), Company may prioritize Change Requests at its discretion. Emergency requests may attract premium rates and are subject to capacity.

B.4 No Obligation to Accept

Company reserves the right to decline Change Requests that are technically infeasible, would compromise system integrity, or conflict with our Acceptable Use Policy. In such cases, Company will provide a reasonable explanation.

B.5 Impact of Change Requests on Timeline

Approved Change Requests automatically extend the project timeline by the period reasonably required for implementation, unless otherwise agreed in writing. The Timeline Pause Rule (A.3) applies during Change Request assessment and approval.

B.6 Multiple Change Requests

Where multiple Change Requests are submitted, they will be assessed and prioritized based on business impact, technical dependencies, and resource availability. Company may batch Change Requests for efficiency.

🛠️ PART C: SUPPORT POLICY

C.1 Support Overview

This Support Policy applies to all projects and services delivered by Long Haul Technologies. Ongoing support beyond the periods described herein requires a separate Support Agreement or paid support package.

C.2 The 30-Day Support Window

For all development projects, Company provides a thirty (30) day support window commencing on the date of final delivery or Go-Live ("Support Window").

What is covered during the Support Window:

• Bug Fixes: Issues where the system does not function as specified in the Scope;
• Errors: System errors, crashes, or malfunctions;
• Broken Features: Features that were working but have stopped functioning correctly;
• Security Vulnerabilities: Any security issues identified.

What is NOT covered during the Support Window:

• Feature changes, enhancements, or new functionality (Change Request);
• Content updates or additions;
• Training for new users;
• Integration with new third-party services;
• Issues caused by Client modifications or third-party changes;
• Dissatisfaction with design after approval.

C.3 Support Tiers

Maintenance Agreements, Premium Support, and Training are subject to separate fees as quoted.

C.4 Support Request Process

1. Submit Request: Email support requests to support@longhaultech.com with clear description, steps to reproduce, and screenshots if applicable;
2. Acknowledgment: Company acknowledges receipt within one (1) business day;
3. Assessment: Company assesses whether issue is a bug (covered) or change request (chargeable);
4. Resolution: If covered, Company works to resolve within reasonable timeframe based on severity;
5. Communication: Regular updates provided until resolution.

C.5 Severity Levels

C.6 Support Exclusions and Limitations

• Support is provided on an "as available" basis during business hours, excluding public holidays;
• Company does not guarantee resolution of all issues within specific timeframes, but will use reasonable efforts;
• Issues caused by third-party services (hosting providers, payment gateways, APIs) are subject to third-party resolution times;
• Client is responsible for maintaining current backups and implementing reasonable business continuity measures;
• Support excludes training, consulting, or configuration assistance unless covered by a separate agreement.

C.7 End of Life and Deprecation

Where Company discontinues a product, feature, or technology version ("End of Life"), support will be provided as follows:

• Notice of End of Life provided at least six (6) months in advance;
• During notice period, standard support continues;
• After End of Life date, no further support, updates, or security patches are provided;
• Migration options may be available at additional cost.

📢 PART D: ESCALATION PROCEDURE

If Client is unsatisfied with project progress, delivery, or support, the following escalation path applies:

All disputes remain subject to the Dispute Resolution clause in the MSA.

⚖️ PART E: GENERAL PROVISIONS

E.1 Entire Agreement

This Project Delivery & Change Management Policy, together with the MSA and all Incorporated Policies, constitutes the entire agreement regarding project delivery, changes, and support.

E.2 Amendments

Company may update this Policy from time to time. Updated versions apply to new engagements and renewals. For existing engagements, the version in effect at acceptance applies.

E.3 Severability

If any provision is held invalid or unenforceable, the remaining provisions remain in full force and effect.

E.4 Waiver

No waiver of any term is effective unless in writing. Failure to enforce any right is not a waiver of future enforcement.

📞 PART F: CONTACT INFORMATION

For project delivery, change requests, or support enquiries:

Version 1.0 | Effective 20 February 2026
Long Haul Technologies reserves the right to update this Policy. Updated versions apply to new engagements and renewals.