23.6. Figure 23.14 shows the task durations for software project activities. Assume that a serious, unanticipated setback occurs, and instead of taking 10 days, task T5 takes 40 days. Draw up new bar charts showing how the project might be reorganized.
Assuming that the project is being done by one team approaching tasks in a linear fashion, there is no reorganization to be done. While T5 takes longer than expected, the project won’t be getting completed any faster by moving things around. As we learned from The Mythical Man-Month, making changes to the team composition mid-project rarely has a positive effect. As such, it’s really better to accept the 30 time units lost than risk losing more by changing the project setup further.
That said, if the team was already split into two development groups, or could easily have it done so, then the distribution could look like this:
Due to the dependencies allowing some leeway in terms of splitting into teams and parallelizing the work, this two-team model almost perfectly breaks the requirements into semi-independent groups. Note, however, the semi. This is for two reasons. First, because at the very end, T15 and T16 are quite linear, so at that time I merge the two groups to finish the project off. Secondly, and far more significantly, the teams are not completely independent because both teams work on things that the other team will eventually require. For instance, when Team 2 gets to T9, T6 will have to have been completed by Team 1 already. Scheduling-wise, Team 1 should have completed T6 a full 20 time units before Team 2 needs it, but if more delays occur in this project, the multi-team schedule will prove increasingly complicated to manage.
The advantage of parallelizing as much as possible, though, is potentially faster overall project completion. In the graphs for the two-team split, I doubled the time estimates for all tasks for each team, as they are working with half the manpower. However, in reality this number could be significantly lower (or significantly higher) depending on the composition of each team and the tasks that they are suited for. For instance, if there are fifty developers on this project, then splitting the teams would absolutely be a good decision; I would want to split them into even more groups wherever possible. But, if we have only a couple of developers with significantly different skill sets, and all of the tasks rely on a mix of all the various skill sets, then I would redesign the tasks to better diversify the skills required, and still split the teams. But if they work really well together and really poorly apart, or if you have only one programmer, then obviously the linear approach would have to do.
The core factor comes down to understanding your people, and organizing the project in the way that best utilizes their skills and creates the least friction. Of course, that’s much easier said than done, but the theory is sound.