COTS Selection (You Make The Call)
This is a two-part post which originally appeared on August 27 and on September 1, 2010 on BetterProjects.net.
Part 1
Its time for yet another installment of our favorite game here at BetterProjects.net, You Make The Call! The rules are simple… we’ll present a situation that is based on a real life project with which we have been involved. If you think you have the answer to the situation, post your thoughts in the comments section at the bottom of the blog. A few days after the post goes live, we’ll add a new post with what we did and if that solved the problem or not. Remember, the answer may involve a technology component, but it will not be solved solely by technology.
COTS Implementation
Your CIO has recently received a great deal of negative feedback about one of the applications that nearly all of your internal customers use on a daily basis to complete their work. This application was developed internally and is highly customized for that business process and your organization. Most of this feedback focuses on the speed at which users can complete tasks and the age of the technology in question. Most stakeholders believe that a solution that uses newer technology that focuses on a touchscreen instead of keyboard entry would allow for faster throughput by users, resulting in a small labor savings and a large customer satisfaction increase.
Despite the dislike of the current system, its customizations and integrations with other corporate systems make it difficult to replace with a COTS (Commercial, Off The Shelf) product. Still, your CIO does not wish to develop another system internally when there are numerous COTS products that perform similar, if not exact, functions. You are instructed to initiate an RFQ (Request For Quote) process with the major vendors who have produce applications in this market.
Picking Up The Phone
You, being a person who keeps in touch with industry trends, know the major players in the market segment and start making phone calls with those vendors. Besides the standard information most vendors want to know, such as number of users, number of locations, operating systems used, etc, you also provide a list of functionality of your current system that you are looking to replace. You explain to the vendors that it is of critical importance that their systems replicate all functionality in your existing solution and that their product be able to interface to all your other internal systems.
As the vendor RFQs trickle in, you notice a disturbing trend… the cheapest of them is an order of magnitude greater in price than what it cost to develop and maintain the existing system since its implementation over a decade ago. While you know your legacy system is very specialized to your company, you are astounded as to the large number of development hours that will be needed for every one of the vendor systems to meet your needs.
Checking In
Now you are in a dilema… your CIO expects your findings to be on her desk by the end of the week and you know she won’t be happy with the price tags on the RFQs. What do you say in your report? Is there anything you can suggest to help lower the prices? What could you have done differently in the RFQ process?
Part 2
In an earlier post we presented you with a situation about a COTS (Commercial Off The Shelf) software package selection process. Here are some things that could have made this process better.
Square One
The first suggestion on improving the selection of a COTS product is the same as any internally developed application, namely a better understanding of the goals of the project. While your stakeholders feel that they could see labor and customer satisfaction increases with a new system, it wasn’t clear (intentionally) from the description that the stakeholders wanted a COTS package, only that the CIO preferred one. Was there a bias on the part of the CIO towards using a COTS package or did she think it just made more financial sense to go that direction? Asking additional questions during the initial discussion with the CIO would have been a good first step.
Next, why was a list of current system functionality given to the vendors? The CIO made no mention of wanting to try and replicate the existing system in a COTS package. If the users main complaint is speed and older technology, could the existing system have been enhanced to meet those needs quickly? The stakeholders did not say they were unhappy with the system as a whole, just those two aspects of it.
But a more fundamental question is what do the stakeholders need? If the existing functionality works for them, with the requested speed improvements, then it doesn’t sound as if they were necessarily unhappy with what the current system. If speed and old technology were ways users were expressing their displeasure with a product that was in reality more deeply flawed, only a rigorous review of the business processes in comparison with the system processes will find the underlying problem.
At its core, not enough questions were asked. The price tag returned by the COTS vendors were set very high as recreating an unknown system on top of their product is not usually cheap. Such a high price tag is a method vendors use, and rightly so, to provide incentive for clients to reassess their request and frame the conversation in terms of actual needs and not just a functionality list.
What other thoughts do you have on this situation? Have you been in a similar place yourself? Let us know what you did in the comments.