Project goals and objectives

Following are the documents/deliverables that will be provided during the course of the Project:



Implementation Locations

The project will be executed from CUSTOMER’s Base City as in the Proposal document for the following activities.

CUSTOMER will arrange/be charged at actuals for the travelling and accommodation for the consultants travelling out of CUSTOMER’s Base City. if required.

Implementation Vouchers

At the Project Kick-off, Hal’s Customer Success will handover Implementation vouchers, quantity based on Project scope to the CUSTOMER’s Project Manager. Any forthcoming Project Milestones will be executed with Project Manager handing over the voucher to Customer Success and at the end of each meeting, participants will sign the voucher and mention if there are any comments. Without vouchers, Customer Success will not proceed with the milestones.

Project Milestones
Requirements Gathering

Requirement Gathering is one of the Key Activity as per the HAL Implementation Methodology.  The process that will be followed for requirements gathering would be as follows can be either of this approach as Customer Success will deem fit based on CUSTOMER business case:

GAP approach
As-Is To-Be Approach

Requirements Gathering document will be presented to the Customer for Signoff. Build will start only after the signoff. Requirement implementation will be purview of build team. It will be implemented in best interest/practices of the Customer not necessarily the approach mentioned in document or advised by Customer Success team. When things are out of scope, Change requests will be invoked

Typical Problems we need to avoid at this stage :


One requirements Gathering Phase is over, Customer Success will orient the Project Development Team to start the Build

Project Team will do the following:

  1. Set up Tenant/Server & all infrastructure requirements
  2. Do necessary configurations
  3. Implement Customizations (as per below section)
  4. Migrate Data (as per scope)
  5. Do Testing & handover to Customer Success for Training/UAT
  6. Implement UAT suggestions
  7. Perform Go-Live activities & Go-Live

Any Technical developments required other than the standard functionality of the Application is considered as a Customization (By Definition). Customizations are enhancement/unique process exit of existing modules and not the new module development.  

Any Customizations not mentioned in the Proposal/Requirements document are out of scope and will be accepted as change requests once Requirements Gathering Phase & UAT phases are completed. This will ensure the go-live date is not impacted

Allowed Customizations and average efforts:-

FormsReportsPrintsBusiness Logic
1 CreditsNew FieldsRemove FieldsValidations PrecisionsAdditional InformationNew columns in ReportCustom SortingCustom FilteringRemoving FieldsCosmetic ChangesDocument No. Overriding
2 CreditsMini ReportsCalculated FieldsCopied Fields Pulled FieldsNew ReportReport requiring a new fieldCalculated Fields in the ReportNew FieldsCustom HeaderCustom FootersNew formats
4 Creditsor moreWorkFlows (Approvals)Reports on a Custom LayoutData RestrictionsNew PrintsCalculated Fields in the PrintsTemplate GenerationPre-Printed FormatsNew Flows New Scenarios Restrictions across Modules New Module Impact

1 Credit = 1 Man Day

All Customizations will be consolidated and developed during the period, usually, 2 to 4 weeks as mentioned in the Project Scope.

HAL Team will follow the below Process  

Change Requests (CR)

Change requests will be raised in case there are requirements that fall outside the scope of services or requirements post-approval of a requirements document or changes to implemented software after UAT i.e., User acceptance testing confirmation overrides all the previous scope. The costs of the change requests are calculated based on the estimated man-day effort & chargeable as per the contract. For CR’s lesser than a man-day effort will be charged at 1 man-day effort.

If any of the below parameters drivers change, there is a likelihood of change order (CR): Duration of the phases of the project, Scope of the Product modules, Number of legal entities, Requirements Gathering workshop/schedule changes, Documentation / Training deliverables, availability of resources for workshops/queries/approvals, User sign off per agreed timelines, number of sessions/phases, Change Management Issues, training completion.

The scope of services as in Section 2 of the Proposal may be changed only by a written agreement in the form of a “Variation Order” Any changes to the scope of service/Change requests will be dealt with on a case-to-case basis and might attract charges.

Typical Problems we need to avoid at this stage :

Data Migration

Data migration will cover uploading the data provided by CUSTOMER in the formats given by HAL (as per agreed scope). CUSTOMER will extract the required data in the format (Templates) developed by HAL. HAL will not be involved in extracting the data directly from the legacy system or in the cleansing activity.

It is important to ensure that creating the necessary mapping between new and old Master Data will be addressed by CUSTOMER Business Team.

The data will be uploaded to the servers using the different upload tools prepared and tested by HAL during the build and test phase respectively.

