Should Your Software Selection Process Have a Proof of Concept?
Part One: Structures and the Selection Process
Featured Author - Robert Rudd
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:
- Development
of business case for implementation and key success factors
-
Determination of requirements and production of a request for proposal
(RFP), which is issued to software vendors and VARs for response
-
Selection of shortlisted software vendors or VARs based upon response to RFP
- Demonstration
of solution
- Selection
of preferred software vendor and VAR and software solution
- 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