Recommendations for Improvement
Take
a Guide
Software
evaluation and selection is a learning process. The selection team will learn
a great deal about itself, the company requirements, external software vendors,
application software tools, and outside consultants. During this "journey of
discovery" it is often helpful to take a guide someone who has been there
before and can lead you through the process.
When
looking for a consultant to guide you through the process, look for a firm that
is unbiased and has no hidden agenda. Many consulting firms resell software
or have close financial alliances with software vendors. While these consultants
may be very useful during the implementation phase, their judgment may be impaired
during the selection phase. Also closely examine the specific individuals who
will work on the project.These
are the people you will work closely with on a daily basis, so choose them wisely.
Evaluate their skills, past experience, market knowledge, industry expertise,
honesty, integrity and references. Be wary of any consulting firm that will
not clearly identify the resources for your project.
Don't
rush the process!
This
seems like heresy in today's corporate climate where everything must be done
yesterday. The key here is to maintain the paradigm of software as a capital
investment. Look at similar corporate decisions regarding machinery, real estate,
facilities, etc. and use that as a guideline for your decision-making timeline.
Obviously
there is a balance between "analysis paralysis" and constructive action
toward a known objective. Effective management is crucial at this early stage
to ensure the team continues to make progress and does not bog down in over
analyzing the selection.
Build
a strong business case
Probably
the most important deliverable in the entire evaluation and selection process
is the business case, which serves as the "guidebook" for the remainder
of the project. A strong business case establishes the project expectations
and guidelines including:
-
Project scope
-
Expected costs
-
Expected benefits
-
Project performance metrics
- Risks
-
Overall implementation approach and timeline
- High
level project workplan
-
Resource requirements
-
Assumptions
But
it is not enough to simply produce these documents and call the business case
complete. Sufficient analysis must be performed such that the project expectations
are realistic and supported by factual evidence. For example, saying that a
project will result in $1M in cost savings due to "more efficient supply
chain processes" is not sufficient analysis. One must identify the specific
performance metric that will improve due to the new system, discuss how the
software will actually improve that metric, assign an "owner" responsible
for delivering that benefit, and then calculate the expected financial results.
For
example, if your project is expected to reduce raw material inventory, a thorough
business case will record this as follows:
Expected
Benefit #1 - Reduce raw material inventory in category A by 25%
-
Justification:
-
Software and business process enhancements will reduce the purchasing
cycle from 4 weeks to 3 weeks. This 25% reduction will allow a corresponding
reduction in raw material inventory on hand. This benefit assumes that
the three week purchasing cycle will not result in additional transportation
costs due to increased shipment frequency or less than truckload shipments
(this assumption is supported by the evidence presented on page XXX of
the business case).
-
Owner:
-
Bob Jones, Director of Purchasing
-
Savings Summary:
-
Expected annual savings = $125,000
-
Expected one-time reduction in working capital investments = $1,250,000
-
Savings Detail:
-
Current average raw material inventory value in category A = $5,000,000
-
Expected inventory reduction = 25%
- Expected
annual return on invested capital = 10%
-
Annualized Dollar Savings = $5,000,000 x 25% x 10% = $125,000
-
Reduction in working capital = $1,250,000
As
you can see, a more detailed set of benefits will remove ambiguity, assign ownership
and give the project team a clear set of goals and metrics to target. Developing
a business case at this level of detail is a key component in gathering executive
support for the project.
In
addition, a strong business case serves as the project reference manual. As
the implementation begins questions will arise surrounding scope, objectives,
budget, resources, deadlines, milestones, etc. The business case must be used
to guide the decision making of the project management team. Without an effective
business case, and managers who use it properly, an implementation can quickly
lose focus and wander off course.
This
is Part two of a two-part article.
Part
One discussed some of the reasons software implementations so often fail.
Involve all affected departments on the selection team
What
seems to be a simple concept is often bypassed for political, personal, and
resource/schedule constraints. But there should be no compromise here. A software
evaluation and selection team that does not include affected parties will invariably
face high-levels of resistance and increased risk of failure. When implementation
troubles set in or questions arise over the software capabilities, organizational
buy-in and support will help you manage through these issues. Without it, the
project can and will lose momentum.
Be
thorough in your requirements definition
Again
this is a simple concept, but one that is often bypassed due to expediency or
difficulty. A comprehensive set of business functional and technical requirements
serves multiple purposes:
-
Acts as a basis for software evaluation
-
Acts as a basis for defining software gaps
-
Acts as a basis for final software testing (system, performance, user acceptance,
etc.)
-
Acts as a basis for training
-
Establishes project scope
Concentrate
on data
Many
legacy systems are weak and ineffective because they don't provide the information
desired by the Executives to effectively run the business. Often, the needed
data does not exist in the legacy system. Hence the company embarks on the implementation
of a new, modern system.
When
analyzing the new system, concentrate on the required data elements. These data
elements may not be readily available in your company, and without them the
new software will not work properly. As part of the evaluation process, assess
your company's ability to provide the requisite data to the new application.
If additional data gathering is necessary, consider how this will be done (manually,
or through automated means such as bar code scanning, or through interfaces
to other systems, etc.). Also consider the cost associated with this data gathering
effort, as it can often be substantial.
To
illustrate, a large, multi-national semiconductor company recently initiated
a project to implement a state-of-the-art supply chain planning system. The
new software was purchased and initial analysis begun before a major data issue
was brought to light. The new system required consistent item information. Unfortunately,
item master information for the company was located on several different systems,
with little consistency between applications. The data problems were so large
that the new system was simply unable to perform properly. To rectify the problem,
the company embarked on a 12-month item standardization process that delayed
all efforts pertaining to the supply chain planning system. When finally completed,
executive support for the supply chain planning system had eroded and the project
was shelved. Over $2M in software, hardware and consulting services was wasted.
Prototype the software BEFORE buying!
During
the heyday of application software sales in the mid-to-late 1990's, large application
software contracts were being signed regularly and without rigorous buyer evaluations.
Except in certain circumstances (i.e., large buyer in strategic market), software
vendors were reluctant to expend abnormal amounts of effort convincing a customer
to buy their software. Pre-configured demos, high-level brochures and limited
technical documentation were the basic info given to the buyer. Demands for
additional evaluation hurdles were often met with delays, excuses, and even
flat refusal.
But
the times have changed and the power is now most certainly in the hands of the
buyer where it should be. Returning to our capital investment paradigm and
machinery analogy, an organization would never consider buying a key piece of
production machinery without ensuring that it had been thoroughly tested for
quality, ease of use, and engineering/supplier/customer acceptance. Software
should be no different.
In
short, before signing the final contract and buying a piece of software, put
the selected candidate package through a rigorous set of tests. Require the
vendor (or an implementation partner) to build a prototype using real data and
execute a test using real processes. Produce extract files and reports that
are close approximations of technical interfaces and user requirements. Allow
users from various business departments to see, touch and manipulate the system.
Basically build a prototype.
You
should expect to compensate the vendor for his time and effort to build such
a model since the work product serves as a solid basis for full project implementation.
But a small amount of time and money invested up front to discover gaps, product
issues, and vendor capabilities is invaluable. This prototyping effort will
limit the project risk and provide an option to stop the project before wasting
significant time, energy and money.
Don't
focus on price!
Price
is obviously a key component of any business purchase, and software is no different.
But price is not the right factor to weigh. The cost of the software itself
is minor compared to the long term costs associated with its "care and
feeding". Instead look at Total Cost of Ownership (TCO), which includes
support costs (both internal and external), service fees for implementation,
enhancement and ongoing growth of functionality, maintenance fees, vendor viability
risks, software upgradability, and hardware requirements.
Often
the cheapest software solution ends up being the most expensive over its lifetime.
For example, one factor that significantly impacts the total cost of the solution
is software customization. Modifying packaged software is strongly discouraged
due to the high-cost and complexity in supporting and upgrading the software
over time. Often the lowest priced software lacks functional depth, driving
companies to adopt a software customization approach. When a software customization
path is chosen, expenditures for software development, long-term support costs,
and upgrade costs must be included in the total cost of ownership and ROI models.
Invariably, when TCO is considered, the lowest priced solution becomes more
expensive and the benefits of the cheap price are lost.
Conclusion
The
implementation of any mission-critical software application is fraught with
risk. As the Standish Group statistics at the beginning of the article note,
over 30% of implementations fail, and over 50% cost more than twice the original
estimates. Those are very bad odds that most organizations should not accept.
Pursuing an alternative strategy for software evaluation and selection based
on the capital investment paradigm and the principles outlined above is an effective
method to mitigate this inherent risk.
About
the Author
Paul
Winandy is a founding partner of Spinnaker Management Group
(www.spinnakermgmt.com), a management
consultancy guiding small and mid-sized businesses along the entire journey
from strategy creation through technology implementation. Mr. Winandy has over
15 years experience transforming organizations through business process and
technology solutions. He specializes in the planning, selection, and implementation
of mission-critical ERP and supply chain related systems. Mr. Winandy has assumed
project leadership roles on several major strategy and systems implementation
projects for multi-national manufacturing and distribution enterprises in industries
such as semiconductors, CPG, food & beverage, wholesale distribution and transportation.
Paul
Winandy can be reached at paul.winandy@spinnakermgmt.com.