Buying Software

Print

1. Best Practices Approach to Buying Software

Written by Al Kenney on Tuesday, 01 May 2012 16:07.

Software selection is science, not an art. It is a solid process with a beginning and an end. Many companies continue to struggle with this issue.

Virtually every reader has heard of or been involved with at least one software purchase “horror story” in which the software either didn’t work as advertised, or never paid out. Software vendors always get the blame, but is it really their fault? Buying software is a two way street. A successful deployment will involve an equal effort on both sides. Many companies buy a software product such as TPM or analytics and honestly expect it will implement itself… It won’t.

The return you get from enterprise applications is in many cases a direct proportion to the preparation, process, and people power you put into it. If you buy it correctly, software will be an investment that will provide your company a substantial return year after year. But in my experience, most companies still look at a software purchase as an expense without the belief of any financial returns. In fact monetary returns can be quite large, but again you have to set the table correctly in order to see them.

Having spent the better part of my 25 year career in the CG vertical, I have learned much about the software business from both sides of the desk. I have seen many mistakes being made with both sellers and buyers, most stemming from lack of preparation. As you read my comments, keep in mind I am talking in generalities and percentages. There are always exceptions in every situation, so my comments reflect the majority of cases I have personally come in contact with (50 or so large software sales).

Print

2. Recognize You Have a Problem

Written by Al Kenney on Friday, 01 June 2012 16:07.

This is the second part of a series on buying software.

Houston, we have a problem. Recognizing that your current process is broken and/or your current software application is not efficient is the first step to admitting your organization has a problem which needs to be addressed. I can say beyond a shadow of a doubt that if you are currently utilizing Microsoft Excel to handle any process, you need to be looking yesterday. No matter how much you “dress up” Excel, it can’t replace an enterprise application.  Also, if you are requiring that your sales force send in reports which you have to tally and distribute, it’s also time to begin your search.

Is an internally built product best? For any company thinking about creating their own application based on a recommendation from their internal IT personnel, I can tell you that unless you have extremely talented people with this specific type of build and support experience this is a very bad idea.  Yes, there are some exceptions I have seen that are working, but this is the extreme exception.

Print

4. Write a Specific RFP

Written by Al Kenney on Wednesday, 01 August 2012 16:07.

Once you have completed the documentation of your current environment, you must fashion those needs into an RFP which should be sent promptly to your prospective vendors. Putting together this document is vitally important.

You must define your project and what issues you will be looking for the vendor to solve. Ask questions in key areas such as:

  • Technology
  • Integration
  • Experience with this type of product and functionality
  • Future product direction
  • References
  • Financial viability
  • Implementation process and planned team
  • Upgrade plans
  • Project risks
  • Ongoing support
  • Estimated fees & costs over 3 year period (more on this later)
Print

6. Whittle Down the Field

Written by Al Kenney on Monday, 01 October 2012 16:07.

It is important that you use the responses to your detailed RFP as the major decision making factors to whittle down your vendor list. Use other resources such as analysts to fill in the blanks on the second go around for vendors.

Do not use reader polls or other ranking services to do this. Remember, you are judging each vendor based on how they match up against your current and future needs (3 years out) and not much more.

I recently was told by a potential customer that they used the CGT “readers poll” vendor rankings as one of the main criteria to get to their final 5 finalists. I pointed out to them that these rankings are based solely on a popularity contest, meaning that readers were asked to rank vendor solutions. Keep in mind that each reader does not have first hand experience with all vendors on the list; therefore the more well known applications would logically score best in the rankings. This will leave out some very capably vendors with excellent solutions which might be perfect for your company.

Print

8. What Should be in the Contract?

Written by Al Kenney on Saturday, 01 December 2012 16:07.

Your contract is the agreement between two parties on what was purchased and how much things will cost. Yet, I continue to be amazed on what items don’t make this all important document.

The first thing that should be done is to reference the vendor’s final vendor responses in your legal document! It actually protects both parties and eliminates any confusion going forward.

Keep in mind that many vendors modules are intertwined, this means that during a demo you might actually see functionality that is not part of the module they are selling you. There should be no gray areas in the contract. List out the functionality you believe you will be receiving and be specific. Too many contracts go out the door saying you bought “our trade funds module”. Even if they have a version number make sure the functionality is documented (modules always evolve).

Print

10. Measuring Progress and ROI

Written by Al Kenney on Friday, 01 February 2013 16:07.

Based on my experience with approximately 60 companies the past ten years, 90% of companies who have bought software never even attempt to measure their progress or ROI.

This is an absolute must for all software implementations. This step needs to be completed and right away.  You can start by requiring all your potential vendors to present you a proposed ROI. Look to see the areas where they believe they will generate savings. This is definitely an area where you can compare vendor ideas. Ask them to leave you their numbers. Use this as the beginnings of your measurement criteria. You must first know your starting point then pick the areas which you plan to measure. Ask each vendor how they plan to help you measure your progress and ROI. Ask for case studies of successes with past clients. The key is to come up with measurement criteria and KPI’s which you will update on a monthly basis.

