Acumatica Implementation

H100 Introduction to
Acumatica Implementation
Delivery Framework

Training Guide

Last Revision: 11/2/2016

Acumatica ERP 6.0
Contents
Introduction .................................................................................................................................................. 4
Acumatica Implementation Delivery Framework ......................................................................................... 5
Learning Objects .................................................................................................................................... 5
Key to running a Successful Implementation by avoiding key failure indicators: .................................... 5
Understanding Project Types .................................................................................................................... 7
Key Terms.................................................................................................................................................. 7
Key Elements of Acumatica’s Implementation Delivery Framework ....................................................... 8
Project Roles ............................................................................................................................................. 9
Lesson 1: Understanding Discovery Processes ........................................................................................... 14
Learning Objects .................................................................................................................................. 14
1.1 Why the Discovery Phase is important ............................................................................................. 14
1.2 Steps for a Successful Discovery: ...................................................................................................... 14
1.3 Discovery Key Activities and Deliverables......................................................................................... 17
Lesson 2: Understanding Planning & Monitoring Processes ...................................................................... 18
Learning Objects .................................................................................................................................. 18
2.1 Why the Planning & Monitoring phase is important: ....................................................................... 18
2.2 Core Project Management Processes: .............................................................................................. 19
2.2.1 Develop & Monitor Project Plan & Schedule ............................................................................. 19
2.2.2 Develop & Manage Project Team .............................................................................................. 22
2.2.3 Plan Communications ................................................................................................................ 22
2.2.4 Plan & Monitor Quality Assurance & Stabilization .................................................................... 22
2.2.5 10 steps to a successful project kick-off meeting ...................................................................... 24
2.2.6 Core Project Management Activities and Deliverables: ............................................................ 26
2.3 Risk Management Processes:............................................................................................................ 26
2.3.1 Identify Risks .............................................................................................................................. 27
2.3.2 Managing Risks........................................................................................................................... 28
2.3.3 Strategies for Negative Risks or Threats .................................................................................... 28
2.3.4 Risk Management Activities and Deliverables: .......................................................................... 30
2.4 Contract Management Processes: .................................................................................................... 30
2.4.1 Monitor and Control Project Work ............................................................................................ 30
2.4.2 Managing Changes to Scope ...................................................................................................... 30
2.4.3 Managing Budget and Costs ...................................................................................................... 31
2.4.4 Managing Client Billing .............................................................................................................. 31
Page 2 of 59
 2.4.4 Contract management Activities & Deliverables ....................................................................... 32
2.5 Using Project Management applications to help manage a project................................................. 32
Lesson 3: Understanding the Analysis & Design Process ............................................................................ 34
Learning Objects .................................................................................................................................. 34
3.1 Why the Analysis & Design Phase is important ................................................................................ 34
3.2 Analysis & Design Activities - Express Project ................................................................................... 34
3.3 Analysis and Design Activities – Standard & Advanced Projects ...................................................... 35
3.4 Guide to Mapping Business Processes .............................................................................................. 37
3.5 Collecting Configuration Requirements ............................................................................................ 40
3.6 Collecting Customization Requirements ........................................................................................... 41
3.7 Best Practices for preparing a Data Migration plan .......................................................................... 46
3.7 Analysis and Design Activities and Deliverables ............................................................................... 48
Lesson 4: Understanding the Build Processes ........................................................................................... 49
Learning Objects .................................................................................................................................. 49
4.1 Why the Build Phase is important..................................................................................................... 49
4.2 Build Phase - Key Activities & Deliverables ....................................................................................... 50
Lesson 5: Understanding the Stabilization Process .................................................................................... 51
Learning Objects .................................................................................................................................. 51
5.1 Why the Stabilization Phase is important ......................................................................................... 51
5.2 Stabilization - Key activities and deliverables ................................................................................... 51
5.3 End User Training Models ................................................................................................................. 52
5.4 User Acceptance Testing Best Practices ........................................................................................... 52
5.5 Cutover Plan Components ................................................................................................................ 54
Lesson 6: Understanding the Deploy Process ............................................................................................. 56
Learning Objects .................................................................................................................................. 56
6.1 Why the Deployment Phase is important ......................................................................................... 56
6.2 Deployment - Key activities and deliverables ................................................................................... 56
Lesson 7: Understanding the Post Go Live Process .................................................................................... 58
Learning Objects .................................................................................................................................. 58
7.1 Why the Post Go Live Phase is important ......................................................................................... 58
7.2 Post Go Live - Key activities and deliverables ................................................................................... 58
7.3 Conducting a Post-Project Review .................................................................................................... 58
7.4 Hand over to support ........................................................................................................................ 59

Page 3 of 59
Introduction

The purpose of this course is to explain the fundamental principles and proven practices of the
Acumatica Implementation Delivery Framework for successfully delivering implementations faster and
yielding higher quality results. The Framework was designed to help partner organizations understand
the dynamic nature of implementation project environments and provide the tools to successfully
deploy Acumatica.

The course is divided into 7 lessons that focus on the processes involved in each phase of the
Implementation life cycle. At the end of this course, the student will understand all the key elements of
Acumatica’s Implementation Delivery Framework and when to apply the appropriate tools to different
project types.

Page 4 of 59
Acumatica Implementation Delivery Framework
Learning Objects

Learn about Acumatica delivery Framework, different Project Types, Key Terms, Key Elements and Roles
for a successful Acumatica Implementation

Why Acumatica Implementation Delivery Framework?

Acumatica recognizes that the one size fit all approach, which treats all implementation project
in the same way is not the best practice. There are several considerations, environmental
factors and constraints that affect a project. Acumatica’s Implementation Delivery Framework
was designed to be scalable for different project types, as well as help Partner organizations
achieve a high level of customer satisfaction, increase channel productivity and improve
profitability. The framework includes project management discipline based on field-tested best
practices, in addition to tools that will guide you through the deployment process and
configuration of Acumatica.

Key to running a Successful Implementation by avoiding key failure indicators:

There are many important aspects to a successful Acumatica ERP Implementation. Success
requires people who will be involved through the life cycle of the implementation project.
Management must provide appropriate resources, key performance indicators (KPIs), realistic
timelines, and encourage employees to accept the changes coming.

Somewhat surprisingly, it is generally agreed among the ERP consulting community that failures
are rarely caused by the software. Most of the packages on the market today actually do what
the vendor claims. Ultimately, what this means is most of the problems that come
with an ERP install can be summed up in one word: People.

The mistakes that lead to the ultimate failure of an ERP implementation are often cumulative
and iterative and can take many months to unfold.

While success is repeatable each failure is unique, when you start looking closely some common
themes start to surface.

Below are some of the top common reasons why implementations succeed:

1. Experienced Project Manager – A strong leader to keep the project team accountable and
on track will be critical to the success of the project.

2. Setting Proper Expectations - In the beginning of any new project, you have is a great deal
of excitement over the benefits that a new system will bestow upon the organization --
streamlined processes, bottom-line savings, top line growth, more efficiency, reduced
waste, better customer service, etc . Problems arise when this leads to a “hurry up and get

Page 5 of 59
 things done” approach. When business processes and goals are not clearly understood and
defined.

3. Communication - Having open and frequent communication with stakeholders is an

essential component of good project management. Ensuring all stakeholders are equally
informed of how, when, and why communication will happen. Communication is often a
very effective way to solve problems, deal with risks, and ensure that tasks are completed
on time.

4. Proper Planning Documents – Strong planning documents are crucial to understand how
the project is trending. It is extremely difficult to clearly understand cost overruns and
missed deadlines until after they occur.

5. Resource availability- Communicating the level of resource commitment the project will
take is equally important. Most companies have very little overhead. Team Members must
devote an additional 10 to 30 percent of their day to this project at any given time. Which
begs the question, can they really do this and do their “day job” too?

6. Information loss and delays due to staff change – It is not uncommon for projects to lose
resources on the way. When resources leave a project, it can cause tremendous delays to
find new resources and get them up to speed quickly.

It is important to have your clients understand that ERP is a business initiative, not an IT
project or a software package.

A critical first step is to know why your client is implementing a new ERP system and what
they expect to get from it. Involving key personnel and stakeholders early in the process as
you define the outlines of the initiative will save a lot of rework later in the project.
Communicate openly the strategy and tactics with the entire organization and make sure
the Executive Sponsor stays involved and educated as the project progresses. It’s difficult to
over communicate. Keep control of scope and leave the little things for once you’ve
completed the heavy lifting.

A strong project team always looks at the ERP project through the eyes of those most
effected by the change. In the end, they are the ones who have the most to gain and to
lose. This will guide the team to make a lot more right decisions than wrong ones.

Page 6 of 59
Understanding Project Types

Assessing your client’s delivery environment is very important in deciding the implementation
approach and methodology that should be applied. It is very critical to understand the project
constraints and adapt your methodology over the life cycle of the project.

Acumatica Implementation Delivery Framework recognizes the following project types:

Express Implementation Quick Implementation approach & methodology for customers

that require no customizations, single entity, and business
processes are not complex. No add-on solutions. OOB
functionality.

Standard Implementation Single or Multiple entities, minimal customizations, minimal

add-on solutions, single currency, and language.

Advanced Implementation Single entities or multiple entities with various locations,

multiple currencies, and languages. Moderate to Complex
business processes, and integrations. Complex roll-out with
multiple phases. (Template or Pilot roll-out)

Even though Express implementations can be enjoyable, majority of Acumatica implementations

are Standard with a growing number becoming Advanced projects types. Managing an
Advanced Implementation requires more project management processes and tools; whereas an
Express Implementation will require fewer. The Framework was designed to provide the tools
and methodology to guide Partner organizations through the various project types emphasizing
very few implementations should be treated as an Express Implementation. In all cases Project
Management, must be a top priority.

Key Terms

Project – According to the PMI Institute, “a project is a temporary endeavor undertaken to

create a unique product, service, or result.”

 Projects have a beginning and an end.

 The end is reached when the objectives have been met, or is terminated because the
objectives can’t be met or the need no longer exists.
 Projects consist of processes that can be recurring at certain intervals.
 A project can vary in budget, complexity, resources and expected outcomes.
 Projects will consist of a team of subject matter experts from multiple departments and
disciplines.
 In most cases, projects will involve change to an organization, which means there will be
some sort of conflict.

Page 7 of 59
Project Life Cycle – The series of activities which are necessary to fulfill project goals or
objectives and is typically divided into sequential or overlapping phases. The lifecycle provides
the basic framework for managing the project. The seven phases of Acumatica’s Project Life
Cycle are; Discover, Plan & Monitor, Analyze, Build, Stabilize, Deploy, and Post Go Live. Dividing
the project life cycle into phases allows for milestones & deliverables to be identified. At each
milestone, approval is generally required from the client before proceeding to the next stage.

