Software selection: is a Proof Of Concept (POC) necessary?

Some software publishers and integrators offer you a POC (Proof-Of-Concept) to validate the feasibility of a project. More often than not, it's the customer who requests it. Is this a comfort phase to reassure the customer, or is it a mandatory operation to reduce risk?

See all software Operations Management

Advantages and disadvantages of a POC for the customer

There are a number of advantages to POC for the customer:

• Synchronization of expectations with the supplier;
• Better ownership of the implementation process;
• Identification of functional deficiencies or over-estimation;
• A better understanding of the investments required. A more precise framework provides a better understanding of the investment required to complete the implementation;
• Evaluation of the implementation partner. The inherent POC process allows the customer to evaluate both the software and the implementation partner.

There are also POC limitations that need to be noted. These are :

• Commercial flexibility. The flexibility built into some POC arrangements that allow the customer to opt out without purchasing the software is rarely considered in reality, as a significant investment of money and time has been made. On the other hand, the customer often makes the decision to embark on a POC without fully evaluating all the solutions, due to the low risk of this option.
• The sales exercise. Depending on the commercial agreements in place, the POC may be integrated into the sales cycle, so the supplier's ability to fully disclose this information is restricted. Furthermore, the documentation produced in the POC may have marketing content that adds no value to the project.

This article is the second part of a two-part tutorial. The first part was devoted to analyzing the structure of a POC and how it corresponds to the selection process.

Advantages and disadvantages of a POC for the vendor

Here are the advantages for the vendor:

• Having a competitive edge in the sales process. The POC is another tool in the sales toolbox. The POC can be used to take the potential customer to the next stage of the sales process without the customer having to make a full commitment.
• Better implementation and satisfied customers. A key success factor for any VAR or software supplier is to have customers ready to serve as references. Any tool that improves customer satisfaction should be considered.

Here are the disadvantages for the vendor:

• Sales timeline. POC can prolong the sales process. In addition, the timeline (important for publicly traded companies) becomes more uncertain, which may lead to a further price reduction.
• Requests for resource advice. Due to the nature of the POC, requests for advice can be significant and resource-intensive. As a general rule, more experienced consultants are required to ensure that the POC results in a purchase order.

See all software Operations Management

When should a POC be carried out?

A POC should be carried out as part of the selection process when the risk of project failure is relatively high. Risk can be measured by two key variables. These variables are the complexity of the requirements and the level of expertise within the selection and implementation team (MOE). The more complex the system requirements, the greater the benefits obtained from a POC. Complexity can be measured by the number and nature of modules implemented, the extent of customization, the number of interfaces and the quantity and quality of data to be converted.
The number of modules to be implemented (for example, a purely financial implementation versus a financial + distribution + storage implementation) increases the scope of the implementation, and therefore the risk. In addition, the nature of the modules to be employed also influences risk. Modules such as sales force automation (SFA) in 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 consider include

• Knowledge of the sector
• Knowledge of existing business processes
• Understanding of the high-value software selection process
• Knowledge of software vendor management
• Knowledge of ERP/CRM systems

These factors should be used to measure the competence of your team. A highly competent team reduces the risk factor for the project.
The table below represents these factors and how to determine whether a POC is required for the selection process:

About the author

Robert Rudd is an expert ERP solution consultant with over nine years' experience in implementing ERP systems. His experience also includes IT supporting customers in the financial and banking sector. He has implemented ERP systems in a number of industries, but specializes in supply chain management. Rudd works for Australia-based Scalable Data Systems. Scalable Data Systems has been implementing enterprise solutions for the mid-market for over twenty years.