The dark art of selecting your custom-software vendor

Usually I address a technical audience, but it’s about time I spent some time on you unfortunate people that actually pay for all that engineering that goes on. Why unfortunate? Because a lot of those custom software projects fail, for many reasons. Today I’d like to talk about one of them: not picking the right partner.

Suppose your organization has found a valid business case for getting custom-made software built. You’ve done some thinking into which problem the software should solve and now it’s time to find a company that will do that for you. Perhaps this is the first time you’re procuring a custom piece of software. This is a daunting task.  You talk to four or five companies and let’s say you go for the one that is almost the cheapest. You’re no engineer yourself, so you probably feel a bit uneasy talking to these people that tend to use a lingo you don’t understand. Never mind, you’ll get legal-assistance involved so you can protect your organization if these techies mess up.

And then they do mess up. And you’re now the owner of a software system that doesn’t work and is nowhere near completion. Few software companies seem be keen to help you out in reviving it. “Start over,” they tell you. Meanwhile ‘legal’ is going after the first vendor and you might get some compensation (50% of the sum is the best you can hope for). But your project is dead in the water.

So, you selected the wrong partner. And no wonder, it’s not like you order a piece of custom software on a monthly basis. So here it is:

To select a competent software constructor, you need a competent techie.

Sounds like a catch-22? It doesn’t have to be. I’m sure somewhere in your network somebody has had a project done that was reasonably successful. Make the lead engineer on that project a personal offer.

Enlist the temporary help of an independent software engineer that will help you make the right choice. A decent engineer can smell a faulty engineering-culture from a mile away. They may spend a day or two talking to your short-listed partners. They shouldn’t just talk to the sales rep or the management, but also to the people that will actually do the work. This engineer must not be involved with the actual implementation of the project and not make any choices towards technologies or tools that will be used during the project. That part will be left to the competent engineering team you select.

Here’s a non-exhaustive list of red-flags the competent engineer might use when probing a company:

  • The company is receiving or has received kick-back fees from a larger vendor such as IBM or Oracle.
  • Engineers have crappy hardware and their workplace is noisy.
  • None or very few members of management have or have had an engineering career of any substance.
  • Too many engineers that are young. (Guess what, experience matters)
  • Too many engineers show no interest in the latest developments in their field.
  • The company says “yes we can!” to even the most outlandish of “requirements”.
  • The company lets you dictate technology and architecture even if it is clear that you have no real experience. In other words, it is willing to serve you sh** on your pizza.


2 Responses to The dark art of selecting your custom-software vendor

  1. Winfried March 25, 2015 at 7:36 am #

    Actually, procurement is a profession. I would definitely involve technical staff in the process, but there’s more to it. For larger projects, RFIs and RFPs have a reason to exist. During the process, you will get to know the vendors and there’s time to see if there’s a match on a number of levels, one of which is their technical competence, of course. Apart from the vendors competence, one of the most important things for me is there’s partnership. Are we going to fix this thing TOGETHER? Even if it becomes a hard ride? Having this right provides a firm basis to achieve success and overcome problem that – undoubtedly – will pop up during the project.

  2. Hans Westerbeek March 25, 2015 at 8:07 am #

    It is a profession indeed, and I am aware that my post highlighted the technical aspects only. I found this post to be excellent.

Leave a Reply