CFBS Implementation eBook 2025 spreads-email - Flipbook - Page 4
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 connection.
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.
04
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.
