All Posts by Bob Lewis

|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: Cognitive Enterprise|Last Updated:

The third-finest movie I’ve seen about the space program was First Man. Marvelous as it was, it was biography, telling the story of Neil Armstrong, a quintessentially American hero.

The second-finest was probably Hidden Figures, about the team of mathematicians who made the early missions possible, overcoming the dual prejudices they faced for being both African American and female. It is an incredible story, about the space program but even more to help us see that while we still have quite a long way to go in overcoming prejudice, we clearly have come quite a long way from where we were.

These two stories rate second and third because they’re about individuals. Remarkable individuals we should remember and honor, but individuals nonetheless.

For my money the truly outstanding work is Apollo 13 — not because it’s a better piece of film-making but because it tells the story of NASA as a profoundly capable organization — one that could not only achieve the remarkable, but one that could adapt to the most intense challenges, and overcome them because and only because it was a profoundly capable organization.

I’m admittedly biased — I once had the privilege of hearing Jim Lovell and Gene Kranz speak about the mission and the movie, for which they served as consultants to Ron Howard to make sure he got it right.

While we’re on the subject, take a few minutes to read Randy Cassingham’s homage to Chris Kraft, not because it honors a man who deserves to be remembered in the same breath as these others, but because it describes his achievement and contribution: he designed Mission Control — not just the facility, but the roles, operating procedures, and all the rest of what made putting human beings into space possible.

In 2015, when Scott Lee and I wrote The Cognitive Enterprise, I’m embarrassed to tell you neither of us thought to mention NASA as the archetypical example.

But it is. From everything I know and have read, NASA is a seriously cognitive enterprise. It’s an organization that acts with purpose, having clear goals and then sensing, interpreting, and responding to changing circumstances so as to achieve them. Which is how it is that NASA landed Mars rovers that exceeded their planned mission lives by 2,500%; launched a spacecraft (Cassini) for a planned four-year tour of Saturn that lasted 20; and that sent the New Horizons spacecraft to visit both Pluto and the Kuiper belt, thereby inspiring astrophysicist and Queen lead guitarist Brian May to record a song named after its destination — Ultima Thule.

What’s most remarkable about NASA — and what we should, as Americans, be particularly proud of — isn’t what it’s achieved but how easily it might have failed to achieve it.

Like all large organizations, government agencies easily slide into bureaucracy. This happened to NASA in the course of its history, resulting in a sad string of mission failures that ranged from embarrassing — the Mars Climate Orbiter missed the red planet because some calculations used the English measurement system while others used metric units — to the tragic Columbia and Challenger shuttle disasters. Richard Feynman’s analysis of the latter demonstrates that the core failure was of the organization as a whole, not of incompetent engineers.

What’s extraordinary about NASA is that its leaders didn’t pretend, didn’t duck and cover, and didn’t make politically expedient decisions. They took serious steps to understand what it was about the organization that encouraged mistakes. They then accomplished the truly remarkable — they fixed the organization, restoring its cognitive essence.

KJR is, at its core, about managing and leading effective organizations. As one of its readers you might lead and manage an organization; you might either enjoy the results of good leadership or cope with the consequences of the other kind; or you might fall into both categories.

To the extent you’re responsible for running an effective organization, and even more so to the extent you’re responsible for fixing an organization that’s less effective than it needs to be, you could do worse than use NASA’s leaders as your role models.

Far worse.

Also to the extent you need to fix an ineffective organization, a caution: Effectiveness is the least-stable state of organization. Among the reasons: organizational effectiveness asks everyone involved to subordinate their personal ambitions to the larger aims of the organization as a whole.

Which, among other challenges, means defining the larger aims of the organization as a whole so they’re inspiring enough to make this choice worthwhile.

Comments