HAL ERP - PROJECT GOVERNANCE

Project goals and objectives

• To help CUSTOMER run their Business/Operations Faster with HAL ERP
  
• To improve CUSTOMER’s business processes and procedures by adopting best business practices.
• To deliver clarity & Control to CUSTOMER’s management to end-users.
• To ensure Minimal Time spent by both Hal & Customer for Go Live including less time on Documentation
• To deliver a WoW experience for CUSTOMER before and after Go Live.

Documents/Deliverables

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

Documents:

• Requirements Gathering Document -As-Is/To-be OR Gap list of Customisations
• User Test Scenarios for Training
• Online Help Documents and Videos

Deliverables:

• Project Kick-off Presentation
• Project Governance Document
• Hal ERP on Development Server
• Hal ERP on Live Server
• Access to Support Desk
• Access to Knowledge Base

Implementation Locations

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

• Requirements Gathering
• Conference Room Pilot for Custom Modules, if applicable
• User Acceptance Testing
• Training

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

• HAL’s Customer Success Manager will demonstrate the Standard system to CUSTOMER Key Users.
• Key Users will mention Gaps from the system which will help them in running the operations
• Customer Success will document the Gaps and send it for CUSTOMER Approval
• Once CUSTOMER Key Users & Project manager approve, Project Team will start the Build

As-Is To-Be Approach

• HAL will do the requirements gathering based on a standard questionnaire prior to the start of the Project for each module. The questionnaire will pertain to the current business process followed and the future business process that CUSTOMER would like to implement. CUSTOMER can also indicate the current problems and business challenges faced using the current system or processes during this pre-project activity.
• Based on this the AS-IS Document would be provided and CUSTOMER is required to provide a response to the document in advance (prior to the start of the project).
• Once confirmed HAL will provide the TO-BE process so that the business users can provide valuable feedback if their requirements are being satisfied.
• HAL would conduct an interactive session with CUSTOMER Key Users on the future business process.
• It is assumed that the CUSTOMER Business Representatives (Key Users Only) would provide a brief on their current business and the processes followed. They would also be required to provide details of the current system and processes followed and the current challenges faced in the business which they would want to be resolved. This would also involve a review of the responses in the document provided.

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 :

• Extra Collection: We ensure that the requirement gatherings happen on areas defined within the scope of the project. The objective of gathering information is to provide a functional and effective system.
• Lack of barebone info: We need your team to provide with at least the most critical info on each module.
• Lack of Scope understanding: We are working towards providing a solution to run operations and it is not a custom application development.
• Lack of Cooperation: Unless the CUSTOMER’s team is cooperative in providing the correct information there is less we can do to ensure a properly working system.
• Lack of Consolidation: Instead of taking inputs from each end users which even might be contradicting each other we require you to have some on consolidating the requirements of each process in scope.
• Req. Doc Sign-Off: Timely signoff is most critical to ensure that we can start the build and also to prevent any post-build or go-live issues.

Build

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
   

Customization

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

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 :

• Completely new module or component development apart from those defined in the project scope.
• Beyond Customization Period/Credit Points: Asking for customization beyond what is agreed.
  

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:

• Providing template
• Uploading the data into ERP system using the standard upload programs
  

CUSTOMER is responsible for performing the following:

• Extracting, cleansing and mapping all master data and opening data to be uploaded
• Checking and correcting all these data to be uploaded
  
• Formatting the data in the format required by our template
  
• Verifying correctness of the data after the upload
  

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:

• One-Off Scenarios training: Both HAL and CUSTOMER need to mutually ensure that the most repeated and critical scenarios are handled well and not get into one-off issues
  
• Just a few sample transactions: CUSTOMER has to ensure that each key user makes day to day transaction and completes the Scenario documentation.
  

Go-Live

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

Service Level agreement

Access to HAL Support Desk

• HAL would provide access and login to Hal Support desk to the CUSTOMER ’s Project Manager/Coordinator (max of 2 access) and service will be continued through the CUSTOMER‘s License payment from 2nd year onwards. Change of such personnel shall be allowed during the contract period upon written notification from the CUSTOMER.
  
• Hal would offer Six non-carry forward Complementary Support Tickets other than CR’s every month and throughout the Project lifetime will fix any Product bugs/Online server downtime issues. Tickets raised regarding it will not discount monthly support ticket quota of CUSTOMER
  
• Post-Go-Live, All Support ticket should be raised only at the HAL Support desk.  The Project Manager/Coordinator should raise all support tickets in the Support desk. Phone calls made related to issues demanding immediate attention will be considered as a ticket and the issue should be logged in support desk before the call. Tickets beyond the quota will incur man day cost according to the complexity and Customer Success/Support Team would invoice the CUSTOMER.
  
• Support Desk will be available from Sunday to Thursdays during the regular 8 hours working day. Support timing and Public holidays will be communicated via the Support desk.
  
• Any meeting will happen based on appointments on 3 day’s notice with clearly charted out agenda either from CUSTOMER or HAL and it will run between 60 minutes to 2 hours Meetings will be conducted either from onsite or offshore (through cloud conferencing tools) based on the requirements
  

Out of scope Items

• All other aspects fall under Change Request and it will be executed as per our contract/proposal
  
• Preparation of Data is the responsibility of the user. HAL will provide the formats to get the data from the user. HAL will not perform any data cleansing and data validation.
  
• Line level data migration will not be done unless documented in the Scope.
  
• Coordination with Third-Party Vendors for development or integration. Our API’s would be given and the third party vendor can work with these for integration. Should HAL’s effort is involved, it will require a CR. Hal API’s can be accessed at http://bit.ly/HalErpApi
  

[Project Governance - Confidential]
www.halsimplify.com