Should Your Software Selection Process Have a Proof of Concept? Part Two: Advantages, Disadvantages, and Conclusion
Written By: Robert Rudd
Published On: July 13 2004
Advantages and Disadvantages to the Client
are a number of advantages to the proof of concept (POC) for the client including
synchronization with the vendor
Improved ownership of the implementation process
Identification of functional gaps or overselling
Better understanding of investment required. More accurate scoping provides
a better understanding of the investment required to complete the implementation.
Evaluation of the implementation partner. The POC process allows the client
to evaluate the software and also the implementation partner.
are also limitations of the POC that should be noted. These are
flexibility. The flexibility incorporated into some POC arrangements whereby
the client may walk away without purchasing the software are rarely used in
reality as a significant investment in both money and time has been made.
Furthermore, the client may be convinced to move into the POC without fully
evaluating all solutions due to the perceived low risk of the POC option.
Sales exercise. Depending upon the commercial agreements in place, the POC
can be within the sales cycle thus the ability of vendor for full disclosure
is restricted. Further, the documentation produced within the POC may have
marketing content that does not add value to the project.
is Part Two of a two-part tutorial.
One discussed the structure of a POC and how it fits in the selection process.
Advantages and Disadvantages to the Vendor
are the advantages to the vendor:
a competitive edge in the sales process. The POC is another tool in the sales
toolkit. The POC can be used to move prospects into the next step of the sales
process without the client having to make a full commitment.
Better implementations and happy clients. A key success factor for any VAR
or software vendor is having clients that are prepared to act as reference
site. Any tool that improves client satisfaction should be examined.
are the disadvantages to the vendor:
of the sale. The POC can lengthen the sales process. Moreover the timing (important
for public listed companies) becomes more uncertain which can lead to further
Demands on consulting resource. Due to the nature of the POC, demands on consulting
resource can be extensive. Typically, more senior consultants are required
to ensure the POC leads to a purchase order.
When should a POC be completed?
A POC should be completed as part of the selection process when the risk of project failure is comparatively high. Risk can be measured by two key variables. These variables are complexity of requirements and level of expertise within the selection and implementation team. The more complex the system requirements, the greater the benefit obtained from a POC. Complexity can be gauged by the number and nature of the modules implemented, amount of customization, number of interfaces, and the amount and quality of the data to be converted.
number of modules to be implemented (such as, a financials-only implementation
versus financials, distribution, and warehouse implementation) increases the
scope of the implementation, thus the risk. Furthermore, the nature of modules
to be implemented also impacts on risk. Modules such as sales force automation
(SFA) within a customer relationship management (CRM) suite tend to
have a higher risk profile than financial modules such as accounts receivable.
The level of expertise within the selection/implementation team is also an important indicator. Factors to be considered are
of the industry
Knowledge of existing business processes
Understanding of the high value software selection process
of software vendor management
Knowledge of ERP/CRM systems
These factors should be used to measure the expertise of your team. The greater expertise within the team reduces project risk.
chart below represents these factors and how to determine if a POC is required
for the selection process:
Rudd is a senior ERP consultant with over nine years experience implementing
ERP system. His experience also includes information technology supporting clients
in the finance and banking industry. He has implemented ERP systems in a number
of industries but specialized in supply chain management. Rudd
works for Scalable Data System based in Australia. Scalable Data Systems has
been implementing enterprise solutions for the mid-market for over twenty years.
He can be contacted at Robert@scalableDS.com.au