Remember the rule from the KJR Manifesto, that there’s no such thing as an IT project — they’re all business change projects that make use of information technology?

It’s just as true for the projects that result in so-called “shadow IT” — the information technology that happens without IT’s direct involvement. And because it’s shadow IT, the folks who ask for it know this. They’re looking for business improvement — that’s where their thought process starts. The linkage is automatic.

Last week’s column explained why IT should start supporting shadow IT. But that isn’t enough. We need to support shadow projects as well … the too-small-to-notice-but-too-important-to-let-fail projects business managers charter to make their shadow IT happen, and also to make all kinds of other stuff happen too.

Let’s imagine, for the sake of argument, that your company has established a PMO or EPMO ([enterprise] program management office). If it’s like most PMOs, the company’s project managers all report there, and one of the rules is that all company projects must be managed by its trained project managers. That way, the company doesn’t risk investing in projects that are managed poorly.

Sounds a lot like the arguments against shadow IT, doesn’t it? Like those arguments, the driving force is risk reduction, but the actual impact is mostly opportunity avoidance.

Limiting the number of projects a business can take on to the number of available project managers artificially limits the company’s capacity for change. And when it comes to change, any bottleneck other than the company’s ability to absorb it is inappropriately limiting — a decision to adapt and improve more slowly than necessary.

Which is why, in so many companies that have established an official PMO or EMPO, business managers charter lots of under-the-radar projects.

The shadow project situation sounds more and more like shadow IT, doesn’t it?

On the whole, shadow projects have less risk and yield higher returns than most of the official projects in the company’s portfolio, a natural consequence of their being small, short, tightly focused, and properly sponsored.

Yes, properly sponsored, something that’s more-often true of shadow projects than official ones, because shadow projects are started by business managers who personally want them to succeed. This makes them sponsors … real sponsors, by definition … and the importance of sponsorship in effective project management is well known.

Just in case: Real sponsors want their projects to succeed enough to stick their necks out and take risks when necessary to support their project-manager partners. That’s in contrast to assigned sponsors, who are thrown in front of official projects, just because the methodology says every project has to have one. Assigned sponsors don’t really care, because why would they?

So shadow projects have less risk than their formally chartered brethren. Except for one thing: They’re mostly led by employees who, while promising, have no project management training or previous experience. Their managers/sponsors, themselves usually unaware of what project management actually takes, tell them, “This will be a terrific development opportunity for you,” ManagementSpeak for “There’s a bus approaching at high speed!” followed by a shove.

The result is that right now, many shadow projects aren’t managed as projects at all, because the employees who are put in charge of them have never managed a project and have no idea where to start.

They need help.

So here’s a thought: Instead of trying to stamp out these shadow projects the way IT used to try to stamp out shadow IT, why not provide some support?

Like, for example, giving about-to-be-run-over-by-a-bus neophyte project managers some tools and training, instead of treating them like orphan stepchildren. The secret, and the challenge: Those best equipped to provide the tools and training know too much about the subject. They know, that is, the techniques needed to implement SAP, erect a skyscraper, or build a nuclear submarine.

What many of them don’t know is which of those techniques can be safely jettisoned when the task at hand is managing a team of three people for a few months — at a rough guess, 90% of their expertise. As is so often but so strangely the case, scaling something down can be harder than scaling it up.

Still, it can be done, and doing it is important. In the aggregate, shadow projects add up, even if no one of them is a big hairy deal.

If the PMO/EPMO reports inside IT, the CIO can make shadow project support part of its charter. If not, there’s no reason IT can’t provide it on its own.

Which is a nice irony: Where IT used to do its best to stamp out shadow activities, it has just become an active conspirator in them.

“I have two questions for you,” a client told me, shortly after I launched IT Catalysts: “The first is, how can I instill a better customer-service attitude among the IT staff? The second is, how can we stop all of the shadow IT [he called it ‘rogue IT’] that’s going on in the company?”

My answer was, and continues to be, pick one. If they’re really your customers you have no business telling them they can’t do what they want to do. It’s the difference between being a restaurateur and a dietician.

And even that answer is less than the best, because neither one is a particularly good idea. So pick neither.

There are no internal customers, as regular KJR readers are tired of reading by now, and anyway, the word “customer” is superfluous. Instill a service attitude and have done with it. “We’re here to help everyone else take care of the people who pay the bills … the company’s customers,” does the job just fine.

Meanwhile, IT’s attempts to stop shadow IT are like squeezing a closed tube of toothpaste. The toothpaste just moves around inside the tube, just as shadow IT is moving from the PCs hard drive to the cloud.

We used to be able to pretend. We’d lock down the desktops, hoist up the landlubbers, and congratulate each other over having followed security best practices.

We can’t pretend anymore, though. Back when, we were able to prevent the sales force from installing Act! on their laptops, thereby reducing an already-minor security risk while helping make sure the company’s revenues were smaller than they could be.

That was then. This is now. We can still lock down their laptops, but we can’t lock down the cloud, which means that while we can stop the sales force from buying Act! licenses ($550 each one-time), the only way to stop them from “installing” Salesforce.com licenses ($780/year ongoing) is to use a website blocker, which means the cost of blocking Salesforce.com (blockers aren’t free, and someone needs to administer them too) probably exceeds the cost of buying Act! licenses.

Here’s what kills me: Salesforce.com has to have the most amazing PR machine in history, because the usual cant about Software as a Service is how much more economical it is than the usual IT-installed solutions.

And lots of CFOs believe it!

There are, at a rough level of analysis, two types of CFO. One understands only costs, and sees IT as the company spendthrift, always trying to increase them; the other understands both the concept of investment and the value of better tools.

The CFOs who believe the “the cloud saves money” stuff are mostly cost-CFOs, I think, probably because:

  • It fits the IT-as-spendthrift narrative they’ve already bought into. Few people scrutinize statements they agree with.
  • As Salesforce.com charges are paid monthly, and out of the Sales Department’s budget besides, they’re pretty much invisible, even though they’re a helluva lot higher.
  • IT has locked down the desktops to stop shadow IT, which means IT has to buy the Act! licenses (there’s that spendthrift thing again), handle the installations, and support the users (we’ll have to hire more staff).
  • Because we’re IT and think this way, we’ll first do a bunch of business analysis to determine whether Act! or an enterprise CRM suite would be a better choice.
  • Also because we’re IT and we think this way, we’ll do more business analysis to determine how to configure the solution we decide on to fit the company’s sales process, and to integrate it into whatever other systems it has to integrate into.

By the time we’re done, Salesforce.com costs a lot less … not because it has to, but because we’re so determined to stamp out shadow IT and do things “right.”

Imagine that instead of trying to stamp out shadow IT, we embraced it. The sales director would have told us that many of the sales reps wanted to install Act! Is there any problem with this?

No. No problemo, so long as they’re willing to be self-supporting (just as they are with Salesforce.com) and aren’t looking to integrate Act! into any of the company’s other systems.

And if Sales wants IT to provide integration and support? That also isn’t a problem, and costs the same whether IT is integrating and supporting Act! or Salesforce.com.

There are three bottom-line “goods” in any business: Revenue, cost, and risk. Stamp out shadow IT and you’ll reduce risk a bit. Embrace it and you help improve revenue and cost.

Tough choice.