Let's Talk Roadmap Planning: Can 9 Women Make One Baby in One Month?
Many new project managers who come to the IT industry compare the planning and execution of a software project as if it were a job of unloading a truck: the more people you add, the quicker the result will be. In this article, I’d like to check this hypothesis and compare the task of unloading a truck to the actual realities of building a software project.
Here we need to unload a track with various items. The truck contains 100 boxes of furniture. This is from our house, and so they are all very valuable and expensive for us and should be carried with care. We also have workers that will be unloading the truck. All of them are very capable and carry about the same number of items per hour. Simple job indeed!
Software projects are a different fruit. In fact, they are more similar to the job of building a house. In construction, you need to create an architectural sketch, then put in the foundation, build walls, establish water pipelines, install electricity, put on a roof, and lastly paint everything. Each process may require teams with a unique expertise. Likewise, in software development, projects require backend and frontend development, building services and databases, perform quality assurance, and DevOps duties. Every team has unique capabilities and skills to perform the job.
Our crews are ready, let’s start!
Let’s start with two people for unloading a truck and seven people for developing software. Two people on a truck can usually do the job two times faster, spending 0.5 hours together instead of a full 1 hour. Whereas having seven people on the software project requires them to extend the timeline seven times because they only can do their job after the previous dependent job has been finished. For example, a QA engineer can’t start their job if the backend and the frontend engineers haven’t finished development. They will spend 7 days in total. Bummer!
Let’s double the number of people for both crews. We can see that in the truck example, it clearly results in a faster timeline. Let’s look at the software project. The timeline still improves as different teams that have more people can do the job much faster. Nice!
Let’s double the number of people one more time. For a truck, having eight people on a job clearly results in a much faster timeline. Let’s look at the software development project. Here we can see that although we have doubled the number of people, the timeline may not change so dramatically.
The reason for this is for a simple software project, two people can be more than enough to do software architecture, while for QA engineering or business analysis, it can be more beneficial to have more people. So, the new people will be mostly idle for most of the jobs. At the same time, adding them to the work will require communication and coordination to explain the context for their activities and provide updates about the work that the other team members have already completed. Thus, the effort and cost increase even higher! So does that mean that adding more people to software development projects beyond a certain threshold wouldn’t be practical?
For software development, there is research on how far you can optimize a software project without major risks to delivery. There is even a term for it called “The Impossible Zone.” The term essentially defines the compression limit of 25%. Beyond the limit, the project will almost certainly fail. That means if you have a project for 100 estimated days, you can only compress to 75 days maximum by adding people or paralleling jobs.
Other research shows that adding more people to a single software development team can affect performance. When adding team members beyond pizza size of 5, the communication between them will require more effort while the calendar days output will not improve or may even degrade. In that situation of adding more people to a single team of five, you may be even paying more for poorer outcomes.
All of that shows one thing. It can be tempting to simply hire more people because it is a visible action taken to resolve the issue, but this does not alleviate the systemic problems in planning that are at the root of numerous delivery failures we see nowadays in software projects. When planning for software development, one needs to learn project specifics and team expertise, understand how jobs can be paralleled and optimized and where they cannot. Don’t try to engage multiple women to deliver one baby!
If you need a complete all-in-one solution to build reliable roadmaps check out the method developed by our team of experts: https://honestroadmaps.com.