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.

Including Keep the Joint Running and its predecessors – InfoWorld’s IS Survival Guide and Advice Line – I’ve been sharing thoughts and opinions for more than 26 years.

When I started, I wanted people to read what I had to say and think, “Wow!” Now, I’m gratified if they think, “A column a week for 26 years? Wow!”

Quantity seems to have gradually overtaken excellence as my most crucial KPI.

Meanwhile, I’m more likely to remember having written about a subject than you’re likely to remember having read about it for, I think, obvious reasons. As a result I sometimes obsess about avoiding repetition – that if I’d written about a subject in 1998 you’ll feel cheated if I write about the same subject here in 2023.

Which brings us to this week’s subject: “Shadow IT,” also known as “Rogue IT,” “DYI IT,” and, if you want to encourage Gartner in its perennial game of claiming concept ownership by attaching snappy new names to unoriginal concepts, “Citizen Developer.”

Or, you could use the handle my co-author Dave Kaiser and I introduced in There’s No Such Thing as an IT Project, as a contrast to Shadow IT, namely, “Illuminated IT.”

As with so many ideas in life, illuminated IT comes with trade-offs, making it sadly easy to succumb to confirmation bias when deciding whether to encourage it or try to stamp it out.

The stamp-it-out logic

End-users aren’t trained developers. They might fall short when it comes to application architecture, testing, or security. And if or when something goes wrong, IT will have to pick up the pieces.

Not only that, but when the end-user developer “calls in rich,” IT will be called in to support the mess the end-user developer left behind.

The philately-free logic (okay, it’s a stretch)

DIY development increases IT’s bandwidth – not once, but in two complementary ways.

The first is the obvious one: a DIY developer still counts as a developer. Maybe not an ideal developer, but I’ll bet not all of the developers housed within the IT organization are ideal ones either.

The less obvious one? For the most part, IT development, along with IT “development” (when IT configures and integrates commercial off-the-shelf software), involves a business analyst here and there. DIY IT does not.

Related: No more arguments about whether what IT delivers is what the business needs.

The best of both worlds

Once IT jettisons its protectionist instincts, and once business users jettison their IT-distrust instincts, getting the best of both worlds isn’t particularly complicated:

1. Encourage using what you already have. It isn’t uncommon that an application suite you already license provides the additional functionality the business needs. The formula for success: Inform, train, follow up.

2. Encourage COTS. If some application provider licenses a solution that does what business users need, it reduces the risk of losing support due to the end-user developer finding something else to do.

3. Establish platform standards. Whether it’s Excel, Access, or a “no-code/low-code” cloud-based alternative, setting one of these as the supported and recommended development environment reduces IT’s support burden. Once you’ve established the standard, offer training and support as needed.

4. Inventory. Ask business users to provide three layers of documentation for anything they develop. Layer 1 is the application’s title (“MS Word” is an application title). Layer 2 is the application’s headline (“General-purpose word-processing application” is an application headline. Layer 3 is a no-more-than-three sentence explanation of what the application does. With this inventory, should IT have to swoop in to save the day there’s a good starting point to swoop from.

5. Establish a Mentor Program, aka a Power Users Cool Kids Club. How to do this? See “Mentors are your friends. Be nice to your friends,” which first appeared in InfoWorld September 23, 1996.

Bob’s last word: For far too long, IT’s “best practice” on DIY development has been “We won’t do it for you and won’t let you do it for yourself.

Without a doubt, DIY development comes with some risks attached. But then, DIY prevention comes with risks of its own, namely, that various parts of the business will forgo important opportunities for technology-enabled improvements in effectiveness, all because a focus on what might go wrong blinds decision-makers to what might go right.

Now on CIO.com: “The 7 venial sins of IT management.” What it’s about: Seven mistakes to worry about that probably aren’t on your to-don’t list already.