HomeIndustry Commentary

Never mind shadow IT. How about shadow projects?

Like Tweet Pin it Share Share Email

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.

Comments (5)

  • I think declaring all (even most) of these are high reward low risk is not necessarily correct. Many of them are in fact not consistent with the total business activity. Just because some guy has budget to spend does not mean he is optimizing the whole business. I firmly believe suboptimizing some piece of the total business may or may not be good for the whole business. Certainly the point about having a dedicated sponsor is right on, however. I think the real question is not project management. Most of these are small so they get done. The real question is does it deliver true value or is it one more piece of unnecessary noise.

  • An estimate would be 50% shadow projects. Not IT but engineering that usually somehow involves IT because of our remote nature. Many of our customers don’t want formal projects because they believe it will cost them more but if it is done on the field level, there is a cost advantage. Never mind that eventually it is shifted to Technical Support because long term the field staff cannot maintain the end result.

  • Good thinking. Many years ago, while working as a Senior Manager (Consultant) for Arthur D. Little, Inc. I asked for and had to justify replacement of my clunky old IBM PC/AT with a newly released IBM ThinkPad. At the time, none of the IT department had even seen a laptop computer before. My line supervisor supported me, and over the IT objections I was the proud owner of a ThinkPad with a 10.5″ screen and a “Butterfly” keyboard. I think it had almost 10Mb of hard disk space, but an external floppy disk drive. Later, I acquired an external CD drive and external hard disk. I used that configuration for almost 6 years without a failure. My boss was influential in the decision to buy a laptop, and my success was influential in the company IT department’s decision to equip all consultants with laptops.

  • I totally agree that’s it’s best for the organization to educate these accidental (post shove) project managers, I don’t even mind that this totally sidesteps the portfolio management process that was, as I recall, initiated in response the problems like: duplicate projects, zero value projects, shortage of resources on approved projects, etc. The problem rests with getting buy-in from IT. IT doesn’t really care about these shadow projects, because why would should they?

    In their worldview these shadow projects are direct competitors to the approved projects that put food on their table. IT groups are shared resources and have budgets, lists of goals, and customers (yes the dreaded internal customer) to satisfy. Customers that pay for their services through some sort of tax or directly with a charge back. If IT spends its resources helping the shadow projects succeed they undermine the argument for their own existence. Customers see their IT projects running a gauntlet of approval steps like: business case reviews, alignment with strategic goals, evaluation against competing projects from other departments, requirements gathering, QA, UAT, etc. while the projects they fund directly (and discreetly) are completed (or fail) quickly and cheaply. Why wouldn’t they think they could do it better on their own.

    When you know that your customer is already thinking this way the last thing you want to do is help them avoid using your well-oiled super nifty (because you created it) portfolio/program/project/product methodology. There is no metric IT is measured by that will tick up if those shadow projects succeed more often, no list of successful implementations for IT to report out, no shared lunchroom humor at the expense of those bumbling fools in finance who (snort, gaffaw) tried to implement a cloud based collaboration tool and failed miserably.

    So you fall back on the tried and true “Guys we’re all in this together, if you help these projects succeed we as a business will be better off, your friends in finance will do great things, can’t you just pitch in and help?”

    Good luck with that 😉

Comments are closed.