When you move your family, even if it’s into your (and presumably their) dream home, the inconveniences outweigh everything you love about the new place.

At least they do for a while, which is why, if you’re in the change business, you should read and re-read William and Susan Bridges’ Managing Transitions. It clarifies the essential divide separating a change’s immediate annoyances (the transition) from its ongoing joys.

Which is why I had my annual physical before upgrading our household to Microsoft 365.

I wanted my blood pressure to look good.

So while I like my terabyte of cloud storage and 50 more gigs for email, I didn’t at all appreciate the three multi-hour chat support sessions required to make them available (don’t ask).

Not to mention the time spent finding all the features that have been rearranged.

Which brings us to why, if you’re in the change business, you should also ponder how and why it is that plug-in hybrids and pure-play electric vehicles are more likely to dominate future driving than the vastly superior alternative — cars powered by hydrogen fuel cells.

Disagree? Explain why in the Comments. For our purposes today just go with it.

The problem with hydrogen powered vehicles when compared to plug-in hybrids or pure-play electrics is as easy to grasp as it is difficult to solve.

Pure-play electric vehicles need electricity. As a nation we have an electrical grid that delivers it. It might (and does) require upgrading, but it’s there. Plug-in hybrids need the grid, along with gasoline or some other hydrocarbon-based fuel. We have a deep and rich system in place for obtaining, refining, distributing, and selling this stuff in massive quantities.

Hydrogen? Even overcoming the unfair perception, created by the Hindenberg, that hydrogen is too explosive to ever be safe. I’ve read that most of those who died were killed by the fall; the hydrogen itself, being lighter than air, floated up as it burned).

Where was I?

Overcoming the complete absence of a hydrogen distribution network will most likely prevent hydrogen from ever catching on as a fuel.

Now about that software project you’re running.

By now, assembling requirements or their Agile user-story equivalents, is something most IT shops know how to do. Your developers know what outputs the software is supposed to deliver, and the inputs and algorithms it needs to deliver it.

Your testers have the same knowledge and know how to turn it into an organized, and ideally automated test plan and program. Your project might not deliver bug-free code, but its bug count won’t be the sort of embarrassingly huge number generally reserved for astrophysicists trying to describe the age of the universe in months. No worries on that front.

You’ve ticked all of the check boxes put in front of you by the Change Advisory Board (CAB) and Architecture Review Board (ARB). These i’s have been dotted and t’s crossed.

And you’ve involved Organizational Change Management (OCM) throughout. They’ve communicated with everyone to explain why the change is necessary and good, and they’ve put a training plan in place which you’re ready to launch just as soon as you know the official deployment date.

What could go wrong?

Welcome to the problem of hydrogen logistics. Sorta. It’s an analogy. Don’t worry if it’s not a perfect fit.

Anyway, imagine, for the sake of argument, the software your team is preparing to deploy is to consolidate the 17 supply chain management systems that are the legacy of past corporate acquisitions.

You might have designed the new software to be flexible enough that all 17 supply chain managers can use it to manage their supply chains as they like (the car will run on hydrogen, gasoline, diesel fuel, or batteries) at which point you might as well have designed and developed 17 separate supply chain management systems. You’ll deliver all pain and no gain.

Or else, all 17 supply chain managers agree to standardize their processes so they can use the same software the same way. It’s as if enough gas stations start selling hydrogen, fuel delivery trucks are retrofitted to transport it, and so on that anyone driving a hydrogen vehicle anywhere can fill it up before it runs out of fuel.

Let’s hope process standardization is the plan. If it is, make sure your OCM trainers avoid a common mistake: Teaching business users how to operate the software, not how to do their jobs a new way with the software.

That leaves you with one advantage over hydrogen: You don’t have to convert supply chain management all at once.

But you do need to figure out who will go first.

And last.

# # #

Want to be more adroit at making change happen in your organization? Get yourself a copy of There’s No Such Thing as an IT Project. It’s nothing but practical ideas you can put to use tomorrow.

