So you found a third party application that you like. The vendor tells you it will meet all your needs, you liked the demo, and you are ready to hand over a substantial amount of money. But are you really ready? You need to balance the benefits with the risks. Let’s say you buy the application and a couple months down the road you find out the application is missing a critical piece of functionality. How about you implement it and it doesn’t fit within your current technological architecture or processes? How about the current data doesn’t fit within the new system? Or maybe the application doesn’t just flat out work? The list of scenarios is endless.
The point of these questions is that you need to ask the vendor, what happens if we are having trouble making this work? Good vendors will offer to develop application changes and bring staff engineers to your company to ensure their product meets your organization’s needs. The purpose of this is to ensure that you aren’t left owning a bad application that can’t meet your requirements. Also, see if you can run a proof of concept or pilot implementation using a temporary license. Create a test case with a small sample of users and data.
There is low risk and high reward in taking an application for a test drive. Now, if you are thinking that, “this is a waste of time”. I have another question. Isn’t it a waste of time, money, and resources to implement a full blown enterprise application across the organization and not have people use it and lose exponentially more valuable time and money in the process? Let’s say your application costs one million dollars. For about $25,000 in labor and resources, you can see if the application in a proof of concept test will work. If it doesn’t, you are only out $25,000 vs. the one million dollars that you would’ve lost in a failed enterprise rollout. If it does work, you have a functioning baseline environment to compare against and an internal knowledge base to use for the enterprise implementation. Next, make sure you have assessed the requirements of your users and IT staff and the scope of their needs. The application should meet their needs. Lastly, make sure the application will be compatible with your infrastructure.
Subscribe to:
Post Comments (Atom)
This reminds me of my wife, who calls herself the "queen of returns." She doesn't buy anything without trying it on, and then the sale isn't final until she is completely satisfied. Only then does she throw away the packaging and sales tags.
ReplyDeleteIt goes without saying that she will not shop at any store that doesn't have a liberal returns policy.
Should a business be any different? The vendor might think that if the project fails, the buyer should have done a better job of assessing needs and so forth, as David outlines above. But a part of that process is making sure the relationship between seller and buyer is clear -- including the policy on returns.