1. Introduction:

This Change Request Policy defines the structured process for handling change requests within projects executed by Nine Hertz India Private Limited. It serves as a foundational document guiding the collaboration between Nine Hertz India Private Limited and its clients. Through mutual agreement, both parties commit to adhering to the procedures stipulated herein to ensure the smooth execution and successful delivery of projects

2. Definition of Change Request:

A change request is a formal proposal that is made to bring changes or revisions to ongoing project’s requirements, features, scope or deliverables by stakeholders. These requests are recorded and examined to determine whether they are feasible, significant and consistent with the goals of the project. Change requests might come from stakeholders’ input, new requirements, developing business demands or technology advancements.

3. Importance of Streamlined Change Request Process:

In software development, having a smooth process for change requests is really important. It lets us quickly adjust to new needs or situations, making sure our final product stays useful and competitive. By carefully looking at change requests, we can spot and avoid potential problems, making sure our project stays on track and our clients are happy. We thoroughly test any changes to make sure our product stays reliable and top-notch, which keeps our clients satisfied and trusting in our work. When we handle changes well, we stick to our deadlines and keep everyone involved happy, ensuring we deliver our projects on time.

4. Criteria for Initiating a Change Request Process:

Change requests will be initiated under predefinedcriteria to ensure clarity and alignment with project objectives. The criteria include:

• Purpose: Provide an explanation for the proposed change to ensure that it aligns with the projectgoals and objectives.
• Scope: Thoroughly defining the scope of the change so we can see how it might affect our project’sgoals, deadlines, and resources.
• Impact: Evaluating the impact of the change on projectschedules, budgets and existing functionalitiesto enable more informed decision-making.
• Risks Assessment: Identifying any possible problems the change request might cause and figure outhow to deal with them, so we can make the change as smoothly as possible.

5. Change Request Process:

• A. Submission: The client submits a change request detailing the proposed modifications to the project.
• B. Initial Evaluation:
  • i. Upon receiving the change request, it will be logged into the system and assigned to the technicalteam for evaluation.
  • ii. The technicalteam willreview the change request to understand itsscope, purpose, and potentialimpact on the project.
• C. Technical Assessment:
  • i. The technical team conducts a thorough assessment of the proposed change to determine itsfeasibility and compatibility with the existing system architecture.
  • ii. They analyze whether implementing the change would adversely affect any other features or functionalities of the application.
• D. Impact Analysis:
  • Beta Solution: If the change requests is to be made on a beta solution which is at the staging phase, it may not disrupt or affect any of the features on the live solution and take less time for implementation comparatively to making change request on a live solution.
  • Live Solution: If the change requests is to be made on a live solution which is in a live environment, it may be more time consuming because making changes to a live solution would require multiple assessments and verifications.
• E. Prioritization:
  • Based on the impact analysis, the change request will be prioritized relative to other pending requests and project requirements.
  • Priority will be determined considering factors such as urgency and dependencies with other features.
• F. Testing and Validation:
  • i. If the change request is feasible and prioritized for implementation, it will undergo rigorous testingand validation.
  • ii. Automated tests will be executed to ensure that the change does not introduce regressions orconflicts with existing functionalities.
  • iii. Continuous integration and deployment pipelines will be leveraged to seamlessly integrate thechange into the existing codebase and environment.
• G. Deployment and Monitoring:
  • i. Once the change has been successfully implemented and tested, it will be deployed to theproduction environment using the CI/CD pipeline.
  • ii. Monitoring tools will be employed to track the performance of the application post-deployment,to ensure that the change does not introduce any unforeseen issues.
• H. Documentation and Feedback:
  • i. A detailed record of the change request, evaluation process and implementation steps will be documented for future reference.
  • ii. Feedback from stakeholders and end-users will be solicited to assess the effectiveness of thechange and identify any areas for further improvement.

6. Client Responsibility for Bypassing the Process:

In the event that the client requests to bypass the standard change request process,the clientmust provide an official note acknowledging that any adverseoutcomes, including system failure, crashes, data loss or functional issues, resulting from the bypassed process, shall be solely the client’s responsibility.