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?
Playing to strengths vs Forcing growth
When it comes to allocating individual work units to people, I go back and forth between these two methods.
Playing to strengths means assigning issues to people that lie within their comfort zones or are topics they prefer to work in. Bob may be more than competent enough for both the database design and the analog sensor interface, but he prefers to work on DBs, so I give him that part. This assumes, of course, I've got someone else to do the analog stuff.
Bottom line: people are happy when they do things they like - if happiness and job satisfaction are important metrics at your organization, then this is something to consider.
Forcing growth means deliberately assigning tasks to people where they aren't the top dog. This does four things:
It makes them uncomfortable, thus encouraging most people to work faster, so they can go back to something they like. You have to watch out for the people who procrastinate when they're uncomfortable: don't stretch them too far, and make sure they're teamed up with someone to help them out.
It forces them to learn and to pay attention, rather than letting them go through the motions with the stale and familiar. This does a lot to prevent lazy mistakes.
It encourages outside-the-box thinking. Concepts and analogies and thought processes from one discipline can help find new and better ways to do things in another discipline.
It forces them to collaborate with each other when they hit sticky problems.
If innovation, professional growth, and team building are important metrics, then use this technique.