Buying Software – Secrets they don’t want you to know: The “guarantee”

I’ve been in application solutions for manufacturing since the 1970′s.  I’ve sold mainframes; I’ve defined packages for sale on Minicomputers; I’ve been in marketing and support; and I’ve spent years working alongside customers installing and supporting MES systems.

It really irks me when I see an otherwise very intelligent customer get bamboozled by marketing hype, and spend millions of dollars on the wrong solution!  So I am breaking with the magicians’ union (so to speak) and will share with you over the next several blog posts some of the secrets that, once you know, can help you make better decisions on software solutions.

I will share with you strategies and anecdotes that may help you in your decision process.

Certainly if you are dealing with a smaller company, you are important to them.   I can tell you that every customer that QIC supplies is important to us.  Our large multi-plant implementations are extremely important to us.  Our single plant, single line customers are just as important. If we guarantee something, we will make good.  We can’t afford to lose the customer, or go to court.

But when you are dealing with a huge vendor, the same is not necessarily true.  If you have invested millions of dollars and years of employee time in a new ERP system, are you really going to sue the huge multinational software vendor that guaranteed it would work?  They have deeper pockets, specialized software savvy lawyers, and probably have covered themselves 10 ways in the various correspondence and contracts.  And you have a business to run, and a disaster to recover from.  Unless you are hooked on the principle, you will back off and lick your wounds.

I have heard so many stories about software purchases, ranging from misleading information to outright lies and impossible guarantees.  And it happens to everyone.  When we upgraded our CRM software, we upgraded from a package we had been using successfully for 10 years.  We upgraded to get 4 new features that were crucial to us.  We were guaranteed these features worked great.

What happened?  The features were there, but didn’t work properly.  We paid the support fees because the next release was going to fix the problems.  We stopped paying for support when the 4 calls we made about these problems were still open issues years later!  Now, almost 10 years later, apparently the next release fixes two of the issues.  We are changing to another CRM that has the functionality.  We went from a huge supporter of the software to its biggest detractor… but that doesn’t help us with the solution.

Unfortunately, some salespeople lie. In our experience, the leaders in software seem to be “fact challenged” more than many of their competitors.  Maybe this is how they got big? Or maybe it is because the salesperson at the huge software company does not have the intimate product knowledge found in a smaller company.

Is there a solution?  Sure, and ths is how you can reduce the risk.   You need to know your supplier and trust them to have your best interests at heart.  Deal with salespeople who will still be there AFTER the sale, and not fob you off on “a team of specialists” (which is a euphemism for “got your money, goodbye”).  Look for answers like “I don’t know, but I will find out for you”;  “what do you mean by….” ;  and “there are a couple of ways we can address that”, and “No, I am sorry we don’t do that”.   These all indicate that the salesperson knows your issue, knows her product, and wants to be sure that her information is correct.   The most dangerous words you can hear are “Sure, no problem”….  “that is coming in the next release”….

Or my favourite from a software demo given to a candy company “pretend your candies are car parts…..”

What Box?

Henry Ford is credited with saying “If I had asked people what they wanted, I would have built a faster horse”.  Even though the Harvard Business Review disputes that Ford ever said this, it is still a valid reflection of a philosophy shared by Steve Jobs – people don’t really know what they want.  They often don’t realize the possible solutions to their problems.

At QIC, we fully embrace that approach.  Even though it often makes our job more difficult, it inevitably achieves better results for our client.  Have you ever noticed how most people tend to define their problems in terms of the solution:   The problem isn’t “I need to get my 4 kids to Tuesday soccer practice”; it becomes “I need to buy a new minivan, because my 4 kids have soccer every Tuesday and I need to drive them.”

At QIC we try to elicit the root cause, and then go to work on a solution.   Clients sometimes think we did not understand them when they explained the problem.  Usually we heard and understood too well.  Some call this “thinking outside the box”.  I prefer to deny the existence of the box – it restricts creativity.

In the minivan example, there are alternatives such as:

  •    Set up an account with a taxi / transport company;
  •    Make arrangements with a neighbour;
  •    Get the kids new bikes;

all the way to

  •     Move next door to the soccer pitch; or
  •    Hire a nanny with a Maybach.

And yes, that would include “buy, lease, steal, borrow a new minivan, bus, 6 seat car or truck, etc.” which may be the right answer, or not…

We have had 3 scenarios in the last few weeks.  In each case, although the client came to us with a specific, very expensive solution they expected from us, we came at the problem from an entirely different direction.

In one case our solution cost about the same as what the client asked for, but could be done with far less complication, planning and personnel.

