C.O.T.S.

It has long been known that just about everyone thinks that they can build a better mouse trap. Indeed, several in fact have. That is where innovation comes from. By building something better than what currently exists, a competitive advantage is created. It is usually a short-lived advantage as there are many others that are always also trying to innovate as well, who will either copy, or actually improve on the new design.

Add to this, the question of whether you should actually make your own better mouse trap, or buy someone else’s better mouse trap, and you have the makings for a reasonably spirited discussion. Remember, not everyone is in the same mouse trap business. So, do you invest in developing your own, or do you just go out and buy somebody else’s, already complete? However, when it comes to your own business systems, processes and tools, the decision should be very simple.

Unless you are in the tool and system business, never, ever, ever make your own tools and systems.

The tools and systems within an organization usually fall under the purview of the Information Technologies (IT) group (or some derivative thereof). The IT group can be staffed with some of the finest and brightest people in the organization. But everyone must remember, that unless you are in the IT services, tools and application development business, that is not the business that the organization as a whole is in. IT is then not directly associated with the products and services that the company positions as best in class and sell to its customers. It doesn’t develop them. It doesn’t sell them.

If IT based tools and systems are not the organization’s prime business, then investing in their custom development should never make sense. IT should then be treated as an administrative expense that is required to be spent in order for the organization to maximally leverage the available technology in the pursuit of its business goals, not a tools and systems development organization.

With this definition and positioning of IT in mind, I’ll now delve into the issues that almost every organization now faces when it comes to leveraging available technologies and how to be more efficient at it.

Over (a long) time I have had the opportunity to witness several different businesses and organizations try to utilize their product development capabilities to develop what has come to be known a “Multi-Tool Product”. This is a product that is supposed to do everything. It is designed to be all things to all customers. Instead of buying four different devices to serve four different purposes, you can buy one device to do all four.

And every time I have witnessed this type of product development attempt, I have witnessed what can best be described as failure, and worst described as abject failure.

There are two primary reasons for this type of Development failure:
1. The time and expense associated with this type of development is always, always much longer, much more complicated and much more expensive than ever budgeted or even imagined.
2. The functionality of the multi-tool product is never, ever good enough, nor delivers enough value to unseat the individual discrete products that it is competing against.

I like to tell the story of attending a multi-tool product development review some many years ago. The review was opened by the product manager stating that it had been eight weeks since our last formal review, and that unfortunately due to unforeseen development complexities, product availability had slipped twelve weeks in that time.

I commented that since it seemed that we were now falling behind faster than time was passing, that the only logical thing to do was cease development now so as to fall no further behind.

I was never invited back to another one of those product reviews.

The product however, was never completed nor released. It was quietly shelved many months, and millions of dollars later.

As to multi-tool product functionality. It may be time for another Gobeli Postulate on Product Development. It goes:

1. A product that is purported to be able to do everything, will do nothing very well.

Individually developed products are each optimized for value and performance. They are targeted at being the “best in class”. Multi-tool products by their very structures cannot match this. Each individual capability in a multi-tool product must carry the product cost and functionality overhead of every other capability in the multi-tool product.

This is equivalent to the Swiss Army Knife example. It may have a knife, screw driver, spoon and scissors, but none of those attributes are as good in comparison to a separate standalone knife, screw driver, spoon and scissors. And you must pay the added expense of the housing and overhead that is required to combine them all into one device. Invariably the four different best of breed items can be bought for less than the single, less functionally capable multi-tool product.

Okay, so what has all this got to do with IT?

Part of the average IT group’s responsibility is to create / select tools that will enhance the systems and automation of the business organization, their customers. It must be remembered that IT is a support group. They exist to provide functionality to the business.

This is contrary to some IT departments I have witnessed who appeared to believe the business existed in order to fund them.

Most internal (not out-sourced) IT tools groups think that they can create tools, capabilities and applications that are far better than what can be purchased in the market. They believe this due to their increased knowledge and proximity to their very business specific support needs. It is their focus to create tools and systems that deliver ever greater functionality and capability to an ever-greater number of people.

In short, they believe they can create better Multi-tools.

This is not always the case, but I think we can all probably remember instances where a perfectly functional and eminently usable tool was replaced in the name of “integration” by a tool that had greater integration with other systems, but lower functionality than the tool it replaced.

So here is where we get to the Title of this article: C.O.T.S. – Commercial Off The Shelf.

“Commercial off-the-shelf or commercially available off-the-shelf (COTS) satisfy the needs of the purchasing organization, without the need to commission custom-made, … solutions … Although COTS products can be used out of the box, in practice the COTS product must be configured to achieve the needs of the business and integrated to existing organizational systems.” https://en.wikipedia.org/wiki/Commercial_off-the-shelf

Please take note of the word “configured” in the above definition. It does not say “customized”. IT provided tools and systems should be configurable to handle multiple applications across different business groups. They should not be customized into different discrete tools to address each group.

There are organizations in existence whose business model is to create tools for other companies and organizations. In order for them to grow and flourish they must create best in breed tools for their specific applications. They cannot create all the tools. Only those types of tools that they are experts in.

That means that in order to get a full suite of tools to address all the business needs of the organization that the IT group serves, they will need to deal with multiple tool supplying organizations.

IT is usually a technology oriented group. External tool providing companies will usually provide tools much faster, better, cheaper and with greater functionality than anything that an internal tools group could create. However, working and negotiating with external businesses is not very technical in nature, which is somewhat out of alignment with the desired direction of most IT Tools groups.

They want to create and develop. Not negotiate and buy.

Many companies have created their competitive advantage by developing their own “better mouse trap”. This self-reliant development mentality can easily bleed over into the IT group when it comes to the tools and systems. Senior management can also be receptive to the IT tool and system development siren song, since that is how they were able to achieve success as a business.

However, management needs to remember that regardless of what they may think, or be told by IT, their business systems and tools needs are probably not so unique as to require custom tool development, but more likely just need the proper configuration of a C.O.T.S., best in breed, already available tool or system. This solution direction will invariably lead to simpler and faster implementations, as well as a lower cost of ownership and sustainment across the commercial life time of the tool.

IT will almost always be the owner of the make / buy analysis when it comes to tools. Building your own multi-tools will almost always be a slower, more expensive and lower functionality alternative to buying C.O.T.S., regardless of what the IT tool development group may want or think. Especially if your business is not the tool and system business.