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:
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:
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:
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:
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.
Labels: economics
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.
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.
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.
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.
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.
This theory would apply to all activities in general?
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.
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.
Post a Comment