Should Your Software Selection Process Have a Proof of Concept? Part One: Structures and the Selection Process

Introduction

There are a number of studies that point to a high rate of enterprise resource planning (ERP) and customer resource management (CRM) implementation failure. There are many reasons for these failures. The selection phase has been identified as a key area where problems arise.

The proof of concept (POC) is a tool sometimes used within the selection process to overcome these issues. The POC is a consulting exercise undertaken by the software vendor or value-added reseller (VAR). The purpose of the POC is to determine scope, functional fit, level of customisation, resources, and project timetable of high value software implementations.

There are as many different terms for the POC including implementation planning study (IPS), pre-implementation study, pre-sales review, diagnostic, etc. The different terminology for the POC sometimes reflects the structures for the process. This article explores how the POC fits into the software selection process, when a POC should be undertaken, structural variables, and the advantages and disadvantages of the POC from the client and VAR point of view.

This is Part One of a two-part tutorial.

Part Two will discuss the advantages and disadvantages to both the client and vendor and how to determine if a POC is necessary.

Software Selection Process—Where Does the POC Process Fit In?

A software selection process can be structured in a number of ways. Below is an example:

1. Development of business case for implementation and key success factors
   
   
2. Determination of requirements and production of a request for proposal (RFP), which is issued to software vendors and VARs for response
   
   
3. Selection of shortlisted software vendors or VARs based upon response to RFP
   
   
4. Demonstration of solution
   
   
5. Selection of preferred software vendor and VAR and software solution
   
   
6. Negotiation of commercial terms and issue of purchase order

The POC process should occur after the preferred software vendor or VAR and software is chosen. The POC process is a major undertaking, and thus should not be used as a tool to compare one solution to another. Furthermore, as the POC is oriented to the chosen solution and implementation methodology, the content or process undertaken cannot be readily transferred to another software solution or VAR. The POC should be used to confirm the preferred vendor's status rather than establish it.

Structure of the POC

Commercial The commercial structure of the POC has a number of variables including

• When is the purchase order for the software required?
  
  
• Is the POC a billable consulting exercise?
  
  
• If the POC is billable, is it on a fixed price basis or time and materials basis?

There are a number of different commercial structures for the POC. The commercial agreements for professional services, software licenses, and support can be completed before the POC or after. If completed before the POC, a refinement of the contractual agreements is undertaken once the POC is completed.

The alternative structure is to complete all contractual agreements at the end of the POC.

Length of POC

The length of the POC determines the depth of the process and document produced. The POC can range from a week (or less) to months. At one end of this continuum is a confirmation of scope' exercise. This process extends discussions undertaken in the sales process and documents the expectations the parties have of one another. Elements covered include the identification of customization, project team, and high level estimation of major tasks.

At the other end of the continuum, the completion of the POC represents the entire analysis and design phase of the project. This POC requires more investigation and takes a "clear sheet" approach to the POC. The POC documentation from this process will include elements such as a detailed project scope, key success factors, return on investment analysis, infrastructure required, identification of major customisation, and integration points with high level design and a detailed project plan.

The length of the POC will largely be determined by the risk associated with the project. The greater the project risk, the longer the POC process. Please see the last section of this paper for a method of determining project risk.

Sales or Consulting Exercise

The POC can be performed by pre- or post-sales consultants. Pre-sales consultants are responsible for assisting the sales team and typically do not perform implementations. If the POC is completed by pre-sales consultants, the POC becomes an extension of the sales process. Optimally, the consultants responsible for producing the POC should then proceed to complete the implementation. This provides ownership and accountability to the assertions made in the POC. Further, the business knowledge gained in the POC process is not lost when "fresh" consultants are provided for the implementation.

Post-sales consultants are also focused on implementing software. They tend to have a deeper knowledge of the product and business domain in a particular area whereas pre-sales consultants tend to have broader knowledge which tends to be achieved with less depth. Thus, the client should insist on post-sales consultants for the POC process.

Whether pre- or post-sale consultants perform the POC, the POC process itself remains part of the sales process for the software vendor or VAR if the POC is undertaken before contractual negotiations for licensing, professional services, and support are completed. In this situation, the client should be aware that some of the effort within a POC will be directed to closing the opportunity rather than strictly an analysis and design process. Further, as the sale is still at risk, participants from the software vendor or VAR are likely to be less candid than if they in post sales environment.

Justification of a POC

The POC has been introduced to overcome some of shortcomings of the tradition selection process. These shortcomings are

Inflated or unrealistic expectations

Once there is a business justification to invest in a new system, there is a lot of excitement generated at the prospect of improving the current processes within the business. Unrealistic or inflated expectations can be generated amongst employees and management due to the marketing material from software vendors and general press relating to advances in technology. If these expectations are not synchronized with the vendor, the mismatch in expectations can lead to project failure. The POC attempts to synchronize expectations by documenting the scope of the project, then performing a more detailed estimation of effort required to deliver the project.

Lack of ownership

Ownership by management and staff of the decisions made in the initial phases of the project is crucial for the overall success of the project. The evaluation process tends to be managed by a core project team to limit the impact on the business and ensure the process is not paralysed. The POC builds the perception amongst line management and employees they have been consulted in the process.

Overselling and identification of functional gaps

As a consulting exercise, the POC can minimize overselling as salespeople are often removed from the process. Overselling can be due to the salespersons lack of knowledge of the product and accountability.

The POC limits overselling and identifies more functional gaps and interfaces as

• Consultants have greater depth of the product than sales team
  
  
• The POC provides a subsequent exposure to the product that allows functional gaps and interfaces to be identified
  
  
• Consultants have accountability for commitments made

This concludes Part One of a two-part tutorial.

Part Two will discuss the advantages and disadvantages to both the client and vendor and how to determine if a POC is necessary.

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