Want less to do? Kill projects that are already dead

Some projects are on the books, suck in lots of capital and effort, and have no chance of succeeding. Kill them all, kill them dead, kill them without regret

When you have less, you have to do less. High on your priority list should be to invest as little time and capital as possible on losing propositions.

Of course.

[ Learn all about the concept of doing less with less the Slow IT way. Rant on our wailing wall. Read the Slow IT manifesto. Trade Slow IT tips and techniques in our discussion group. Get Slow IT shirts, mugs, and more goodies. ]

Some losing propositions are hard to spot, but many are easy to identify. High on the list are projects that have no chance of success.

And by "success," I don't mean completion. It's easy to complete a project -- well, no, it isn't. Relatively speaking, though, it's easy when you compare what's required to complete a project with what's required for the project to succeed.

Here's the difference: Completed projects produce all of the deliverables described in the statement of work, in accordance with their specifications. It's nothing to sneer at; accomplishing even this isn't easy. But completion doesn't matter unless the deliverables are put to productive use in ways that change and improve how the business operates. That's what's required for success.

So how you can identify projects that will never succeed? Here are some indicators:

  • Big size, long duration: Any project with more than seven core team members and a completion date more than six months after its launch date is questionable. Any project with more than 20 core team members and more than two years to get its work done has a chance of success that is technically greater than zero -- but not by very much.

To be fair, you probably shouldn't kill these. What you should do is break them apart into a collection of separate small projects, each with no more than seven core team members and six months from start to finish. You won't officially be doing less with less, but you'll be doing the same with less, because two-year projects engender a very relaxed attitude. They also let slackers hide behind the herd, so by breaking big projects apart, you'll get more out of each staff member.

While you won't be doing less with less, you'll be doing the same with less -- not a bad result.

  • No sponsor: Sometimes it's easy -- no business executive was willing to step up to the plate and sponsor a project, and because it was important for the company, the CIO (you?) had to do it.

Forget it. You'll be able to bring the project to completion. But you won't be able to bring it to success, for a very simple and obvious reason: A project's deliverables are just means to an end. The end -- the goal -- is business change.

Business change is hard enough when high-level executives are willing to stick their necks out and take risks to make it happen. If no business executive wants change enough to sponsor the project, it won't lead to any useful result. Ever.

Bring these projects in front of the executive committee (or whatever group is responsible for project governance) and suggest, politely but forcefully, that since nobody seems to want the project's results enough to serve as sponsor, the company should invest its resources in something else that business leadership does want.

  • Bad sponsor: Sometimes it isn't so easy. Sometimes a project has a SINO -- a sponsor in name only. These are easy for a project manager to spot: The sponsor is never available for update meetings, ducks important decisions that are beyond the authority of the project team, fails to commit members of his or her staff to the project (or does commit them but doesn't make sure they show up when they're needed), and informs the project manager when issues arise, "That's your problem and I expect you to solve it."

SINOs are the folks who figured out that while advocating bold change is a career builder, implementing bold change is the sort of risk only losers take on. When the project wraps up, SINOs will explain that the deliverables don't do what they need them to do, blaming the project manager and project team for the mismatch.

Dealing with SINOs won't be easy. As a class, they're better at company politics than you are, so you have to find a way around them that doesn't force you to outplay them at their own game.

Your best bet is to promote a new philosophy to the executive committee: Because all projects are about business change, all projects must include the tasks, deliverables, and participation required to make business change happen. It should be an easy sell. Once you get their approval, instruct your project managers to make the necessary changes, which means the project plan will now include specific tasks that have business participants' names on them.

If they don't show up, you're in a much better position to recommend to the executive committee that because the SINO clearly can't spare enough staff time to make the project successful, the company is better off cutting its losses than continuing.

  • No point: In the end, businesses experience only three forms of benefit: increased revenue, decreased costs, or better-managed risks. Any other supposed benefit is either a means to one or more of these ends, or it isn't a benefit at all.

It's up to the sponsor to identify the benefit, commit to it, figure out how long it will take to show up, and explain how everyone will be able to recognize it when it does.

Cost-cutting is the easiest to measure, of course, but that doesn't make it the most important -- revenue generally wins that award. Regardless, if the executive committee doesn't already enforce the discipline of "no revenue, no cost-reduction, no risk management, no project," then it should. Encourage it.

You already have less -- primarily, less staff, so doing less isn't an option. It's an inevitability.

And if you're going to do less anyway, the first items to toss are the ones that are worthless.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies