Software Proof of Concept Best Practices proposed environment and function the way it
was promoted by the vendor. The outputs from
A software selection process is often described a proof of concept includes design documents by project managers and business analysts as that detail current business and best practice one of the most difficult endeavors an processes, in depth tests and analysis of the organization can undertake. The costs alone of capabilities of the product and the company, bringing in vendors, pulling employees off their communication and training plans that facilitate current job duties, sitting through canned end user adoption, architecture documents that presentations, comparing notes, and selecting a specify data mapping and conversions as well as product creates such an enormous burden that any interfaces to third party external systems. “No Selection” is often the conclusion to the Defining a proof of concept as an process. Creating buy-in from end users only implementation milestone educates users on adds to the time, costs, and efforts of the requirements. process. The indirect costs associated with an evaluation can often be up to 25% of the cost of When to Perform a Proof of Concept the product. Studies (DeGrace, 1990) indicate that those organizations that do select a Due to the scope and complexity, the proof of product often set expectations for a failed concept occurs at the end of the sales cycle and implementation by creating requirements that continues as the first milestone of the are not fully understood before the project implementation. As a result, an organization is begins, by educating users on requirements better off working with one vendor in a proof of only after having seen an initial version of the concept for a myriad of reasons: the high cost software, by changing requirements during the and effort involved in understanding the software configuration process, or product capabilities, the time spent on incorporating methodologies that make the gathering requirements, the re-allocation of implementation of best practices impossible. A human resources, the money spent on travel, proof of concept is used as an implementation the efforts to generate best practice design milestone. It gets a buying committee past the documents, the depth of testing and the level of “canned sales” presentations to a true involvement from the vendor. Conversely, an understanding of the capabilities of both the organization would have to perform the first company and the product. A proof of concept implementation milestone twice should they phase of the buying cycle enables an use a proof of concept as part of the vendor organization to incorporate the concerns and selection process. The end result would be facilitate adoption of the end user community, much greater costs, efforts, and resource create change, incorporate best practices, and utilization that create a greater probability of set the tone for a successful implementation. “No Selection”. Due to the scale of the proof of concept as the first milestone in an What is a Proof of Concept? implementation, best practices indicate that the organization complete the vendor selection A proof of concept is a test(s) of a software process with one vendor. It may be in the application made by building a prototype organizations best interest to inform the second architected from detailed process design place vendor of their status in the event that documents. It is the first milestone in the the primary vendor does not succeed in the implementation process that clarifies the proof of concept. Defining the proof of concept requirements process and prototypes the as a milestone in the implementation enables configuration requirements. The proof of an understand requirements in a concept requires bringing the vendor's product methodological manner that sets the tone for a in-house to ensure that it will work in the successful implementation. Creating a Proof of Concept concept should include tests about the vendor. For instance, does the vendor have the As mentioned earlier, a proof of concept is a knowledge and expertise to manage change in test of a software application architected from an organization? Do they understand how to detailed process design documents. The implement best practices? What level of timeframes for a proof of concept should be experience do they bring to the table? A key well defined and in proportion to the time of consideration in the proof of concept is the implementation. For instance, an eight whether a vendor has the experience to assist month software implementation should take no in the development of the workflows. Defining longer than two months for the proof of the proof of concept as an implementation concept. As it is the first milestone in the milestone is a means of solidify requirements implementation, the first step is design during configuration of the software. documents that include project plans and charters, developing product training Conducting a Proof of Concept workshops, conducting design sessions that go beyond functional requirements that include The proof of concept typically occurs at the data conversions and interface mappings, location of the customer. A project room provisioning environments, and generating test should be allocated with enough space for all scripts. The outputs should include product the end users to fit comfortable for the duration specific project plans with clear roles and of the implementation. The users should be a responsibilities, product training, functional and cross sample of both “inter” and “intra” technical requirement documents, a production departments: inter-departments are those and development environment, fit-gap analysis, areas that may be affected either through the and testing documents with measurable elimination of informational silos or through pass/fail results. Project plans are often interfaces; intra-department are interested in produced by the vendor and managed by the end users acceptance. The resources assigned organization. Product training enables the should be well respected within the community organization to assist with configuration and as their acceptance to the system correlates to train end users. A fit-gap analysis is often end user adoption. Depending upon the performed after product training and may be contractual agreements, the responsibilities of develop from a request for proposal (RFP) or the organization will be to serve as the overall request for information (RFI). It is important to manager of the project. This includes managing have a development environment as part of the the scope of the proof of concept, time and system to test processes prior to migration to budget. The organization should also be the production environment. The major forms available to provide input to support the design of testing include user acceptance, system and documents, facilitate communication with end parallel testing. User acceptance testing occurs users to generate excitement and adoptions, when a particular feature is used with a result input into product configuration, and testing. of pass or fail. For instance, can a product save The organization will sign-off on the measures account information: the result is either yes it used for success of the proof of concept, the fit can or no it cannot. User acceptance testing is gap analysis, and the results of any tests. The also used to generate end user buy in especially responsibilities of the software vendor include when performed by a well respected peer(s). building out the design documentation, Stress tests measure the speed and developing best practices, configuring the responsiveness of the system. Parallel tests system for the proof of concept, resolving have two inputs, one in the legacy system and issues, and coordinating testing activities. one in the proposed system and the outputs of Defining the proof of concept as an the tests should be identical. Last, the proof of implementation milestone is a means of adopting best practices.
Conclusion
A proof of concept as an implementation
milestone is the first step towards a successful implementation. As such, it should not be used as part of the evaluation process, but rather to develop a deeper understanding of both the product and the company, and ultimately reduce business risk. It will educate users on requirements, solidify requirement, enable best practices and set the tone for a successful implementation.