Delivering projects is more than simply tasks undertaken to get something out of the door. Inevitably, how a project is delivered is dictated by the culture of the organisation. I work for a niche technology solution provider that has undergone nearly four-fold expansion since I joined six years ago. I have been thinking how that has changed our project delivery. Many of the analogies I draw will be familiar to you if you have read Frederick P Books Jr, the father of IBM System/360.
As a small company, we worked on small projects – mostly using one or two resources. Because of the size of work we could take in, there was a natural limit to risk we were exposed to. It is easy to communicate between two or three people by simply sitting next to each other. Even informal communication is sufficient to set goals, share designs, report progress and quality control each others’ work. Because the work packets are small, it is also easier to slot them in based on project timeline commitments. We managed to get a phenomenal productivity out of our staff.
As the company started growing, the work packets started getting larger. We were able to take on more complex work. Goals that a project manager could explain to two developers, now need considerable documentation. He cannot now sit next to all the team and fill in the gaps if something comes to light. As growth continued, there was need for more project managers. This creates more challenges, as now all the project managers have to align their processes to ensure projects are delivered in a uniform way. Slowly, but surely, the productivity achieved in the early days becomes difficult to sustain.
The staff we have are of exceptional calibre. So why the impact on productivity? The key here is the the overhead of communication. The original scenario I described is what Brooks calls the duo working out of a garage producing software that far exceeds big teams. However, there is a certain size of software you can produce with that capacity. In order to deliver something more complex with the two same developers, it will take so long it will not be worth pursuing. The only answer here is to add more people. As soon as you do that, it creates the productivity issues I talked about previously.
A simple mathematics shows the impact. The communication channels in your project team is n(n-1)/2. In a team of 2, there is only a single line of communication. Team of 3, makes it 3, 4 makes it 6. As you can see, More people you want to herd to the same goal, your communication effort multiplies exponentially. Military works by asking no questions. So one may ask why not follow that model. Most of your development team are usually from the opposite end of the IQ spectrum to that of your privates. Persuasion is your best ally here.
This clearly shows that more complex the delivery, and more people are required, software development itself becomes less of the overall effort. Ensuring the team works well, everyone knows what they are required to achieve, outputs are tested for their fit for purpose and efforts are targeted correctly to achieve the goal that has been set out requires considerable dedication.
Many a time reaction from management or clients is to throw more resource at it and expect output to increase in a linear fashion to the number of resources added. That may be achievable in fruit picking, or office cleaning, not in software development. It also does not take into account some tasks take a certain duration. No amount of resources will deliver an early output. I love Brooks’ analogy here … Bearing of a child takes nine months, no matter how many women are assigned.
Have you been growing recently? I would love to hear your experience.