All Posts in Shadow IT

|In: Organizational Design|Last Updated:

Ever wonder what separates successful IT departments from the ones that generate nothing but gripes?

Not what separates star-performing IT from “the pack,” but what separates the competent from the rest?

150 factors make the difference, but they aren’t all created equal. Squint at the list hard and 18 float to the top. (Why 18? Because that’s how many actually floated to the top. I didn’t start with a number in mind.)

Some background: Back in the last century when I wrote the  IS Survival Guide I organized the factors needed for IT to work into four buckets. Over time these evolved into the framework I use today: Business integration, process maturity, technical architecture, and human performance.

The 150 factors on my list of what makes the difference come from drilling down into these four categories. Selecting the 18 “critical success factors” from that list was less than scientific but more than arbitrary — it was the result of experience and lots of correspondence over the years.

This week’s column defines the big four and their overall scope. Starting next week we’ll dig into the critical success factors and what to do about them if your organization comes up short. So without further ado:

Business Integration

Business integration covers everything about how IT fits into the enterprise as a whole. It happens at three levels: strategic (meaning enterprise-scale), tactical (divisional), and business-infrastructural (overall “lifestyle” technologies) integration. And yes, I’m abusing the language using it this way. Live with it.

Those are the whats of business integration. The hows are governance and the business/IT relationship.

Process Maturity

Process … more accurately, processes and practices … are how an organization does its work. IT’s processes and practices fall into five broad categories:

  • Delivery management: Primarily on the applications side of IT, how the organization makes sure IT actually does deliver what it’s supposed to deliver. Delivery management breaks down into three levels: Program management, initiative management, and project management.
  • Application support: This includes everything having to do with designing or selecting; building or installing, configuring and integrating; enhancing; maintaining; and (when the time comes) retiring business applications.
  • Information management: Making sure all structured databases and unstructured data repositories contain what they’re supposed to contain, and are organized so as to maximize their maintainability, integrity, and value.
  • IT Operations: If the systems are down, nothing else matters. If they’re sluggish, something else matters but not much. IT Operations is where IT makes sure the value it’s already delivered is there, ready to use when it’s needed.
  • Personal technologies: The ERP suite is strategic and runs the company. The CRM suite is strategic and drives revenue. But employees live their lives on their PCs, smartphones and tablets, using the office suite, email system, and telephones. Handle these well and employees will forgive a lot. Handle them badly and your reputation is shot.

Technical Architecture

Yes, IT might be “about the business,” but in the end, someone has to make sure the company has the right technologies in place, organized well, and put together to facilitate the company’s next step instead of acting as a barrier or bottleneck. Notwithstanding all that’s written about shadow IT, non-IT IT and so on, when it comes to the stuff that can’t just be a standalone “island of automation,” that someone is IT.

Technical architecture encompasses the applications portfolio, the company’s structured and unstructured data repositories, and all the platforms and technical infrastructure they reside and run on. And how they all fit together.

Human Performance

IT might be “about the business,” and its job might be to provide the technology the company needs (and by the way, its job is now bigger than that, but that’s a different topic for a different column).

IT might get its work done through well-organized processes and practices, but in the end it’s the people who work in IT who make the difference between success and failure.

Human performance isn’t about whether the people who work in IT perform. It’s about everything that has to come together so IT has great people working in it, with as few barriers as possible standing between them and success.

These four factors — business integration, process maturity, technical architecture and human performance — are what IT has to be good at if it’s going to be considered competent.

How does IT become good at them? That’s what the list of critical success factors is for. We’ll start digging into it next week.

Comments

|In: Cloud|Last Updated:

Ready for a classic horror story?

It’s a dark and stormy night (of course it is). Deep shadows are spreading. In them, a nameless evil starts to take form.

A secret society is there to name that evil and fight the shadows (sound fx: crack of thunder). But it needs your help!

The secret society is Internal Audit, the spreading shadows are shadow projects — the too-small-to-notice-but-too-important-to-let-fail projects business managers charter. The name of the nameless evil? “Shadow IT“!

Now you know why I don’t write fiction.

It is, however, a horror story because the last thing IT should be doing in most organizations is treating these as evils.

The story so far:

Before the cloud became a force, IT had mostly stomped out shadow IT by locking down desktops, limiting the availability of MS Access, and disabling VBA. That successfully eliminated the risk that non-IT staff might create value with IT innovation, while shifting intruders from buffer-overflow exploits to phishing attacks.

But then came the cloud, and specifically Salesforce.com, which represented a triple threat:

  • It catered to Sales, the least rule-conscious group in any business. Being part of revenue and all, it has more political muscle than IT, too.
  • Unlike most business applications, Salesforce.com can be implemented effectively without any integration into other business systems.
  • IT couldn’t stomp it out without instituting Internet filtering, which is a labor-intensive pain in the patootie requiring additional headcount the CFO probably wouldn’t approve were IT to try to make its case.

Face it: The cloud means shadow IT is going to happen. That ship has sailed. We can either climb on board or wait at the Greyhound station, doing what we can to keep our so-called “internal customers” from climbing onto buses they no longer want to ride anyway.

Oh, and in a classic case of turnabout being annoyingly fair play, while IT can’t stop shadow IT anymore, our partners throughout the business can easily stop us from climbing the gangplank to join them.

Then there are shadow projects. Like shadow IT, shadow projects happen outside the company’s approval processes. The managers who want them to happen simply charter and assign them, because they have enough authority without anyone else butting in to make sure they’re “done right,” whatever that might mean.

Something else the two shadows have in common: As a practical matter, their costs are low, their benefits are, in proportion, high, and the cost of stopping them would exceed the cost of just letting them happen.

One more characteristic they share is that they increase risk, because the folks who take them on often aren’t as familiar with the company’s compliance requirements as IT professionals are who have to take them into account with everything they do.

That doesn’t, however, mean IT has to become the Deputy Dawg of company compliance.

The fact of the matter is, Internal Audit gets a bad rap in most companies. It’s goal isn’t to prevent people from doing their jobs. It’s to recommend a healthy set of management controls, then to make sure everyone complies with the controls management actually adopts.

Describe a hypothetical shadow project to Internal Audit. Make it a typical one — one that’s going to build some shadow IT that won’t cost very much, and will do something useful and profitable. Ask if it should be stopped because it might lack the proper controls, and the most likely answer will be, no, don’t stop it. Just have it add the proper controls.

Internal Audit isn’t the only compliance function in the company. Inside IT (or inside its orbit), enterprise technical architecture management (ETAM) and information security wear compliance hats, and sometimes the PMO as well. Because they’re compliance functions, making sure everyone complies is almost instinctual. That is, after all, what compliance means.

And so, ETAM turns into the architecture police, the PMO turns into the methodology police, InfoSec turns into the Value Prevention Society, and IT takes the easy way out, doing its best Sergeant I-see-nuthink! Schultz impression while deploring the whole shadow enterprise.

There are alternatives. ETAM and InfoSec can collaborate to create a secure and supported end-user-computing platform. Internal Audit can provide a compliance checklist available to anyone who wants it.

IT can provide consulting services on how to design and build small applications. And if you have a PMO, it can provide training and coaching in ultra-basic project management techniques.

Preventing failure and encouraging success aren’t the same thing. The difference is the vast gap separating “No!” from “How can we can help?”

Comments