Extracting the data from a legacy system(s), cleansing the data and providing the data in the required format is considered the responsibility of the CUSTOMER. This data will be uploaded into HAL ERP as provided.

Migrated data will only correspond to implement business rules, processes & as per scope. Business rules will not be modified to suit old or obsolete business rules and processes. Line level transactions will not be migrated unless explicitly available in the Scope.

The correctness of collected data for migration is the responsibility of CUSTOMER and any mistakes that require re-migrating data/multiple times migration will be not be considered within the scope as it will need additional man-days’ effort. This can initiate a CR having a commercial impact.

In Summary, HAL is responsible for performing the following:

CUSTOMER is responsible for performing the following:

Training and Knowledge Transfer

CUSTOMER will ensure the Key Business Representatives (a.k.a Key Users) are fully involved in the Project from the date of Project Kickoff.

HAL will follow Training Session with hands-on training methodology to make sure that the training is well appreciated by the users.

At HAL we follow the train the trainer approach by which we will train a set of identified users (key users) from CUSTOMER. Key users could thereafter train the remaining Users/new employees who will join the company in future  

The team that will attend Training Sessions will be the same as the implementation team. End Users are welcome to join but their inputs/suggestions will not be accepted without direct communication from Key Users

Testing and User Acceptance

The objective of the testing phase is to ensure the proper operation of various cycles applicable within business tracks as per the requirements gathering document. The testing implicitly will include all the solution standard and custom components.

A test acceptance process must be followed to ensure the testing is conducted successfully in the right sequence and within the planned time frame.

Testing will include a comparison of the results of entered data with expected results.

HAL’s Technical Team will be involved in performing system testing (unit, component, integration)

During UAT Business Leads would be required to do their Testing. Other users as required by CUSTOMER can be nominated to conduct the Testing simultaneously during this Stage. All people conducting the testing should come prepared with the required UAT Test Scenarios. The UAT should be conducted by the Key Users and will be guided by HAL.

During this stage, Users should test the system with sample data/real transactions and also test all business scenarios identified during the requirement gathering phase.

Any defects identified will be documented and would be rectified within the agreed time frame (3-5 days) and presented again to the Business Leads for re-testing. The re-testing should be completed within 3 days to ensure the project timelines are not impacted.

CUSTOMER should ensure that the current system is sufficient for handling the day to day operations. One revision will be accepted and new suggestion after submission of a revision (infinite loop) will not be accepted

UAT Sign off: CUSTOMER should be completed within 3 days of last training date. When there is no sign off from Users for more than 7 days, it will be deemed signoff and Project will be automatically moved to the next phase

Typical Problems we need to avoid at this stage:


Once Training, UAT & Data migration phases are completed, Project Team will set up Live Server with Data & latest document numbers. As soon as the Modules are moved into Production/Live Server, the system is announced as “Go Live”.

Transactions that came between Data migration completion & Go-Live has to be entered by the Users and those transactions won’t be migrated. So it is in the best interest to keep days between Data migration completion & Go-Live minimal and in the weekends.

Should there be any delays from Estimated Go-Live date by CUSTOMER, Estimated Go Live plus 2 weeks respectively will be considered as UAT Go-Live date for future references.

Post-Go-Live Support

After the GO Live, HAL will provide 14 days HYPER CARE support to CUSTOMER. This period for support have to be consumed within 14 calendar days from the date of go-live. After that Project will be moved to General (complimentary 6 tickets per month support)

Bugs/issues are part and parcel of any software solution and fixing them is what makes the software robust and improve over time. HAL has an excellent customer satisfaction record and will try its best to fix/solve any issue promptly.  

CUSTOMER should create tickets for issues via email/tickets portal along with the severity as below. Tickets will be promptly attended by HAL Support teams.

Service Level Descriptions
HighSystem unavailable
System hangs/freezes
System timeout
Code-level exceptions
Error Pages
Database exceptions
Link Error
Total system inoperative
MediumFunctional clarification (Training)
Unexpected functional behaviour
Errors at irregular intervals
Errors occurring at some places/scenarios
Form fields error
Partial system inoperative
Not able to perform core business functions
LowCosmetic UI Errors
Javascript Errors
UI layout issues
Grammar/Spelling mistakes in UI
UI colour/Theme issues
System in operation
Service Level agreement
SeverityResponse TimeResolution Time
High4 hours0-8 hours
Medium1 Business day3-5 Business days
Low1 Business dayEstimation
Sample Caption
Access to HAL Support Desk
Out of scope Items

[Project Governance - Confidential]