Project Management – The application of knowledge, skills, tools, and techniques to manage
activities to meet the project objectives. Project management is all about comparing the
progress made against the original plan and thereby updating the plan.

Project Management Processes – Projects consists of processes. It is the consistent application

of processes that make even the most complex project attainable. Each process is characterized
by its inputs, the tools and technique that can be applied, and the resulting outputs.
Environmental factors and project types may constrain the project management options. In
order for a project to be successful, the project team must:

 Select appropriate processes required to meet the project objectives

 Use a defined approach that can be adopted to meet requirements
 Balance the competing demands of scope, time, cost, quality, resources, and risk to
produce the specified product, service, or result.

Each phase consists of a set of processes:

Discovery – Consists of processes that help define the need, vision and scope of the project and
obtain commitment from the customer to continue.

Plan & Monitor – Consists of processes that involve developing a strategy to complete the work,
as well as measure the progress and take corrective action as required.

Analyze – A more detailed level of discovery. Consists of processes that involve gathering
detailed requirements and analyzing the client’s business needs.

Build – Involve processes that carry out the tasks identified in the strategy.

Stabilize – Consists of a set of processes to ensure a solution meets the client’s requirements
and is ready for full deployment to a live production environment. This also includes a client’s
readiness to use the solution.

Deploy – Processes that will deploy the solution to a production environment.

Post Go Live – Processes that are in place to support the client once they are live on the solution
that will lead to project closure.

Key Elements of Acumatica’s Implementation Delivery Framework

Acumatica’s Implementation Delivery Framework project lifecycle is divided into seven phases
as shown in figure 1. It is possible for some phases to occur multiple times or throughout the
implementation life cycle, as in the case of plan and monitor phase.
Page 8 of 59
Each phase has processes that contain inputs feeding tasks and activities that will provide the
outputs or deliverables. Each phase will be discussed in more detail throughout this course.

Figure 1

Project Roles

Project Team – A project team is comprised of the project manager, project management team,
and other team members who carry out the work but who are not necessarily involved with
management of the project. This team is comprised of individuals from different groups with
knowledge of a specific subject matter or with a specific skill set who carry out the work of the
project.

Below is a diagram of the typical project team structure:

Page 9 of 59
Sponsor (Client)– A project sponsor is a person that provides the financial resources for the
project. It is good when a project is initiated to have the Project Sponsor champion the project
and promote the benefits that the project will bring. The Sponsor typically leads the project
through the engagement or selection process, and plays a significant role in the development of
the initial vision and scope. For issues that are beyond the control of the project manager, the
sponsor serves as the escalation path. The Sponsor may also be involved in other important
issues such as authorizing changes in scope, go/no-go decisions when risks are particularly high.

Project Managers (Client / Partner) – Project Managers are responsible for achieving the
project objectives, lead person responsible for communicating with all stakeholders. The
Project Managers will serve as a liaison between the implementation team and the appropriate
Business Decision Makers or Functional Owners within the organization. Additionally, he or she
should submit regular reports to the project stakeholders outlining progress, project risks, and
any additional required resources.

 Provide project direction

 Manage the delivery of the project elements, and realign activities to assure project
outcomes
 Maintain key stakeholder relationships
 Responsible for project status and reporting of such as well as issue escalation to the
Project Steering Committee
 Managing all project resources on the project
 Successful delivery of the project including budget, timelines, and scope
 Overall project planning, direction, and guidance
 Monitoring of overall project resources and budgets

Page 10 of 59
  Review of strategies, methodologies and approaches for completion of deliverables by
team members
 Project leadership, team building, strategy consultation, and advice in all aspects of the
implementation
 Review and obtain sign off of all deliverables for the project
 Management of scope changes
 Resource escalation
 Prepare Project Executive sponsors for Steering Committee meetings
 Contract reviews and invoice approvals
 Active management of Accounts Payable
 Responsible for escalating issues and risks to the Functional Owner as required.

Business Process Owners (Client) – Business Process Owners are managers that have a
management role in a core business area such as Sales, Accounting, Service, Manufacturing
etc.… They are key decision makers in how processes are carried out in their business area. It is
important to involve Business Process Owners in the Discovery, Analysis and Stabilization phases
of the project. They express what is currently broken in the process and provide feedback as to
what an ideal process will look like. As the solution is designed it is important that each
Business Process Owner understands the impact the new solution will have on their business
processes and approves the solution.

Functional Subject Matter Experts (Client) – These are individuals that are considered end users
and have very detailed knowledge of the systems and processes in their functional area. When
gathering detailed requirements, it is important to include functional SMEs in the discussions, to
provide detailed requirements. SMEs are also responsible for conducting user acceptance
testing.

Technical Resource(s) (Partner) – For on premise projects the client might have dedicated
technical resource(s) that manage their infrastructure. The Technical Team could be responsible
for the procurement of the hardware and software installation and networking components, as
well as designing and developing customizations and providing 1st level support once the
solution is deployed. It may not always be the case, in which a client has these types of
resources, in which case they will rely on the Partner Organization or Acumatica for technical
support.

The Technical Consultant will create detailed documentation of the required customizations,
reports and integrations. Customization of the product to meet the needs of the customer
based on the specifications from the Solution Consultant, Integration of the solution into other

Page 11 of 59
applications, Document custom developed functionality in accordance to documentation
standards and best practices, Initial test of the developed functionality, and Assistance to the
Solution Consultants during testing.

Account Manager (Partner) – Individual that is responsible for managing the client relationship
and ensuring client satisfaction throughout the project lifecycle. Serves as an escalation point
for the client and was involved in the sales cycle.

Functional Business Consultant (Partner) – This is an Acumatica expert in various functional

areas and has passed the Acumatica Business Consultant exam. They are responsible for leading
the requirements discussions during the Analysis phase, as well as configuration of the system.

The Consultant will participate in every aspect of the implementation from analyzing the
customer’s business requirements to configuring the application to meet the customer’s needs.
The Solution Consultant communicates with the customer’s organization on many levels to
obtain the necessary understanding of the business processes. The analysis of the business
processes may lead to changing these processes. The Solution Consultant works with the
customer’s Key Users to ensure full understanding of the implications to the current business
processes. The analysis of the business processes may also lead to modifying the Acumatica
standard application. In this case, the Application Consultant will communicate with the
Development Consultant to ensure implementation of the necessary modifications to the
Acumatica application.

Executive Steering Committee:

Overall senior management oversight and direction for this Project will be provided by an
Executive Steering Committee. Executive Steering Committee meetings will be held onsite or
by conference call on a monthly basis or as required. The [Client] Project Manager, with
support from the [Partner] Project Manager, will be responsible for reporting to the Executive
Steering Committee. The Executive Steering Committee will consist of the Project Sponsor, Key
Business Process Owners with overall responsibility for leading this Project at a strategic level.
Responsibilities include:
 Overall Project direction and guidance
 Top management commitment through active participation in the Project
 Review and monitoring of Project progress
 Input on strategy, policies, and major issue resolution
 Attending Steering Committee meetings
 Supports resource needs/requests from Project Managers
 Address issues as defined by Project Managers
 Be responsible for the delivery of Project benefits

Page 12 of 59
  Set priorities for Cloud ERP initiatives in line with allocated funding
 Manage the overall Project scope.
 Review and approvals of any Change Requests
 Report Project performance to Board and provide strategic guidance to the Project
Director
 Play an active role in resolving issues and risks escalated to the Steering Committee.

All project team members must:

 Have a good understanding of the scope of the project, budget for each deliverable and
the project milestones
 Ensure that all their project activities and/or dependencies are stated within the
project schedule
 Ensure Project managers are notified of possible risks that may affect the completion
of tasks/deliverables
 Escalate delays and issues experienced on tasks/deliverables to the Project managers
as quick as possible
 Attend status meetings as required and provide regular updates to the Project
Managers and project team
 Notify Project Manager of approved leave
 Portray a positive image of the project at all times
 Work together as part of the “One Team” approach to deliver a successful project
 Work together to deliver the business outcome required by Client
 Take ownership of issues and resolve them promptly
 Escalate to the Project Managers where business decisions need to be made by the
Steering Committee
 Support each other in delivering a common outcome

Page 13 of 59
Lesson 1: Understanding Discovery Processes
Learning Objects

Understand the Importance and how to have a successful Discovery Phase, along with the Key Activities
and deliverables.

1.1 Why the Discovery Phase is important

The purpose of the Discovery Phase is to gain an understanding of the client’s business and its
processes, what is broken in the process, and in an ideal world what the process should look
like. By understanding the customer’s pain points and relative costs associated with the pain
you can establish better priorities and justification for the project. The Discovery process
involves looking at a company’s corporate structure, lines of business, departments, product
lines, as well as diving into the business processes such as quote to cash, procure to pay, Issue to
resolution etc.

The Discovery process is typically performed during the sales cycle; however, it may not always
be feasible especially in the case of a company with more complex business processes. In this
case, it is difficult to justify resources to perform discovery that will extend several days or
weeks during the sales cycle. It might be best to present the customer with a proposal for a
standard implementation project with the understanding that once Discovery is completed the
proposal could be adjusted based on the Gap analysis. Including Discovery as part of the
project, rather than the sales cycle, implies it would be billable to the client. This should be
communicated to the client. Most clients will be willing to pay for Discovery if it is positioned
properly and the client will have tangible deliverables as a result.

The goal of Discovery is to establish a common vision of what the project team and sponsors
wants to accomplish. During this process the project goals, risks and constraints should be
identified and documented in a vision and scope document.

1.2 Steps for a Successful Discovery:

1. Establish the Project Team

The client’s project team should include subject matter experts and business process owners
that represent all aspects of the business. Team members should have a strong knowledge of
current procedures in their area and be active system users with hands on experience, knowing
what the system does and its limitations. The client project team should also include the project
sponsor and any stakeholders.

The Consulting project team should include the Account Manager and Solution Architect /
Business Analyst that is an Acumatica expert and has completed the appropriate training and
certification.

Page 14 of 59
If you require assistance from Acumatica; it’s required to complete the Pre-Sales Request Form
that is available on partner portal. It requires a minimum set of information about the customer
and their requirements before engaging in the Discovery sessions. Regardless if you are going to
engage with Acumatica, this document should be completed as a matter of course to help
prepare you for the Discovery Sessions.

