10 Leadership Mistakes on Megaprojects

1.Making blame the first response to a problem

A failure review needs to explain how the work went wrong and what will change. Starting with a convenient culprit can leave the same weak checks, unclear instructions or unmanageable workload in place. Ownership matters, including the leader's own part in creating or supervising those conditions.

Learning and accountability belong together. An honest mistake, a lack of competence or support, negligence, deliberate concealment and other misconduct need careful, fact-based consideration. Address conduct through the appropriate fair process; a learning discussion is not a substitute for it. Equally, an individual action should not end the examination of the system around that person.

Try this: For a recent failure, separate the known facts, contributing conditions, individual responsibilities and corrective actions. Name the changes you own as a leader, then assign who will verify that the changes work.

2.Teaching people to bring good news instead of useful news

Watch what happens when someone brings an uncomfortable fact. If the first response is ridicule, irritation or a demand to make the dashboard green, the next warning may arrive later and less clearly. Welcome early information while still asking for evidence, consequences and a response.

Drawing on the estimating story, AJ Waters advises people to explain what happened and bring options for moving forward. The useful leadership habit is to make that conversation possible before the team has a complete solution or a polished explanation.

Try this: Open the next review with: What are we worried about, and what have we not yet been able to verify? Record the concern, decide who will investigate it and tell the person who raised it what happened next.

3.Arriving with the answer before understanding the project

Experience gives a leader useful questions. It does not guarantee that a method from another project fits this delivery model, workforce or phase. A rapid reorganisation can remove a workaround without solving the constraint that made it necessary.

Try this: Before changing a recurring process, ask the people doing it to show you the last real example: what happened, where it stopped and why they handled it that way. Check the contractual and technical constraints, then explain what you will keep, change or investigate. Act on urgent risks while that learning continues.

4.Giving responsibility without a usable route to a decision

A name on an organisation chart does not tell the team who can accept a design change, commit money, resolve an interface or stop unsuitable work. When authority is unclear, people either wait or make commitments that another organisation later rejects.

Try this: Walk one live decision through the team. Identify who prepares the recommendation, who is consulted, who decides within what limits, who acts and when an unresolved issue escalates. Test the arrangement with the owner, designer and delivery team rather than assuming the job titles agree.

5.Making the project depend on your constant intervention

Checking every minor choice can leave skilled people waiting for permission and leave you without time for the decisions that need your attention. Delegation still needs an agreed outcome, competent people, clear limits and a way to surface exceptions.

Try this: Choose a routine decision you currently approve. Agree the outcome, authority, boundaries and escalation triggers with the person taking it on. Review a small sample of completed decisions together. Keep specialist, safety-critical and contractual approvals with the people authorised to make them.

6.Treating a quick, quiet meeting as proof of alignment

A decision can look unanimous because nobody had a safe or practical opportunity to challenge it. The work needs the reasoning behind different views, including the people who must implement the decision and those who will inherit its consequences.

Try this: Before endorsing an option, collect concerns individually, invite the affected disciplines to explain their assumptions and ask what evidence would change the recommendation. Summarise unresolved disagreement in the decision record, with an owner for any further work. Avoid manufacturing conflict merely to make the meeting look rigorous.

7.Expecting a culture statement to do the work of leadership

A team learns its working rules through repeated behaviour: who gets heard, whether commitments are kept, how problems cross organisational boundaries and what happens after someone asks for help. A launch workshop cannot carry those responsibilities for the life of the project.

Try this: Agree a few observable team practices, such as raising interface problems early, keeping action commitments and checking understanding across disciplines. Demonstrate them in reviews and handovers, then ask the team where leaders are failing to follow their own rules.

8.Committing the work before securing the capability to deliver it

A resource total can conceal a missing discipline, an unavailable decision-maker or a specialist arriving after the work needs them. Repeatedly stretching the same reliable people is a weak substitute for resolving the gap.

Try this: For the next phase or major milestone, map the work to capabilities, availability and lead times. Identify the critical gaps, agree whether to sequence, recruit, develop or obtain support, and make unresolved capacity assumptions visible before accepting the commitment.

9.Offering people a task with no credible path to grow

A long project can hold someone in the same narrow assignment while their responsibilities expand or their ambitions change. Development needs an honest conversation about the work, the support available and the opportunities that actually exist.

Discuss development alongside pay, location, stability and personal circumstances. Be clear about which opportunities the project can actually provide.

Try this: Ask a team member what they want to learn next and what support would help. Agree a realistic assignment, mentoring or training opportunity and a review date. Plan for handovers and deputies so development does not create a hidden gap elsewhere.

10.Collecting lessons without changing the next piece of work

A well-written lesson has limited value if the next team repeats the same assumption or cannot find the earlier decision. Close the loop by changing a plan, check, responsibility or working method, then examining whether that change addressed the problem.

Use the earlier register as a prompt for investigation. Reassess each lesson against this project's conditions; an old mitigation or probability is not automatically suitable for the next job.

Try this: Take one lesson from a recent event. Identify the next activity it should affect, change the relevant plan or control, assign an owner and check its use. Keep enough context that a different team can understand the lesson after the original people leave.