Project Management and Task Switching

Human Task Switching is Horrible for ROI

Loosely Coupled Human Code Factory — Fri, 11 Jan 2008 23:24:09 GMT

Some people get it, some companies do, some other don't, and it really goes to show on the company's...

re: Project Management and Task Switching

Ben Adams — Mon, 25 Jul 2005 21:03:00 GMT

I concur.

re: Project Management and Task Switching

Eli Robillard — Wed, 20 Jul 2005 21:18:00 GMT

Ryan, that's true, though I'd consider those issues at the project level and not the task level. Let's say for every person and every month a project lasts, I expect a total of three days lost for health or personal reasons. Again, that would at least be a standard and I'm now not padding individual tasks. Would that be a good way to account for the interruptions you're thinking of?

Bil, I agree -- Agile methods tend to be free of the issue by nature. Each team member is accountable on a daily basis to promise and deliver, therefore the pieces are small enough that expectations will tend to be realistic and met. And predictable is good.

I suppose the hypothesis could be stated "In non-Agile shops that use MS-Project-style planning, Task Switching _dominates_ the controllable reasons for PMs to pad estimates," and the questions are a) is this valid? and b) does this work to simplify and/or standardise project planning?

re: Project Management and Task Switching

Bil Simser — Wed, 20 Jul 2005 19:25:00 GMT

I don't like padding but tend to break down the work into really small pieces. This takes a bit of work up front but you end up with a set of bite size units of work that, even with an interupption or two, will never extend past a half-day. Maybe there's something that will take two days overall but it's really 4-6 smaller tasks. I don't communicate the smaller tasks, just the overall goal of the story (assuming you're following an Agile practice).

This has the advantage of two things. First, I can manage the time much better and if I have to pair up or spend time designing or architecting, I know the boundary I have to work in and the end goal. More often than not, people put tasks down that they have to do (build GIN/GO system) but really don't understand the extend to which they need in order to build a solution. Second, I can show progress and velocity with this as long as I stick to it. It's like going onto a strict diet. If you stray from it and gobble down that bag of chips, it may only be 100 calories today but will cost you days of effort to make it up. There needs to be a good balance of understanding, design, and implementation and it's not something a lot of people can do (certainly junior developers are horrible at it).

I personally wouldn't get too over analyitical with the numbers on tasks and the fact that spreading something out over multiple days will add 20% to it. I believe as long as you have a clear goal and know the work ahead (doing some upfront analysis, even in Scrum we don't just dive in and start coding) it will work out in the end. With a Scrum type approach you do daily checks at your stand-up and after 3 days if the task still isn't done and you're burning a lot of cycles it might be an indicator to take it out of any critical path and re-assess just how big it really is.

re: Project Management and Task Switching

Ryan — Wed, 20 Jul 2005 18:07:00 GMT

I totally agree -- but I think this is a very technical developer's perspective. Meaning that when dealing with humans, there are many reasons for variation, and this is one. Your mood or stress from something non-work related, lack of sleep, etc... are all factors that might affect you. That's why I like padding. Sure there are unknowns, but padding is a human factor. Maybe it would work to pad tasks GIN/GO style with a little more 'room' for other mental conditions.