All Posts in Strategy and Tactics

|In: Organizational Effectiveness|Last Updated:

It’s called “solution selection.”

There are those who grouse that we should stop the doublespeak and call it software selection.

Not me. We engage in this sort of thing because we have a problem that needs solving, after all (or, in happier circumstances, an opportunity that needs chasing). A software product by itself is, as logicians might put it, necessary but not sufficient for solving (or chasing) it.

The fundamentals for going about solution selection are, by now, well understood: When comparing the alternatives, evaluators should dig into: (1) Features and functionality — does the solution do what you need it to do? (2) Internal construction — is it built well? (3) Terms and Conditions — what will it cost, and beyond cost is contract and licensing language acceptable? (4) Vendor characteristics — is the seller financially viable and, almost as important, easy to work with?

The fundamentals are well understood, and yet the results, more often than not, are disappointing.

What goes wrong? What follows is just a starting list. I hope you and your fellow members of the KJR community will add to it in the Comments so we can, as the saying goes, all be smarter than any of us are.

So with that in mind, here’s my shortlist of hard-to-avoid solution selection gotchas:

Wrong selection: The selection is always wrong and has to be. No matter the depth of due diligence, some warts only appear when you implement. So you’ll see the awful reality of the selected solution. Everything else exists in the glorious world of brochureware. It’s a case of the grass always being greener under someone else’s GrowLux.

Each requirement vs all requirements: I’ve seen this a few times — a supplier’s products can handle every requirement the solution selection team has identified. Sadly, no one of the supplier’s products can handle them all, and the ones you need to cover everything aren’t integrated.

Feature scaling: A vendor can usually get its software to do what you need it to do. It can make it do something else you need it to do, too. But there’s often a limit on how many different something-else-you-need-it-to-do-toos their software can do at the same time, because really, what they’ll have to do to get their software do each of those things is a one-off. Doing them all makes it a kludge.

SaaS means not having to worry about the internals: Wrong! Saying that a software product’s internal engineering doesn’t matter because it’s SaaS is a lot like saying an airplane’s engineering doesn’t matter because someone else is flying it.

There’s a limit to how much of a solution’s internal engineering a provider will share. In the case of software what you probably care about the most is the data model. Explain what you need to know about each type of stuff the software will manage, and ask where that data gets stashed.

Terms, conditions, conditions about conditions, and conditions about conditions about conditions. Some software vendors still hide terms and conditions inside linked documents, inside documents linked to the linked documents, and so on ad infinitum. I guess it makes sense that if good software design means that modules invoke modules that invoke modules, that good software license design would be similar.

Regardless, some T&Cs can place unfortunate limits on what you can do with what you’re licensing. This is why you need lawyers.

Vendor from where? In Greek mythology, Prometheus was the good guy, stealing fire from the gods for humans to use. In Christian mythology, Lucifer (light-bringer) was guilty of pretty much the same crime, assuming you’re willing to overlook that little war-on-heaven peccadillo.

Some software vendors are more Lucifer than Prometheus (you were wondering where this was going, weren’t you?).

What can you do to anticipate this? References won’t get you there. Even the worst vendor will have a few customers who like it. The best you can do is ask around and hope a few people you trust have had experience with the vendors you’re considering.

What else can go wrong? Lots else can go wrong. As I said at the beginning of this column, this list is just for starters, and it doesn’t include any of the mistakes customers make while implementing the solution they’ve so painfully selected (for example, thinking they’re implementing the software and not changing the business).

So now it’s your turn. Jump to the Comments and share your insights as to what can go wrong while choosing the right solution.

The KJR community awaits your wisdom!

Comments

|In: Digital|Last Updated:

I’m getting hands-on experience with DevOps.

No, not as a member of a DevOps team. It’s that I use Office 365.

Don’t get me wrong. I like Office 365, to the extent it’s possible to like this sort of thing.

Except that once a week or so when I fire up my laptop, I have to hunt for features that mysteriously moved from their accustomed spot on the ribbon when I wasn’t looking.

It’s like Who Moved My Cheese?, where someone moved the protagonists’ cheese to an unknown location with no obvious reason for doing so and little or no notification that it had happened.

So to all you hardworking DevOps team members, and especially to the fine folks responsible for implementing Office 365’s epics, features, and user stories (here at KJR headquarters we’re nothing if not Fully Buzzword Compliant (FBC)) …

To all you hardworking folks: DevOps’ CI/CD mantra can stand for Continuous Integration/Continuous Delivery or Continuous Integration/Continuous Deployment.

If it’s Deployment and what you’re Continuously Deploying includes UI changes, CD has a third translation: Continuous Distraction.

Which brings us to the serious business of self-promotion, specifically, the impending (September) release of There’s No Such Thing as an IT Project: A Handbook for Intentional Business Change.

User Interface and User Experience design is one (or are two, depending on your perspective) of the topics we touch on in the book. In it we establish what most businesses should establish as their core UI/UX metric: Annoy customers and users as little as possible.

Yes, yes, yes, Tom Peters is still flogging excellence and delighting customers as what you should strive for. And far be it from my co-author, Dave Kaiser, or myself to denigrate excellence or customer delight in general.

It’s in particular that we have some concerns, namely, the nature of many business relationships is such that customers have no interest in being delighted. If you’re among them, managing to not irritate them is doing well.

Trying to delight them inevitably results in more and longer contacts, when what they want are fewer and shorter ones.

And if you accept the KJR distinction between quality (absence of defects and adherence to specs) and excellence (flexibility, customizability, adaptability and the presence of desirable features) … if you accept this distinction, simply delivering what you promised to deliver — quality — might not be enough to delight anyone, but compared to your competitors and earlier self they might be pleasantly surprised.

Try to get inside your customers’ heads. When they’re looking to buy something, what do they care about? What do you care about when you’re looking to buy something?

While not a universal truth, the odds-on favorites are price and convenience.

Look at the big business success stories of the last few decades, and for every Excellence-and-Delight example (Facebook and Twitter, maybe?) companies that focus on price and convenience are making a lot more money. Google, Amazon, and Uber are three noteworthy examples. At least they are from the perspective of revenue. I’m thinking Uber will turn a profit before investors lose interest, but you never know.

Google is an interesting example because when we use it we aren’t its customers. We’re its product, to which it sells access to its customers, which are the advertisers who want to reach us so as to tell us their stories. Google makes buying access to us easy. Whether it’s cheap depends on the details of how you measure the cost of customer access. Certainly, it’s no more expensive than the other ways businesses have to gain access to interested buyers.

Amazon is more straightforward. Whether you’re looking at its bread-and-butter retailing, its Kindle books, or AWS, price and convenience are everything.

Likewise Uber. Compared to traditional taxis, Uber costs less and is a lot more convenient. Uber doesn’t delight its customers except by comparison. But it sure has thought through the factors that irritate ride buyers and has done quite a good job of minimizing them.

There are, of course, exceptions to the price-and-convenience rule. If you’re in the business of selling Lamborghinis, Ferraris, or Aston Martins, neither price nor convenience are what your customers are after. Likewise if you own a professional sports team or Marvel and its stable of superheroes. If that’s you, excellence and delighting your customers by giving them a great experience is exactly what you need to do, because the customer experience is what you’re selling and they’re buying.

If, on the other hand, you’re the purveyor of more prosaic merchandise, just not irritating your customers is a pretty high bar.

Comments