BoK on Step-by-Step Guide for Project

Management in ERP Implementations

Author(s): Manish Agarwal (manish_agarwal03@infosys.com)
Saurangshu Chakrabarty (saurangshu_c@infosys.com)
Date written(MM/DD/YY): 03-Mar-2008
Declaration
We hereby declare that this document is based on our personal experiences
and experiences of our project members. To the best of our knowledge, this
document does not contain any material that infringes the copyrights of any
other individual or organization including the customers of Infosys.
Manish Agarwal, Saurangshu Chakrabarty
Project Details

Projects involved : HKSMLAXA (Axapta Implementation at SML Hong Kong)

H/W Platform: Windows 2003 Server, Unix
S/W Environment: Microsoft Axapta 4.0, webMethods 7.0
Appln. Type: ERP implementation
Project Type : Fixed Bid

Target readers: Project Managers

Keywords: Project Management in ERP implementations, Risk, Fit-Gap
Analysis, Requirements Traceability matrix, SDLC , Project Plan

Page 1 of 45

INTRODUCTION
The document is a step-by-step guide for Project Management in ERP
Implementations. It details out the various phases in ERP implementation. Authors
have included a chapter to explain the dynamics and idiosyncrasy of the SMB ERP
implementations and key points to consider for reducing the timeline and cost, vital
for implementation. The authors have embedded the templates which can be readily
used with minor modifications as per the customer requirements.
The authors have mentioned Objective, Entry Criteria, Activities, Exit Criteria, Dos,
Donts, Expedition Tips and Responsibility Matrix for each of the Implementation
Phases.
This document is based on the personal experiences of the authors. However, inputs
have been taken from other SMB projects and some of the templates have been
taken from PRIDE.
This is a working document and any inputs or suggestions you may have will be
extremely valuable to us!
Thank You!
Saurangshu Chakrabarty (Saurangshu_C@infosys.com)
Manish Agarwal (manish_agarwal03@infosys.com)

Page 2 of 45

TABLE OF CONTENTS

INTRODUCTION............................................................................................6
ZERO PHASE..................................................................................................7
OBJECTIVE....................................................................................................7
ENTRY CRITERIA.............................................................................................7
EXIT CRITERIA...............................................................................................7
ACTIVITIES...................................................................................................7
DOS..........................................................................................................7
DONT........................................................................................................7
EXPEDITION TIPS...........................................................................................7
RESPONSIBILITY MATRIX....................................................................................7
PROJECT INITIATION/KICK OFF...................................................................8
OBJECTIVE....................................................................................................8
ENTRY CRITERIA.............................................................................................8
EXIT CRITERIA...............................................................................................8
ACTIVITIES...................................................................................................8
DOS........................................................................................................10
DONTS....................................................................................................10
EXPEDITION TIPS..........................................................................................10
RESPONSIBILITY MATRIX..................................................................................10
AS-IS UNDERSTANDING..............................................................................12
OBJECTIVE..................................................................................................12
ENTRY CRITERIA...........................................................................................12
EXIT CRITERIA.............................................................................................12
ACTIVITIES..................................................................................................12
DOS........................................................................................................13
DONT......................................................................................................13
EXPEDITION TIPS.........................................................................................13
RESPONSIBILITY MATRIX..................................................................................13
REQUIREMENT GATHERING.........................................................................15
OBJECTIVE..................................................................................................15
ENTRY CRITERIA...........................................................................................15
EXIT CRITERIA.............................................................................................15
ACTIVITIES..................................................................................................15
DOS........................................................................................................16
DONTS....................................................................................................16
EXPEDITION TIPS..........................................................................................16
RESPONSIBILITY MATRIX..................................................................................16
FIT GAP ANALYSIS......................................................................................17
OBJECTIVE..................................................................................................17
ENTRY CRITERIA...........................................................................................17
EXIT CRITERIA.............................................................................................17
ACTIVITIES..................................................................................................17
DOS........................................................................................................17
DONTS....................................................................................................17

Page 3 of 45

EXPEDITION TIPS..........................................................................................17
RESPONSIBILITY MATRIX..................................................................................18
FUNCTIONAL DESIGN PHASE......................................................................19
OBJECTIVE..................................................................................................19
ENTRY CRITERIA...........................................................................................19
EXIT CRITERIA.............................................................................................19
ACTIVITIES..................................................................................................19
DOS........................................................................................................19
DONTS....................................................................................................20
EXPEDITION TIPS..........................................................................................20
RESPONSIBILITY MATRIX..................................................................................20
TECHNICAL DESIGN....................................................................................21
OBJECTIVE..................................................................................................21
ENTRY CRITERIA...........................................................................................21
EXIT CRITERIA.............................................................................................21
ACTIVITIES..................................................................................................21
DOS........................................................................................................22
DONTS....................................................................................................22
EXPEDITION TIPS..........................................................................................22
RESPONSIBILITY MATRIX..................................................................................23
DEVELOPMENT............................................................................................24
OBJECTIVE..................................................................................................24
ENTRY CRITERIA...........................................................................................24
EXIT CRITERIA.............................................................................................24
ACTIVITIES..................................................................................................24
DOS........................................................................................................24
DONTS....................................................................................................25
EXPEDITION TIPS..........................................................................................25
RESPONSIBILITY MATRIX..................................................................................25
SYSTEM INTEGRATION TESTING.................................................................26
OBJECTIVE..................................................................................................26
ENTRY CRITERIA...........................................................................................26
EXIT CRITERIA.............................................................................................26
ACTIVITIES..................................................................................................26
DOS........................................................................................................26
DONTS....................................................................................................27
EXPEDITION TIPS..........................................................................................27
RESPONSIBILITY MATRIX..................................................................................27
USER TRAINING..........................................................................................28
OBJECTIVE..................................................................................................28
ENTRY CRITERIA...........................................................................................28
EXIT CRITERIA.............................................................................................28
ACTIVITIES..................................................................................................28
DOS........................................................................................................28
DONTS....................................................................................................31
EXPEDITION TIPS..........................................................................................31
RESPONSIBILITY MATRIX..................................................................................32

Page 4 of 45

USER ACCEPTANCE TESTING.......................................................................33

OBJECTIVE..................................................................................................33
ENTRY CRITERIA...........................................................................................33
EXIT CRITERIA.............................................................................................33
ACTIVITIES..................................................................................................33
DOS........................................................................................................33
DONTS....................................................................................................33
EXPEDITION TIPS..........................................................................................33
RESPONSIBILITY MATRIX..................................................................................34
GO-LIVE......................................................................................................35
OBJECTIVE..................................................................................................35
ENTRY CRITERIA...........................................................................................35
EXIT CRITERIA.............................................................................................35
ACTIVITIES..................................................................................................35
DOS........................................................................................................35
DONTS....................................................................................................35
EXPEDITION TIPS..........................................................................................35
RESPONSIBILITY MATRIX..................................................................................36
KEY RISKS AND MITIGATION STRATEGIES.................................................37
ERP IMPLEMENTATION FOR SMB CUSTOMERS............................................41

