When selecting asset management systems or solutions, buyer’s remorse is not uncommon. The software demo was wonderful, the RFP promised everything that was wanted, but the day-to-day ride and frequent repairs are rough to deal with. In the world of asset management, how do we avoid buying a “lemon”? Like Colleen Devine recommends in her blog “Take it for a Test Drive,” the solution is take it for a spin until you are sure it is right. Don’t settle after the RFP—help ensure that you make the best selection by running a proof of concept (POC) before signing on the dotted line.
Although the POC is far from a new idea, in recent years it has become more prominent in investment operations. A POC is often referred to by other names such as business simulation, smoke test, model office or capacity testing, but these are essentially all ways to make sure the system meets your needs.
There is much more to properly setting up and running a POC than can be covered here, but following are a few tips to help your POC provide the proof that is needed to move forward confidently:
Secure stakeholder support.
POC efforts require real investment and commitment. If the decision makers at your company don’t accept this upfront, you will find your POC quickly undermined by resource and schedule conflicts.
Determine and prioritize key objectives.
It can be tempting to try to test everything at once, but this complicates the process and, in worst cases, can doom the POC to failure. Key variables need to be isolated and other aspects held constant. Changing priorities as you go can throw you off track and keep you from getting to your destination. If there is more than one set of key issues to discover, it may require additional stages of the POC.
Size the effort properly.
Some POCs may be a quick test drive to make sure the wheels don’t fall off and the engine has some power, but other POCs may be more like renting the car for a few weeks to make sure it is truly the right one. The greater the complexity and cost of the system or process involved, the longer and more involved the POC may need to be.
Budget for success.
Expect to pay vendors appropriately for their participation. If you push the vendor to provide the POC resources for free, you risk getting what you paid for in results. There are also significant internal time and equipment costs that should be budgeted for. If you are going for more than a short test drive you can expect to pay some rental, gas, and maintenance costs; the same is true of your POC—it won’t travel the distance on fumes.
Be pragmatic and flexible in assessing results.
POCs by nature tend to be aggressive and push the envelope on what can be configured and tested in a short time. A POC is extremely valuable in increasing confidence that a process or software is suitable to task, but it will not match what the system will look like after an implementation that takes months, or even years, to complete. Be realistic about what the POC can and can’t do.
Capture requirements as you go, but don’t change course.
Make sure to document new requirements that are uncovered as you go through the POC but don’t keep jumping to the newest thing. Some requirements that are in harmony with the POC may be added without derailing the effort, but care must be taken not to change course so often that you don’t make it to your destination.
In our industry, technology projects are often massive undertakings and leave “sticky” applications within the organization. It’s critical that any new system being implemented has been thoroughly tested so you’re not facing a pull-out after investing significant resources in implementation, training, and the cost of the software itself. Like a thorough test drive, a well-structured POC will not only give you the assurance to buy but can help pave the way to your final destination.
Comments