Finance Capability Lead, Bluefin Solutions
The power of the Proof of Concept (PoC)
21 Jul 2010
Project Management & Methodology, Consumer Business
"Proof of concepts (PoC's) are now a more powerful tool to educate and influence a customer to implement a solution or process".
Is this a statement that you believe in or have experience in? I am going to share my views on the power of PoC's and provide a high level insight how to use the engagement to your benefit as a customer and as an implementer.
Set the scene - what is a PoC?
A proof of concept in terms of a SAP implementation is a quick installation of either a system or process to show the business the potential of the solution. There is not a set rule that defines how long it should take to implement your proof of concept. For some solutions the PoC could be designed and implemented in a couple of weeks, some solutions may require more effort both in terms of time and resource. Whilst the duration may be unpredictable the key is that the solution should provide a high level overview of the functionality and that part of the PoC will be re-useable in a full blown implementation. Further to this the effort required to deliver the PoC should be a fraction on doing the implementation without the PoC. It is advisable to request some business input into the PoC, so when the solution is played back to the business audience the PoC can be seen to fit the high level requirements of the business.
Benefits of a PoC
1 - Customer benefits
The main benefits for this approach are with the customer. The customer can get early visualisation of the solution that they are interested in implementing. If this is wrong or needs to be re-scoped then this can be done in a more costly fashion - i.e not waiting until some form of UAT. The customer can also influence the final design by reviewing the potential functionality and change the scope so it aligns to the true business requirements. Further to this, the customer has a - built system (not tested, not end user trained) but you have an asset that can be built to validate the cost of using a PoC.
Lastly it could provide a customer the missing information to create a business case for a fuller implementation. Without a detailed knowledge of the product and the businesses requirements it is very hard to write an accurate business case for the functionality. The PoC methodology aligns to an AGILE methodology of drip feeding functionality in small chunks of effort, providing business benefits much quicker than a traditional Waterfall implementation.
2 - Implementer benefits
The PoC implementation provides benefits to the implementer as well. It could be argued that it is an easier sale to a customer, as the outlay is not as high in terms of cost and the effort is not as great. Aligned to this the implementer starts to build a positive relationship with the customer demonstrating knowledge of the customer's business and related processes. This then leads to the implementer being seen as a reliable partner to sound ideas off and to help scope the solution.
Summary
Whilst this article is very high level, and you may be using a PoC for some new edge technical solution or a full CRM implementation the benefits are there for both customer and implementer. There are many cases where the use of a PoC is not required. I am not saying that a PoC is for everyone or every project. The PoC implementation needs to be seen as a partnership between the customer and the implementer.
Comments
Niresh Gungadeen 08 May 2012
Some advice required please:
My company is currently in the process of upgrading to a later version of SAP and are currently in the PoC phase of the project. As an auditor, should I expect that a final test strategy be in place prior to initiation of PoC, or is it best practice that a test strategy is finalized on completion of the PoC which has it's own inherent elements of testing?