I've been thinking about why people should ever change projects. The longer they're on the project, the more familiar they are with it, and the more effective they are. We might draw this on a graph, with productivity increasing over time:

increasing productivity as people become more familiar with the project

However it's likely that for a brand new project, there might be some initial work to do before they really get going: studying the problem, building some models, designing a solution, etc. So let's draw this in this way:

initially the team is unproductive as they set things up

I'd also guess that for many projects, things are prioritized so that the parts with the best benefit/cost ratio are done first. That means as time goes on, the things the team is working on are less beneficial, or higher cost. We could draw it in this way, with cheap wins coming first:

do the best cost ratio things first

What's the combination of these three? On one hand, people are becoming more effective over time. On the other hand, the things that being worked on are less important over time, because the most important things were done earlier. I multiplied the above three graphs to get this:

combined productivity

In this model, it takes some time to get going, but once the team is going, they're getting a lot of good stuff done. But eventually they end up working on less important or more difficult things. When should the management start moving people to new projects? I don't think you want to switch as soon as you pass the maximum effectiveness, because there's plenty more to do that's valuable. But eventually the things they're working on are just not that important compared to the contributions they could be making on another team, and I think that effect will overtake the effect of people becoming more knowledgeable about their current project. I just don't know how to identify that point in time.



Anonymous wrote at Sunday, April 18, 2010 at 9:14:00 PM PDT

interesting! i've only switched projects voluntarily a couple times now, as opposed to at artificial points in time (e.g., finished school, sold a company), but i can definitely identify with the idea.

incidentally, i recently switched projects again. i'll see how ramp-up feels on my new project, and if i can identify when i hit different points on the curve.

xaminmo wrote at Monday, April 19, 2010 at 3:10:00 AM PDT

I completely agree with this assessment. I'm a travelling computer consultant, and when I get plugged into a long running project, there's some acclimatization, then some hard work, lots of progress. This ties into getting things working and general interest because it's new. Once functionality is reached, interest wanes. People forget it's "incomplete". Daily activity isn't usually impeded. Etc.

Occasionally, there's a bigger dip on the left side of the curve due to technological roadblocks, but in reality, the curve should extend to the right substantially. The fade off is about as steep, but the last, say, 10%, is easy to drag out over 10x the duration of the whole project.

So the key is to know where to focus your energies, and to have an exit strategy. Usually, that involves having administrative or operational staff begin taking over about 25% down the backslope. By about 50% down, they should be doing everything, and just talking to the initial project folks for occasional questions. Once you're 75% down, the admin/ops staff should be running everything.

Nikhil@Ted wrote at Wednesday, May 19, 2010 at 6:58:00 AM PDT

Amit, I like the simplicity of the "who times what = output". There is class of projects that this describes quite well. I'd suggest a third multiplier, "motivation". Even if you don't know the exact point to switch, your model at the very least helps qualitatively classify projects into those that require faster switches and those that don't.

Anonymous wrote at Tuesday, July 13, 2010 at 7:53:00 AM PDT

I suppose this model depends on the type of project worked on.
In game development, you would never consider optimizing code until you are near the end of development since you won't know until then what are the true bottlenecks. Then there's also finding and eliminating remaining bugs. These two tasks are very important and beneficial to any game, it can make or break the project.
Also, things that are riskier are usually done earlier in the projects, this way if the feature fails there is time to recover from it.
For these reasons I believe that your 3rd diagram is flawed. With over 10 years as a dev guy on games, I've always found that team sizes explode as you approach the end of the project.

Amit wrote at Saturday, October 9, 2010 at 11:22:00 AM PDT

Anonymous, yes, I agree. I hadn't been thinking about the game development model. Most games are developed, shipped, and then forgotten about, whereas a lot of other software is maintained for a long time, with periodic updates. It's for software like Microsoft Word that I produced that graph — you start with basic features that everyone needs, like entering text, paragraphs, formatting, etc., and later on you end up working on more features that are less important, such as dialog boxes that let you change the color of the squiggles.

JAL wrote at Thursday, October 14, 2010 at 7:19:00 AM PDT

This theory would apply to all activities in general?

Bemmu Sepponen wrote at Friday, April 20, 2012 at 6:26:00 PM PDT

The more important the project becomes, the bigger the gains from small improvements. If you start on a project that makes $1k / month and expect it to exist at least two years, spending a month to accomplish a 15% improvement might be justified.

If you managed to make five such improvements and got the project to bring in $2k / month, then after that even a 7% improvement would be worth chasing after. As you would improve it more and more, even though gains would become more difficult to achieve, they would also be more worthwhile.

Amit wrote at Friday, April 20, 2012 at 10:49:00 PM PDT

That's a good point Bemmu. A small change in a widely used or long lasting project can have more impact than a large change in a little used or short lived project.