This may seem obvious to some readers but I haven’t seen a good list of considerations to help ensure a successful PoC project. Here are some training wheels to make sure you don’t crash and burn.
- Lack of requirements – All key stakeholders involved should sign off on a detailed requirements document. It doesn’t have to be in blood, an email response with a “yes” will suffice unless there are contractual obligations. I hear, “We just want to see if it will work” all the time. When you’re doing a PoC, be as specific as possible in defining “IT”. Unless a solution is completely unbaked, think about how you would envision it working in your environment. Talk to people and ask them how it works in their environment as you come up with requirements. Be as transparent as possible with the vendor so there is no hidden agenda or confusion.
- Lack of a leader – Designate a lead. I’d be rich if I got a nickel for every PoC that failed because of a lack of a leader. You need someone to keep track of the requirements, vendor involvement and testing. PoC’s are easy to get lost in the fray because there aren’t obvious penalties for the customer who doesn’t see a PoC through. Conditional PO’s instead of freebie PoC’s are becoming more common.
- Lack of experience with the product – Let the vendor show you how a product was meant to be used. If you’ve never touched a product before, why would you want to run a PoC all by yourself? Seriously, your parents had to teach you how to velcro your shoes. Which leads me to the next point that comes after someone says “We couldn’t get it to work this way so we tried X, Y and Z”.
- No documentation – Document your setup and any changes as they’re made. There are a ton of variables in your environment, document them. I can’t stress this enough. First make sure you deployed the product according to best practices. If you need exceptions then run them by someone who knows what they’re doing and note them.
- Not asking for help – If you must, call and allow time for help. Yes, you might anger someone but it’s worth calling in for help before declaring a project a failure. I can’t promise that a white knight will come in and save the day as the deadline for your PoC approaches but call for help anyway.
When I come in to help out with PoC’s that are in trouble in their 11th hour, two things are usually immediately apparent. First, there was no leader or everyone went off in their own direction without accountability. Second, there was a lack of familiarity with the product. This list isn’t for my benefit, it’s all to help others have successful PoC’s. If you have suggestions, send them in!