The mythical labour month

What construction can learn from a book about software

When a construction project falls behind, the response is often immediate: increase the labour, add another shift, bring in another subcontractor and issue a revised manpower histogram showing a sharp rise over the coming weeks. It looks decisive and gives the project team something tangible to present as a recovery plan. Yet adding people does not always address the reason the project is late, and in some cases it can make the position worse.

Fred Brooks wrote about this problem in The Mythical Man-Month, first published in 1975. He was not writing about construction, but about the management of large software projects, drawing heavily on his experience at IBM. His best-known observation became known as Brooks’s Law:

Adding manpower to a late software project makes it later.

The statement is widely known in technology, but it deserves more attention in construction. The two sectors are plainly different, yet both deliver complex projects through large teams, linked activities, incomplete information and a high number of interfaces. Both can also fall into the same planning trap by assuming that people and time can always be exchanged at a fixed rate.

The mythical man-month

The title of Brooks’s book refers to a simple but flawed unit of planning. If one person needs 12 months to complete a task, the arithmetic suggests that 12 people should complete it in one month. That works only where the task can be divided fully and each person can work without depending on the others.

Some construction work can be divided in this way. Separate painting crews can work in separate rooms, while drainage gangs may work in different areas if the design, access and materials are ready. Other activities cannot be split so neatly. Concrete needs time to cure, testing cannot take place before installation, and a long-lead item cannot arrive before it has been designed, approved, manufactured and shipped.

Construction programmes contain both types of work. The error arises when every delay is treated as though it belongs to the first group. Adding labour may increase output where work can proceed in parallel, but it does not remove fixed sequences, approval periods or physical limits. Where the work is not ready, it may only create a larger number of people waiting for instructions, materials or access.

Brooks’s point was not that more people are always useless. It was that the relationship between people, work and time is not linear. Some tasks can be divided across a larger team, while others become harder as more people are added. The question is not simply how much work remains, but how much of that work can genuinely be carried out at the same time.

More people create more work

New people create a cost before they create value. They need to be briefed, they need to understand the project and they require support from those who already know it. The later they join, the greater that initial cost is likely to be.

The same applies on site. A new engineer must understand the design history, correspondence, outstanding instructions and current site conditions. A replacement subcontractor must learn the package limits, access rules, inspection process and links with other trades. New workers require inductions, permits, tools, supervision and suitable work fronts.

All of this takes time from the existing team. The people who already understand the project must pause their own work to explain what has happened and what remains to be done. For a period, the project may have more people but less productive time. Recovery plans often ignore this and assume that 100 additional workers will provide 100 workers’ worth of added output from the day they arrive.

The same problem applies to communication. As a team grows, the number of possible relationships between people rises far faster than the headcount. Two people have one possible communication route between them, ten people have 45, and 20 people have 190. Not everyone needs to speak to everyone else, but each added person still brings more handovers, questions, meetings and decisions.

Construction projects already have enough of these. A single design issue may pass through the client, project manager, engineer, designer, supervision team, contractor and several subcontractors before anyone makes a final decision. Adding another manager or reviewer may not shorten that route. It may create another meeting, another comment sheet and another approval stage.

The problem is often not too little communication, but too much communication without clear authority.

Construction has a physical version of Brooks’s Law

Software teams become crowded by communication. Construction teams can also become crowded in the literal sense.

There is a practical limit to how many people can work safely and efficiently in a trench, shaft, plant room, ceiling void or small apartment. Once that limit is reached, trades compete for access, materials block the working area, completed work is damaged and supervisors spend more time dealing with clashes. Workers may also be moved between areas because the planned work front is unavailable.

The labour return may improve while the output remains unchanged.

This is the site version of Brooks’s Law. More people are added to recover time, but the additional workers create extra coordination, reduce the available space and weaken the effectiveness of the existing workforce. The project may then use more labour-hours for every unit of work completed.

That leads to an important distinction between production and productivity. Production is the amount of work completed, while productivity is the amount completed for each labour-hour used. A contractor may meet its daily target by doubling the workforce. Production has been maintained, but productivity has fallen by half.

This does not always mean the recovery has failed. A contractor may knowingly accept lower productivity to protect the completion date. It does mean, however, that increased production should not be confused with efficient working. A project can finish on time and still suffer a serious loss of productivity, particularly where the remaining work has been forced into a shorter period.

