Shield Performers when Work Is Not Ready
March 30th, 2004 by HalPromises and Prescriptions
Part 5 - Set a Priority to Eliminate Multi-Tasking
I agree with Frank Patrick whole-heartedly on this. Multi-tasking is a the primary source of waste in professional services firms. We have our attention on keeping people busy all the time. And then we go measure people on that. It's no wonder that those same people are starting and stopping tasks. We've got to stop multi-tasking before we go broke!
At the portfolio level, prioritize and launch projects only at the rate that the system can absorb them. If you try pushing ten pounds of project through a five-pound pipeline, you won't even get five pounds of successful projects through to the end.
Here's what you can do: adopt a hard and fast rule. Staff are not allowed to start a task that is not in a condition to be finished. That way, the only stopping is when the task is completed. Now, the action for you as project manager is to see that tasks are queued in a ready state for work. That's no small task. However, profits will soar and customers will be delighted!
Related Posts
- Bringing New People to Your Project Needn’t Be Hard As project performers come and go you'll need a strategy for them to be successful. Johanna is ready to help. Read h...
- Lower Utilization to Reduce Variability I've been writing about variability and uncertainty for the last few days. Someone asked, "What do we do when we are al...
- Fool Me Again and Again! Task durations depend on the quality of the conversations. Schedules are not commitment. We have been fooled enough ...
- Projects, Planning, and Promising (Back from Colorado) Here's a synopsis of the Projects, Planning, and Promising lecture at CSU. I started, rather than finishing, with my re...
- 5 Practices for Managing (Constrained) Projects Successfully Projects are always constrained. Accept it. Now what? (Day 5 in the TOC series.) We've discussed three types of cons...
April 2nd, 2004 at 7:48 pm
Hal,
One practical approach is to invert the task list and time box the work. We do this with a “hanging PERT” tool. Define the deliverables for the iteration. Anchor the iteration deliverable day. Assemble the tasks needed to get to the deliverables in reverse order. This is hard to see in words, but imagine a milestone that says (and milestones are always nouns, tasks always verbs – the you can read the schedule as a statement of work) iteration completed. What pre-conditions are needed to make that noun be “true?”
Logic would tell you that the pre-conditions them selves have to be whole – that is fully functional entities that can then be assembled into a deliverable. Keep working backwards in the iteration until the start date of the cycle. That’s all the work you can do.
Resource loading is this simple. No one is waiting for a pre-condition.
NOW the problem is that individual people may run out of work for that iteration (assuming they have single specialties) and therefore need to multitask either in support of another parallel cycle or make work ready for the next cycle.
In the end though serializing work through the avoidance of multitasking – at least in software development – is a very bad idea.