Assuming, of course, you’re a fast reader.

There are, according to the KJR Manifesto, no best practices, only practices that fit best.

More often than not, though, “best practice” refers to neither. Most so-called best practices are really no more than minimum standards of basic professionalism.

Take a situation I’ve run into several times over the past few years: Whether due to mergers, acquisitions, and divestitures, years of IT being stretched too tight, or just plain sloppy management, IT can’t produce an accurate business applications inventory.

Clearly these IT organizations aren’t in sync with “best practices,” which call for instituting:

  • PMO (Program Management Office): The body responsible for reviewing, approving, and tracking all IT-related projects. The PMO matters because it’s the projects it oversees that change the applications inventory.
  • CMDB (Configuration Management Database): A repository that keeps track of What’s Installed Where. Business applications are among the “configuration items” the CMDB keeps track of, along with every piece of real and virtual hardware, server OS instances, DBMS instances, development environments … every item IT has to keep up and running.
  • CAB (Change Advisory Board): The organization responsible for reviewing all “change requests” (read “installation requests”) to make sure development teams, IT infrastructure teams, and anyone else trying to change the IT production environment has dotted all requisite i’s and crossed all corresponding t’s. Also, for making sure someone updates the CMDB to reflect every change.
  • EAMS (Enterprise Architecture Management System): An information system that keeps track of … well, of all layers of the enterprise architecture, from hardware at the bottom to platforms layered on it, to information repositories, applications, and the business capabilities, functions, and processes that depend on them.
  • ARB (Architecture Review Board): Enterprise Architecture’s enforcement arm — the organization that reviews all IT-related plans to ensure they conform to the company’s technical standards. And, for making sure every change results in an update to the EAMS.
  • Forms: Lots of forms, to make sure each change consistently updates the CMDB, EAMS, and enterprise project portfolio to keep them consistent with one another. Or, as an alternative, application integration that makes sure an update to any of these systems synchronizes the others.
  • MA (Mandatory Arbitration): With three different committees, each responsible for finding flaws in the creative work of other people, do you think all parties will agree? Envision the oarsmen on a trireme with multiple captains directing them to row in different directions.

Forget (or at least delay) best practice. Achieving the minimum standard of basic professionalism in all this is more than ambitious enough. And that’s having a single, trustworthy application inventory. What it will take:

Count each application once. Is the application installed on multiple servers in multiple locations? Doesn’t matter. Count it once. Do you have separate Dev, Test, Prod, and possibly other intermediate instances? Doesn’t matter. Count it once.

Do you have multiple versions or releases installed? That does matter — count each of these as separate inventory entries.

Determine application granularity. If you, like most businesses, rely on large-scale suites to support major business domains (e.g. Workday for HR, Salesforce for CRM, SAP for ERP), the suites aren’t granular enough. Make each module an entry.

If your business is at the other granularity extreme, microservices are too granular to track in the inventory. Go up a level and track the applications microservices assemble into.

Manage app/platform dualities. To take an example, SharePoint is both an application and a platform for building applications. Track these uses separately.

Track the bare minimum. For each application track its name, version, product owner (or non-Agile equivalent), IT support lead, a brief description, and vendor. If you can’t easily implement the inventory on a spreadsheet you’re being too ambitious.

Related: If you find yourself tossing around terms like “metadata,” stop unless you’re planning on using an EAMS for the job. Don’t even daydream about metadata until you have an accurate inventory.

Survey the business. Ask each top-level executive this question: “What are the five applications your organization relies on the most? Please reply; also please forward this survey to your direct reports, asking them to respond and also to forward it to their direct reports.”

Use the results to validate your inventory, but be careful. Your business respondents might not use the same application names you used in your list.

Enlist the PMO and ARB. Ask them to let you know of any new applications being installed, updates to existing ones, and retirements.

And finally, instill in everyone the first rule of inventory management: What the inventory shows today will be wrong by this time tomorrow.