أخبار
Want less to do? Kill projects that are already dead 
8/8/2009

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.

 

4