Page 5 of 45

Introduction
Authors have divided the implementation cycle in eight major phases and 12 sub
phases. The details of these phases are covered in the later chapters.
S.No

Major Phases

Sub-Phases

Zero Phase

1. Zero Phase

Project Kick Off

1. Project Initiation/Kick Off

Requirement Analysis and Functional

Specification

1. As-Is Understanding
2. Requirement Gathering
3. Fit Gap Analysis
4. Functional Specification

Technical Design and Development

1. Technical Design
2. Development

System Integration Testing

1. System Integration Testing

User Training

1. User Training

User Acceptance Testing

1. User Acceptance Testing

Deployment and Go-Live

1. Deployment and Go-Live

Page 6 of 45

Zero Phase
Objective
1. The objective of this phase is to get Project Manager acquainted with the project
background. This is a meeting conducted between Project Manager, Proposal
Anchor, Delivery Manager, Functional Lead and Technical Lead.
This meeting is conducted 1 week before the Project start.
Entry Criteria
1. Signed off SOW
2. Identification of Project Manager, Functional Lead and Technical Lead
Exit Criteria
1. A draft version of the Project Charter
Activities
1. The agenda of this meeting is to update the Project Manager of the Project
background and should cover the following topics:
a. Understanding of the Business needs by the Project Anchor
b. Indentified Risk
c. Assumption made during the proposal submission
DOS
1. Proposal Anchor should share any available documentation related to the project
with the Project Manager.
2. All the Risks/Assumption should be re-discussed and re-validated. These
risks/assumptions should get into the Project Plan to be prepared by the Project
Manager.
DONT
1. Nothing specific to be highlighted
Expedition TIPS
1. Nothing specific to be highlighted
Responsibility Matrix
S.
No

Deliverable

Draft Project Charter

Primary Responsibility
(Onsite/Offshore)

Project Manager (Onsite)

Page 7 of 45

Secondary
Responsibility
(Onsite/Offshore)
Proposal Anchor

Project Initiation/Kick Off

Objective
1.

The objective of this phase is to set the right expectations with the customer.

Entry Criteria
2.

Sign off Statement of Work from the customer

Exit Criteria
1. Project Charter
2. Sign off on the Project Plan
3. Finalization of Stakeholder Matrix for the As-Is Process understanding
Activities
1. This Phase usually start with the Kick-Off presentation to the customer Project
team. A template for the Kick Off presentation is embedded below:

Kickoff Presentation
Template.zip

2. A Program/Project Charter needs to be jointly prepared by Infosys and

customer Project Manager. This document defines high level objectives of the
Program/Project. A sample template is given below.

ProgramCharter.zip

A Project Charter gives the business driver, Project justification and high level
stakeholder requirements.
3. A Project Plan needs to be prepared and approved by Customer Manager. A
sample template of the Project Plan is given below.

Program
Management Plan.zip

Given below are the templates which can be used for various sections in the
Project Plan. The Project Manager needs to customize these templates after
discussing with the customer IT team.
A Risk Assessment Questionnaire and a Risk Management template are
embedded below.

Page 8 of 45

Risk Assessment
Questionairre.zip

Risk Management
Templete.zip

A Schedule Plan can be made either in MS Excel or *.mpp can be used. A

sample template for excel schedule plan is embedded below:

Project Timelines.zip

A Communication Management template is embedded below.

Communication Plan
Template.zip

A Knowledge Management Plan template is embedded below.

K-MapTemplate.zip

A Training Plan template is embedded below.

Training Plan
Template.zip

4. A Configuration Management Plan needs to prepared and signed off with the
customer. A template of the Configuration Management Plan is given below.

Configuration
Management Plan Template.zip

5. A Stakeholder Matrix needs to be prepared. This matrix will help Infosys

Project Manager to get a list the key contacts person from each of the business
area and the sign off ownership of various documents from the customer
IT/Business team. A template of the Stakeholder Matrix is given below.

Stakeholder Matrix
Template.zip

6. A Scope Change Request Analysis template, a Scope Change Tracking

template and a Change Request Template are embedded below:

Scope Change
Scope Change
Change Request
Request Analysis TemRequest
plate.zipTracking Template.zip
Template.zip

7. A Resource Plan template is embedded below

Page 9 of 45

Resource Plan &

Variance Report.zip

DOS
1.

It is recommended that Infosys Project Manager discusses the deliverables for

each of the phases with the customer. A Container document containing all the
deliverable should be maintained and shared with the customer Project Manager
after completion of each of the phase. A template of the Container document is
embedded below:

Container
document.zip
2.

Project Manager should prepare a Master Sign off document for all the
deliverables on which Infosys needs the customer sign off. This should be shared
with customer Project Manager. A template for the same in embedded below.

Sign Off
Template.zip
3.

Infosys Project Manager should track the important Project Measurement

Statistics and the same should be discussed with Infosys Management (and with
customer Management, if required) at regular intervals. The key milestones
metrics are discussed in the document given below.

Measurement_Analy
sis_Guideline.zip
4.

Project Manager should share the template of the Weekly Report with the
customer team. The template for the Weekly Report should be finalized in this
Phase.

Weekly Status
Report Template.zip

DONTS
1. Infosys Consultant(s) should not hesitate to discuss the minutest requirement
detail with the customer. It is better to have these understandings documented
and get a sign off from the customer rather then having ambiguities which will be
deleterious to the project.
Expedition Tips
1. Nothing specific to be highlighted

Page 10 of 45

Responsibility Matrix
S.
No

Deliverable

Primary Responsibility
(Onsite/Offshore)

1
2

Project Charter
Project Plan

Project Manager (Onsite)

Project Manager (Onsite)

Stakeholder Matrix

Project Manager (Onsite)

Configuration
Management Plan
Resource Plan

Project Manager (Onsite)

Project Manager
(Offshore)

Page 11 of 45

Secondary
Responsibility
(Onsite/Offshore)
Not Applicable
Project Manager
(Offshore)
Functional Consultant
(Onsite)
Project Manager
(Offshore)
Project Manager
(Onsite)