Ask what process the vendor is using to help them measure their products return on your investment. The fact is, every vendor would like to measure your ROI due to the fact they know documented savings with their customers will enable them to sell new customers faster. The problem is that many vendors are so used to having their customers push them for the fastest implementation times possible, that they have forgotten how to assist you in measuring your savings. I recommend this as one of the first topics to address in your first implementation meeting.

Print

3. Document Your Requirements

Written by Al Kenney on Sunday, 01 July 2012 16:07.

In the second part of this series I noted that recognizing that your current process is broken is the first step to admitting your organization has a problem that needs to be addressed.

The very next thing to address is document your infrastructure, processes & requirements. One thing that has always amazed me is approximately 70% of all buyers who are actively looking for a software solution to solve a problem, have not documented these important items. This is a huge mistake for several reasons. The old adage “if you don’t know where you are going, any road will take you there” couldn’t be truer. Without detailed documentation of your current environment and needs, you will have no framework by which to judge your potential solutions! I can’t tell you how many times I have sat in front of potential buyers of my software asking them what they are looking for, only to hear this response “we are not sure what we need, so we are looking at everything in the hopes of getting a few ideas”.

Print

5. Implement an RFP Rating System

Written by Al Kenney on Saturday, 01 September 2012 16:07.

Once you have a good RFP developed, you should implement a ratings system for each area and each question.

Decide what's most important to you and follow these steps to create your rating system.  This gives you an easy way to see how the vendors stack up:

  • Apply percentages within each key area of your RFP for example; technology counts for 30%
  • Within each area of the RFP rate each questions (i.e.: question #3 within the technology area counts for 20% of the overall score in that area)
  • Rank vendors responses once based on their written RFP response (to get down to your top 3), then again when the vendors come in for their product demos
  • Keep track of how each vendor deviates from their initial score (bad sign if too much, as they either did not understand your questions or are being deceitful)
  • Make sure you include a separate line item for “ease of use”.

One major mistake companies make in their RFP process is not giving the vendors enough time to reply to them. Vendors need to be given about 3 weeks to respond to a detailed RFP. In my personal experience, software companies are usually given little more than a week.

Print

7. Making Your Final Decision

Written by Al Kenney on Thursday, 01 November 2012 16:07.

At this point you should have all the information you need to make your final decision. Making your final decision is a combination of many factors. If you have run your process correctly, you probably have a clear winner.

Remember, in the end think ROI not initial price and you won’t go wrong. As I said earlier, the most important thing you can do now is make a decision. This will allow you to keep your momentum going when everything is fresh in both your people and the vendor’s minds. Move quickly to your most important step which is the implementation.

Stick to your ranking system and don’t let other outside factors impact your decision. I’ve seen it over and over, buyers selecting a software vendor putting too much stake on who can implement the product fastest because they have run behind on time. While it is important for the selected vendor to be able to implement in a “reasonable time period” with excellence.

Print

9. Do it Right or Do it Over

Written by Al Kenney on Saturday, 01 December 2012 16:07.

Congratulations you’ve made a decision, now the real work begins. Implementation is where the rubber meets the road.

By far the most often made mistake by software buyers is not allowing enough time for proper implementation of the product you have purchased! The scenario goes something like this; Company “A” spends 8 months selecting a software vendor then allows only 4 months for its implementation because they are behind on time. This is the norm, not the exception. It is a recipe for disaster that plays out in our industry hundreds of times each year.

Remember, virtually all of your ROI will be determined in your implementation phase. This is where you should be challenging your current processes and trying to streamline and automate most of it. A manufacturer must dedicate the internal resources to do this right. You must not only challenge the way you are currently doing things, you must set measurement criteria to track your progress and returns.

Print

11. Keeping the Momentum Going

Written by Al Kenney on Friday, 01 March 2013 16:07.

Once the software has been implemented I would suggest a celebration dinner paid for by the client. Congratulations!

If you followed your process closely chances are you have chosen the right software, implemented it close to your timeline. Now you must continue to benchmark and measure your savings. The key now is to continue to adjust.  This is an ongoing business relationship so expect at least bi-annual business review meetings with your software vendor. If this is not part of their current process then make it part of yours. And please, don’t let senior executives get disconnected from these meetings as they are of the utmost importance.

In summary, there are many great software vendors out there both big and small with many great products. Many times the buyer is the key to get the most return from their software purchase. Remember this is a partnership with two equal parties. Working together as a team and leveraging industry best practices will almost certainly result in good ROI returns.

My Best Practices “top ten” for enterprise software buyers:

 

  1. Learn how to recognize you have a problem
  2. Assign a dedicated internal team
  3. Document your infrastructure, processes & requirements
  4. Produce a very specific RFP
  5. Define a ratings system and stick to it
  6. Do your due diligence in all areas
  7. Make a decision
  8. Put together a very specific contract
  9. Challenge all your current processes and accept change
  10. Set ROI measurement criteria from the beginning