This chapter is from the book
This chapter is from the book
This chapter is from the book
Examining Largeness
In my experience, I have found that a project can be considered large in many dimensions. For example, the money, scope, amount of people, and risks involved can be large. These different “dimensions” of largeness are mostly interrelated. Some dimensions exist as a first-order consequence of the requirements and constraints. Others are derived from these first-order dimensions.
The individual dimensions of largeness and their interrelations are defined as follows:
- Scope is a first-order dimension of largeness, created by the amount and complexity of the requirements. If a project is large in scope, you can either address that issue by allowing a large time frame, making the project large in the sense of the time it requires. The other possibility would be to allocate a large staff to the project. In this way, the scope dimension influences the time and people dimensions.
- Time is rarely considered a first-order dimension in software development. I mean, I have never encountered a company that decided to work on a project over 20 years, just to kill time. Some projects may go on forever, though, because nobody has the courage to cancel them. But time is never the reason for starting a project. It is typically a dimension that follows another dimension. For example, if the risk of the project is high because you have a number of unskilled people on your staff, you will need to have them trained, which will take time.
- Money is also typically a second-order dimension. This means high costs are always a consequence of the growths of some other dimensions. At least, I have never seen a project that was started just because there was a lot of spare cash lying around. On the other hand, I have seen a lot of projects waste enormous amounts of money without batting an eye. But this was always a consequence of one of the other dimensions. For example, a large team could cost a lot of money, but the question of whether it is necessary to have such a large team is rarely raised.
- People are a different matter. The number of project members is usually a first-order dimension. It is possible for the size of a project’s staff to be a side effect of the scope of the project. However, projects are sometimes staffed with a lot of people—in the worst case, right from the beginning—mainly to show the importance of the project, or of the project management. The amount of project members may not only be related to the amount of developers, but also for example to the number of customers. The more customers are involved in the project, the higher the risk of contradictory requirements.
- Risk is a much more complicated dimension because it can refer to almost anything. For example, team size can be a risk, but focusing on a hot technology also carries a big risk and is often followed by having to spend money to train the staff, among other things. However, risk is typically a second-order dimension.
Therefore, the two initial reasons for scaling a project are scope and people. You can definitely run a large-scope project with a small team. But large-scope projects are almost always developed by a large team—especially in large companies.
Typically, if a project is large in terms of people, all its other dimensions are probably just as large. For example, you will hardly ever find a large team working on a project with a narrow scope, a schedule of only three months, or a budget of only a few hundred thousand dollars. The project itself might not carry any extraordinary risk, but scaling all the project’s dimensions implies a risk of its own. For instance, if a lot of money is involved, there is a high risk that a lot of money will be lost. Or, if the time frame is extremely large, the risk that the project will never be finished at all increases.
In this book, I focus on projects with large teams. However, due to the fact that large teams also usually scale the dimensions of scope, time, money, and risk, these other dimensions will not be ignored.