Look What I Found! It’s The Greatest! We MUST Have IT!

You saw a GREAT new customer relationship software product at a trade show. “This is the greatest thing since sliced bread!” You send a quick “we have to get this” note to you techie via your blackberry. You set up a meeting between the product salesperson and your Chief Techie (Chief Information Officer).

Chills just went up and down your techie’s body. Horror and panic just hit your Information Technology department. “Oh no, another product that we’ll have to force into our systems. We’ll have to modify other systems to get it to work with this thing. Then we’ll have to support it!”

Nothing causes more friction between business and information technology that this scenario. Interesting, it can easily be avoided with little effort by the business community.

Let me give you a little background. Software systems come in two basic categories. One that is built just for you and the other is purchase and installed.

Software that is built just for you is either built in-house or by an outside organization. Either case, the software is built to meet your needs. This was the only way software was built decades ago. It is costly and time consuming and may no longer be necessary.

With business processes become standardized, software packages and products exist to support common business functions (such as customer relationship management products). Commercial-off-the-shelf (COTS) software or package is becoming increasingly popular. For example, multiple customer relationship management products are available. Why reinvent the wheel!

Technologists concern is the need to incorporate the package with existing software systems. Techies have to worry about licenses, implementation, rollout and continual support.

The business does not need to make the choice to build or buy software. The business, however, does have to define what they want the software system (customized or that new product) to do. If a software package meets 80% of your “I really need this function” requirements, it is quicker (in most cases) to buy and implement the software package. Not that implementation will automatically be easy. Bridging different software packages so they “talk to each other” requires careful planning and bridges need to be built between them. This is not always so easy to do. It will add to the cost and time to get the package up and running.

If your requirements are so unique, it is easier to build it from the ground up. It all depends on the uniqueness of your requirements. This approach is usually easier to have the system integrate with all your other systems.

The crucial point is to define your requirements BEFORE saying “Hey, this software is great. Let’s buy it and implement this.” Define what you want from Information Technology FIRST. Then go look if your needs can be satisfied with software packages. You can tell your technologist about a tool you heard about or saw at a presentation, but include with that a list of what functions you need.

• * Let the technician be part of the evaluation process.
• * Let the techies show you all the work (and cost) that will be involved in incorporating the new package with the others.
• * Let them explain the total cost of the rollout and maintenance.
• * Let them show you two other options that may be more cost-efficient and satisfy at least the same functionality requirements or more. You may be able to get the new functionality with a simple tweak of a product you already use.

You owe this to the business to find the best least-cost (which includes customization, rollout and ongoing support) solution. If the product is the best thing since sliced bread, you will have the backing and support of your technology department. The techies will help sell your new idea to management. The techies will be just as passionate and the process and installation will go smoother than if the package is forced upon them.