2. Discovery Meetings
This is where interviews are conducted with the project team to get an in-depth understanding
of various parts of the business at a detail level. When conducting interviews, it is best practice
to circulate an agenda prior to the meeting including the topics of discussion and any other
items the project team needs to bring or be prepared to demonstrate. Prior to the business
process interviews it is good to have a separate interview with the project sponsor and
understand the business goals, why they are looking to implement a new solution and what
problems they want to resolve. The Discovery Questionnaire guide is a recommended tool
which list important questions to ask.

Breaking the Discovery meetings down by business process helps keeps the discussion focused
and allows the project team involved in the process to explain it from start to finish. (see
section 3.4 for guide to mapping business processes). It is important that all the subject matter
experts or business process owners involved in the process are included in the interviews. Some
clients have documented processes; therefore, it would be advantageous to have the project
team bring relevant documents to the meetings, as well as any sample forms or reports used in
the process.

In addition to the discovery meetings related to business processes, understanding the data
migration requirement is important. Identifying data migration requirements early is important
to set expectations and identify any risks associated with data cleansing.

Below is an example of the information about the data that should be collected during the
Discovery Phase:

Object Source Est. # of Records Comments

Transactional Records
Leads How are leads identified in current
system?
Opportunities Will only open opportunities be
migrated?
Orders Open Orders? History?
Shipments Shipments not invoiced? History?
Invoices Unpaid and/or historical Invoices?
Purchase Orders
Purchase Receipts
GL Transactions / Trial
Balances
Master Data Records
Customers Parent / Child relationships?
Contacts

Page 15 of 59
 Inventory Items Stock and Non-Stock Items? Kits?
Costs?
Vendors
Customer Price Lists
Vendor Price Lists
Chart of Accounts
Taxes
Shipping Terms/zones
Vendor Inventory
Projects / Tasks
Users
Configuration Data
Numbering Sequences

3. Identify potential Gaps, Risks and Solutions

It is important to identify all the areas where the current system doesn’t meet the company’s
needs. For Advanced Projects that may have more complex processes, preparing a GAP Analysis
is recommended. The GAP Analysis worksheet can be used as a tool to gather and prioritize
requirements. It is important to measure the importance of the feature and whether or not it
should be included in a future phase. If it requires customization than the development
estimate should also be included. Your findings should be identified and discussed with the
client prior to submitting your statement of work. It is important to set expectations and
explain to the customer the impact the Gaps will have on the implementation in terms of scope,
cost and time.
It is also important to identify any potential risks that will impact the project. Factors that
typically present risks to a project include:

 Lack of project resources.

 Lack of Executive Support.
 Poor data that will require extensive cleansing
 Competing projects
 Large number of add-on solutions
 Complex interfaces
 Large number of customizations

In some cases, you may want to suggest conducting a proof of concept. This allows you to prove
your solution to the customer for their approval before you initiate extensive development
efforts.

4. Prepare the Vision and Scope document

The Vision and Scope document provides the details of all the requirements gathered during the
discovery workshops. It important to validate the information with the client to ensure the
Partner’s understanding of the requirements are the same as the Client’s. The Vision and Scope
document also includes the reason why the client is initiating this project and the success
criteria. This information will become very important throughout the project lifecycle to ensure
the scope is adhered to and during project closure to ensure all the client’s objectives were met.

Page 16 of 59
5. Get Client Approval

6. Prepare Statement of Work

The Statement of Work is required for all projects, as it determines the terms and conditions of
the engagement, as well as details all the pricing.

7. Get Client Approval

1.3 Discovery Key Activities and Deliverables

Project Type Task / Activities Deliverables

Express Discovery meeting(s) Project Budget Estimator
Prepare Statement of Work Pre-Sales Request Form (Guide)
Discovery Questionnaire (Guide)
Statement of Work

Standard Discovery Meeting(s) Project Budget Estimator

Prepare As Is Business Process Docs Pre-Sales Request Form (Guide)
(Optional) Discovery Questionnaire (Guide)
Proof of Concept (Optional) Vision & Scope Document
Prepare GAP analysis (Optional) Data Migration Requirements Document
Prepare Vision & Scope Document Statement of Work
Prepare Statement of Work GAP Analysis Worksheet (Optional)

Advanced Discovery Meeting(s) Project Budget Estimator

Prepare As is Business Process docs Pre-Sales Request Form (Guide)
(Optional if not provided by customer) Discovery Questionnaire (Guide)
Proof of Concept demo (Optional) Vision & Scope Document
Prepare GAP Analysis Data Migration Requirements Document
Prepare Vision & Scope Document GAP Analysis Worksheet
Prepare Statement of Work As Is Business Process documents
Statement of Work

Page 17 of 59
Lesson 2: Understanding Planning & Monitoring Processes
Learning Objects

We will discuss the importance of the Planning and Monitoring Phase which include the following
processes: Project Management, Risk Management, Contract Management and what tools are available.

2.1 Why the Planning & Monitoring phase is important:

The Planning and Monitoring phase is conducted throughout the whole project lifecycle. It is
initiated from a signed Statement of Work and includes the official kick-off of the project. It is
the longest phase, because it contains the most processes. The processes from planning and
monitoring touch every aspect of the project and will look at all the work being performed and
ensures all deliverables are in line with the plan. The overall project is accessed for how it’s
progressing and corrective actions needed through change requests. Any necessary changes to
the plan are identified and made in this process. Project is monitored to ensure risks are being
identified and managed properly to ensure implementation is on track.

Emphasis lies on the core project management process, risk management process, and contract
management process. The project management methods and tools were designed to answer
the basic question: What needs to be done to proactively manage, prepare and enable optimum
management of the build, stabilize and deployment phases?

According to author Harold Kerzner, Ph.D. there are sixteen points that will lead to project
management maturity:

1. Adopt a project management method and use it consistently.

2. Implement a philosophy that drives the organization toward project management
maturity and communicate it to everyone.
3. Commit to developing effective plans at the beginning of each project.
4. Minimize scope changes by committing to realistic objectives.
5. Recognize that cost and schedule management are inseparable.
6. Select the right person as a project manager.
7. Provide executives with project sponsor information; not project management
information.
8. Strengthen involvement and support of all appropriate management.
9. Focus on deliverables rather than resources.
10. Cultivate effective communication, cooperation, and trust.
11. Share recognition for project success.
12. Eliminate nonproductive meetings.
13. Focus on identifying and solving problems early, quickly, and cost effectively.
14. Measure progress periodically.
15. Use project management software as a tool; Not as a substitute for effective
planning or interpersonal skills.
16. Establish an all-employee training program with periodic updates based upon
documented lessons learned.

Page 18 of 59
2.2 Core Project Management Processes:
Project Management processes ensure every part of the project is coordinated. The project
manager assembles the project plan, executes the plan, and verifies the results of the work, and
then the project is closed. At the same time, the project manager must prioritize different
objectives competing for time and resources while keeping the team focused on completing the
work.

The core project management processes include:

2.2.1 Develop & Monitor Project Plan & Schedule

The project plan guides the management, execution, monitoring and controlling of the
project. It specifies the who, what, when and how. The project plan is progressively
modified, meaning that it is developed, refined, revisited and updated regularly.

The project plan approver differs based on the organization structure and other factors,
but typically it would be:

 The Project Manager

 The Project Sponsor
 The Functional Managers who are providing resources for the project.

The inputs for the Project Plan include the Vision & Scope Document, Proposal and/ or
statement of work.

To create the Project Plan, based on the deliverables defined in the Vision & Scope
document need to be subdivided into smaller, more manageable activities or work
packages that will be executed by the project team. A work package can be scheduled,
cost estimated, monitored, and controlled. The work breakdown structure can be
created using phases of the project life cycle as the first level or based on the
deliverables, with the product and project deliverables as the second level. A technique
that is often used, called Rolling Wave Planning, allows for in the near term to be
planned in detail and future work is planned at a higher level of the WBS. Therefore,
activities can exist at various levels of detail depending on where it is in the project life
cycle. For example, during the discovery stage, when information is less defined,
activities may be defined at the milestone level. As more is known about the upcoming
events in the near term it can broke down into more detailed activities.

Example 1 Project Plan by Deliverables:

Below is an example of the Project Budget Estimator down by deliverables. Notice that
the plan includes timeline and baseline estimates in hours and days. For each
deliverable, an estimate is also provided for the number of hours expected from the
client. This example is good for estimating the project and provides the client with a
high level timeline. This template can also be used on-going when reporting to the
client the actual vs estimate status and % completion of the project.

Page 19 of 59
Note: The Acumatica Implementation checklists that are available within the online help
under Implementation are an excellent resource in planning the detail activities required
for the configuration of each module.

Example 2 Project Plan by Project Phase:

For Advanced implementations that have a number of customizations, interfaces, data

migration requirements you will want to create and manage to a more detailed project
plan broken down by project phase.

The plan should include a detail listing of the all the tasks that need to be completed the
start and end dates, duration, owner(s), and any dependencies between tasks.
Identifying dependencies are important because if a task is not completed as scheduled,
all tasks dependent on the completion of that task will need to be pushed out as well.

Below is an example of a Project Plan broken down by project phase.

Page 20 of 59
The plan should be broken down to all the tasks that need to be completed. The project
manager should meet with the owners of each task on a regular basis, typically before
the status meeting to understand what is the percentage completion of the task. This is
important to understand how the project is trending compared to budget.

For example; 8 hrs. were budgeted for a particular task and you already have 7 hrs. into
it, however, you expect another 4 hrs. to complete it. The task will be over budget by 3
hrs. It is important to monitor the overages compared to the budget and be able to
explain them to the client. By proactively explaining how the project is trending, it allows
the client to make decisions on how to proceed. Overages should be documented using
a Change Request and approved by the customer.

Displaying the project plan as a Gantt Chart in summary is visually easy for the client to
pay attention to specific milestones and dates. Microsoft Project is a great tool to
facilitate this type of project plan.

You can see at a glance, tasks that are being completed in parallel with other tasks. As
well as identify any conflicts.

Project Plan Summary – Gantt Chart example:

Page 21 of 59
2.2.2 Develop & Manage Project Team
This process focuses on staffing the project. This process is typically performed
throughout the life of the project. For instance, you may need business analysts early
on in the life of the project, while you may need more technical resources later in the
project. In order to set the appropriate expectations, it is important to communicate
the resource plan and include roles, responsibilities, how long the resources will be
needed and when. It is also important to know the availability of resources and planned
vacations, so you can incorporate additional coverage during these periods.

2.2.3 Plan Communications

The project manager’s most important skill set is that of communication. It is integral to
everything the project manager does. It is estimated that an effective project manager
spends about 90% of his/her time communicating, and fully 50% of that time is spent
communicating with the project team. The Project Manager should be in control of the
communications process. This is done by creating a strong communications
management plan, adhering to it, and regularly monitoring and controlling.

