Excellent Johanna Rothman article on the perils to the Project Manager of Multi Tasking ([Context Switching]). 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. I'll go a little further, and say that many "less important project" should never get done, because they really aren't important (hmm, a variant of Buy Build Avoid). On the other hand, sticking to just one project at a time is really hard work (for me).

Bill, are you talking about sticking to just one project or just one task? I find that I enjoy doing several different tasks for a given project. When I'm working on a software project, I have trouble working on multiple projects, especially if I'm working at different levels (design on one project, debugging on another, project managing on a third). I even have trouble project managing more than one substantive project, because inevitably, both projects need me at the same time. --Johanna Rothman

• Bill Seitz says: even sticking to a single project is tough in a small start-up environment because almost every activity is a (small) project, and there are lots of them around, and each project involves at least 3 people, each of whom is working on multiple projects, so everyone's juggling. Of course, this can become a rationalization...

User Options Recent Changes Help Page