Today I realize that I’ve seen three very different ways to allocate people to projects. While each is very different, each project was profoundly helped by the use of the particular method. I thought I’d record them here so I can remember them better.
I can’t take credit for these ideas. While I’ve anonymized these anecdotes, I can assure you that they are examples of people much smart than me.
Anecdote 1. Take a project, give everyone a different piece, and try to get it all done.
This is pretty traditional. It makes sense in the modern division-of-labor society we seem to live in. Everyone worked in parallel and got their piece done.
Anecdote 2. Take a project, break it into milestones, and have everyone work on a milestone as a group until it is done. Then move to the next milestone.
Once I was involved in a major software project. The next release was going to have a lot of new features. After some analysis, someone realized a better way to do the development would be to break the features into three groups based on the part of the system they affected. They would do three releases, one for each group of features. Marketing could just ship the last release or ship intervening releases if it made them happy. The important part is that the entire team was focused on getting each milestone done correctly rather than being scattered about. Everyone could help everyone because they were all focused on the same part of the system. QA could test each milestone better because they knew to do the heavy testing on the part of the system being modified. QA also liked this plan because they could test milestone 1 while milestone 2 was being worked on. Ah parallelism. Also, instead of having to do a lot of testing at the end, they would be doing heavy testing of group 3, and simple retesting of the previously tested parts. This reduced the chance that they would be blamed for delaying the ship date. It opened opportunities for more parallelism in other areas too.
Management bought into the idea and the project was very successful. Interestingly, however, if upper management hadn’t bought into the plan it wouldn’t have mattered because the developers could have done it under the radar… the only difference is that the customers would only have seen one release.
Anecdote 3. Take your best people and put them on the most difficult problem. When they are done, move them to the next biggest problem. Keep moving them until your biggest problems are quite minor.
A person was hired to manage an IT team that spanned 3 areas. We’ll call them Area A, B and C. The systems and networks in each area were a disaster. Users weren’t getting their requests done in a timely manner and outages were frequent. After a month he saw quite clearly that one area was more messed up than all the others. While his predecessor had her office in Area C, it was Area A that needed the most work. Thus, he broke with tradition and moved his office to be in Area A’s building. He moved two of his top team members to this building (one was already there, struggling with the chaos) and focused on fixing the problems there. After a while things were stabilized and much improved. Then he moved his office to Area B and took those two top team members with him. They repeated their success in Area B. Finally they were able to move to Area C. By focusing concentrated effort to the places where the biggest impact could be made (rather than doing the easiest segment first), he was able to create the biggest positive change quickly. By bringing the best people on his team to the task, he reduced the risk of failure. By using the same people for all three segments, he was able to have a team that learned and improved as they moved on, getting better each time rather than repeating the same mistakes over and over.
When it comes to allocating people for projects I’m sure there are many other ways to do it. I’d be interested in hearing your thoughts.
Comments? Suggestions? Recipes?