The communication plan should include the following:

- How often communications will be distributed and updated

- In what form communications will be distributed (e.g., email, phone, web etc…)
- What information will be included in the communication.
- Which project stakeholders will receive these communications.

The plan sets expectations on the project, letting them know what information they will
receive and when and how they will receive it. Typically, the plan is developed during
the project kick-off.

Standard communication plan:

- Weekly Status meeting with Project Team

- Weekly project status report emailed to project stakeholders
- Monthly meeting with Project Stakeholders.

Example Status Meeting Agenda:

 Review activities accomplished last week

 Review activities scheduled for next week
 Review Budget status and forecast
 Review open items
 Review issue list

2.2.4 Plan & Monitor Quality Assurance & Stabilization

Everyone on the project team has an important contribution to make to project quality.
A Partner that delivers customizations to a customer should ensure the customization
functions in the customer’s test environment prior to publishing it in their production
environment. Customers have a responsibility to allocate resources to test the solution
Page 22 of 59
prior to going live ensuring it will meet their requirements and their staff is ready to use
it. Therefore, it is important the Project Manager has a plan in place that ensures
customizations are tested in a test environment that closely mirrors the production
environment. The customer allocates resources to conduct tests within the test
environment and provides approval when the solution has been accepted.

Quality planning is performed early in project planning, because decisions made about
quality can have a significant impact on other decisions such as scope, time, cost, and
risk. Quality can also be a very significant area of project risk. For example, it may be
identified that there may be issues related to customer acceptance or satisfaction if
quality is not satisfied. It is best practice to build in quality or validation checkpoints
into the project plan, especially when dealing with an advanced project that has many
customizations. Validating the solution during the build process ensures early on the
solution will meet the client’s needs.

Projects should include 2 quality assurance plans:

1. Solution Testing Plan – Includes the test cycles that occur during the build phase.
The plan should include unit testing, integration testing and data migration testing.
This is very important, especially for projects with customizations and interfaces to
any third party applications.

As customizations are published to the test environment the client should do unit
tests to ensure the customization meets their requirements. Once third party
integrations are setup in the test environment, integration testing should be
performed by the client as well. During the build phase test migrations are
performed and it is important that the client tests the migrations to ensure all the
data has come into the new system correctly. The plan should include how the
client will perform the data migration tests. It is impossible to view every record
that is migrated, however the client needs to decide on what is a good
representation of their data to spot check.

For example; A client may have 3 different types of customer classes; therefore,
they should test 5-10 customer records from each class.

2. User Acceptance Plan (UAT)– Includes the test cycles during the stabilization phase
after the build cycle is completed and all the customizations have been delivered
and accepted during solution testing, the first and possibly second data migration
tests completed, and all integrations are in place. UAT is the final stage of testing
prior to go live. It is conducted by the client. Test scripts are written by the client to
ensure they can carry out their business processes in the new solution.

The Quality Assurance plan should include a process in which a customer can report
issues as they are discovered, and ensure they are assigned and resolved in a timely
manner. In smaller, less complex projects issues might be reported via email and
tracked on a spreadsheet or in the status report. In more complex projects when you
are dealing with a large project team, it is recommended to have a more formal issue

Page 23 of 59
tracking solution (such as; SmartSheet or JIRA). In either case, it is important that when
an issue is reported that it can be recreated. Therefore, capturing the necessary
information in very important. The plan should detail how to report an issue, who to
report the issue to. When tracking the issue, it is important to know who the issue is
assigned to and the status of the issue (Open, In-Process, waiting on feedback, Closed).
Reviewing open and resolved issues on a regular basis with the customer is very
important.

2.2.5 10 steps to a successful project kick-off meeting

Every project should be kicked-off with a formal meeting. The kick-off meeting sets the
stage for your entire project. The intent to get the project team to hit the ground
motivated, energized and focused. Prior to the project kick-off meeting the following
steps should be followed:

1. Establish vision & scope – The vision and scope is established during the discovery
phase. However, should be confirmed and reiterated during the kick-off meeting
for all team members. It may also be a good idea to have the project sponsor
present this portion of the kick off meeting to the team.

2. Identify Team and set roles – It is also important that all team members understand
their roles and responsibilities as it relates to the project. Make a contact list of
team members with names, roles, and contact information.

3. Develop initial project plan – Prepare a high level schedule of the project plan to
review with the team so everyone has an understanding of the timeline.

4. Define how you measure success – Review with the project stakeholders how they
will measure success. The following list provides a variety of conventional and
unconventional ways to measure the success of your ERP implementation:

a) Tangible Benefits – Measurable benefits are always tangible. But not all
tangible benefits are readily measurable. For example, ERP systems can give
employees more and better information for doing their jobs. That will help
them make fewer errors and communicate better. The reduction in errors is
both tangible and measurable. But while the benefits of improved
communication can be quite obvious and real to employees and managers alike,
they may also be harder to measure.

b) Generalized improvements
Some benefits, which you may or may not have been able to project as
described in #2 above, might be measurable but not directly attributable. For
example, ERP implementation may significantly improve customer relations.
This can produce such results as

Page 24 of 59
  Higher sales
 More repeat sales
 Higher sales conversion rates
 Higher customer retention rates
 A better public image

c) Measurable impact - such as cost savings or increase revenue

d) Internal indicators
Some indicators of ERP success are both highly visible within the company and
nearly impossible to quantify. One is that the new ERP system has become a
routine part of daily operations. Employees find it better, and/or less
frustrating, to use than the old system. Operations as a whole feel less
fragmented. Managers are happier. And there is a general sense that
implementation delivered on expectations. This too should be included as a
measure of success.

e) Strategic advantage
ERP can also bring broad strategic benefits. In particular, it can give
management better understanding and control of the business as a whole. This
can help them plan major moves and initiatives, including those involving new
products, new markets and acquisitions, based on data rather than instinct. It
also lets them better position the business against competitors, providing
increased flexibility and efficiency in responding to rapidly changing conditions.
These factors too may be hard to quantify. But ultimately they may represent
the most important benefits of all.

f) Live on time and on budget – Not a great measure of success.

5. Review plan and identify potential risks – Prepare the team for critical stages in the
project and encourage them to ask for your help with roadblocks.

6. Establish logistics of team communication

7. Choose your project management methodology or outline your preferred work

process. – Establish the best practices your team will follow.

8. Decide which tools your team will use.

9. Schedule your kick-off meeting.

10. Set your agenda and prepare handouts and slides.

Page 25 of 59
 2.2.6 Core Project Management Activities and Deliverables:
Below is a list of available project management tools that can be applied to various
project types

Project Type Task / Activities Deliverables

Express Project Planning Project Budget Estimator
Kick-Off Meeting Communication Acumatica Project Kick-off_Deck_V7.ppt
Planning Acumatica Implementation Checklists
Quality Assurance Planning Project Status Report
UAT Test Plan

Standard Project Planning Project Budget Estimator / Project Plan

Kick-Off Meeting Acumatica Project Kick-off_Deck_V7.ppt
Communication Planning Acumatica Implementation Checklists
Quality Assurance Planning Project Status Report
Develop & Manage Project Team Solution Test Plan
UAT Test Plan (client)
Issue Log Template

Advanced Project Planning Project Budget Estimator / Project Plan

Kick-Off Meeting Acumatica Project Kick-off_Deck_V7.ppt
Communication Planning Acumatica Implementation Checklists
Quality Assurance Planning Project Status Report
Develop & Manage Project Team Solution Test Plan
UAT Plan (client)
Issue Log Template
Training Plan
Communications Plan

2.3 Risk Management Processes:

Project Risk is always in the future. Risk is an uncertain event or condition that, if it occurs, has
an effect on at least one project objective. Objectives can include scope, schedule, cost, and
quality. A risk may have one or more causes and, if it occurs, it may have one or more impacts.
For example, interfacing to a third party add-on solution will require a third party resource. The
resource has limited availability that will impact the project schedule and cost. Identifying risks
early on makes it possible to create a plan to mitigate the risks. However, if a risk occurs, it then
becomes an issue. To be successful, partner organizations should be committed to address risk
management proactively and consistently throughout the project. Risk exists the moment a
project is conceived. Moving forward on a project without a proactive focus on risk
management increases the impact that a realized risk can have on the project and can
potentially lead to project failure.

Page 26 of 59
2.3.1 Identify Risks
Common risk areas for ERP Implementations:

 Communication Issues
One of the more frequently identified risks to a project success is lack of
communication and slow decision-making among key stakeholders, including;
executive management and business process owners.

 Project management and executive sponsorship

It is often the case that an ERP implementation is considered an “IT project” and
lacks the appropriate engagement by stakeholders. In some cases, IT is leading
the project and making business process decisions. Or core business process
owners are assigned responsibility for managing all aspects of the process, even
if they have little or no experience as project managers or understanding of ERP
systems.

 Realistic project schedule and plan

Some implementations can fail because organizations underestimate the
magnitude of the undertaking and develop a project plan with an unrealistic
timeline that leaves no contingency to accommodate delays due to even minor
unforeseen circumstances, which typically result in significant project overruns.

 Organizational change management

The impact the user community has on the overall success of an ERP
implementation should not be underestimated. An ERP solution will transform
how people work in the organization, making their activities more transparent
and could possibly become unnecessary.

 Appropriate business involvement

Another potential risk area during an implementation is lack of appropriate
involvement from the functional areas of the business. Most project team
members are not dedicated to the project on a full-time basis.

 Testing to ensure core business processes are functioning properly

Although testing is essential to the success of the implementation, shortcuts are
often taken to make the planned go-live date.

 Data conversion
Data conversion and validation process often is not adequately planned and
typically takes more time than anticipated. Data mapping can be time
consuming and tedious.

 Cutover
Cutover is the period during which the changeover to the new ERP system
occurs. It typically involves a comprehensive and highly choreographed set of
specific tasks related to shutting down business on existing systems, converting
Page 27 of 59
 data to the new ERP system and ramping up business on the new system. If
cutover is not orchestrated properly, it could be disastrous for an
implementation.

It is important to identify risks throughout the project lifecycle and the impact it will
have on the project. Risks can be tracked in a formal Risk Register or included in the
weekly project status report. The benefit of including Risks in the weekly project status
report is that they are always reviewed on a regular basis by the Project Team.

Information to include when identifying risks:

2.3.2 Managing Risks

Once risks have been identified it is important to plan responses to the risks that should
result into an actionable plan. Managing risks is a process that is performed almost
continually throughout the project. Monitoring and controlling risks should be an
ongoing concern.

Work performance reports often serve as an input to managing risks. The plan is
brought in as in input, and the work performance information provides information on
the results. For example, the schedule of a deliverable provides helpful information
related to schedule risk, cost risk or other areas of concern.