As-Is Understanding
Objective
1. The objective of this phase is to get an understanding of the present business
processes of the customer.
Entry Criteria
1. Sign off on the Project Plan from customer Project Manager
2. Stakeholder Matrix
3. As-Is discussion Schedule
Exit Criteria
1. Sign off on the As-Is document from the customer
Activities
1. Infosys Consultant(s) should have discussions with customer Business and IT
team on the As-Is Process. Some of the key areas, Consultant(s) need to
capture in the As-Is document are listed below:
a. Business Processes: Understand the customer business Processes,
preferably in a visio format. For each of the steps in the flow chart,
Consultant(s) s should capture the name of department, user role
executing that specific step.
b. Screenshots: If the customer is using a legacy application, capture the
screenshots corresponding to each of the steps in the business processes.
c. Documents (Invoice, Packing Slip, Picking List, Custom Invoice etc) required
during the business processes. These are mandatory documents required in
the business flow. (Need to be sent to customer, government, external party
etc). Purpose of the documents should be understood and documented.
d. Analysis Report: Understand the purpose of the each of the analysis
reports. Consultant(s) should collect the sample report copies. Purpose of the
reports should be understood and documented.
e. Security: A high level security requirement should be collected for each of
the processes. As a part of Security Requirement Gathering, Consultant(s) s
needs to understand the user roles and their privileges for each of the
business processes.
f.

As-Is Integration Points: Capture the details of all the integrations points
and their purpose

g. Field: Capture all the informational/derived fields used in the current As-Is
System. It is preferable to capture the purpose, data-types and length of
these fields.
h. Tables/Components APIs: If these fields need to be brought from the
legacy application, it would be preferable to capture the names of the table or

Page 12 of 45

parameters returned by the component APIs in the legacy system. This would
be of great help in the Data Migration and Interface development.
A As-Is template is embedded below:

As-Is Process
Template.zip

2. Infosys Consultant(s) should start working on the Requirement Document in this

phase. All the As-Is requirements which customer expects in the future ERP
should be documented.
DOS
1. Infosys Consultant(s) should try to be hands-on on the legacy system of the
customer. This will help them understand the As-Is flow better.
2. Understand how the As-Is Integration Points work and the data/message
exchanged.
3. Request Customer to give Read Access to their legacy system and their back
end database.
4. Project Manager should ensure that right audience are present for explaining the
As-Is process from the customer business team.
5. Peer Review (Onsite as well as Offshore) should be done on the As-Is document.
6. Once the Infosys Consultant have understood the As-Is processes, Infosys
Consultant should start showing the future ERP system to the customer. This will
help Business team to have an understating of the future ERP and will help
Infosys team start getting a buy-in of the ERP product.
7. Infosys will give the Security Set up training to customer team during the
Technical Design Phase. Final security configuration will be done by the customer
during the development phase. The same will be tested during the SIT. Infosys
Project Manager should communicate the same to customer Project Manager.
DONT
1. Documents and Report requirements are usually missed during the As-Is process
study. Infosys Consultant(s) should have the functional understanding of all the
documents and reports.
2. Do not assume anything in the As-Is processes. If there are any assumptions,
they should be explicitly mentioned.
Expedition TIPS
1. Infosys Consultant(s) should share the As-Is template with the customer before
this phase starts. It is expected that the customer business team comes prepared
for these sessions. Some of the tasks which can be expected from the business
team before these meetings are:

Page 13 of 45

a. Draft version of the Business process Flow: Infosys Consultant(s) should

study these process flows before going for the As-Is meetings.
b. Document and Report templates to be given to Infosys Consultant(s) s
beforehand.
These draft versions can be finalized during the As-Is meetings.
2. Some of the tasks like table information, data-type of the fields can be
accomplished with the help of the Customer IT team and Infosys Technical
Resource. Customer business team is not required for these tasks. This can be a
parallel activity.
Responsibility Matrix
S.
No

Deliverable

As-Is Document

Primary Responsibility
(Onsite/Offshore)

Functional Consultant
(Onsite)

Page 14 of 45

Secondary
Responsibility
(Onsite/Offshore)
1. Technical Consultant
(Onsite)
2. Functional
Consultant
(Offshore)
3. Technical Consultant
(Offshore)

Requirement Gathering
Objective
The objective of Requirement Gathering phase is to collect all the functional and
non-functional requirements of the customer. These requirements will be in bits
and pieces, which combined with the As-Is understanding will help Infosys
Consultant(s) prepare the To-Be-Process flows.
This phase can also be done in parallel with the As-Is phase. However if the
customer processes are complex, it is recommended that Requirements are gathered
in a separate phase. In this phase, it is expected that the customer business /IT
team mention the requirements which are not presently handled by their legacy
system.
Entry Criteria
1. Signed Off As-Is documents
2. Requirement Gathering discussion Schedule
3. Identification of customer Business Process owners
Exit Criteria
1. Sign off on the Requirement document from the customer
Activities
1. All the functional, Non functional and Interface requirements should be collected
in the requirement document.
a. Functional Requirements: These are functional expectations from the
application/package. Some of the key points are:
It is preferable to capture the detail requirements in an excel file.
Consultant(s) should also capture the genesis of these requirements.
Department/user name should be captured against these requirements.
Doing this will enable Consultant(s) to track them later for further
clarifications/discussion.
b. Non Functional Requirements: Consultant(s) should also capture any non
functional requirements during this phase. These requirements can be related
to:
System Performance
Response Time
Load
Availability

Page 15 of 45

c. Interface Requirements:
If the legacy system(s)/trading partners need to be exchange data with
the new system, these requirements should be captured here.
Non functional requirements of each of the integrations points like the
load, frequency, etc can be should be captured.
Details of existing EAI tool (if any) being used, the existing error handling
framework and reusable components (if any) should captured.
A template of the Business Requirement document is given below:

Business
Requirement Document.zip

2. This requirement sheet is the starting point for the preparation of the
Traceability Matrix. Consultant(s) s should use this document to capture the
requirements in detail. These requirements can then be tracked in the later
phases for coverage. The template of the traceability matrix is given below:

Traceability Matrix
Template.zip

DOS
1. Requirement documentation should be detailed enough so that individual
requirements can be tracked until the UAT test planning phase. Consultant(s)
should not try to club requirements.
2. Infosys Project Manager should communicate to customer that there can be some
requirements which cannot be met due to technical complexity or product
limitation, Infosys will get back to customer with proper reasoning of the same
during the Fit-Gap and Functional Design Phase.
3. If there are some tasks which need to be done by the customer IT team; the
same should be highlighted to customer Project Manager.
4. Peer Review (Onsite as well as Offshore) should be done.
DONTS
1. Nothing specific to be highlighted
Expedition Tips
1. Nothing specific to be highlighted
Responsibility Matrix
S.

Deliverable

Primary Responsibility

Page 16 of 45

Secondary

No

(Onsite/Offshore)

Requirement
Document

Functional Consultant
(Onsite)

Page 17 of 45

Responsibility
(Onsite/Offshore)
Functional Consultant
(Offshore)

