Should Your Software Selection Process Have a Proof of Concept? Part Two: Advantages, Disadvantages, and Conclusion

Advantages and Disadvantages to the Client

There are a number of advantages to the proof of concept (POC) for the client including

• Expectation 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.

There are also limitations of the POC that should be noted. These are

• Commercial 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.

This is Part Two of a two-part tutorial.

Part One discussed the structure of a POC and how it fits in the selection process.

Advantages and Disadvantages to the Vendor

These are the advantages to the vendor:

• Gain 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.

These are the disadvantages to the vendor:

• Timing 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 discounting.
  
  
• 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.

The 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

• Knowledge of the industry
  
  
• 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 expertise of your team. The greater expertise within the team reduces project risk.

The chart below represents these factors and how to determine if a POC is required for the selection process:

About the Author

Robert 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