During weekly status meetings risks should be reviewed with the client.

2.3.3 Strategies for Negative Risks or Threats

Three of the following strategies typically deal with threats or risks that may have
negative impacts on project objectives if they occur.

 Avoid – Risk avoidance involves changing the project management plan to

eliminate the threat entirely or change the objective that is in jeopardy.
Examples might include; extending the schedule, changing the strategy, or
reducing scope. Some risks that arise early in the project can be avoided by
clarifying requirements, improving communication, or acquiring expertise.
 Transfer – Risk transfer requires shifting some or all of the negative impact of a
threat, along with ownership to a third party. It doesn’t eliminate the risk, but
transfers responsibility for managing it to another party.

 Mitigate – Risk Mitigation implies a reduction in the probability and/or impact

of an adverse risk event to be within acceptable threshold limits. Taking early
action to reduce the probability of a risk is often more effective than trying to
repair the damage after the risk occurs. Adopting less complex processes,
conducting more tests, or choosing a more stable supplier are examples of
mitigation actions.

 Accept – This strategy indicates that the project team has decided not to change
the project management plan to deal with a risk, or is unable to identify a
Page 28 of 59
 suitable response strategy. Passive acceptance leaves the Project Team to deal
with the risks as they occur. Active acceptance will have some sort of
contingency plan to deal with the risks, including amounts of time, money, or
resources to handle the risks.

Examples of risk plan responses to common risks:

Risk Plan
Slow decision making Formal decision making plan in place that will empower
business process owners to make timely decisions
regarding new business processes.

Project timeline and Prepare Project Trending report weekly based on

overruns milestones and discuss with team during status
meeting.
Project Trending Report compares Actual, against
Budget and Estimated to Complete.

Organizational change A change management plan that will bring awareness

management across the organization of the new ERP system and its
expected benefits. To include the impact, it will have on
people, processes and technology.

Business Process Owners A resource sheet that shows the expected hours
are not involved in project required from each resource throughout the
implementation by month and week is helpful to explain
what is expected. This allows the client to plan their
resources accordingly.

Inappropriate testing Develop a comprehensive testing strategy that include:

- Business Involvement to define end-to-end test
scenarios.
- Documented test scripts vs. ad hoc testing.
- Use of test data that has been converted from the
legacy system.
- A stable test environment subject to tight change
control.
- Use of end user access security roles.

Data Conversion Mock data migrations and test plan in place that is
validated by business users who can confirm their
accuracy.

Cutover A comprehensive cutover plan is put in place that

includes:
- When the legacy system will be frozen.
- Go/No go decision points.
- Financial cutover activities.
Page 29 of 59
 - Back-out contingency plan

2.3.4 Risk Management Activities and Deliverables:

Below is a list of available Risk management tools that can be applied to various project
types

Project Type Task / Activities Deliverables

Express Risk Identification & Planning Project Status Report

Standard Risk Identification & Planning Project Status Report

Advanced Risk Identification Risk control plan

2.4 Contract Management Processes:

The Contract Management Processes consists of those processes required to track, review, and
regulate the progress and performance of the project; as well as identify any areas in which
changes to the plan are required; and initiate the corresponding changes. It is important that
the project performance is observed and measured regularly and consistently to identify
variances from the project management plan.

The Contract Management Processes includes the following processes:

2.4.1 Monitor and Control Project Work

Monitor and Control project work is the process of tracking, reviewing and regulating
the progress to meet the performance objectives defined in the project management
plan. Monitoring includes regular status reporting, progress measurement, and
forecasting Performance reports provide information on the project’s performance with
regard to scope, schedule, cost resources, quality, and risk.

2.4.2 Managing Changes to Scope

Managing Changes to Scope is the process of reviewing all change requests, approving
changes, and managing changes to the deliverables, organizational process assets,
project documents and the project management plan. It is important during project
kick-off the client is informed of the Change Management process and how change
requests will be handled throughout the project.

All change requests need to be tracked and approved by the Project Sponsor, especially
if the change will impact the project timeline, scope and cost. Typically, all change
requests will be reported to the Project Manager, who will track the request and solicit
an estimate to implement the change. The changes will be reviewed with the Project
Sponsor, who will then provide formal approval for the changes. If the changes are

Page 30 of 59
approved the Project Manager will make the appropriate adjustments to the project
plan and communicate the changes to the Project Team.

2.4.3 Managing Budget and Costs

Managing Budget and Costs is the process of monitoring the status of the project to
update the project budget and managing changes to the cost baseline. Early on in the
project you should establish how frequently you will be reporting Budget Vs. Actual and
how the costs of the project are trending. This type of report is called an ETC or
Estimate to Complete Report.

The format of the report should be as follows:

Budget Hrs. Actual Hrs. Budget – Actual ETC Total Variance

Budget typically includes the hours or dollars agreed in the SOW, as well as approved
change requests.

Actual Includes Actual hrs or dollars charged to the project.

Budget – Actual is the variance in hours or dollars from Budget.

ETC - Estimate to Complete – are the remaining hours necessary to complete the project
for tasks that are still open. It is important to meet with the project team on a regular
basis to understand what tasks are still open and the estimate to complete those tasks.

Total = Is Actual + ETC.

Variance = Budget - Total

The ETC report is very important, because it will show the client how the project is
trending. It is up to you and the client as to decide on how much detail they would like
to see on the report.

It is important to have some sort of time tracking system that will allow you to easily
pull out the actual costs by project for each resource involved in the project. If you have
cost overruns, then it is important you explain to the client why those cost overruns
occurred.

2.4.4 Managing Client Billing

Most Partner Organizations are billing for time and material and billing after the fact.
With that in mind, below are some best practices on managing client billing.

Frequency of Billing: Bill as frequently as you can. It is recommended that your billing
cycle be twice as often as your payroll cycle. For example, weekly billing would support
a biweekly payroll. If you are billing twice a month (15th and 30th) it is likely that your
company will suffer from cash flow problems.

Work Orders: Besides acknowledging that work was completed, a good work order will
provide feedback from the customer and track any recommendations for additional

Page 31 of 59
 work that needs to be performed. It is good practice to have a customer sign a work
order for any work completed on-site or off-site.

2.4.4 Contract management Activities & Deliverables

Project Type Task / Activities Deliverables

Express Create and manage Project work Project Status Report
and Plan Project Budget Estimator
Manage changes to scope Acumatica Implementation Checklists
Manage budget and costs

Standard Create and manage Project work Project Status Report

and Plan Project Budget Estimator
Manage changes to scope Acumatica Implementation Checklists
Manage budget and costs Change Request Form
Change Order Log

Advanced Create and manage Project work Project Status Report

and Plan Project Budget Estimator
Manage changes to scope Acumatica Implementation Checklists
Manage budget and costs Change Request Form
Change Order Log

2.5 Using Project Management applications to help manage a project

There are many project management applications available to help you plan, track and
collaborate your project tasks and documents with your clients.

Benefits of using a Project Management application is that you can centralize and organize all
the project information, so that everyone has access to it and working from the same version.
Instead of sending documents via email, force users to go to the wiki. Use your wiki to manage
open item lists, requirements, project tasks, and meeting notes.

Below are some of the more popular Project Management Applications:

http://www.capterra.com/project-management-software/

Smartsheet: https://www.smartsheet.com

Zoho: https://www.zoho.com/

JIRA, Atlassian: https://www.atlassian.com/

Basecamp: https://3.basecamp.com
Page 32 of 59
Sharepoint

Googledocs

Demonstration: How Confluence was used in a project.

Page 33 of 59
Lesson 3: Understanding the Analysis & Design Process
Learning Objects

Discover the what Activities, Processes and Planning is required to have a successful Analysis and Design
Phase

3.1 Why the Analysis & Design Phase is important

During the Discovery Phase, the project team and the client have focused on high-level
questions and requirements regarding the project. In the Analysis and Design Phase these
questions and requirements are taken to a more granular level. This is when the team will ask
the question “How will the solution be built?”

The Design Phase is where you look at the many potential solutions and narrow down the
choices to determine the most effective and efficient way to construct the solution. The Design
Phase answers the questions about "how" you will build the best solution. The Input is from the
functional requirements in the Vision and Scope document, and the output of the design phase
is the design specification. The design specification is like a set of blueprints that the technical
consultant follows when developing the system. And just as it is very difficult, inefficient, and
costly to build a house without blueprints, it is very difficult, inefficient, and costly to build a
software system without a design specification. Even if the project was small and the
requirements were simple, there is still a mental design process that occurs in between
understanding the requirements and starting to construct. Design becomes more and more
important as the project becomes larger and more complex.

3.2 Analysis & Design Activities - Express Project

For implementations that will not have customizations and only require configuration the
activities and deliverables during the Analysis and Design phase can be simplified to include the
following:

 Install Acumatica Test and/or Demo environments.

 Map “To Be” business processes to the new system. Once you have an understanding
of the Customer’s “AS IS” processes from the Discovery Sessions you can start to map
those processes to the new system. This may require diagraming the processes, or
demonstrating how things will work in a test system.
 Review business process with client. Prepare to demonstrate how their processes
would work in Acumatica in a test or demo system.
 Conduct Core Team Training. The training should occur as you review their business
processes and through demonstrations. It is important the core team has an
understanding of how Acumatica works before they make decisions on how it should be
configured.
 Collect configuration requirements. As you demonstrate their processes you can
collect configuration requirements; however, it is recommended to have separate
sessions for configuration in which you will walk the customer through the Acumatica
Implementation checklists. This will also include data migration requirements.
Page 34 of 59
  Prepare “As Built” documentation. As you collect their requirements it is
recommended that you document the requirements and decisions made, and why the
decisions were made in an “As Built” document. We recommend you use the Acumatica
Implementation Configuration Checklist as the “As Built” document where you will
document the configuration requirements as each section is reviewed with the
customer.
 Receive Customer’s approval for “As Built” Documentation. It is recommended that
you review the As Built checklists with the customer and receive their formal approval.
 Adjust project plan and issue change requests as necessary. If any changes are
identified that affect the project scope and cost, then they should be identified
immediately and handled appropriately with a change request.

 Schedule “To Be” Process Sessions – The purpose of these sessions is to demonstrate to the
customer how their processes will work in Acumatica in a Test or Demo environment; as well as
provide the core team with a better understanding of how Acumatica works, so they can make
more informed decisions when it comes to configuring Acumatica.
 Breakdown the sessions by Business Process.
 Elicit feedback from the Customer.
 Explain that the environment is a demo environment and is not intended to be
