What’s the secret to a successful, hassle-free proof of concept? Planning, pure and simple. Before you launch a PoC, you need to prepare. Then double-check your preparations. You get the idea. But what, specifically, do you need to consider? Here are the main areas where you will need to do some research and ask questions before you press the Start button.
Fill out your proof-of-concept team with a cross-section of users who will use or benefit from the solution. Identify how they will feed into the process and what their evaluation criteria will be. They should adopt an optimistic approach toward a successful outcome and not be constrained by a reluctance to change.
What does a PoC team look like?
Key decision maker
This is the person who will ultimately make the yes-or-no decision once the proof of concept is complete.
The tech leader validates the integration and implementation of the product. They also lead the development of the PoC.
Involving a business user is valuable because they are is able to quantify the business benefits that feed into the success criteria.
At the vendor
An account executive at your vendor works to align the expectations for a successful adoption of the product.
This person is the counterpart to the technical lead in-house, providing backup for the project in the form of product support.
When considering a product, you need to ensure that it integrates with your target architecture and addresses any security concerns. For example, do you need to keep sensitive data within your private cloud, or is that less of a concern? Ultimately there will be a set of technical requirements that a product will need to adhere to if it is to meet an organization’s technical governance.
Gain a firm grasp of an organization’s cost model. Do you have control of the costs? Are there additional costs as you scale, or can you scale the solution without financial penalty? Does the cost model offer the flexibility your enterprise needs in order to build the environments you need for your implementation?
Use the proof of concept to understand the options and speed of installation. But remember, you are not building a fully productionized system.
Maintenance is typically 40 to 80 percent of the total cost of a solution. As data changes and business logic evolves, does the solution remain easy to maintain? Can you quantify improvements in maintenance effort required and compare them to existing processes?
In other words: why are we doing this and what are we trying to achieve?
Ultimately a proof of concept should give you proof of value. Identifying where this value lies will provide a framework for how you want to define your success criteria. Cost savings are driven by:
Does it speed up the development process?
Is the interface easy to use and navigate?
Does it simplify the process?
Do you need specialist technical resources or is it simple and intuitive to use?
Does it support industry standard languages like SQL?
Do you need to have specialized configuration knowledge to scale the solution for future use?
Does it leverage the benefits of the cloud computing approach to simple scaling?
Are there cost penalties or gates if you scale your data volumes?
Can you develop my data flows in a visual way?
Do you have control over data and alerting processes?
Do you need specialized skills to maintain the product, or can it be done through a standard interface?
Can you restart processes from point of failure? Build in retry mechanisms, monitoring, and alerting?
You need to identify a small number of typical use cases to prove out. Keep it simple, and start small. These use cases should be your typical data flows. You are not trying to reproduce every scenario; a sample of typical flow will give you a good indication of how the product performs.
Identify the pain points in the current process. For example, are you blocked because you need specialized knowledge or have complex scripts that are difficult to maintain? Is your current solution hard to scale?
Pick several use cases – don’t try and replicate legacy implementations. Take several simple business use cases and try and prove that the approach will work.
Feasibility within your environment
Technical governance will feed into the evaluation checklist. For example, does the product support source control integration (Git), native integration with cloud services, and interaction via an API? Is there flexibility and control around integration that allows the tool to grow within your organization?
Evaluate your vendor support: Are they customer obsessed? Are they willing to help you succeed? Do they value your feedback?
Once you find answers to your questions in each area of consideration, you should be in a good spot to begin executing your proof of concept.
For more information and tips on how to run a fast, low- or no-cost proof of concept, download our ebook, Your Guide to a Successful Proof of Concept.
The post Planning an ETL Proof of Concept: 9 Things You Need to Consider appeared first on Matillion.