A manpower histogram shows input. It does not prove progress.

A late project may not have a labour problem

Labour is easy to count, which makes it an easy target when progress is poor. Yet the true restriction may lie elsewhere. Drawings may not be approved, materials may not have arrived, the previous trade may still be working, access may not have been released, or the design may remain unsettled.

Adding people does not solve any of these problems. It may simply hide them behind a higher headcount.

A sound recovery plan should start by identifying what is stopping the work. If the problem is labour capacity, add labour. If it is access, release the work front. If it is design, settle the design. If it is procurement, correct the procurement plan. If it is supervision, appoint capable supervisors.

The cure should match the cause.

This becomes even more important where the project has lost time early but retains the same completion date. The remaining activities must then be carried out over a shorter period, often with more trades working at the same time, longer hours, added shifts and supervisors covering several crews.

The programme may show recovery while the site experiences falling productivity. Work may proceed out of sequence, tools and materials may not be available where required, defects may rise and workers may become tired. Time recovery is possible, but it is rarely free.

Brooks’s argument is useful because it challenges the belief that every lost week can be bought back through an equal increase in manpower. The relationship between labour, time and output is far less direct.

Small teams and clear authority

Brooks discussed what he called a surgical team. Under this model, a small group would control the main design, led by one person with a clear view of the whole system, while a wider team provided specialist support. The name is dated, but the idea remains useful.

Construction projects often have many specialists but no clear route for technical decisions. Architecture, structure, building services, façades and specialist systems may each be designed well in isolation, yet serious problems appear where they meet. Ceiling voids, risers, plant rooms, service crossings and maintenance access can remain unresolved because no one has the authority to decide which requirement takes priority.

Large meetings may discuss these matters for weeks. A small group with clear authority may settle them in an afternoon.

Brooks also wrote about conceptual integrity, meaning that a system should follow a consistent design rather than become a collection of separate ideas. A construction project cannot be designed by one person, but it still needs a consistent design intent and clear rules for how systems fit together.

Without this, every package becomes its own small project. The façade contractor protects the façade, the MEP contractor protects the services, the structural designer protects the structure and the architect protects the appearance. Each decision may be reasonable on its own, but the combined result may be difficult or impossible to build.

The answer is not always more design resource. It may be fewer decision-makers with a clearer view of the whole project.

Reducing the cost of coordination

Brooks wrote before cloud platforms, shared data systems and artificial intelligence. These tools do not remove the problem he described, but they may reduce some of the administrative weight created as teams grow.

A large part of project coordination is not decision-making at all. It is finding information, checking which version is correct, reconciling records and passing the same facts between planning, commercial, design and site teams. Each handover creates delay and another chance for the information to change or lose its meaning.

A well-designed system can reduce that burden by giving the project team a shared view of the work. Labour, plant, materials, programme activities and cost records can be connected rather than maintained as separate accounts of the same event. If a delivery is delayed, the effect should not remain buried in a procurement tracker. It should be visible against the work fronts, crews and following activities that depend on it.

This is where newer data platforms and AI may have a useful role. Palantir’s work with Thomas Cavanagh Construction, a Canadian civil contractor, provides one example. Cavanagh has connected operational information across labour, equipment, materials, contracts and site reporting so that the same data can support several business functions. The important point is not the product itself, but the reduction of repeated entry, reconciliation and manual exchange between departments.

Applied to a recovery plan, the same approach could help the team see whether added labour has suitable work available, whether materials and plant can support it, and whether higher production is being achieved at an acceptable level of productivity. It could also show the wider effect of a delayed approval or inaccessible work front before the issue reaches the monthly report.

This supports Brooks’s argument rather than overturning it. As organisations grow, coordination becomes more costly. Better systems can reduce some of that cost by making information easier to find and decisions easier to trace. They cannot remove physical restrictions, shorten fixed sequences or create work fronts that are not ready.

Nor should the system replace the people running the project. It may show that moving a crew produces the best programme result, while the construction manager knows that the alternative area is unsafe, the design is likely to change or another trade is not ready. The software can organise the facts and test the options. Judgement remains with the project team.

The lesson is that technology should shorten the route between information and action. If it adds another dashboard, another report and another set of records to reconcile, it has merely added a new communication route to the problem Brooks identified.

Learn while change is still cheap