Fit Gap Analysis

Objective
The objective of the Fit Gap phase is to map the Customer Requirements to Product
functionalities. Business Requirements are classified in given below four buckets:
1. Out of Box
2. Customization
3. Configuration
4. Not Possible
Entry Criteria
1. Signed off Requirement document
Exit Criteria
1. Classification of all the requirements in appropriate buckets (as per the Fit Gap
Analysis sheet). Infosys Project Manager should share the same with customer
Project Manager, if needed.
Activities
1. Fit Gap Analysis sheet is prepared during this phase. The Fit Gap Analysis
template is embedded below:

Fit Gap Analysis.zip

DOS
1. For the Complex/Not Possible requirements, Infosys offshore team should do
Proof of Concepts. If technical team is not able to achieve the same, product
vendor help should be taken. If it turns out to be a Product limitation,
Consultant(s) should highlight this to customer with proper reasoning.
2. If it is Fixed Price project and the number of Gaps found after Fit Gap Analysis
are much higher then what was budgeted for, Infosys Project Manager should
discuss the same with the customer Project Manager. If it leads to
Scope/Cost/Time increment, the same should be discussed candidly with the
customer.
3. Identification of extra software components /package that the customer might
need to buy. The same should be discussed with the customer and the list should
be derived and shared with customer.
DONTS
1. Nothing specific to be highlighted

Page 18 of 45

Expedition Tips
1. Nothing specific to be highlighted

Page 19 of 45

Responsibility Matrix
S.
No

Deliverable

Fit Gap Register

Primary Responsibility
(Onsite/Offshore)

Functional Consultant
(Offshore)

Page 20 of 45

Secondary
Responsibility
(Onsite/Offshore)
1. Technical Consultant
(Offshore)
2. Functional
Consultant (Onsite)

Functional Design Phase

Objective
The objective of the Functional Design Phase is to prepare the To-Be-Process flows,
have a complete functional understanding of the customizations, report, interfaces,
data migration and security requirements which needs to be developed as a part of
implementation.
Entry Criteria
1. As Is Process Document
2. Business Requirements Document
3. Fit Gap Analysis Document
Exit Criteria
1. Signed off Functional Design Document
2. Finalization of Data Model/Database Structure
3. System Architecture Document
4. Mapping Specifications for Interfaces
Activities
1. Functional Design document is prepared during this phase. A template of the
Functional Design is embedded below.

Functional Design
Document.zip

2. Database design to be finalized. (Use tools like PowerBuilder, Visio, etc to create
the data model)
3. Update the traceability matrix
4. Using the metrics collected on data load to derive the capacity planning
5. Prepare a system architecture document. This document highlights the
interaction between ERP product to be implemented and customer legacy
systems.
6. Identification and planning for the appropriate integration patterns to be used
taking into consideration the functional requirements/non functional
requirements.
7. Identification of Performance Testing tools to be used and its procurement.
DOS
1. Iterative internal and external review process during the preparation of
Functional Design Document will reduce the defects injected during this phase.

Page 21 of 45

2. Develop Proof of Concepts for complex requirements.

3. Publish the intended data model.
4. Review of Architecture document
DONTS
1. Do not leave the review process for the last stage. The review of Functional
Design document needs to happen continuously.
2. The different tracks like Reports, Integrations, Customizations, Extraction should
not work in silos. They should work cohesively to ensure all the requirements are
covered in the functional design document.
Expedition Tips
1. Nothing specific to be highlighted
Responsibility Matrix
S.
No

Deliverable

Primary Responsibility
(Onsite/Offshore)

Functional Design
Document

Functional Consultant
(Onsite)

Finalization of Data
Model/Database
Structure
System Architecture
Document

Technical Consultant
(Offshore)

Mapping Specifications
for Interfaces
Traceability Matrix

Technical Consultant
(Offshore)
Project Manager
(Offshore)

4
5

Technical Consultant
(Offshore)

Page 22 of 45

Secondary
Responsibility
(Onsite/Offshore)
1. Functional
Consultant (Onsite)
2. Technical Consultant
(Offshore)
Not Applicable
1. Functional
Consultant
(Offshore)
2. Functional
Consultant (Onsite)
Not Applicable
Project Manager
(Onsite)

Technical Design
Objective
The objective of the technical design Phase is to prepare a detailed level design so
that developers can directly code from this. Given to any developer, this document
should be able to explain the code structure.
Entry Criteria
1. Signed off Functional Design document
2. Mapping Specifications
3. System Architecture Document
4. Database Design
Exit Criteria
1. Sign off on the Technical Design document /low level design document/detailed
level design document.
2. Completion of draft System Integration Test Plan, User Acceptance Plan and
Performance Scenarios
3. Test Strategy document
Activities
1. Technical design is finalized during this phase. A template of the Technical Design
documented is given below:

Technical
Specification Document.zip

2. Set up the development instance

3. Pseudo query code for Database extraction and conversion logic should be written
in this phase
4. Pseudo code for the Performance Testing Scripts should be written here
5. A Test Strategy document should be prepared and discussed with customer.

Master Test Strategy

Template.zip

Test Strategy
Template.zip

Performance Test
Strategy Template.zip

6. Prepare System Integration Test Plans. A template for the same is embedded
below:

SystemIntegration
Test Plan.zip

Page 23 of 45

7. Prepare User Acceptance Test Plan. A template of the UAT Plan is embedded
below. The UAT Plans should be prepared by the Customer Business/IT Team.

User Acceptance
Test Plan.zip

8. Performance Testing Scenarios are identified and documented.

9. Trace back all the technical designs to match with the traceability matrix.
10. Unit Test Cases should be prepared during this phase: A Unit Test Case template
is embedded below:

Unit test Plan.zip

11. The Development Environment is set up along with all the softwares in place.
12. Format of the training material should be finalized during this phase. Sample
training material documents are attached below. This needs to be finalized after
discussing with the customer.

Training Material
Template 1.zip

Training User Manual

Template.zip

13. Infosys Consultant should give Security Set up training to customer team.
14. Instance Plan should be prepared during this phase. Customer should ensure the
procurement of hardware as per this plan. A Instance Plan set up is embedded
below:

Instance Plan.zip

DOS
1. Identification of Reusable components. Try to use existing reusable components
wherever feasible like for e.g. Error handling framework, alerting framework, etc.
2. Try to design the code in such a way so that reusable artifacts can be made out
them.
3. Setting up the best coding practices and guidelines for the development team.
4. Constant iterative reviews should be put in place for all the Technical Design
documents and Unit Test Cases.
5. Unit Test Cases should cover both positive and negative test cases. They need to
be reviewed thoroughly to ensure all the unit test cases are covered. Field by
field verification should be done.

