Software Selection: Who’s In Charge?

Decide what you want, decide what you’re willing to exchange for it. Establish your priorities and go to work. – H. L. Hunt

21609-cart-horse

You’re living in a cramped 2 bedroom apartment and you decide it’s time to buy a house.

You have a spouse, 3 kids, 2 cars, a dog and a home-based business. On that basis, you determine that you’ll need a 2 storey home with 4 bedrooms, an office, a 2 stall garage and a medium-sized yard.

You give this information to your realtor and she compiles a list of houses for you to look at. Most of them are 2 bedroom bungalows with no garage on postage stamp lots.

In spite of your stated requirements, the realtor has determined that a 2 bedroom house is less costly to heat and cool, the cars can be parked outside and a small yard requires less effort to maintain. Most importantly, there’s an abundance of 2 bedroom houses on the market right now, so she’ll be able to get you into a house more quickly this way.

All of those things may be true, but you’re the one who’s going to be living there for the next several years, not the realtor. Sure, some tradeoffs are possible (even expected) – maybe the two youngest rugrats can bunk together until the oldest goes to college, or perhaps you can build your home office in an unfinished basement after you move in – but in this scenario, it seems as though the realtor is more interested in meeting her requirements.

All too often, a similar story plays out when companies embark on the journey of selecting new software to run their enterprise. We’ve seen it many times firsthand when it comes to supply chain planning software, but it really applies to any area of an organization that uses technology.

The burning platform may come from the business (“Our performance and productivity is suffering because of this clunky old legacy system!”) or from I.T. (“We can’t support this piece of crap any longer!”)

Regardless of the impetus for change, it’s the next decision where things start to go of the rails: “Well, since we need new software, then I.T. should be in charge of selecting it, right?”

Um, wrong.

I.T. certainly has a critical role to play, but if you’re the manager of a business process (and people) that will need to be supported by new technology, you take a back seat in the selection process at your own peril.

There are 3 things to always remember:

1. I.T. can’t read minds

I.T. folks love business requirements. Lots of them. With as much detail as you can muster. It helps them to shortlist candidates and research alternatives. If you don’t invest the time and energy to carefully think about what you want the future state to look like and write down your requirements, then you’re forcing I.T. to guess them. This would be like telling a real estate agent to ‘find me a house’ without providing any other details.

2. What I.T. considers important in a software package is not what the business considers important

Yes, the business has requirements, but so does I.T. A new software package must perform a number of functions in order to enable a new process. But it must also be supported (and supportable), process appropriate volumes and fit in with the established architecture of the systems that won’t be changing.

3. The business people will be using the new software each and every day to do their jobs

This speaks to the relative weighting between business requirements and technical requirements. The cheapest solution with the best processing speed and architecture that’s impossible for a user to understand and doesn’t support the business requirements isn’t much use. In other words, business requirements are more important and consequential to the running of the business than technical requirements – there, I said it.

So, suppose you get a good set of business requirements and a good set of technical requirements. A few software vendors come in to demonstrate functionality with the business folks and talk tech with the I.T. folks. You short list it down to 2 vendors:

  • Vendor A meets 80% of the critical business requirements, but 65% of the technical requirements
  • Vendor B meets 70% of the business requirements, but 75% of the technical requirements

What do you do now? The same thing you would do if the realtor at the beginning shows you a few houses that lacking in some way when compared to your ‘wish list’. You talk it through. You figure out which tradeoffs you’re willing to make. You discuss where workarounds might be used to bridge a functionality gap.

None of that is possible if you don’t give yourself the choice.