14 November 2002

by Michael Mah

It’s been said that the great science fiction writer Isaac Asimov had10 typewriters in his basement for the multitude of writing projectsthat he engaged himself with. It’s also been reported that the averageperson can effectively handle only about four concurrent tasks atonce, with the maximum being about seven. Clearly, Isaac Asimovwas a rare exception in humankind.

Which brings me to the issue of continuous partial attention (CPA)and the notion of active multitasking as a way of life, particularly inthe world of IT. Over the years, I’ve worked with a lot oforganizations on the subject of measuring and improving applicationsdevelopment productivity. There’s no doubt that CPA has becomemore and more prevalent in the world of software projects. Thequestion is, what is this doing to productivity? Is there an impact? It seems there may be.

Productivity Drops — Bucking a 15-Year Trend

Recent statistics reveal a significant productivity drop in ITprojects for the first time in 15 years. This was first reportedlast year in the August issue of IT Metrics Strategies (nowCutter Benchmark Review),in an article about productivity trends in a worldwide projectsdatabase maintained by QSM (Quantitative Software Management). Since then, additional data confirms that the “bull market” of risingsoftware development productivity is over (at least for now). CouldCPA be a factor?

It seems that it indeed could be. When we look at the data, onetrend that seems clear outside of CPA is a rising complexity intoday’s IT projects. That certainly has an impact. Most managersI talk to say that today’s applications have more engineering-levelcomplexity and multisystem interdependencies compared to thebatch processing standalone systems of yesteryear. I’ll buy that.

But the other reason seems to be the effects of CPA. I contendthat we may be able to split our time among repetitive-type tasks,but when it comes to knowledge work like software development,we may be finding that CPA doesn’t fly. Many organizations arespreading people over many projects, but they’re finding thatschedules are dragging out.

Over the years during speaking engagements on softwaremeasurement and estimation, I’ve conducted an informal survey ofsorts. I ask my audience, “How many of you are working on morethan four software projects at once?” Nearly all the hands go up. I up the ante — “how many of you are working on more than five,six, seven…? What’s shocking is how often that number nowexceeds 10, and it seems to be a rising trend.

This is exhibited in project statistics. IT organizations report moreand more “small projects” — most companies don’t do as manylarge projects as they did in the past, especially in the currenteconomy. Today, it’s more typical to find lots of small teamsworking on several releases and incremental builds. And most ofthe folks on these small teams are doing 4, 7, 10 projects at once.

And here’s the rub — productivity metrics have been dropping. We’re seeing more organizations demonstrating levels of productivitycharacteristic of the early to mid-1990s. The bull market inproductivity gains has turned — we’re in a correction. Why mightthis be? Well, in his book, Slack,Tom DeMarco says that when knowledge workers are forced totask switch among say, nine tasks in a given day, there’s a task-switching “penalty” — about 10 minutes lost from the mechanics ofmaking the change. It takes time to pull your mind (and body,papers, reports) from one task, and ramp up on another. If eachswitch wastes 10 minutes, then 90 minutes are lost in any given day. That translates to a 20% penalty for an eight-hour day. Interestingly,that’s roughly the amount of the recent productivity drop from theQSM industry statistics. I’m also guessing that simple tasks maytake 10 minutes to task switch, but on knowledge work likesoftware, it probably takes longer.

What This Means

CPA indeed seems to be doing some damage when it comes tosoftware development productivity. Managers today are going tohave to rethink things like:

Software project estimation — Projects are under more deadline and resource/budget pressure today than ever. If CPA is whacking your IT productivity, and I bet it is (and most don’t know it without metrics), you’re in a jam, big time. Constraints are tighter, yet your delivery rate might be less — you’re going to have to account for this when you estimate projects. If you’re a typical IT shop, you may be doing more small projects these days, but they’re probably taking longer than you’d like them to. If you don’t adjust your estimates accordingly, your promises will be off base, and your projects will miss their dates more often. Many organizations will find themselves either cutting functionality at the last minute to get something out the door or slipping schedule.

Package implementation — More managers will call for trying to buy packaged functionality and build less software inhouse. In some cases this might make sense. However, the downside will be how much organizations underestimate what it takes to implement these packages. It’s often more difficult than it seems, and often there’s still coding to do! Interfaces, bridges, table modifications, etc. CPA will hit these areas too.

Project management — The difficulty of multitasking all these IT projects can potentially create a project management nightmare, and overwhelm many project management infrastructures. Time and effort tracking will be more difficult than before. Organizations will spend more time trying to figure out how to manage this complexity. Most will struggle with it — and still miss deadlines.

Software metrics — CPA may be harming your efficiency but it will be difficult to tell if you don’t measure. If you want to know what’s happening in your organization, you may want to see what your metrics are saying. Start by collecting four core measures for software projects — time, effort, size, and defects. You can establish a productivity baseline and see what trends your numbers are exhibiting, just like an annual or semi-annual check-up.

An Anti-CPA Strategy?

It may pay to seriously consider an anti-CPA strategy if improvingeffectiveness is important to you. While CPA may be possible forroutine tasks, it seems to break down when complex problemsolving is involved. People in a harried state simply don’t thinkfaster or smarter — the complexity of today’s IT projects demandsmore full and less partial attention.

Partial attention may also preclude elegant IT solutions. If we wantmore killer apps that can grow us out of this current economicdownturn, we’ll need the full faculties and skills of a workforce thatisn’t burned out from overtime, trying to do 10 things at once. Organizations that do 5 things well rather than 10 things poorlymight have an edge over their competitors.

Managers may have to rethink how they design their teams. Realsoftware development demands effective teams that gel — theymake better decisions that can produce more value to anorganization than teams that are fractured and split among manymasters. As tempting as it may be to go with the trend of CPA,the progressive manager might want to buck the trend and breakout from the pack, with higher levels of real productivity that ateam overburdened by multitasking can’t match.

— Michael Mah, Senior Consultant, Cutter Consortium

© 2002 Cutter Consortium. All rights reserved.