In a second, we actually proposed a completely different software package that will cost less in its entirety than the cost of just support on the existing solution – the most interesting thing is that the two software solutions are as different as Word and Internet Explorer – not even the same kind of solutions.

In the third case, although the client wanted to replace their existing system, at some considerable expense, we recommended they continue to use the existing system, which worked exceptionally well, and add a new component that allowed them to do the analysis that was missing.  This results in far less change management, and accomplishes everything the client expected to gain after years of rebuilding their environment in a new, expensive software solution.

So the next time you hear yourself say “We need a… because …” pay close attention to the “because” clause… that is probably where you find the true problem definition.

Getting new software – Make or Buy?

This is a huge question facing every buyer of software today.  Why does Joe, the owner of Joes Baked Goods LLC, a $100 million bakery thinks he can hire his brother-in-law’s son “the geek” for a summer and have the same Manufacturing Execution Tools that others have paid hundreds of thousands for?   If it was that easy, as they say, everyone would be doing it.

There is no question that with the tools and technical expertise available today, many solutions can be built in-house [and some should].  But, these should be very specific, very contained, very well defined, very organization-specific, and/or very confidential solutions.  They should be single-user or at worst, workgroup solutions.

To even consider building an integrated enterprise solution today should be met with a great deal of skepticism by management.

In most cases today, there is a well-written, well-supported, fully-featured parametric package out there that will do what needs doing, and much better than anything you can build – even given unlimited time and money.  Do you want ABC Biscuit Company to make the best biscuits; or to become the ABC Biscuit, Software & Computer Company?

Conversely though, your software often gives you a competitive advantage.  If the software supplier that is telling you how you need to run your process (because that is the way their software works) could run your business as well as you can, perhaps they should be in your business rather than software!  However, there is still probably another package that is adaptable to the way you do things.

So there are some unique circumstances when building your own, is a viable option – but that is usually where proprietary processes are involved, or you come up with a need that no one has ever automated before – unlikely but feasible.  The trick is to know the difference.

Remember the inevitable laws of software development, all of which are unfortunately true:

90-90 law :  “The first 90% of the software takes 90% of the time to build, and the last 10% of the software takes the other 90% of the time.”

Cheops’ Law:  “Nothing ever gets built on schedule or within budget.”

Brook’s law:  “Adding manpower to a late software project makes it later.”

Starting down the “we can build it, they will come” road is costly.  I have seen clients delay implementing a solution because they are going to write it.  Years later, they are still going to write it.  If they had implemented the package solution in the meantime, just as an interim solution while they were writing the panacea, they would have paid for the package several times over from savings.

Sure, $100,000 or more may be a lot of money to invest in a solution, even if it saves $500,000.  Perhaps putting a couple of junior programmers in a room for 6 months to a year will give you at least the basics you need in your business – you don’t need all the bells and whistles that the $100K package has.  So pay each of these guys just $60,000 a year ($120K), plus benefits ($30K), give them an office ($5K), development software ($10K), and computer horsepower ($5K), and give them unlimited access to the user community that they will need to develop a responsive package ($$$).  And get someone to write decent user documentation (about 30% of the cost of any system).

What most people don’t realize is that it is not the writing of the code that is difficult – exceptional coders are available – it is the ability to understand user requirements and translate them into workable system definitions that work in the culture and are supportable on current and future platforms – that is the key to success.  This is why sending the code offshore to be “developed” in India often fails.  In order for the Indian coders (who are very good) to write it correctly, you have to take the time to define it in infinitesimal detail – so now you need to add your time to the expense calculation.


At the end of the year I guarantee you will have a half-written, very basic single-user partial solution, and be out about $300,000 in salaries and expenses – not to mention the opportunity cost of not having a solution in the meantime. Even if the junior programmers produce exactly what you need in the time promised (you would be the first), you will still have spent $300,000 and lost a year getting part of a $100,000 solution.

So, to avoid this, you will decide to hire a “professional” consultant, or software developer.  You still need the detailed definition.  All you have accomplished is a restart, and a cost base of $100+ per hour, instead of $30.

I personally wrote my own Client Database several years ago.  Took about 6 months and did exactly what I thought we needed.  Single user.  Then we bought a commercially available CRM.  Cost about the same as the underlying database and supporting software for my custom system.  Had everything mine had, and hundreds of other features we could use, but I had not even thought of.  And it was designed for enterprise use.  No brainer!  We still use it.

At QIC we have developers on staff to perform integration for clients.  They are beyond programmers – for the most part they can define the details and understand the business processes behind the software.  If anyone is positioned to write our own, we are.  And yet, every system we use internally is an application package.  There is a reason for that.