setup with their data.

 Schedule “Configuration” Sessions – The purpose of these sessions is to review the checklists
with the client. Collect the requirements, provide the client with a list of Action Items they need
to follow up on. Document the requirements in the Checklist. During these sessions you will
cover data migration requirements. Review configurations you and/or the client completed
from any prior sessions.

Note: The sessions should be broken down by Module and in a specific order. You will
always want to do the Finance Modules first (GL, AP, AR). The Core System is
dependent on the GL Setup, before any other module can be setup.

3.3 Analysis and Design Activities – Standard & Advanced Projects

For implementation projects that will involve customizations, interfaces to third party
applications and a number of modules, the activities during the Analysis and Design phases will
be more extensive and should include the following:

 Install Acumatica as sandbox for testing and training.

 Map “To Be” business processes to new system. As you map the “To Be” business
processes to the new system, it recommended that you document any GAPs that are
identified in the GAP analysis worksheet and provide estimates for those GAPS.

Page 35 of 59
 Conduct Core Team Training – The Team Training happens as a result of the business
process review sessions and configuration sessions. As you walk through the system
with the client they will get a better understanding of how things work in Acumatica.
 Collect configuration requirements. Refer to Express Project
 Prepare “As Built” documentation. Refer to Express Project
 Conduct data migration workshop. The purpose of the workshop is to discuss in detail
what the client’s data migration requirements are. If the client is responsible for
importing the data, then a session on how to create import scenarios is recommended.
During these sessions you should be analyzing samples of the client’s data and reviewing
how the data will be mapped to Acumatica.
 Prepare data migration strategy document. The purpose of the Data Migration
document is to detail how the data from the legacy system will we imported into
Acumatica. If there are any data transformation requirements, they should be detailed
in this document.
 Conduct workshop for custom development. It is recommended to schedule custom
development workshops to get the detail requirements for each customization.
 Prepare design document for customizations. Document the design for each
customization using the appropriate design document. We have available a design
document for reports, one for interfaces and another for other customizations that may
require a change in logic or form layouts.
 Build prototypes for the new system as necessary. Prototypes might be required for
complex customizations.
 Prioritize requirements. In the GAP Analysis document ensure you understand the
customer’s priority for customizations and what could possibly be covered in a future
phase.
 Evaluate alternatives. Research if there are workarounds available that would provide
the same end results.
 Meet with management to discuss new options. Present your findings and estimates
for the custom development and get client’s approval before preceding any further.
 Conduct Integration Workshop. It is recommended to have a separate workshop to
discuss the design for interfacing to 3rd party applications.
 Prepare Design Document for Integrations. Use the Design Document for Interfaces to
document the design.
 Review design with client.
 Receive customer approval for Design Documents.
 Conduct Testing / Training Workshop – The purpose of the Testing & Training
Workshop is for you to explain your testing procedures. When a customization is
completed, how is it tested and approved. What it the procure for logging and reporting
bugs? How will UAT be conducted? Discuss the resources that will be available for
testing and who can participate in preparing test scripts. There should be a point
person from the client that will manage UAT test script writing and testing. In terms of
training, you should educate the customer of all the different training models available
to end users and decide how the customer wants to handle end user training.
 Prepare Testing Plan & EU Training Plan – Explain to the customer how to prepare a
test plan for UAT using the available documents. The Training Plan is optional if the
customer takes on the responsibility of training their end users.
 Conduct User Security Workshop – The purpose of this workshop is to discuss with the
customer user Security and roles. You need to understand how to group the users for

Page 36 of 59
 security role purposes based on the functions and features they need to perform their
job
 Prepare User Access Roles
 Adjust project plan and issue change requests as necessary.

3.4 Guide to Mapping Business Processes

Making system changes without truly understanding how your client’s business processes are
working and why, can lead to costly mistakes. It can also create conditions to make it difficult
for your client to work effectively, and often creates further problems. Process mapping allows
organizations to identify problem areas, which allows you to develop solutions and introduce
new business processes. During the discovery phase you should ask your client to provide you
with any documentation of their current business processes. During the Analysis and Design
phase you are mapping their “To Be” business processes to the new system.

This is important as it can be used as a training aid for staff and should clearly define who is
responsible for each action. It is also important to remember that process mapping is merely
the first stage in a continuous cycle of incremental improvement and refinement of processes
which is ultimately aimed at:

 Eliminating duplication of tasks and to reduce costs

 Improved efficiency and co-ordination of working practices
 reducing the transportation of materials e.g. files between locations
 improved quality and timeliness in the organization
 improving the effective deployment of staff

3.4.1 Types of Process Flow Charts

 Process Flow Chart – represents the sequence of activities and decision points
in a process. Useful when capturing the initial detail of a process.

 Deployment Flow Chart – This type of chart shows who does what, along with
their interactions between people and departments.

 Data Flow Diagram – This is useful if you are developing interfaces to any third
party systems. It illustrates how data flows between different systems and
data sources. Very useful when data is coming from or going to multiple
sources.

3.4.2 Basic Flow Charting Symbols

If you decide to incorporate Flow charts as part of your Design Deliverables, it is
important to come up with a standard convention in which your customer will easily
understand. Below is the most common Basic Flow Charting Symbols used on Flow
Charts.

Page 37 of 59
 3.4.3 Preparation for Business Process Mapping
Schedule 1-2 hr. meetings focused on each business process with a small team of all
those working in and around the process including representatives for:
 Those who do the work
 The suppliers to the process
 The customers of the process
 The supervisors / managers of the process

Key points to ensure are that:

 Participants clearly understand what the aims are and what is involved
 Sensible deadlines are set to allow enough time to complete the exercise
properly.
 There is clear and visible management commitment and support to the exercise.
 All staff are made aware of the exercise, terms of reference and likely impact on
them, together with an invitation to contribute or voice any concerns
Ensure you are prepared to walk-through the process based on your understanding of
the process from your discovery sessions. Don’t ask the customer the same questions
you already asked during your Discovery Sessions. At this point, you should be
demonstrating solutions. How the “To Be” processes will be carried out in the new
system. There is nothing more frustrating to a customer, when they must reiterate what
was already discussed. It is recommended that a demo system be used to demonstrate
standard processes; however, if the client’s process falls outside of Acumatica’s standard
workflow and can’t be demonstrated without a customization, then it is recommended
you demonstrate what you can; however, have flow chart that explains the complete
process with the customization.

Elicit the client’s feedback. Make sure they have opportunities to poke holes in what
they determine will or will not work for their business.
Page 38 of 59
Document their feedback.

3.4.4 Creating a Process Flow Chart

Simply sketch the process describing the sequence of tasks and decision points. The
sketch should indicate:

- Who does what

- What is done and when

- What decisions must be taken

- What possible paths follow from each decision

Concisely describe each task or decision in its own box. If necessary number boxes and
provide a key to where the activity is described in more detail. Decisions often pose
questions answerable by Yes or No. It is usual to draw the YES route out of the bottom
of the diamond (the normal course). The NO route is drawn out of the side of the box
(the alternative course).

3.4.5 Creating a deployment flow chart

Page 39 of 59
 In a deployment flow chart departmental considerations are added horizontally along

the top of the chart. These can be individuals, groups, departments, agencies,
functions etc… Whatever kinds of units play major roles in the process.

3.5 Collecting Configuration Requirements

Acumatica comes with many Implementation preparation articles and checklists for each

module. These articles should be used as your guide when collecting configuration

requirements. You can access the Implementation articles by navigating to Help >
Implementation from the main menu.

The checklists can serve as your “AS Built” document for Express Implementations and your

configuration requirements document for Traditional and Advanced projects. It is very easy to

copy and paste the checklists to a word document or to a page within your project
management application and add a few more columns, such as; Person Responsible, Status,

Due Date, and Comments/Requirements. As you go through the list you can mark the task
Page 40 of 59
completed, and store the requirements within the comments column or as an attachment
depending on the size.

3.6 Collecting Customization Requirements

It might be necessary to change some part of Acumatica to meet the client’s specific needs.

Customizations can be in the form of adding attributes to a form, creating a custom report or

query, or creating custom logic that changes the standard behavior of the software.

Depending on the type of customization the information for collecting requirements may vary.

Acumatica offer several different templates to capture the requirements of various

customizations.

A Template is available for custom reports, custom interfaces, and a template for

customizations that involve form and business logic changes. A design document should be

developed for each customization. The design documents were broken down intentionally, to

make it easier for the customer to approve individual customizations, rather than having them

read through and approve a huge design document. There could be one item in a single

design document the customer has an issue with that might prevent sign-off. Therefore, if

you break things down into individual components, it is much easier for the customer to digest
and sign-off on.

3.6.1 The Use Case Approach

When you have a customization that require modification to the standard logic of how

Acumatica behaves with the end user, documenting use cases can be very effective to

capture the specific logic and behavior the system needs to have when interacting with
the user.

A Use Case is a discrete, stand-alone activity that an actor/user can perform to

achieve some outcome of value. The use case is made up of a set of possible
sequences of interactions between systems and users in a particular environment and
related to a particular goal. It consists of a group of elements (for example, classes and
interfaces) that can be used together in a way that will have an effect larger than the
sum of the separate elements combined. The use case should contain all system
activities that have significance to the users. A use case can be thought of as a collection
of possible scenarios related to a particular goal.

Software developers don’t implement business requirements or use cases. They

implement functional requirements, specific bits of system behavior that allow users to
execute use cases and achieve their goals.

Page 41 of 59
Essential elements of the Use Case:

 A unique identifier

 A name that succinctly states the user task in the form of a “verb” +

object, such as “Place an Order”.

 A short description

 A list of preconditions that must be satisfied before the use case can begin

 Post conditions that describe the state of the system after the use case is

successfully completed.

 A numbered list of steps that shows the sequence of dialog steps or

interactions between the user and the system that leads from the
preconditions to the post conditions.

The use case will have normal course of events; it is also called the main course, basic

course, normal flow, and primary scenarios. Other valid scenarios within the use case

are described as alternative courses or secondary scenarios. They represent variations

in the specifics of the task, but the post condition is the same as the normal course.

Example of a Use Case:

Use Case ID: UC-1 Use Case name: Request a Chemical

Created By: Last updated by:

Date Created: Date Last updated:

Actors Requestor

Description The Requestor specifies the desired chemical to request by

entering its name or chemical ID number or by importing its

structure from a chemical drawing tool. The system satisfies

the request either by offering the Requester a new or used

container of the chemical from the chemical stockroom or by

letting the Requester create a request to order from an

outside Vendor.

Preconditions 1. User’s identity has been authenticated.

2. User is authorized to request chemicals

3. System is online

Post conditions 1. Request is stored in database

