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.
Saturday, March 21, 2009
Saturday, March 14, 2009
Wait Loss
What do weight loss solutions and third party applications have in common? More than you think. The other day I was listening to the radio and I heard an ad for a weight loss product that promised to help you lose weight. It promised to do this without the need for you to change your dietary and exercise habits. I began to reflect on the same promises I have heard from third party IT application vendors. I’ve heard promises stating that their products can help improve their operations, profitability, efficiency, and so on. But again, what is conveniently absent is the need to change your processes and/or business habits and putting some effort into its implementation and administration.
I bring this up because recently in a class I’m taking, we were talking about the processes that organizations should follow when they adopt a new technology and implement it. Factors that organizations like to discuss are what is the cost benefit, how more efficient we could work, or how new and cool these applications are. So without much thinking, the organization spends millions on an application, without giving much thought to a specific question. What are the risks of implementing this solution? You might be saying, that’s obvious…..right? Well, try Googling “Failed Technology Projects”, and see what comes up.
Millions of dollars are spent each year on technology projects that fail. Do you think that the employees at these organizations one day got out of bed and said, “Boy, I can’t wait to attempt to implement a hopeless million dollar boondoggle?” Of course not. But, what they probably did was enthusiastically embraced a brilliant and noble notion of improving the organization and figured that proceeding to purchase a readymade third party solution based on a presentation and a short demo will be the answer to their problems. There are steps that should be taken before you hand over a signed check to an IT vendor. You should be excited to improve your organization. But at the same time, you need to take a step back, wait, and analyze the situation. Like in weight loss products claims, the claims of organization improvements through technology solutions may prove to be deficient. In future blog posts I’ll address what can be done to improve your chances of implementing a technology that will be successful.
I bring this up because recently in a class I’m taking, we were talking about the processes that organizations should follow when they adopt a new technology and implement it. Factors that organizations like to discuss are what is the cost benefit, how more efficient we could work, or how new and cool these applications are. So without much thinking, the organization spends millions on an application, without giving much thought to a specific question. What are the risks of implementing this solution? You might be saying, that’s obvious…..right? Well, try Googling “Failed Technology Projects”, and see what comes up.
Millions of dollars are spent each year on technology projects that fail. Do you think that the employees at these organizations one day got out of bed and said, “Boy, I can’t wait to attempt to implement a hopeless million dollar boondoggle?” Of course not. But, what they probably did was enthusiastically embraced a brilliant and noble notion of improving the organization and figured that proceeding to purchase a readymade third party solution based on a presentation and a short demo will be the answer to their problems. There are steps that should be taken before you hand over a signed check to an IT vendor. You should be excited to improve your organization. But at the same time, you need to take a step back, wait, and analyze the situation. Like in weight loss products claims, the claims of organization improvements through technology solutions may prove to be deficient. In future blog posts I’ll address what can be done to improve your chances of implementing a technology that will be successful.
Subscribe to:
Comments (Atom)