Brooks originally advised software teams to plan to discard the first version because it would expose problems that could not have been predicted at the start. Construction has long followed a similar approach through mock-ups, sample rooms and trial sections.

A bathroom mock-up can identify coordination problems before they are repeated across hundreds of rooms. A façade panel can test appearance, workmanship, access and weatherproofing before full production begins. A trial section of road or utilities can test the method, plant, crew mix and inspection process.

The purpose is not to build badly and begin again. It is to learn while change is still manageable.

A mock-up should also test more than appearance. It should test buildability, sequence, inspection, access and maintenance. One controlled error is far cheaper than hundreds of repeated ones.

Digital systems can support this process by recording what was learned and applying it to later work. If a trial area shows that the planned crew mix is wrong, that tools are arriving late or that an inspection step creates waiting time, the revised method can be carried into the next work fronts. The lesson becomes part of the working process rather than remaining in meeting minutes that few people read.

No silver bullet

That qualification matters because Brooks later warned against expecting any single technology or management method to solve the difficulty of complex project work. Digital platforms and AI are no exception.

The useful part of the Cavanagh example is not simply that the contractor adopted Palantir. It reviewed how its work was carried out, what information people needed and where responsibility should sit. The technology was then built around those decisions.

Construction has often done the reverse. A company buys a new platform, keeps the same weak process and expects a different result. Old spreadsheets remain in use, cost codes remain inconsistent and site teams continue to prepare several versions of the same report. The new system becomes another communication route rather than a way to reduce them.

BIM will not solve coordination where design authority is unclear. A planning system will not solve delay where the programme does not reflect the site. A dashboard will not improve performance where nobody acts on what it shows. AI will not correct poor records or missing information simply because it can process them quickly.

Technology can make an effective project team faster. It can also allow a weak team to produce poor decisions at greater speed.

That is why the link with Brooks matters. The answer to the mythical man-month is not simply fewer people, more software or more AI. It is to understand which work can be divided, where communication is consuming time and which decisions require a clear owner.

AI may reduce the cost of coordination. It does not remove the need to coordinate.

Where the comparison stops

Brooks’s Law is not a rule that more labour will always make a construction project later. Construction work can often be divided across separate areas more easily than software design, and new crews can increase output where work fronts, materials and supervision are available.

Nor does Brooks’s Law decide contractual responsibility. It does not establish who caused a delay, whether acceleration was instructed or voluntary, or whether additional cost is recoverable. Those questions require the contract, notices, programme records and site evidence.

Brooks gives us a management test, not a contractual answer.

The test is whether the added people can perform work that is ready, separate and properly supervised. If they can, more resources may recover time. If they cannot, the project may only be adding cost, congestion and further management work.

The same test should be applied to technology. Does the system reduce repeated work, shorten the route to a decision and give the team a clearer view of what is happening? Or does it add another platform, another report and another set of data that nobody fully trusts?

Software is useful when it removes work from the system, not when it merely moves that work to someone else.

Count the work, not just the workers

The construction industry is good at counting people. It is less consistent at measuring what those people produce.

Daily labour returns show who attended. They do not show whether the right workers were in the right place, whether the work was ready or what quantities were completed. A serious recovery plan should connect labour to activities, locations, quantities, work fronts and expected output. It should explain what the added workforce will do that the existing workforce cannot, and what has changed to make the revised plan achievable.

Have more areas been released? Have materials arrived? Has the design been settled? Have more supervisors been appointed? Has the sequence changed?

AI can make those connections faster and more visible, but it cannot invent the missing answer. A contractor must still plan the work, record what happened and act when performance begins to fall.

Construction often looks to other construction projects for answers, but there is value in looking further afield. Software and construction both struggle with complexity, changing requirements, large teams and slow decisions. Both can mistake activity for progress, and both can add people when the real problem is poor information or unclear authority.

The Mythical Man-Month does not provide a formula for recovering a construction programme. It does something more useful by challenging the assumption that a late project can always be saved by adding more people.

Modern software may help construction deal with some of the communication and information problems Brooks identified. It can connect the plan with what is happening on site, identify restrictions earlier and give a smaller group the information needed to make decisions.

It cannot remove the fixed sequence of the work, create space that does not exist or replace experienced judgement.

Sometimes more people will recover the project. Sometimes AI will help those people work better. Sometimes both will simply add cost.

The difference depends on whether the work, the information and the organisation are ready for them.