Page 24 of 45

DONTS
1. Do not paste code in Low Level design documents; rather place the algorithm or
the pseudo code.
Expedition Tips
1. Infosys Consultants have complete information about the UI and Database
Structure by the end of Functional Design Phase. It is advisable to have a CRP in
which Infosys Consultant configure the system and get a sign off on the UI.
During this CRP, Infosys technical team will finalize the UI and configure the same
in the product. There is no backend logic written on the controls.
Any Proof of Concept developed during the previous stages can also be covered
as a part of this CRP.
Responsibility Matrix
S.
No

Deliverable

Technical Consultant
(Offshore)
Functional Consultant
(Offshore)
Functional Consultant
(Offshore)
Project Manager (Onsite)

Technical Design
Document
Draft System
Integration Test Plan
Draft User Acceptance
Plan
Test Strategy
document
Unit Test Case

Traceability Matrix

Project Manager
(Offshore)

2
3
4

Primary Responsibility
(Onsite/Offshore)

Developers (Offshore)

Page 25 of 45

Secondary
Responsibility
(Onsite/Offshore)
Not Applicable
Functional Consultant
(Onsite)
Functional Consultant
(Onsite)
Project Manager
(Offshore)
Technical Consultant
(Offshore)
Project Manager
(Onsite)

Development
Objective
The objective of the development phase is to deliver Unit Tested pieces of code which
can be moved into the next stage for System Integration Testing so that the system
as a whole can be tested.
Entry Criteria
1. Technical Design document /Low Level Design document/Detailed Level Design
document
2. Unit Test Cases
3. Development Environment is set up
Exit Criteria
1. Developed and Unit Tested code
2. Unit Test Cases updated with Test Results
3. Release Notes
4. Sign off on the System Integration Test Plan, Performance Testing Scenarios and
UAT Plans
5. Installation Guide and Deployment Plan released
Activities
1. Coding for the customizations, Report, Interfaces and Data Migration is done
during this phase. All the functional as well as Non Functional Requirements
should be taken care during the development.
2. Preparation if Installation Guide and Deployment Plan
3. Update the traceability matrix
4. Scripts should be written for the Performance testing scenarios
5. Develop automated test Scripts
6. Build Data Migration scripts, perform the ETL and complete the sanity testing for
the same
7. Review of System Integration Plan, User Acceptance Plan and Performance
scenarios with the Business Team.
8. Training Material should be prepared
9. Infosys Project Manager should discuss the Contingency Plan with the customer
Project Manager and plan for any contingencies after Go-Live.
10. Customer team should do the Security configuration of the ERP system. This
entails defining the User Groups and configuring the access permission for the
same.

Page 26 of 45

DOS
1. Iterative Code Reviews & walkthroughs for components
2. Develop a Test Harness tool for testing commonly used functionalities and
complex calculations and logic.
3. Close involvement of the functional team with the technical team to review the
functionalities developed and identify any missing components.
4. Carry out development with a proper sub set of real time data. The data can be
scrambled if the information is sensitive.
5. Ensure code is well commented with proper indentation to ensure proper
readability.
6. Ensure that all the files checked into visual source safe with proper comments.
7. Any change in the database schema at this stage should be properly
communicated as it impacts all the tracks and its effects should be evaluated
before the change is actually made.
8. Continuously update the technical design so that it is always in synch with the
code developed.
9. Avoid building very complicated logic in stored procedures and try to keep them
in application logic for easier debugging.
10. Periodic builds on developed code should be done to identify compatibility issues
and to ensure that components are not breaking. This is particularly useful when
the code base is large.
11. Periodic deployment on a clean server so as to identify any major system
integration issue before hand. This also serves as a double check on the build
process.
12. Carry out a few rounds of data load in clean environment and test for any issues
around functionality and performance. Perform a basic sanity check around the
same.
DONTS
1. Do not release untested components in the SIT Phase.
2. Never check in code that is not compiled in the Source Safe as it might break
other components.
3. Do not have multiple versions of the same file checked into source safe.
4. Do not have Integrations, Reports and Customizations running on different
versions of the code base.
Expedition Tips
1. Pilot CRPs with customer during the development stage will help Infosys get a
feedback on the development.
Responsibility Matrix

Page 27 of 45

S.
No

Deliverable

Release Notes

Final System
Integration Test Plan
Final User Acceptance
Plan
Installation Guide and
Deployment Plan
Training Material

Traceability Matrix

Contingency Plan

3
4

Primary Responsibility
(Onsite/Offshore)

Technical Consultant
(Offshore)
Functional Consultant
(Offshore)
Functional Consultant
(Onsite)
Technical Consultant
(Offshore)
Functional Consultant
(Offshore)
Project Manager
(Offshore)
Project Manager (Onsite)

Page 28 of 45

Secondary
Responsibility
(Onsite/Offshore)
Not Applicable
Functional Consultant
(Onsite)
Functional Consultant
(Offshore)
Not Applicable
Functional Consultant
(Onsite)
Project Manager
(Onsite)
Project Manager
(Offshore)

System Integration Testing

Objective
The objective of the System Integration Phase is to test the applications from a
functional, Integration perspective.
Entry Criteria
1. Sign Off on the System Integration Test Plans by the customer
2. Readiness of the System Integration Environment and Customers Legacy System
(If used)
3. Completion of Data Migration
4. Completion of Development and Unit Testing.
5. Release Notes from the Development. Attached is a template of Release Note.

Release Note
Template.zip

6. Release of Installation Guide and Deployment Plan from the Development Team
7. Connectivity should be established and checked if the testing is done at offshore
using the server at customer location.
8. Appropriate data needs to set up in Source Systems covering all the possible
scenarios for Integration testing
Exit Criteria
1. Sign off from the customer Project Manager on the Open defects from System
integration Testing
2. Fixing of the defects found during System Integration Testing
3. Training scope and schedule is finalized
Activities
1. Execution of System Integration Test Plan
2. Execution of Performance testing
3. Separate testing for Data needs to be performed
4. Update the traceability matrix
5. Finalize the training scope with the customer Project Manager
6. Prepare training schedule for User Training
7. Set up the User Training instance
DOS
1. Ensure that development is 100% complete before this phase is started.
2. Perform Sanity testing before releasing any build in the SIT instance

Page 29 of 45

3. The release of any patches in the SIT instance should be managed as this is a
controlled environment. Appropriate notification should be send to all the
stakeholders before and after patch release.
4. Appropriate release notes and back out plans should accompany any build/patch
release to SIT instance.
5. Infosys Project Manager should track the defect fixation rate very closely. If
required, defect aging report should be published every day.
6. If the UAT Plans are ready, Infosys testing team should also test the UAT
Scenarios in a separate environment.
DONTS
1. Do not release any build in the SIT Environment during this phase. If there is any
critical defect, the patch for the same needs to be released with proper
notification to all the stakeholders.
Expedition Tips
1. Nothing specific to be highlighted
Responsibility Matrix
S.
No

