Project Management and Task Switching

At Eidenai we're working in the third milestone (M3) of a portal project for a major manufacturer. My methodology is to scope the milestone by reviewing both the planned features for M3 and the features we agreed to drop from earlier releases, identify priorities, identify available resources, break the work down into tasks, and the order the tasks according to priorities and dependencies. 

I sent the task list to our Senior PM with estimated durations, who thought the estimates were too tight. People who Project Manage full-time (e.g. PMPs) will pad tasks to allow for unplanned events. I don't like to pad, it doesn't seem like planning. I figure that if the environment is unpredictable, that's an issue and a problem to be solved. But he's right, while my estimates are accurate for each task, the total is low. A way to fix this occured to me today.

I never liked developing in open offices for the simple reason that when anyone is physically able to walk up to ask a question, they will. This is fine for some people (and expected of receptionists and the help desk), but for developers it kills productivity. Getting your thoughts back to the state they were in before an interruption takes time. On average, let's say we peg it at 20 minutes per interruption (which may be low). At that rate, every three "quick questions" kills an hour of productivity. If this happens twice or more in any given hour, that's less than 20 minutes of productive time per hour. This is why companies like Microsoft provide everyone with an office a door that closes. In software development, doors increase productivity.

Task switching takes at least twice the time of an interruption. After finishing something, there's a period of "getting away from it" (after work, how long does it take you to get out of "work mode"?), and when starting something a period of "getting into it." Let's see what happens when we account for this. Let's say Jason has two tasks to finish this afternoon, each will take two hours, and he will start at 1:00. I have one task that will take 4 hours to complete. Assuming the estimates are dead-on, who finishes first? I will, every time, and the difference will be about one hour. The difference is task-switching.

Bridging tasks across days has the same effect -- a 4-hour task split over two days will take 5 hours. This is one reason (of several) why agile methodologies can lead to higher productivity. In agile teams, the question every morning is "what will we do today?" By nature tasks don't bridge days, and agile methods therefore avoid the cost of task-switching. This makes everyone on the team more productive.

For planning, the solution is to set expectations according to the duration of tasks, the number of tasks involved, and the cost of task-switching. This adds a new type of entry to the project schedule -- the Get-In / Get-Out time (or GIN/GO time, with hard Gs). Add GIN/GO time for complex tasks which require deep thought, and less for the simple pieces. As a standard I'd suggest 20 min for GIN and 10 min for GO, for a total of 30 min for a full Task Switch. At this rate, four one-hour tasks will take 5 hrs 50 min ( GIN, task, GO/GIN, task, GO/GIN, task, GO/GIN, task) while two two-hour tasks will take 4hrs 50min (GIN, task, GO/GIN, task).

This approach assumes that the tasks are refactored. What does that mean? 1) Tasks are broken down into units that don't need to be broken further, 2) closely-related tasks have already been merged into single tasks, 3) tasks longer than a day are either further divided, or include bridge time.

This is just a start and I expect these basic ideas will evolve and be extended as time goes on. Agree? Disagree? Do you have an improvement or think the numbers are off? Tried it out? I'd love to hear your feedback.