CFBS Implementations eBook - Flipbook - Page 4
04
Overview
Since 1994, the Standish Group has been assessing
software implementation projects and quantifying
whether the project was a success. Success was
defined as everything went live within the time &
budget allotted. The project was considered
“challenged” where the project was over budget in
either time or money or completed with less than
the planned functionality. “Failure” meant the
project was completely canceled. As of 2014, 31%
of IT projects were a failure. The percentages have
not changed significantly since 1994. This
document explains how we, Clients First Business
Solutions, successfully implement cloud-based
ERPs that allow your workforce to work anywhere
from any device with an internet connect.
The first success point is project flexibility. When
planning on building a new warehouse, there’s
normally a detailed set of architectural drawings
that must be adhered to during construction of the
facility. The contractor can normally execute based
upon metrics established over thousands of years’
experience. If there is a change to the architectural
drawing, there is a common understanding of the
consequences of that change. Software does not
have the same advantage.
The logical thought to freeze the design early in
order to diminish the risk is normally not practical,
wise, or in the best interest of the business. The
design must be flexible because the software
implementation tasks are highly dependent upon
the input and performance of people in conjunction
with the software, not physical items such as steel
and concrete. What is agreed upon on the first day
may change within weeks due to several influences
after the project is started.
For example, the typical user goes through several
phases when learning a new system. The first
phase is the overwhelmed phase which happens
when the new system is introduced. Even when
there is some understanding of the functionality,
the key nuances of the system still may not yet be
understood – creating a “we-want-to-change-it”
phase. Unfortunately, this phase is early in the
process when the system architect needs the input
of the users to make configuration or development
decisions. The users must gain a higher level of
competence with the system before the system
design is finalized.