Deliverable

Traceability Matrix

Primary Responsibility
(Onsite/Offshore)

Project Manager
(Offshore)

Page 30 of 45

Secondary
Responsibility
(Onsite/Offshore)
Project Manager
(Onsite)

User Training
Objective
The objective of User Training Phase is to enable the customer IT/business users
understand and use the future ERP system. Users will not be able to do the User
Acceptance testing, if they lack the competency is using the system.
Entry Criteria
1. System Integration Testing is complete. All the open defects from SIT have been
discussed with the customer.
2. Training Plan and schedule finalized
3. Training Scope signed off with the customer
4. Training content prepared and signed off by the customer
5. Training Instance is ready.
Training Data
Security Roles set up
Exit Criteria
1. Training feedback is collected from the Trainees and analyzed. The template for
the Training Feedback form is embedded below:

Training
Evaluation.zip

2. Take Sign-Off at the end of User Training completion.

Activities
1. Training is delivered to the end users. Trainers should ensure that concepts as
well as Use Case (Business Cases) are covered a part of training.
2. Discuss and finalize the Go/No Go criteria for the UAT.
3. Prepare the UAT schedule
4. Prepare the UAT instance
DOS
Some of the key things Trainers need to take care during the training are:
Facilities/Equipment
1. Check the training room at least 24 hours before conducting the first class.
2. On the day of training the Instructor should arrive in the training class at least 30
minutes before training.
3. Ensure there are enough chairs & PCs.

Page 31 of 45

4. Endure there are Flip Charts in the room. These will help you note down any
issues, clarifications, requirements during the training.
5. Log all computers onto the ERP
6. If possible, write the Agenda and Objectives on presentation size paper (A1) and
pin to the wall.
7. Ensure all training rooms are correctly identified
Instructor Techniques
1. The instructor should preface all training by introducing themselves; their
position and establishing their credentials (ERP experience, length of time on
project, etc.)
2. Define the purpose and nature of the training to be delivered.
3. Ensure the participants understand why they are in the training room and what
they should expect to get out of the training.
4. An Agenda and set of Objectives should be clearly displayed and explained at
the beginning of each course. Preferably the agenda should remain in view at all
times so progress can be charted.
5. The instructor should think about the way they are delivering the course and their
presentational technique. If they feel style and presentation points may be an
issue, the course should be piloted with one or more of colleagues.
6. Know the audience boredom threshold. The participants may not be as
motivated as the instructor. The instructor should allow an unscheduled break if
they feel the mood of the room is shifting away from them.
7. The instructor should not be scared to be innovative.
8. Ensure the narrative has a logical progression. Follow the course structure laid
out in the training list and agenda, but do not be afraid to deviate from it.
However, ensure that all points are covered.
9. If the instructor does not know the answer to a question, write it on a flip chart
and promise to get back to the class with an answer within 24 hours.
10. Engage the whole audience not just the friendly ones.
11. Always answer questions, even if to say you will answer it later.
12. If the instructor makes a mistake, admit it and continue.
13. If the instructor is uncomfortable with their hands, hold a pen or a pointer or
highlighter.
14. Wear comfortable shoes, the instructor will be standing for long periods of time.
15. The instructor should know the content. Their confidence and ease with the
system will be transferred to the participants.
16. Reinforce information. Repeat the information in different ways. Summarize
frequently.

Page 32 of 45

17. Always remember eye contact and positive words. Do not denigrate the system;
say challenging not difficult, powerful not complex.
18. Instructors should enjoy themselves. Their enjoyment will reduce the audience
stress and anxiety.
Training Materials
1. Instructor is familiar with the transactions/system tasks
2. Instructor is familiar with the structure of the course
3. Data exists for the training course, both for the presentation and for the
participant exercises/scenarios
4. Ensure the exercises/scenarios are valid for the class.
5. Print/photocopy all trainee training materials at least 24 hours before training.
Do not leave it to the last minute.
6. Consider the following when Demonstrating a transaction:
o

Identify the critical path through the transaction. Decide which, if any,
optional screens to show. Remember that new users may be easily
overwhelmed if they are given too many choices.

Decide which fields to mention on each screen, keeping in mind the job
descriptions of the participants using the transaction.

Review the data you will need to enter as you demonstrate the transaction. If
possible, practice using the data.

Identify information that will be of particular relevance for the participants.

Explain to participants that this is a chance for them to watch as you walk
through the transaction. Assure them that everyone will get to practice on
their own during the exercise that follows.

Conduct the demo in a deliberate way, describing what you are doing as you
perform the action. As you show the relevant screens, you may want to have
participants recall points made during the concepts portion of the class.

Point out actions that are very common in the ERP system, such as beginning
a new transaction with an N and the transaction code in Axapta. This helps
users feel that theyre getting a handle on the system as a whole.

Point out actions that are unexpected in the ERP system (selecting an option
using PF15 instead of Enter in Axapta, for example). This helps users feel
that their instincts as to what to do are correct but that this situation is an
exception.

Do not suggest alternate paths or shortcuts the first time through. First-time
users dont want choices.

Remember to ask participants if they have any questions about each screen
and how they will use it.

Remember to discuss examples and information relevant to participants jobs.

Page 33 of 45

When the transaction is complicated, you may want to tell participants that
youre halfway through or almost finished.

You can refer to the navigational chart on the front page of the job aid and
tell them which step of the job aid shows them how to move to a certain
screen.

Emphasize the basic flow through the transaction to perform the job. Repeat
the major steps so the class doesnt get bogged down in details.

7. Consider the following when conducting an Exercise:

o

Review the exercises and identify which are appropriate for this class.

Review the prepared data set to make sure it is appropriate.

Identify additional exercises that can be used by quick learners.

Remind participants of the purpose of the exercise:

To give participants experience with tasks they will do on the system as part
of their job.

To give them practice in using the job aid, the step-by-step instructions theyll
use back on the job to perform the transaction.

Have participants locate the appropriate exercise in the notebook. Help them
find it if necessary.

Have participants turn to the job aid in the notebook.

Inform participants of the time allotted for the exercise. (It often works well
to schedule the exercise portion before a break so that those who need to
take more time may do so.)

Tell them that they may work at their own pace but that you will be circulating
and available for questions.

Circulate to make sure everyone has found the correct exercise and job aid.

Provide coaching to those who need it.

