Vendor Selection

The difference between the almost right word and the right word is really a large matter.
Mark Twain, Author

I am a big fan of COTS products that allow for extensive product configuration. I think that custom development has its place, but with the toolsets available to engineers now there is little need to have an entirely custom solution. I see the value in building specific modules. However, I believe that custom development solutions are less effective once the entire software lifecycle; long-term retention and updating are factored into the cost.

The COTS route also prevents a scenario where the mission critical system in your organization is 15 years old, runs on a legacy Novell server through IPX/SPX with a lone wolf system administrator who sits in the basement and is the only one who knows how it works. Here are a few observations on vendor selection.

Often, after all requirements have been gathered, documented and validated (a process that can take anywhere from a few weeks to months), the first stages of system design start to take shape. It’s a beautiful experience. All the engineering powerhouse brains start brainstorming and some vague representations of what it may look like in the end start appearing on airport bar napkins.

Regardless of the industry, the requirements are somehow communicated to third parties and something is expected in return, regarding how the requirements will be met and how much it will approximately cost. If a requirements matrix is sent out, it is a safe bet that any vagueness in requirement interpretation will allow each vendor to decisively declare that they meet that requirement and put a check mark next to it.

Since we are still in very early stages of solution design, a vendor bake off or a proof of concept may not be practical or may not fully validate how the requirements are met. As such, I have found it necessary to grill vendors extensively on how the product works, in order to find any deficiencies. Sometimes, I wish I had a lie detector that I could hook sales people up to, but since I don’t, I have to rely on my technical prowess.

Almost every software package has certain core competencies. That is, what the product does very well. These core competencies are usually the main focus of the company when it is first started, and are what the product is used for most of the time. As a product matures and existing clients make software change requests, the vendor tacks on additional functionality to meet those specific requirements. Most of the time, the added functionality is put in place with little afterthought to how it will be implemented. In addition, due to the competitive nature of business, vendors may tack on yet another layer of capability so that they can add check marks next to items of requirements matrixes. This is called sales functionality and is generally not suitable or flexible enough for most implementations.  In a nutshell, a product usually does about half of the advertised functionality well.

Usually, the adequate and sales claims functionality is actually present. However, the specific way in which the functionality is implemented may make it impractical for use, or may not scale very well to an enterprise-level system.

A practical scenario is a project where my team had to implement both a case management and business process management solution. One of the requirements was that cases and documents had to be routed via business logic to a user for approval. Naturally, most of the product suites we evaluated had this functionality. However, the way that some vendors implemented the routing decision was poor and did not allow for dynamic token selection. As such, their products would have required large data sets of If… Then… Else statements to decide which person the case had to go to. This was impractical for a system with thousands of users where dynamic routing decisions where necessary. Also, dynamic routing decision requirement could have been interpreted in so many ways that even If… Then… Else statements would have met the criteria on a requirements matrix.

Make sure that high priority requirements are in the core competency of the product.