All Posts in Project Management

|In: Project Management|Last Updated:

I’m still on vacation (and will be for another week). I won’t be in a position to post a re-run tomorrow, so I’m sending this one out early. I don’t think anything in it has become at all stale, so give it a read even though you might remember it from 10 years ago. – Bob

# # #

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

|In: Project Management|Last Updated:

Last week’s KJR introduced 20 ways of thinking something through, beginning with Outline Thinking and wrapping up with the satisfying but unilluminating Ridicule.

Honesty requires this disclaimer: While I’m quite sure none of these are original, I’m even more sure I didn’t plagiarize someone else’s list. The only credit I can claim is that of the numismatist: I don’t know who stamped these coins, and the only credit I can claim is that I’ve collected them.

Some of you asked for a deeper look at the 20 ways. And while I might stop at 19 – I doubt the world needs techniques for creating better ridicule – I figure starting with Outline Thinking – the first item on the list and arguably the most useful of the bunch – is a safe, if dull bet.

Outlining is top-down decomposition. It’s tempting to stop there, making this the shortest KJR ever posted. But that would be wrong.

Outlining is the tool of choice for documenting your understanding of a subject – of the details and how they fit together.

A successful outline begins with a good subject. It then breaks that subject down to between three and maybe nine topics that are of the same type, and which, taken together, fully encompass the top-level subject as viewed from that perspective.

For example, the subject of your outline might be a project you need to organize. You’ll have to address a number of different topics. For example you’ll have to think through the project team’s composition … that is, the roles you’ll need on the team to do the project’s work. Then there are the work products its team will have to produce to accomplish the project’s objective and goals.

And, not to be ignored, you really ought to figure out the tasks the team will have to execute to create those work products.

To figure out what these tasks are, the project manager will need to outline them. The project management buzzword is “work breakdown structure,” but don’t let that throw you – it’s an outline. So far so good.

You start the process of organizing project tasks by answering the question, “What are the tasks that make up the project?” That results in a top-level view of the project task outline, as shown in the box at the top left in the figure below, taken from the demonstration project used in Bare Bones Project Management – implementing a warehouse management system.

Figure: Outlining is progressive decomposition

Next, you ask the equivalent question about each project task that you asked about the project: “What are the sub-tasks that make up this task?” The figure’s middle box shows the result for the “Gather data” task, re-casting Gather data to Gather information requirements to help clarify what will be needed. In a real project you would ask the same question about every other top-level task, too.

The figure’s lower-right-hand box shows the result of taking the Conduct interviews sub-task to one more level.

Then you would continue until you run out of sub-sub-sub etcetera tasks. Or, if you’re smart (and lazy, but that’s just saying the same thing twice) you’d delegate the rest of the outlining to the experts on your project team best-suited to do so.

Bob’s last word: As you can see, outlining is an excellent tool for thinking a subject through to understand it better, whether the subject is project tasks, the components needed to assemble a piece of Ikea furniture (pro tip: yes, an Allen wrench is a necessary component, but no, it isn’t a sufficient one), or a meal.

What makes it such a useful tool is that it lets you understand the subject you’re figuring out at whatever level of depth you need, without having to keep all that depth in your head all at once.

Outlining, that is, is a terrific way to keep your head from exploding.

Bob’s sales pitch: Speaking of thinking, The Cognitive Enterprise, which I co-authored with my colleague Scott Lee, is, so far as I can tell, the only business book with “cognitive” in the title that isn’t about applying artificial intelligence to business situations. It asks what we think is a more profound question: What would an enterprise that acts purposefully look like – one that has more in common with predators than with ecosystems – and how would you build one.

Comments