Improve quality of code by changing staff

In the not-so-distant past, I worked on a small project and reviewed staffing with the project manager. The project was a C++ application that was a component in other systems within the organization.

The code and the procedures were complicated. A new member of the team required at least six months before he or she could be productive, and often the "ramp up" time was closer to a year.

I discussed many issues with the Project Leader. At one point, we discussed the expected tenure of a team member. We agreed that it should be about five years.

Simple math shows that for an average tenure of five years, a team of ten people should "rotate out" two people every year. This project manager did not understand that calculation. More specifically, the Project Leader was unwilling to "swap out" two people of the team that year. This makes some sense, since the two replacement folks would require the better part of the year before becoming productive.

And swapping out another two people in the next year would mean that another two newcomers would need the better part of a year to come up to speed. With my "average tenure of five years" plan, every year would see two newcomers and those newcomers would require time to become familiar with the procedures and the technologies of the project.

So while this Project Leader agreed with the idea of a five-year tenure for team members, she wanted to keep people on the project as long as possible -- and more than five years. Extending the tenure of a person on the project reduced the cost of training a "newbie".

Yet a set of newcomers may be a good thing for a development project. (And perhaps any type of project.)

With a steady influx of new members (and a steady departure of experienced folks), a project must make accommodations for the newcomers. When a project is so complicated, and so difficult to learn, that it takes the better part of a year before a professional skilled in the craft can be productive then adding team members is expensive. The desire to hold on to experienced staff is large.

A project that has a lower "ramp up" cost is better prepared to accept newcomers.

So is the "ramp up" cost high because project difficult to learn. or is the project difficult to learn because there are few newcomers (and therefore little incentive to design the project to be friendly to newcomers)?

The implicit assumption is that the complexity of a project is an innate quality of the project, a result of the requirements and technology. I don't think that is quite true.

Let's turn the idea on its head. Let's work with the premise that the complexity of a project (its processes and its code) is an attribute of the project and one that can be managed, much as the total cost, delivery schedule, quality, and total effort. Therefore, the complexity of a project can be controlled by the project managers. As an attribute, the complexity can be measured and reviewed, and managers can direct changes to ensure that the complexity stays within expected values.

If managers can control the complexity of a project, then they can control the "ramp up" cost for new team members.

Of course, managing the complexity of a project means adding it to the other attributes of a project. There is no free lunch, and devoting effort to one attribute means less effort to other attributes. Reducing complexity may mean less effort for quality assurance, or less effort for support. It may even mean a longer development cycle.

I'm not saying that complexity can be managed for free. I'm asserting that complexity is an attribute of a project can can be managed. How one trades off effort of one attribute against another attribute is what project management is really about.