Page 42 of 59
 2. Request was emailed to the chemical stockroom or
to a Buyer.

Normal Course 1.0 Request a Chemical from the Chemical Stockroom

1. Requestor specifies the desired chemical.

2. System verifies that the chemical is valid.

3. System lists containers of the desired chemical that

are in the chemical stockroom.

4. Requester has the option to view container history

for any container.

5. Requestor selects a specific container or asks to

place a vendor order (alternate course 1.1)

6. Requestor enters other information to complete the

request.

7. System stores request and emails it to the chemical

stockroom.

Alternative Course 1.1 Request a Chemical from a Vendor (branch after step 5)

1. Requestor searches vendor catalogs for a chemical.

2. System displays a list of vendors with available

container sizes, grades and prices.

3. Requester selects a vendor, container size, grade,

and number of containers.

4. Requestor enters other information to complete the

request.

5. System stores request and emails to buyer.

6. System stores request and emails buyer.

Exceptions 1.0.E.1 Chemical is not valid (at Step 2)

1. System displays message: “That chemical does not exist”.

2. System asks Requester whether he wishes to request

another chemical or exit.

3a. requestor asks to request another chemical.

4a .System starts Normal Course over.

Page 43 of 59
 3b. Requestor asks to exit.

4b. System terminates use case.

1.0 E.2 Chemical is not commercially available (at step 5)

1. System displays message: “No Vendors for that

chemical.

2. System asks requester whener he wishes to request

another chemical or to exit.

3a. requestor asks to request another chemical.

4a. System starts Normal Course over.

3b. Requestor asks to exit.

4b. System terminates use case.

Includes UC-22 View Container History

Priority High

Frequency of Use Approximately five times per week by each chemist, 100

times per week by each member of the chemical stock room

staff.

Business Rules BR-28 Only staff who are authorized by their laboratory

managers may request chemicals.

Special Requirements 1. The system must be able to import a chemical

structure in the standard encoded form from any of

the supported chemical drawing packages.

Assumptions 1. Imported chemical structures are assumed to be

valid.

Notes and Issues

3.6.2 Form Layouts

Some customizations may require additional fields or attributes. In which case, it is

important to capture the information in the following example and include it within the

Page 44 of 59
System Specification for the customization. Including Screen Shots in the Design
Document is also recommended.

FORM NAME: CR3010PL

Attribute Description Type Default Required Business

Name Values Yes / No Rules

Rating Rates the Picklist Hot No Defaults to

level of Warm blank
interest of
Cold
the Lead

3.6.3 Custom Reports & Queries

Requests for custom reports and queries are common in ERP implementations. It is

always good practice to ask the customer for a sample of the report with data if it is a

report they currently use. Below is an example of information that should be collected
when writing the requirements for custom reports & queries.

Requirements to collect:

 Name of the Report

 Brief description of the report.

 Information that should be included in the Report Header. This typically includes

report title, date, time when printed.

 Information that should be included page header. This typically includes column

headings.

 How should the information within the report be grouped and will it include sub-

groups. If so, how should the information within each group be sorted and

subtotaled? Should there be group headers and footers for each group and what

information should be contained within each group?

 Will there be a details sections? If so, what information should appear within the

Details section?

 What should the filtering criteria be for the data that appears on the report?

 Should the user be prompted to enter parameters that will be used as part of the

filtering criteria?
 What information should appear in the Report Footer.

Page 45 of 59
  Will the report be exported to Excel, emailed to a distribution list on a scheduled

basis?

Example of Custom Report Specification:

Name of Report Weekly Inquiries by Division

Displays a listing of new leads by division.

Description

1.0
Revision

Display all active leads that fall within the selected

Filters: create date range.

Prompt the user for create data from and create date
Prompts: to.

Header:

[Insert company logo] Weekly Inquiries by Division

Date Lead Company Type of Division Channel Created By Create Date

Received Name Business

Group Header 1:

{Division name}

Details Section:

{Date Received} {Company Name} {Company Type} {Division}{Trade Channel} {Created by} {Create Date}

Group Footer 1:

Summary for {Division Name}: {count of total leads for Division}

% of Total Leads: {calculate % of total leads}

Report Footer:

Total: {count of all leads}

