I recently came across a problem that’s often used as a textbook question. An orchestra of 120 musicians takes 40 minutes to perform Beethoven’s Ninth. How long do 60 musicians take to perform the same symphony? Helpful hints are provided below: Let P be the number of musicians and T the time.
The clue practically puts a pen in your hand. You compare P and T, do the maths, and end up with 80 minutes. Half as many people, twice as long. Online, parents have been up in arms about this very problem, claiming it’s nonsensical. Yet the reflex is the real lesson here. I studied mathematics, and there’s a good reason why problems like this appear in textbooks. They’re an exercise in concentration and help you develop an eye for when a formula for work applies and when it doesn’t.
And anyone who, like me, plays an instrument knows the answer straight away: the duration is determined by the piece itself, not by the number of musicians. The Ninth doesn’t get any shorter with twice as many musicians, nor any longer with half as many.
That said, anyone familiar with the Ninth will smile a second time. The 40 minutes aren’t right either. Depending on the conductor’s temperament, it lasts a good 65 to 75 minutes; some take even longer. Nobody plays it in 40 minutes. Even the CD is said to owe its running time to this length; according to legend, it was calculated so that Furtwängler’s 1951 recording, at 74 minutes, would fit onto a single disc. So this little exercise about a false assumption actually contains a second one as well.
This is exactly what happens all the time in projects, it’s just not so easy to spot there. We plug figures into a neat formula and rarely ask whether the assumptions are correct or whether the calculations make any sense at all. The go-live date is set, often externally and non-negotiable. Implementation isn’t progressing fast enough; the deadline is at risk. The atmosphere becomes tense, and then someone utters that phrase which sounds so reasonable: ‘We need more people.’ So more people join the project. And a few weeks later, things haven’t got any faster. In fact, they’ve slowed down.
Brooks and his law
The fact that this is no coincidence was described by a man almost fifty years ago. Fred Brooks led the development of a major operating system at IBM and, in 1975, distilled his experience into a book entitled *The Mythical Man-Month*. One sentence from it has stood the test of time: 'Adding manpower to a late software project makes it later.' Adding people to a project that is already behind schedule only makes it even later.
Brooks coined the term ‘man-month’ to describe this concept: the assumption that workload can be neatly broken down into person-months. According to this logic, a project requiring twelve man-months would be completed by twelve people in one month. On paper, the maths adds up. In reality, it almost never does. As is the case with the orchestra.
Why 'Man Month' is a myth
There are several factors working against this formula, and two of them are present in every project. The first is the onboarding process. New recruits are not as productive as their more experienced colleagues right from the start. They need to understand the project, its current status and the decisions that have already been made. This knowledge resides in the minds of those who have been working on the project for longer. Consequently, it is precisely the most productive members who are taken off their own work to train the newcomers. For a while, the team’s productivity drops before it can even begin to rise.
The second is communication. With every new person who joins, the number of ways in which people have to communicate grows faster than the number of people. With three people, there are three connections; with ten, there are already forty-five. Each of these needs to be maintained through coordination and meetings. At some point, the team ends up spending more time getting themselves organised than on the actual work.
And then there is the point that our orchestra example has already foreshadowed. Some tasks are carried out one after the other because one step builds on the result of the previous one. Just as a symphony plays its movements in sequence, not every step in a project can be carried out in parallel. No matter how many hands are available, this sequence remains unchanged.
Why this is hitting municipal utilities particularly hard
What does this have to do with the energy sector? Many projects at the municipal utility stem from legislation and regulation, such as a change in market communication or a roll-out with a fixed deadline. Such deadlines cannot be postponed, and this pressure tempts organisations to scale up their operations.
On top of that, the work is knowledge-intensive. There aren’t many people who are familiar with the processes and the regulatory intricacies. A new recruit who first has to familiarise themselves with market communications won’t speed things up in the short term. They initially tie up knowledge that is needed elsewhere.
The real mistake
The decision to bring in more staff is well-intentioned. Anyone who sees a team struggling wants to help, and bringing in more people is the obvious solution. But just like in the school exercise about the orchestra, the problem has two levels. Anyone who thinks in terms of man-months assumes that the workload can always be spread across more people. And then there is the task at hand: a process that nobody has fully grasped before. When it is unclear which steps build on one another, every delay appears to be a staffing issue, even though it has long since become a process issue.
That is the point I never tire of repeating time and again. First the process, then the tool or the project team.
What really helps
What helps when a project gets stuck? In my experience, the first thing is focus. A small team that can work on the most important issues without being interrupted gets further than a large one that constantly has to coordinate itself.
What makes the biggest difference in my practice is collaborative, interactive work. Especially when a process involves many people or systems, developing and testing together is a real game-changer. Instead of everyone quietly building a part in their own corner, which are then brought together at the end only to find they don’t fit after all. Many developers don’t like this, and I understand their objection. In the short term, it demands concentration and feels slower. But when you look at the project as a whole, it saves you the most costly iterative cycles – the misunderstandings that only come to light late on and then have to be painstakingly unravelled.
By that, I don’t mean a commitment to any specific method. I’m not a proponent of agility at any cost. Imposing a framework on a project that isn’t suited to it simply creates new rituals and doesn’t solve the underlying problem. It’s about something simpler: focus and genuine collaboration.
I experienced exactly what this looks like during a project with a statutory deadline that was in danger of falling through. The initial idea was to expand the team. Instead, we took an honest look at the scope and pared it down to what was absolutely essential for the go-live. We deliberately put everything that was desirable but not essential on the back burner. A small team worked closely together on this core work, and we met the deadline. The deferred parts were completed in the weeks that followed, calmly and without pressure. In the end, both were finished, the essential work on time and the rest shortly afterwards, and nobody had to rush to train staff in the heat of the moment, which would have been more of a hindrance than a help at the crucial moment.
And if people do need to be brought in, then they should be brought in early, not only in the final third, when training them costs the most. Before new resources are allocated to the project, it is worth taking a look at the plan’s assumptions. Is the sequence of steps still correct? Were estimates realistic from the outset, or is an overly optimistic plan now coming back to haunt us?
Back to our orchestra. Nobody would dream of playing the Ninth with double the number of musicians in half the time. In projects, we are essentially doing exactly that, with the best of intentions. The more honest question, therefore, is what is actually needed by the deadline and which steps cannot be speeded up anyway, rather than how many extra people we need.
Brooks wrote this almost fifty years ago, for a world of punch cards and mainframe computers. The reason his statement still holds true today is that he was never talking about technology. He was writing about people. And people, like a good piece of music, need time.