In the past, if you worked on a factory assembly line you did one job. You did it very well. You tried to do it as quickly as possible without making errors. Workcells on assembly lines changed this somewhat. Now you may do 2 or 3 things, but you generally aren't trying to do all of them in parallel. That simply wouldn't be efficient. I can just imagine the chaos that would result if the person installing the steering wheel of a car was also trying to install the front seat at the same time. I get this funny picture of them pushing the steering wheel on with their hands, while they are tightening some bolts with the wrench they are holding between their toes. Maybe that isn't what you envision, but I'm sure whatever you thought of was equally funny.

Why is it that software development is looked at in a completely different way. As software developers, especially in larger organizations, it is not uncommon to work on 3 or more projects at the same time. Somehow we are expected to make reasonable decisions about how much time to spend on each project, keep each one straight in our heads, sometimes reporting to 3 different individuals, and create quality software in the midst of the chaos. Why do we get into this position? When I ask that question, most companies say it happens because they have 3 (or more) projects that all need to be completed at the same time or that they have key people needed for several projects at one time. Does that argument actually make sense?Let's say it is 9:00 in the morning on a workday, and you have 3 tasks that all need to be completed before a noon lunch meeting. Let's further assume that each task is one hour in length. How do people attack getting them all done by noon? Most executives will say they spend 5 minutes on each one and keep rotating through the tasks in this way until they are all completed. OBVIOUSLY that isn't what most executives say they will do. I have yet to meet a person that said they would do anything other than completing the first task, then moving to the second, completing it and moving to the third until it was completed. In this way, all tasks will be done before noon, with two of them completed significantly ahead of time. If this is the way we would all handle our own tasks, why do we expect things to be done differently when the tasks equate to projects, and the hours equate to months or even years?

Most people are not capable of working on things in parallel without paying a cost in productivity. It seems that companies are trying to keep people utilized 100% of the time by having them work on multiple projects, but they are not taking into account the loss in productivity due to frequent task/project switching. We all have been guilty of overlooking this overhead when scheduling work. For example, when there is a shared resource issue, how often do we hear something like "Fred can work for Team A 20% of the time, Team B 50% of the time and Team C 30% of the time." We hear that, but for most of us it doesn't trigger the thought that they have overassigned Fred! How can he not have overhead from being on 3 teams and constantly switching tasks/projects? All we care is that 20% plus 50% plus 30% is 100% or lower - if the math works, then Fred has the time and can do it. At least that is our thought process, but when we look at it carefully, we recognize that is not true at all. Yet we let people get away with this method of scheduling resources!

There are times when working on multiple projects can be justified. As an example, there may be times when access to a particular resource (extremely expensive hardware for example) is contrained and for the team to continue to move forward it needs to switch gears and work on something else. The point I am trying to make is that most companies tend to think of multiple projects as the norm instead of as an occasional exception. At Net Objectives we work with many different software development teams each month, and we constantly hear people complain about working on multiple projects, all of which are behind schedule and the reduction in morale as well as productivity is staggering. When employees are complaining to trainers and coaches about something like this it has generally reached crisis stage. Fortunately, most of these conversations happen with clients that have called on us to help them change things because what they are doing is not working. In fact, Alan Shalloway writes about this in an earlier blog called Challenging Why (not if) Scrum Works.

When companies that suffer from "multiple concurrent project disorder" look at the projects they have in process, prioritize them so that the most important ones get worked on first, then do them one at a time, they inevitably get positive results. They improve employee morale. They empower workers in ways that enable creativity rather than stifling it. They get the important things done sooner, which shows employees and the world that they understand the needs of their marketplace. People are no longer overscheduled, so they create higher quality software. Perhaps most importantly, the highest priority items being delivered faster means the company starts making money from those projects earlier! In my 20+ year career, that inevitably leads to important insights that end up changing the priority of other items that are further down the list - projects that would have actually been in process and difficult to change if they were all being worked on simultaneously!

I know that this whole concept sounds ludicrous to some people. For a single individual, I am quite certain that working on multiple projects causes more problems than it helps solve. For development teams this is probably 99% true. As the size of the organization increases, it's percentage applicability gets lower. For example, no one would say an organization like IBM should only work on one project at a time. What I am saying is that teams and individuals within IBM should only be asked to work on one project at a time in order to most effectively utilize them.

Next time you have a choice of scheduling more projects, or working on projects sequentially, you should carefully consider the tradeoffs of each approach. Having people work on more projects simultaneously will not suddenly allow 10 pounds of stuff to fit in a 5 pound bag. In fact, it is much more likely to allow you to only fit 4 pounds of it into a 5 pound bag, rather than the full 5 pounds you could fit if you placed items in the bag one at a time!

Searching for "multiple concurrent project disorder" does not give any hits on Google. Did I just invent a new disease??? Maybe my next blog entry will be about the various diseases specific to software organizations. Do you have any suggestions for me? If so, leave a comment. I'm sure we can all start spouting psychobabble about new diseases in no time.

Technorati Tags: Lean-Agile

tag with del.icio.us