© 2000 Johanna Rothman
A recent client, Bob, asked me to assess their major project. “Johanna, it's so late, I don't know what to do. If we don't get it out on time, we'll miss the market window. I can't believe any of the estimates I get anymore, the project manager hasn't met a single deadline.” I agreed to talk to the project manager, Sam, and find out what was going on.
I had some trouble making an appointment with the project manager. Sam was very busy.
After a week, we arranged an in-person one-hour interview. I started asking him a number of questions about his project.
After I'd been there five minutes, a project member came in with a burning question. Sam excused himself, and talked to the employee for a few minutes.
We started to talk again, and someone from another project came in with an urgent question. Sam excused himself again, and solved the crisis.
Two more crises interrupted us.
Four people had crises only Sam could solve.
Four different projects – only Sam could help.
I stopped the original interview and asked Sam these questions:
- How many projects are you managing?
- Are you happy with that?
Sam frowned, and said, “I'm only managing four projects. But that seems to be three more than I can handle.” I asked if we could talk for 20 minutes uninterrupted, and he agreed that we would. We took a walk, to get uninterrupted time.
After I talked to Sam, I went back to Bob, and said, “I know how to solve your project problem.” Bob was amazed, “Johanna, you've only spent about an hour here. How could you possibly figure out what was going on in that time?” I explained that I could not understand the projects in that time, but I could understand what was happening to the project staff.
Sam was the original architect on Project A. He was now managing a later release of Project A, and managing releases of Projects B, C, and D. The company had shipped Project A before it was completely frozen. After the initial release, they had more defects to find and fix in Project A. Projects B, C, and D used components from the same code base as Project A. Whenever Project A ran into trouble, the project staff called on Sam to help. Delays on Project A delayed Projects B, C, and D.
Sam was also making project-wide decisions about Projects B, C, and D. Sam was on the critical path for all four projects. Sam realized this, and tried to give each project about 25% of his time. During our walk, Sam told me he didn't have much to do on each of the projects, he just had to clean up a few things, and then manage the projects. After all, he said, if he spent just over a day a week on each of them, he would be out of this mess in a week or two. I asked him how long this shell game had gone on. He sheepishly looked at me, and said “About six weeks.”
Six weeks ago, Sam was couldn't free up more than two hours at a time on each of the projects, but he thought he could fix that in the next week. Five weeks ago, Sam couldn't free up more than 1.5 hours at a time for any of the projects. Each week, he was able to spend less uninterrupted time on any of the projects.
All of Sam's deliverables were late, and all the projects were late, because Sam had not been able to dedicate enough time to any of them when they needed it. Sam was unable to spend an entire day on any given project. He was constantly interrupted. He repeatedly switched context: he stopped what he was doing, remembered the thing someone asked for, and then went back to what he was doing. Instead of 25% of Sam on all four projects, the company was getting about 5-10% of Sam on all projects. See Table 1 contrasting the number of assigned tasks with the percentage of available time a person could spend on each task.
I went back to Bob and explained that context switching led to a reduction in people's performance. He said “Well, if I take Sam off two projects, and leave him on two, will that help?” I said it would help, but he still wouldn't be getting half of Sam on each project, he would be getting closer to 40% of Sam on a project. I told Bob it was time to decide which project was the highest priority, and have Sam work full time on that project, and then work on the next highest priority project, etc. until Sam could finish his critical path work.
Bob reluctantly agreed to do this. Without interruptions, Sam was able to complete his critical path work for all four projects in the next 7 working days. He was then able to focus his energies on the project management tasks.
Sam's context switching was caused by chronically understaffed projects. Bob understaffed his projects by design. He had his reasons: difficulty in hiring people; creating a sense of urgency around projects; and the feeling that if everyone was completely busy all the time, he was getting maximum value from his personnel dollars.
By creating a shortfall of people to staff projects, they were forced to repeatedly start projects with insufficient staff. Every project was staffed with portions of people. Since each person had multiple responsibilities, each person decided when to work on which project. Bob's organization could not take a consistent approach to projects and every project was late.
Bob was concerned that if he made choices about which project was more important, than the less important projects would not be done. I explained that he was ranking projects at a given time, and that his rankings would change over time. He had to make that clear to his staff, but I was sure the staff would understand. Ranking each project, even temporarily, helped the entire organization work together.
People do not context switch easily. It is easier and more productive for people to continue working on the same project, at the same level, for as long as possible. Once they switch to another project or to another activity, it costs time and brainpower to switch. Rank your projects, and make sure people know what they need to do and when. Make sure people work in whole-person increments, if you want to get the most out of your people.
Table 1: Number of tasks and actual time available to spend on each task
| Number of taks | % available time on each task |
| 1 | 100% |
| 2 | 40% |
| 3 | 20% |
| 4 | 10% |
| 5 | 5% |
| more than 5 | Random |
Source: Quality Software Management, vol.1, Systems Thinking, Gerald M. Weinberg, Dorset House, New York, 1992.