Who needs it?
Only a few participants will want or need individual help. Of those who do,
some will want the answer to a quick question and then want to return to
working on their own. Occasionally, participants will want you to sit
beside them the whole time; you may be able to assign more experienced
participants to work with them.
How do you do it?
Try not to take over the keyboard. Its always best to have participants do
the keyboarding themselves while you talk them through the process.
Sometimes its more efficient for you to demo a certain step, but then
undo your work, if possible, and have the participants try it.
If several participants are having the same problem, you may want to
provide clarification to the class as a whole

Page 34 of 45

Listen sympathetically if a participant complains that the system is illogical or

harder to use than their old system, but dont engage in a lengthy discussion
about how it could be different. Show the participant the simplest way to
accomplish the task at hand.

Ask the participants the questions listed below.

Was everyone successful in finding the data required?
Were there any areas of confusion?
What aspects of this transaction were similar to other transactions
youve used?
What was different?

DONTS
Instructor Techniques
1. Avoid jerky/nervous movements, in order not to appear jerky and nervous
2. Adjust verbal pitch and tone in order NOT to be monotonous.
3. Do not talk too fast - the audience will drift away. Be exhaustive not exhausting.
Do not rush through the material. If the instructor feels times allocated to a
course are inadequate, adjust them prior to training as far as possible.
4. If a transaction does not work, the instructor should not try to solve it unless it is
very obvious. Explain how it should work, and continue. If it is critical, give the
class a break and try it on your own or call someone for help.
5. Avoid long gaps in delivery unless for deliberate effect.
6. Do not insult the audience's intelligence. Be patient with slow learners.
Encourage the audience to help each other during the exercises.
7. Do not override relevant dialogue that breaks out within the audience (within
limits). The instructor should channel it to their advantage in order to let the
trainees lead on to the next agenda item.
Expedition Tips
1. Confidence of the Trainer is of utmost importance.
Responsibility Matrix
S.
No

Deliverable

Traceability Matrix

Primary Responsibility
(Onsite/Offshore)

Project Manager
(Offshore)

Page 35 of 45

Secondary
Responsibility
(Onsite/Offshore)
Project Manager
(Onsite)

User Acceptance Testing

Objective
The objective of the User Acceptance Training is to get the developed system tested
by the End Users and get a sign off for Go-Live.
Entry Criteria
1. Finalization on Go-No Go decision criteria
2. UAT Test Cases
3. Review of UAT Test Cases completed by Infosys team
4. UAT Environment Set Up
5. Completion of User Training
6. UAT Schedule is finalized
6. Data Set up for UAT Cases
7. Security Roles set up
Exit Criteria
1. Go-No Go Decision by the customer business and IT team
Activities
1. Execution of UAT scenarios by customer business/IT team
2. Infosys team to do the following tasks:
a. Facilitate the Users in execution of UAT test cases
b. Record and categorize (Critical, Major, Minor, Cosmetic) the defects found in
UAT
3. Set up Production instance
DOS
1. Record the defects found during in UAT. These defects need to be discussed with
the Customer team at the end of day.
2. Any patches released in UAT need to be thoroughly tested first in the SIT
Instance before it is updated in the UAT environment.
3. All UAT patches and builds should be accompanied with appropriate release
notes.
DONTS
1. Once the data has been set up, no one from IT team should modify or tamper
with those records, any data created for doing sanity test should be cleansed or
demarcated properly.

Page 36 of 45

2. Do not waste time in discussing the defects found once it is found. The same
should be discussed at the end of the each day with the Customer team and
classified into Critical/Major/Minor and Cosmetic bucket.
Expedition Tips
1. Nothing specific to highlight
Responsibility Matrix
1. Nothing Specific to highlight

Page 37 of 45

Go-Live
Objective
Once the users have tested the system in UAT and are comfortable with the
functionality and performance of the same, the system is deployed to be used in
Production.
Entry Criteria
1. Go ahead from users after UAT
2. Infosys and Customer Team are in sync with the open defects after UAT and are
ready to Go-Live with these defects
3. Production Environments Set Up
4. Extraction for Production Data Complete
5. Necessary Back up strategies in place for both system and database.
6. Steps for rolling back in case of any major issues (unidentified earlier) should be
well defined.
7. All the external systems are ready and configured.
8. Performance Testing is complete
Exit Criteria
1. Successful Go-Live
Activities
1. Production Deployment activities (Code Migration, Data Migration, Security Roles
Set Up, Interfaces code migration)
DOS
1. Ensure that Infosys team has done Sanity testing before Infosys actually switch
on the system for user in Production.
2. If there is any confusion regarding the functionality and performance of the
developed application, Infosys and customer can decide to have a CRP before GoLive and after UAT.
3. Infosys and Customer Project Manager should jointly decide the number of
Cosmetic/Minor/ Major/Critical defects with which the system can be made Live.
DONTS
1. Do not Go-Live if the Users are not comfortable with the System.
2. Infosys should not try to make any code changes based on defects in UAT unless
the defects found are very critical. These changes can be done after Go-Live
during the Support Phase. Making any changes to the code just before Go-Live
can lead to defect creep.

Page 38 of 45

Expedition Tips
1. Given below is a checklist which Infosys Project Manager can use before Go-Live.
Project Manager should discuss the same with the customer, team members so
that all the key activities are covered in check list.

Go_No-Go Live
Checklist.zip

Responsibility Matrix
1. Nothing Specific to highlight

Page 39 of 45

Key Risks and Mitigation Strategies

S.No

Risk

Mitigation Strategy

Requirement Analysis and Functional Specification Phase

1

There is a gap in the

Scope understanding
between Infosys and
Customer

Infosys should avoid any ambiguity in the SOW.

Before the project starts, Project Manager
should have a complete understanding of the
SOW and should clarify any ambiguous inscope/out of scope points with the customer
Project Manager during the Project Initiation
Phase.

Non availability of key

Before the As-Is phase starts, Infosys Project

members of the clients

business team to explain
the As Is
requirements.

Manager should ensure following things:

Understanding of the As Is process is taking much

more than the stipulated
time.

1.

Stakeholder Matrix is finalized

2.

As-Is schedule is prepared and meeting

requests are send to the participants

3.

Suitable back-ups should be planned and

highlighted in the stakeholder matrix

4.

In case the relevant business process

owners do not attend the meeting, same
should be escalated to Infosys and
Customer Management

1.

Project Manager should have sufficient

buffer planned for any such unforeseen
increase in timelines due to the complex
customer processes

2.

Infosys team should inform the increase in

time with the customer Project Manager

3.

Infosys team should prepare a detailed FitGap Analysis sheet and if the scope seems
to have major deviations from budgeted
scope, an alarm should be raised to Infosys
and Customer Management

Conflicting views within

the business on the To-Be
business process and not
being able to reach a
consensus.

Infosys Project Manager should capture all such