{date and time} {page #}

3.7 Best Practices for preparing a Data Migration plan

Data Migration refers to the movement of data from an old or legacy system to a new system.

It is important to have a good data migration plan to reduce the risk of the project running

Page 46 of 59
 over time and budget, which often occurs when dealing with projects that have extensive data
that needs to be migrated.

Considerations:

- Confirm the various types of data that will be migrated – master records,

transactional records, beginning balances, historical data.

- Identify the supplemental data that is associated with the primary data

entities.

- How will the data be extracted from the legacy system?

- How is the data quality?

- How will the data be transformed into the target structure?

- What are the mapping rules?

- What tools will be used to test the migration?

- How will testing be conducted?

- What is the recovery plan in the event the data migration fails?

- What is the deployment data migration plan for go live?

The purpose of the data migration plan is to define the approach the project team will take
when importing data from the legacy system to Acumatica. There are two points during the
project where data migration may occur – during the Build Phase where the team will configure
a test environment and just prior to the final cutover during the Deploy Phase.

Any data migration has an element of mystery and unknown because it’s most likely never been
done before using the client’s specific data. Therefore, the project team should take special
care to plan, manage and monitor data migration plans and efforts. They will always present a
level of budget and schedule risk.

To help understand the level of effort and risk associated with data migrations, we can define
three types of data, each with increasing level of effort and migration risk. This information
should be used to develop the budget for data migration and for risk management. When the
project team agrees that historical data will be imported, project management should record a
budget and schedule risk related to data migration unknown factors.

Data Type Examples Level of Effort Data Migration

for Data Risk
Cleansing
Master Records Vendors, Customers, Chart of Accounts, Subaccounts, Budgets, Low Low
Inventory Items, Employees

Transactional AP open bills; AR open invoices or unapplied payments; open Sales Medium Medium
Records Orders; open Purchase Orders; Inventory open balances using
Receipts

Page 47 of 59
Historical Data Closed transactions such as paid AP bills and their related High High
payment transactions; closed AR invoices and their related
payment transactions; closed Sales Orders and their related
invoices; closed Purchase Orders and their related Receipts

3.7 Analysis and Design Activities and Deliverables

Project Type Tasks / Activities Deliverables
Express  Core Project Management Core Project Mgmt – Use same
 Risk Management deliverables as specified in Sect 2.2.6
 Contract Management
Risk Management – Use same
 Map “To Be” business processes deliverables as specified in Sect 2.3.3
to the new system.
 Collect configuration Contract Management – Use same
requirements. deliverables as specified in Sect 2.4.4
 Prepare “As Built”
documentation. Analysis & Design Deliverables:
 Review business process with
client. Implementation check lists – can be
 Conduct Core Team Training used as “As Built” documentation.
 Receive Customer’s approval for
“As Built” Documentation.
 Adjust project plan and issue
change requests as necessary.
 Build Sandbox environment

Standard/Advanced  Core Project Management Core Project Mgmt. – Use same

 Risk Management deliverables as specified in Sect 2.2.6
 Contract Management
 Install Acumatica as sandbox for Risk Management – Use same
testing and training. deliverables as specified in Sect 2.3.3
 Map “To Be” business processes
to new system. Contract Management – Use same
 Conduct Core Team Training deliverables as specified in Sect 2.4.4
 Collect configuration
requirements.
 Prepare “As Built” Analysis & Design Deliverables:
documentation.
 Conduct data migration Implementation check lists – can be
workshop. used to collect configuration
requirements and be the “As Built”
document.
Page 48 of 59
  Prepare data migration strategy
document “To Be” Business Process mapping doc
 Conduct workshop for custom
development. Design Document for Customization(s)
 Prepare design document for
customizations. Design Document for Custom
 Build prototypes for the new Report(s)
system as necessary.
 Prioritize requirements. Design Document for Integrations
 Evaluate alternatives.
 Meet with management to Data Migration Requirements
discuss new options. Document
 Prepare Design Document for
Customizations.
 Conduct Integration Workshop. Completed User Access Roles
 Prepare Design Document for
Solution Test Plan
Integrations.
 Review design with client.
 Receive customer approval for
Design Documents.
 Conduct Testing Workshop
 Prepare Testing Plan
 Conduct User Security Workshop
 Prepare User Access Roles
 Adjust project plan and issue
change requests as necessary.

Lesson 4: Understanding the Build Processes

Learning Objects

Discover the what is involved during the Build Phase including the Activities and Deliverables

4.1 Why the Build Phase is important

During the Build Phase is when the system environment is stood up, configuration is done, as
well as any custom development and data migration mapping and initial testing of all the new
features. Typically, there are a lot of parallel activities going on. This phase ends when most of
the specified features are developed and tested and the data migration is done. Custom
Training Material and User Acceptance Test scripts are typically developed during this phase.

Page 49 of 59
When dealing with an advanced implementation, that has numerous customizations it is
important to manage the versions of each customization and ensure solution testing is done
before it is published to the client’s environment.

4.2 Build Phase - Key Activities & Deliverables

Key activities and deliverables include:

o
Project Type Tasks / Activities Deliverables
Express  Core Project Management Core Project Mgmt. – Use same
 Risk Management deliverables as specified in Sect 2.2.6
 Scope & Cost Management
Risk Management – Use same
 Complete system configuration deliverables as specified in Sect 2.3.3
 Conduct Solution Testing
 Develop data migration scenarios Scope & Cost Management – Use same
 Test data migration scenarios deliverables as specified in Sect 2.4.4
 Develop training material
 Install Acumatica Production Build Deliverables:
Environment Completed Configurations
Completed test migrations
Training material
UAT Scripts

Standard &  Core Project Management Core Project Mgmt. – Use same
Advanced  Risk Management deliverables as specified in Sect 2.2.6
 Scope & Cost Management
Risk Management – Use same
 Complete system configuration deliverables as specified in Sect 2.3.3
 Develop customizations
 Develop Interfaces Scope & Cost Management – Use same
 Conduct Solution Testing deliverables as specified in Sect 2.4.4
 Develop data migration scenarios
 Test data migration scenarios
Build Deliverables:
 Develop training material
Completed Configurations
 Develop UAT scripts
Completed Customizations
Completed test migrations
Training material
UAT Scripts

Page 50 of 59
Lesson 5: Understanding the Stabilization Process
Learning Objects

Discover what is involved during the Stabilization Process including Key Activities and Deliverables.

5.1 Why the Stabilization Phase is important

During the Stabilization Phase is when the solution is validated as built according to what is
specified and ensures the solution is ready for release and will operate successfully in a
production environment, and meets the needs and expectations of stakeholders. It also ensures
the client is ready to use the new system.

5.2 Stabilization - Key activities and deliverables

Key activities and deliverables include:

o End user training – to prepare all employees who will be using the new solution
o User Acceptance Testing
o Customer Acceptance
Project Type Tasks / Activities Deliverables
Express /  Core Project Management Core Project Mgmt. – Use same
Standard  Risk Management deliverables as specified in Sect 2.2.6
 Scope & Cost Management
 Conduct End User Training Risk Management – Use same
 Execute User Acceptance Testing deliverables as specified in Sect 2.3.3
 Build Production Environment
 Prepare Cutover Plan Scope & Cost Management – Use same
deliverables as specified in Sect 2.4.4

Stabilization Deliverables:
Completed Training
Completed UAT
Production Environment
Cutover Plan

Advanced  Core Project Management

 Risk Management Core Project Mgmt. – Use same
 Scope & Cost Management deliverables as specified in Sect 2.2.6
 Conduct End User Training
 Execute User Acceptance Testing Risk Management – Use same
 Build Production Environment deliverables as specified in Sect 2.3.3

Page 51 of 59
  Prepare Cutover Plan
 Perform Site Readiness Scope & Cost Management – Use same
Assessment deliverables as specified in Sect 2.4.4

Stabilization Deliverables:
Completed Training
Completed UAT scripts
Production Environment
Final Cutover Plan

5.3 End User Training Models

There are a variety of End User Training models & materials that should be communicated to
the client. It should be specified in the Statement of Work the training model the client has
agreed to. As it will affect the costs of the implementation. Just make sure you have a plan in
place and it is clearly understood and accepted by the client.

 One on one individual training – This is the costliest.

 Train the trainer sessions – This implies that the core team will be trained and will be
responsible for supporting and training end users. This is probably one of the more
effective models, as it gets the customer to take ownership of the system. They can
cater the training specifically around their business processes.
 Open University offered by Acumatica
 Comprehensive on-line help – The Online help should always be a secondary option
presented to the client. The client should be shown where to access it and how it is
organized.
 YouTube videos – There are a number of YouTube videos available. The videos are a
good option to learn the basics; however, will not be specific to your client’s business
processes. For an Express implementation, this might be a good option, but probably
not enough for Standard or Advanced Implementations.
 Stack Overflow – Forum for asking questions. I would only recommend it as an on-
going support
 Acumatica Blog - http://www.acumatica.com/blog/ Acumatica also has a blog, where
end users can go to learn new things.

5.4 User Acceptance Testing Best Practices

User Acceptance Testing is done by the intended users of the system or software. This testing
usually happens at the client location. User Acceptance testing is required because developers
have included features on their “own” understanding and requirements changes during the
course of the project may not be communicated effectively to the developers or consultant
configuring the system.

Following points needs to be considered to make UAT Success:

Page 52 of 59
 Prepare UAT plan early in the project life cycle
 Prepare Test Scripts before the UAT starts
 Set the expectation and define the scope of UAT clearly
 Test End to End business flow and avoid system tests
 Test the system or application with real world scenarios and data
 Think as an Unknown user to the system
 Perform Usability Testing
 Conduct Feedback session and meeting before moving to production

6.4.1 Prerequisites of User Acceptance Testing

Following are the entry criteria for User Acceptance Testing:

 Business Requirements must be available.

 Application Code should be fully developed
 Solution Testing should be completed
 No Showstoppers, High, Medium defects exist prior to UAT Phase -
 Only Cosmetic error are acceptable before UAT
 Regression Testing should be completed with no major defects
 All the reported defects should be fixed and tested before UAT
 UAT Environment must be ready

6.4.2 Analysis of Business Requirements

One of the most important activities in the UAT is to identify and develop test
scenarios. These test scenarios are derived from the following documents:

 Vision and Scope document / Statement of Work

 Business Use Cases
 Process Flow Diagrams
 Design Documents

6.4.3 Creation of UAT Test Plan

The UAT test plan outlines the strategy that will be used to verify and ensure an
application meets its business requirements. It documents entry and exit criteria
for UAT, Test scenarios and test cases approach and timelines of testing.

6.4.4 Identifying Test Scenarios

Identify the test scenarios with respect to high level business process and create
test cases with clear test steps. Test Cases should sufficiently cover most of the
UAT scenarios. Business Use cases are input for creating the test cases.

6.4.5 Preparation of Test Data

It is best advisable to use live data for UAT. Tester should be familiar with the
data base flow.

Page 53 of 59
 6.4.6 Run the Test Cases and record the results
Execute test cases and report bugs if any. Re-test bugs once fixed.

6.4.7 Confirm business objectives & exit criterial for UAT

UAT Testers needs to send a sign off mail after the UAT testing. After sign-off
the product is good to go for production.

Before moving into production, following needs to be considered:

 No critical defects open

 Business process works satisfactorily
 UAT Sign off meeting with all stakeholders

5.5 Cutover Plan Components

When planning for the cutover to the new system it is important to have a good plan in place to
ensure the infrastructure and users are ready to use the new system.

The components to a good cutover plan include:

 Pre-cutover activities
This section identifies the tasks that will be required prior to cutover. It should
include all the tasks required to assess the client’s readiness to go live and any
additional tasks required to prepare the production environment.

For example:
validate the infrastructure, configuration, UAT is signed off and Users are trained.
Timing of when data entry will be frozen in legacy system and open transactional
data will be extracted.

 Final cutover activities

This section identifies the data that will be imported after testing has completed
and just prior to going live on the new system, as well as any other activities
required for final cutover.

 Post go-live smoke tests

This section identifies the health check scenarios that will be carried out once the
system is live to ensure it is ready for end users.

For example: final tests on the data that was migrated to ensure everything
balances from the legacy system.

 Rollback Plan

Page 54 of 59
 This section identifies the activities required to Rollback to legacy system in the
event client decides not to go live.

 Cutover Resources
This section identifies the resources that will be available during the cutover period
in the event issues need to be escalated.

Page 55 of 59
Lesson 6: Understanding the Deploy Process

Learning Objects

Discover the Key Activities and Deliverables to a successful Deployment Process.

6.1 Why the Deployment Phase is important

During the deployment phase is when the cutover plan is executed, the final data migration is
completed and the client go lives on their new Acumatica system.

6.2 Deployment - Key activities and deliverables

Key activities and deliverables include:

o Cutover Plan – determines specific timing of go-live cutover

o Final data migration
o Go-Live

Project Type Tasks / Activities Deliverables

Express  Core Project Management Core Project Mgmt. – Use same
 Risk Management deliverables as specified in Sect 2.2.6
 Scope & Cost Management
 Execute Cutover Plan Risk Management – Use same
 Final data migration deliverables as specified in Sect 2.3.3
 Go Live
Scope & Cost Management – Use same
deliverables as specified in Sect 2.4.4

Deploy Deliverables:
Go Live Announcement

Standard  Core Project Management Core Project Mgmt. – Use same

 Risk Management deliverables as specified in Sect 2.2.6
 Scope & Cost Management
 Execute Cutover Plan Risk Management – Use same
 Final Data Migration deliverables as specified in Sect 2.3.3
 Go Live
Scope & Cost Management – Use same
deliverables as specified in Sect 2

Deploy Deliverables:
Go Live Announcement

Page 56 of 59
Advanced  Core Project Management
 Risk Management Core Project Mgmt. – Use same
 Scope & Cost Management deliverables as specified in Sect 2.2.6
 Conduct End User Training
 Execute User Acceptance Testing Risk Management – Use same
 Execute Cutover Plan deliverables as specified in Sect 2.3.3
 Final Data Migration
 Go Live Scope & Cost Management – Use same
deliverables as specified in Sect 2.4.4

Deploy Deliverables:
Go Live Announcement

Page 57 of 59
Lesson 7: Understanding the Post Go Live Process
Learning Objects

Learn the importance of a successful Post Go Live process activities, deliverable and system transition to
the customer.

7.1 Why the Post Go Live Phase is important

The Post Go Live phase is when open issues are closed, client is transitioned to support and the
project is officially closed. The purpose of the post go live processes is to understand if we have
been successful in the customer’s mind.

Did we:

 Identify and correct operational and organizational pain points

 Achieve the objectives that were outlined in the statement of work.
 Complete the scope of work as defined in the plan
 Improve the client’s operational success

7.2 Post Go Live - Key activities and deliverables

Key activities and deliverables include:

o Receive acceptance by customer or sponsor.

o Provide Post Go-live Support to close out issues
o Review deliverables against SOW and Close out project
o Have customer complete post-project survey
o Conduct post-project review
o Document lessons learned
o Transition to Support
o Project Closure

7.3 Conducting a Post-Project Review

A Post Project Review is a very useful and powerful way of adding a continuous improvement
mechanism to your practice. It helps make each succeeding project more successful. Post
project reviews typically involve the project team and major stakeholders meeting together and
reviewing what went well and what went badly during the project. This input can help
participants make the right decisions and plans so that the next project runs better. It can also
help clear up misunderstandings and other issues.

Elements of a good review:

Page 58 of 59
A Post Project review’s primary purpose is not to apportion blame but to identify areas for
improvement and ways to improve them. Before you plan a review identify your primary goals
and what you want to take away.

1. Send out an agenda prior to the meeting outlining the objectives and goals of the
meeting.
2. Review the ground rules and that the purpose of the meeting is for learning and not
criticism.
3. Do not over analyze, but stay at a high level.
4. Review the objectives of the project.
5. Identify items that were done well and why they went well.
6. Identify items that could improve and why did these things not go well.
7. What are you going to do different next time?
8. Have each person rate the success of the project.
9. Identify any specific follow up items.

A good input prior to this meeting is having your customer complete a survey of questions that
allows them to rate various aspects of the project. Once the meeting is over, collect all the
information and record it in lessons learn document.

Post Project Reviews are a valuable way for teams to improve performance and skills. Good
planning and post meeting follow up is crucial to make these reviews a success.

7.4 Hand over to support

If your organization will provide on-going support to the client once they are live and the team
providing support was not involved in the implementation it is good practice to have a formal
hand over process.

Elements of a good hand over to support:

1. Start with a full system demonstration.

2. If the client is on-premise, ensure the support team has access to their environment(s).
3. Ensure the support team has access to a local version of their instance that is the same
version and has all the same customizations. This instance can be used for testing
purposes, and also ensures the support team is familiar with the customizations in their
environment.
4. Have the support team run through the test scripts that were prepared during User
Acceptance. This will familiarize them with the client’s business processes and how they
are using the system.
5. Ensure the customer is aware of how to report issues and check on the status of issues.

Page 59 of 59