The formula is E= -SUM(p(i)*log2p(i)), where i indexes the events being tallied, and p(i) is the probability of each event i.

It’s how to calculate E, the amount of entropy … that is, information … in a system.

Unless, that is, you’re calculating the amount of information in a typical mission or vision statement. Then the formula is simpler: E=0, which is to say your average mission or vision statement is devoid of information.

You can search the entire universe of business (or, to simplify your efforts, search an entire Large Language Model of business) and find few parallels for the juxtaposition of earnestness exhibited during the creation of these documents with the cynicism they face once the drafting is done.

What’s particularly strange is how popular these documents are among business theorists given the near-total absence of research demonstrating their utility … especially as the same business theorists are the first to counsel executive management that they should stop engaging in “non-value-adding work” without appreciating the irony.

Information Technology organizations are, in my non-random-sampled experience, particularly prone to victimization by mission-statement advocates. But before we can understand the situation we’d better go back a couple of steps to define our terms:

Mission is what an organization exists to do. It’s akin to a charter, only shorter.

Mission statements are, typically, grammatically sound paragraphs, or in many cases run-on sentences that should be edited into sound paragraphs, that describe everything and anything an organization does, used to do, or might want to do in the future.

That’s what they are. What they ought to be are conversation starters about what the organization’s mission is – why it exists.

That’s why they’re information-free phrases – they provide no guidance as to what the organization should and should not be doing.

But what’s worse about most IT mission statements is how they’re created, and by whom.

The problem with how they’re created is a matter of their time budget: The management team tasked with creating one of these puppies spends, on average, 37.563 seconds on the substance of the statement, occupying the remainder of the one-hour mission-statement drafting meeting arguing about whether “happy” or “glad” is the more suitable word to include.

The problem with who creates the IT mission statement is that IT didn’t will itself into existence in the first place. At some moment in the by-now-distant past, the company’s ELT (executive leadership team) decided the company should have an IT department, either by that name or one of its historical synonyms.

That being the case, tasking IT management with creating an IT mission statement makes no sense. The ELT chartered the IT organization, so it should inform IT management why it exists, instead of asking IT management to guess at the answer.

Bob’s last word: IT vision statements aren’t subject to the same criticisms. As “vision” is a clear explanation of how tomorrow should be different from today, its formulation is a legitimate CIO responsibility, and in fact setting direction is the first of the eight tasks of IT leadership (or, for that matter, any area’s leadership).

And for that matter, while deciding what IT’s mission should be is an ELT responsibility, IT’s leaders are the experts in what it might be, so by all means the ELT should consult IT’s leaders when deciding IT’s mission.

But whether vision or mission, there’s no excuse for the statement that articulates them to be devoid of information. And as the ELT is involved, might I suggest involving the Chief Marketing Officer in how they’re phrased?

Bob’s sales pitch: I think you’ll enjoy what’s currently playing on CIO.com’s CIO Survival Guide: “5 IT management practices certain to kill IT productivity.”

I’m including it in the sales pitch section because it’s always helpful for my CIO.com’s editors to see that my articles there are generating lotsa clicks. Which is me hinting that you should encourage your friends to read it too.

And oh, by the way … what’s in it for you is that if you’re in IT management it’s worth paying attention to.

As someone wiser than me pointed out, every organization is perfectly designed to get the results it gets.

As someone exactly as wise as I am (that is to say, me) has been known to point out, change happens when someone in a position to do something about a situation has concluded that how their organization does things isn’t good enough.

If you’re that person, do a bit of Googling (or, I suppose, Bing-ing) and you’ll find lots of alternatives for designing an organizational change, including such disciplines as Lean, Six Sigma, Lean Six Sigma, Process Re-engineering, and the Theory of Constraints.

Assuming you choose a change discipline that fits what you’re trying to accomplish, each of these can deliver a change design that can work.

Do a bit more Googling or Bing-ing and you’ll find a complementary change discipline called OCM – Organizational Change Management – whose purpose is to discover and mitigate barriers to organizational change. It’s essential if you want your intended change to become an accomplished change.

Try to make the change happen, though, and you might discover there’s something in the plan that’s either too ambitious, or not ambitious enough.

If it’s too ambitious you’ll find the first chunk of organizational change is too complicated by half – what’s often described as changing the plane’s engine while you’re still in flight.

Or, worse, you’re trying to convert your biplane into a single-wing aircraft without first landing.

When your chosen starting point is at the opposite end of the continuum – when it isn’t ambitious enough – it goes by the orchardarian monicker “low hanging fruit.”

Going after low-hanging fruit is a popular consulting recommendation. It’s usually a mistake because it creates the illusion of forward progress while failing to set the stage for additional forward progress. Extending the metaphor, go after low-hanging fruit and you’ll find you’re clutching a lemon in your left fist and a tree branch in your right, all while you’re trying to avoid falling off your ladder.

Or, because metaphors don’t (speaking of metaphors) build a very good foundation for a logical edifice, let’s make it real: achieve a quick win and you’re left without a plan for what happens next.

Quick wins deliver the illusion of progress, but with no momentum or trajectory.

The missing piece

Quick win proponents get one thing right – that the hardest part of most intended changes is getting started. What they fail to recognize is that staying started is harder than getting started.

We might call what’s needed a “Quick Win Plus.” Like a quick win, a quick win plus gets the change started by making a small, manageable, clearly envisionable change.

Unlike a quick win, the change a quick win plus accomplishes is one that deliberately includes ripple effects – dependencies that encourage additional changes elsewhere in the organization. Especially, they’ll encourage creation or improvement of a few competencies critical to ongoing success – that will, that is, encourage additional beneficial changes.

Some changes don’t fit this mold – they just can’t, for one reason or another, be decomposed into a swarm of small, independent alterations in how work gets done. These big, complicated changes are the ones that call for disciplined, experienced project management and diversion of staff from their day-to-day responsibilities to full or nearly full commitment to the project team.

Bob’s last word: The way the business world is evolving, big, complicated organizational change is becoming decreasingly feasible. Battle-tested project managers have always been in short supply, while the staffing levels needed for traditional project-managed change are higher than most businesses are able to sustain.

Which is why so many organizations are gravitating to agile-oriented, iterative and incremental change methods.

The quick-change-plus approach fits this thought process well.

Bob’s sales pitch: I can only wish I’d had anything to do with Good Night Oppy. It’s the story of the Spirit and Opportunity Mars rovers. You must watch it – then you’ll wish you’d been a part of it too.

It’s simply wonderful – a very human story, brilliantly told. And after you watch it I can pretty much guarantee you’ll be telling your friends that they must watch it too.

Now on CIO.com’s CIO Survival Guide: Why IT surveys can’t be trusted for strategic decisions.” It’s an accurate title.