An effective proof of concept (POC) bridges the gap between expectations and reality. For developers of data migration software, it is not only the best way of illustrating features, functions and benefits, but also ensures that the end product matches the client’s expectations.
In this guide to creating a proof of concept for migration software, we’ll explain how to keep the client in focus and add some tips on successful preparation too. Or click here to read a real-life example of a proof of concept.
Explore why the customer needs the software
Carefully scope the client company’s requirements for the final product. Ensure that the scope is accompanied by a clearly defined way of measuring success.
Also explore the business reason behind the customer’s need for the software, and clarify how the product will assist in overall business improvement. A full view of the business’s needs helps to identify any extra requirements necessary to ensure a successful migration. In addition, assess the customer’s systems to understand the impact on them of the final product.
Understand exactly what the customer is looking for
Clarify all the outstanding questions that the customer expects the POC to answer or demonstrate. Some of these will be direct, such as:
• How long will it take to implement the software?
• How will the product be structured?
• What will the interface be like?
• How much will the product cost?
• How will it be deployed within our architecture?
Also prepare for questions which are indirect and wider in scope, which may include:
• How will it fit with our current products?
• How will it fit with our current processes?
• Do our users believe in the product and are they enthused by what they see?
• How easy is the product to use?
Assess where the proof of concept will be deployed
The customer’s data stores and offices may be dispersed around the world. For each location, consider how the product will be deployed on the site’s servers.
Establish when the customer requires the proof of concept
Ensure all deadlines are clearly listed in advance to allow suitable time for follow-up actions.
Consider whether the execution of the POC should be restricted to particular times or days. Ensure that the windows for execution are fully communicated within the client company.
Clarify who the stakeholders are
It is usual for a wide range of stakeholders to have an interest in a POC. It is the first impression the customer will have of the end product, and first impressions last. Often, more people are exposed to the product in the short timeframe of the POC than will have exposure to it for a good while afterwards.
Typical stakeholders include mangers, architects, security experts and users. A successful early introduction to the project’s stakeholders will encourage decision-makers to give go-ahead quickly and cost effectively. This means that it is crucial to understand the requirements and expectations of all these groups.
Prepare for the practicalities
There are many useful ways to ensure that the POC progresses without issues. In addition to being fully prepared from your own standpoint it is important, where possible, to ensure the customer has carried out any preparation that they are required to do.
A key item is availability and access to all the components required for the POC. From the customer you will need:
• Access to:
o Buildings (if onsite);
o Live or sample data.
• Availability of key personnel such as domain experts and systems experts.
And from your own viewpoint:
• Ensure that any customised components are complete;
• Where possible, review sample data sets and data schemas;
• Confirm that success measurement criteria are clearly defined and agreed;
• Expect users to highlight particular issues they are experiencing;
• Ensure the POC shows what happens when things go wrong and how mishaps are handled.
A POC does not have to cost a great deal, but its thorough preparation is a crucial stage in the success of a data migration project. What are your tips for a successful proof of concept?