Do much less with less: You’ll deliver more value if you do

Here’s a near-universal diagnostic you can apply in just about every circumstance of your life: Whenever you hear anyone say, “It’s really quite simple,” figure the odds-on proposition is that the speaker is too entirely ignorant to be worth listening to.

Having said that, the following suggestion really is quite simple, except for what it will take to make it stick: Only take on as many projects at any one time as you can fully staff.

[ 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. ]

Everyone who knows what it takes to manage projects successfully — and I do mean everyone — agrees on this point: When employees have to divide their time among multiple projects, all the projects suffer. The exceptions are the obvious cases where there isn’t enough work to do on one project to keep the employee busy.

Other than that, when employees divide their time among multiple projects, two separate factors cause project delays.

Delay factor 1: Switching gears slows us down The first is that switching between projects isn’t an instantaneous cognitive process. Getting one’s head out of one project and into another takes real time.

This wouldn’t be a major issue if the “when” of switching was up to the employee. Then it would be simple: Mondays and Wednesday go to Project A, Tuesdays and Thursdays go to Project B, and Friday is reserved for administrivia, non-project-related responsibilities, and project-related miscellany.

That, however, isn’t how it works, because by definition projects involve more than one person. With few exceptions they serve multiple stakeholders, and for the most part involve people working as a team, not as a collection of independent individuals.

All of this means that while an employee is working on Project A, the phone sometimes rings, the chat window sometimes opens, or an urgent e-mail pops in regarding Project B. Depending on the exact nature of the various projects an employee is committed to, the result can be serious time lost to gear-shifting.

Sometimes, of course, the employee will decide to ignore all distractions. It seems like a reasonable decision, and for the employee it is. She is on the hook for getting a task done on time, and allowing interruptions can prevent this.

Which means a team member on Project B will be stalled on his task until he can get the first employee’s attention.

There simply is no way to orchestrate multiple projects that share the same staff in such a manner that both proceed smoothly, without interfering with each other.

Even if there were, it still wouldn’t be the best decision for the business, because (for example) even without the impact of gear-shifting and delayed replies to inquiries, nine concurrent projects that share staff must take at least three times as long as three concurrent projects that each have dedicated staff.

Businesses rarely see any benefit from a project until the project finishes. With the second scenario — three concurrent, fully staffed projects that get done three times more quickly, the business will see its first benefit in one-third the time it would see any benefit with nine concurrent projects, each of which getting only one-third of each participant’s time.

In other words, the company will get more benefit in two-thirds the time.

Delay factor 2: Sponsor conflicts So the business would be way ahead with respect to its return on investment by launching only as many projects as it can fully staff.

Simple, right?

Wrong, which leads to the second delay factor: the fact that each project has a sponsor. That sponsor wants his or her organization to get its benefit first, for business, political, and personal reasons. The business reason is obvious; his or her organization needs what the project will deliver, and it will run better when it gets it.

The political reason is almost as obvious. Being first in queue is an indicator of the executive’s status in the company’s social hierachy — and who wants to be anywhere other than the front of that line?

The personal reason isn’t particularly obscure either: Even in the absence of the business and political ramifications of coming in last, there’s the minor matter of the executive’s ego, which will be shouting, “What about me? Why do I have to be the one who waits? The CEO must like these other people better!”

Doing less with less requires political skills It’s an old rule in business: What’s good for the business will happen only if it’s good for someone in the business.

Taking on fewer projects — doing less — with the smaller number of IT staff you have right now (that’s the “with less” part) makes all kinds of business sense. That’s simple and obvious.

Making it happen in your company is going to take political dexterity and quite a lot of persuasion.

How you’ll go about this is neither simple nor obvious.

It is, however, what you’re paid for.