Image: iStockphoto/pinkypills
A popular way of limiting IT purchase risks is to arrange with vendors to test new technologies or systems with proof of concept (POC) before you buy. A POC project gives you the opportunity to “kick the tires” on a new system or technologies before you invest.
However, conducting a technology or system proof of concept project is only as good as the POC guidelines and methods that you use. The following eight guidelines can help.
SEE: IT project management: 10 ways to stay under budget (free PDF) (TechRepublic)
1. Identify specific business cases and expectations for the new technology
Going into any POC, it is always advisable to have specific business cases and expected outcomes from the technology identified and agreed to between IT and end users. Identifying your business cases and results expectations upfront assists your POC team in focusing on the important elements of the project. It is also invaluable for your vendor, who can verify that the product can do what you want it to do and also assist in product configuration and testing.
2. Know your current performance baselines
If you are performing a POC on a system that you hope will improve your warehouse operations workflows by 50%, it is imperative that you know your present workflow timings in the warehouse so you have something to benchmark against. IT and end users (in this example, in the warehouse) should carefully figure out the current workflow timings of the warehouse so the new product or system can be benchmarked against them.
3. Set your performance goals
It’s important to set your return on investment (ROI) and key performance indicator (KPI) goals in advance of any POC. Once you’ve identified the baseline of current performance and costs (see step 2), you should be able to set goals for improvement over present performance that will deliver a positive investment return to you by way of reduced costs or improved revenues.
4. Run your POC project
Coordinating with your vendor, the next step is to run the POC project itself. From the point of configuring the project solution to concluding the POC pilot, a reasonable POC timeline should not exceed three months. During this time, it’s critical to note any challenges and/or problems that came up during the project and to identify the solutions to these problems.
5. Track your metrics
Once the POC is complete, you’re in a position to compare the KPIs that you’ve achieved for the POC to the current KPIs that you’re getting from your existing systems. Your vendor can assist you in setting up an appropriate way to measure for projected ROI—with the caveat that you and your staff should take ultimate charge of the ROI measurement formulas to avoid any favorable skews that the vendor might have built into its ROI formula that favor its solution.
6. Present the results to project stakeholders
Some POCs succeed and some don’t. The beauty of a POC is that you haven’t committed to anything except the test of a vendor solution. If the POC comes out favorably, you should be prepared to present the POC methodology, the business goals achieved, the ROI, and the KPIs, along with a recommendation for implementation into production. If the POC fails, you should conduct a project “post mortem” to determine what went wrong and then present a summary to management. In both cases, you achieve closure for the POC project.
7. Set your investment levels
If your POC is successful, and management is on board after your presentation, it’s time to scope out the project implementation into production and determine a budget. Your vendor can provide costs for its solution, but it’s equally important to get finance involved, as it can produce true costs of ownership and assist you in preparing for price negotiations with the vendor.
8. Transition the POC to the active projects list
Once you’ve chosen your solution and obtained budget approval, it’s time to move your POC to the active projects list and set a timeframe for implementation.
