Recently at my day job I've been sitting in on some planning meetings for upcoming software development projects. I'm working with a particularly astute Dev manager right now, and he inspired this post. Recently this Dev manager basically turned down the offer of getting more developers for his project. His rationale? Adding more developers would add more complexity to communicating and coordinating work across the team, and this would outweigh the productivity value more team members could contribute.
This is a classic example of (in this case, smartly avoiding) the so-called Mythical Man-Month, a concept popularized by Frederick Brooks, in a book of the same name. The essence of Brook's idea is that adding more people to certain types of projects may actually increase the difficulty of completing the project. Or as Tom DeMarco explains in his excellent book Slack, people are not a fungible quantity of capacity--and especially not knowledge workers. In complex projects, it's not always the case that if a few people are good, a lot more people are better.
If you followed the link in last week's post, you found Tim Johnson's and my excerpt from Project 2007 Step by Step--the appendix A Short Course in Project Management. In this appendix, we use the so-called "triangle of triple constraints" model as a means to describe (and to a large degree, quantify) the three essential attributes of any project:
For brevity I often call this the "project triangle" model.
I started this post discussing knowledge worker resources. In the project triangle model, such resources are one type of cost. The triangle generalizes cost to include people, equipment, direct cash expenses (e.g. for purchasing material for a construction project), and so on. For knowledge work projects, people resources likely are by far the single largest type of cost. On the software development projects I work on, they are essentially the only costs that project managers directly track and account for.
OK, I've established that knowledge workers are one example of a type of cost, and I've framed cost as one side of the triangle of triple-constraints. Now let's consider the "constraint" aspect. In the context of saying a knowledge work project is resource-constrained, I don't mean "constraint" to mean what it means in Project (e.g. a "Must Start On (MSO) constraint applied to a task). Instead, what I mean here that one side of the project triangle is ultimately the most restricted (or constrained), and because it is restricted, one or both of the other sides of the project triangle must be adjusted to accommodate. The appendix walks through the project triangle and constraints.
When my Dev manager turned down the offer of more developers for his project, he was (to me at least) indicating that he (a) was well aware of the risk of adding more resources to his project, and (b) anticipating that some other aspect (time or scope) was better suited to adjust for this project to have the greatest chance for success.
When I thought about this issue more broadly, I came to the conclusion that complex projects that require highly specialized and skilled knowledge workers are by their nature resource-constrained. When a complex project gets into trouble, adding more knowledge workers to help out may be exactly the wrong remedy.
Read previous Projhugger posts here.