How to Add People to a Late Project Without Making it Later

Many of my readers should be familiar with Brooks' Law, as quoted in Fred Brooks' Mythical Man Month:

Adding manpower to a late software project makes it later

The thinking for this statement is primarily that, when faced with tight deadlines, a software development team would spend more time getting new team members up to speed than they would just doing the work themselves. And so, people have taken this statement for granted ever since the book was published. But is it true?

I've had three times in my career where I was the one brought onto a project that was running late (in one case, already past the deadline and over-budget too). In each case, I did something different to bring the project back on track. In all fairness to Mr. Brooks, my experiences were generally for much smaller projects than what he was talking about, but I believe that my experiences could easily be applied to larger projects.

Start small and simple

One project I helped turn around was an internal work tracking application for one of my clients. The project had fallen behind primarily because of extremely aggressive timelines and expectations at the outset. The team really had no chance of finishing the project on time from day one, and unexpected changes pushed the project even further behind. When I arrived, I saw that the team had slightly less experience than I did with this particular technology, but they were quite competent and very familiar with the business need that we were solving.

To turn this project around, I didn't want to waste the time of the developers on the project any more than I had to, so despite the fact that I had skills to do anything on the project, I focused on doing simple, straightforward work normally done by a junior developer. I started with finishing the user interface for a list page, then I finished all of the similar pages. After I gained some familiarity with the project, I moved into some more simple but time-consuming tasks on the project. This allowed the developers already on the project to focus on the more difficult aspects of development. We finished the project a day before our drop-dead date given to us by the business leader.

Select your targets carefully

Another project I helped turn around was an eCommerce site for another of my clients. The project had fallen behind because of a combination of scope creep and trying to bend the selected eCommerce framework beyond its capabilities. To make matters more difficult, some of the features were beyond the abilities of the developers involved. When I arrived, the team's project manager was working to stop the scope creep, but the development team was focusing all of their time on a small number of the most important (and difficult to solve) problems.

In this case, focusing my time on making as much progress as possible wasn't the right solution. The team was clearly getting stuck on a few specific issues. Since I was the senior programmer on the team, I took over responsibility for fixing the most difficult to solve problems which freed up the junior developers on the team to finish the numerous but easier-to-solve issues. We were able to eliminate the backlog list fairly quickly after that and deliver a satisfactory website to our customer.

Sometimes process is the answer

Another project which I helped turn around was a highly-customized eCommerce application for another client. Both companies agreed that an Agile approach would be better for this project, and so each sprint had a fresh set of deliverables. The client was not happy, though, due to the fact that we couldn't deliver features fast enough. We also were not happy, due to the unusually high stress this project caused. When I arrived, there were seven client contacts giving us suggestions for features or enhancements, and all of them felt like their suggestions should be the highest priority.

The first thing I did, and truthfully the only thing I did, was persuade everyone that choosing a contact on the client side to serve as the Scrum master was in everyone's best interest. After that person was chosen, we told him our capacity for each sprint, and he was responsible for setting our priorities accordingly. After everyone settled into their new roles, we were able to spend less time managing the project and spent more time delivering features. We were happy because we were under less stress. The client was happy because the got more features each sprint.

Conclusion

Adding people to a late project can indeed help turn it around. But it's important to add the right people to a project. Diagnose the cause of the problems associate with the project, then assign new people to address those specific problems. Only then will you be able to turn around badly running projects.