issues in an issue tracker and ensure their
resolution before the start of the Fit Gap
Analysis

The number of gaps

If the scope seems to have major deviations

Page 40 of 45

identified is much more

than expected in the fitgap analysis

from budgeted scope, Project Manager should

raise an alarm to Infosys and Customer
Management

Sign off on the As-Is and

Functional Design
document delayed by
customer

1.

Project Manager should plan for review time

of Functional Design documents by the
customer business/IT in the Project Plan.

2.

Infosys Project Manager should share the

Entry and Exit criteria for the various
phases with the customer Project Manager.
Infosys Project Manager should avoid
starting the work for the next phase until all
the exit criterias for the previous phase are
met.

Technical Design and Development

7

Lack of expertise in the

technical team

Infosys Project Manager should arrange for

appropriate training before the start of
development phase.

Product limitations
identified, technical roadblocks identified.

1.

Infosys team should work with Product

Vendor to resolve the issue.

2.

It is advised that for complex requirements,

technical team should do Proof of Concept.
This will help to identify such road-blocks at
an early stage

3.

If there is any issue with the Product

Vendor, it is advisable to inform the
Customer Project Manager on the same.

1.

There should an internal issue tracker

maintained to capture all such issues.

2.

Functional team should do a walkthrough of

the requirements with the offshore team

3.

Technical team should take feedback on the

developed customizations from the
functional team members. If key functional
team members are onsite, demo should be
arranged via meeting place, net meeting.

1.

Infosys Project Manager should ensure

thorough Unit Testing, Code Reviews to
reduce the number of bugs

2.

Adhere to specific dos and donts

mentioned in the phases prior to System

Gap in understanding of
the requirements between
functional and technical
team

System Integration Testing

10

Large number of bugs

identified during testing.

Page 41 of 45

Integration phase.
11

Non-Functional (like slow

response time)
requirements are not met

1.

Project Manager should be knowledgeable

of the Product Performance benchmarks
published by the product vendor and ensure
that the commitment is in line with the
published document. This document should
also be shared with the Customer Project
Manager.

2.

Performance Tuning tips and suggested best

practice should be followed

3.

Ensure that the hardware configuration of

the SIT environment is not very different
from Production environment.

4.

Help from Product vendor should be taken.

5.

Help from a network/infrastructure expert

might be useful. The issue might get
resolved by clustering, load balancing
methodologies

12

Not all the systems are

ready for Integration
Testing.

Project Manager should publish environment

plan during the Technical Design Phase of the
project

13

Critical issues identified

which cannot be
reproduced.

1.

Debugging techniques like SQL tracing can

be run on the SIT environment to diagnose
the defect.

2.

Developers should try to reproduce the

issue with the same data as used in the
testing. The defect can be a data issue.

1.

Infosys Project Manager should ensure

thorough Unit Testing, Code Reviews to
reduce the number of bugs

2.

For Complex requirements, CRP should be

conducted to get the functionality ratified
by the Customer.

3.

Infosys Project Manager should inform the

Customer Project Manager and if required,
extend the SIT timelines.

1.

Subset of real data should be used in the

development environment

2.

Infosys Project Manager should plan and

ensure data cleansing.

14

15

Critical issues identified

whose fix would need
significant amount of
design change and hence
extensive rework.

Large number of data

related issues due to bad
data

Page 42 of 45

User Training
16

Large number of usability

issues pointed out.

CRP should be conducted during the Technical

Design phase (same has been highlighted in
the Expedition Tips of the Technical Design
Phase)

17

Users want many features

to be changed which were
not included in the
requirements document.

Trainer should documents such issues and

should be discussed with the Customer Project
Manager at the end of each training day. A
signed-off copy of all the documents should be
taken as reference for such discussions.

User Acceptance Testing

18

Large number of critical

issues found in UAT

Infosys Project Manager should ensure

thorough Unit Testing, Code Reviews to reduce
the number of bugs

Deployment and Go-Live

19

System having
performance issues.
Downtime in business

1.

Performance Testing should be done during

the SIT Phase with complete Production
data (Master as well as Transaction)

2.

Business Continuity plan should be finalized

with the customer during the development
Phase and appropriate planning for should
be done well in advance.

1.

Infosys Project Manager should have

appropriate backups for the critical
resources.

2.

Internal knowledge transfer sessions should

happen on regular basis within the team.

Others
20

Critical resources leaving

the project

Page 43 of 45

ERP Implementation for SMB Customers

SMB ERP implementations have different needs vis--vis Global 2000 customers. The
key needs of the SMB customers are:
1. IT Expertise: SMB customers usually do not have well defined IT processes and
strong IT team. The size of the customer IT team can also be very small. So as
implementation Partner, Infosys needs to educate the customer IT team and
guide them with the right steps they need to take for successful implementation.
2. Governance Structure: The Project Governance Model might not be very well
defined by Customer. Infosys team needs to have complete clarity on the
Stakeholders from customer team. Business Team needs to be involved from the
beginning in the project. Infosys team needs to stress on periodic Steering
Committee meeting to update the Infosys and Customer Management of any
potential risks.
3. Expectation of One-Stop-Shop: SMB customers expect the implementation
Partner to provide solution in all the implementation areas like Hardware Sizing,
Performance Testing, Network Architecture (Pertaining to the implementation
done) etc. Project Manager should make it clear in the Project Initiation Phase if
these are a part of scope or not.
It is paramount for Infosys to execute the SMB implementations at lower cost and
timelines. It is pertinent for Infosys to follow all the stages required for tier 1
implementations. However some of the tips to reduce the timelines and cost are
given below:
1. Infosys Consultant(s) should share the As-Is template with the customer as
soon as Infosys get the project. Infosys should request customer to fill in these
templates (As-Is Process flows and other details) and send back. Infosys
Consultant can study these documents offshore before traveling for the As-Is
phase.
2. Infosys Consultant should map customer As-Is processes with SMB ERP Package
processes and show them on charts during/in the end of As-Is process flows.
3. Infosys Consultants should try to minimize the customizations to be done in these
SMB ERP packages. Infosys consultant(s) should suggest innovative workarounds
to reduce the number of customizations. An example can be use Macros for
calculations which are done rarely (twice a year) and feed in the final values in
ERP rather than building customization in ERP for the same.
4. CRPs should be conducted to get a buy-in from customers. CRPs should be held
at regular stages of design/development phase.

Page 44 of 45

5. Infosys team should re-use the training material (concepts section) prepared in
other projects and add on the processes steps as per the customer requirements.
6. Re-usable artifacts (code/document templates) should be used form previous
projects.
7. Infosys Project Manager should request customer IT team to attend the standard
product training during the development phase. This will expedite the product
learning process and will help the project during the training phase.

Page 45 of 45