In recent years we have seen the pace of change pick-up significantly in Enterprise IT. Technology is no longer on the periphery; it is part of a businesses' strategic goals. Innovation is critical for success and utilising technology for the core goals of the business is of huge importance. This has seen a rise in the Proof of Concept (PoC)
A Proof of Concept is a means of bringing a vendor's product into your business to make sure it works in your environment, functions in the way it is being sold to you, and works natively within your infrastructure. It is an incredibly important step in purchasing and implementing new technology. You wouldn't buy a new car without a test drive. You need to try before you buy, in your own environment.
A PoC is a useful step in the purchasing process to ensure theories and ideas can be run in practice. Not every new technology needs a PoC, but where they are done they bring huge benefit in motivating the business--seeing is believing. Additionally, PoCs can also reduce the risk of project failure, while also further refining the scope of a project, enabling a deeper understanding of what is possible before jumping in head-first. PoCs ultimately give assurances the business needs to progress.
PoC--the path of least resistance
Before starting a PoC, you need to have clear objectives and key questions determined ahead of time. Its success depends on having these things tied down. Along the process, these objectives and questions you are looking to get answers on need to be constantly referred back to. Don't be hoodwinked into getting something to work for the sake of it. Moreover, more political capital is staked on the success of it, as the costs begin to mount up. IT directors need to guard against these dangers by putting in place the right governance structure with strong project management, to keep the team focused on the right questions, in the right timeframe.
Recipe for success
The Proof of Concept should take a relatively short space of time and require only a modest investment. It should represent a fair test of the system but not an exhaustive one. It should be enough to prove the system can work and answer key questions about how to design and deploy it, as well as how to configure it to make it work for the business. Above all, it should attempt to show whether the product can deliver all that it is expected to.
The PoC should be built in a self-contained environment that is kept separate from...