Chapter 25: The human factor: ego, fear, and shame

It is rarely technology that kills a project; it is silence

This chapter is for those who do not manage a project directly but are accountable for it: company management, board members, deputy ministers, and heads of departments. You do not need to understand code. But you do need to recognize whether the information reaching you is true.

Flyvbjerg and Budzier reviewed 1,471 IT projects: on average, costs exceeded the plan by 27%, but one in six projects was a “black swan” with an average cost overrun of 200% and a schedule overrun of almost 70% Flyvbjerg and Budzier, 2011. It is exactly this kind of extreme case, which disappears in the average, that can threaten a company’s existence.

Such an outcome rarely has a single sudden cause. Research by Mark Keil and colleagues, summarizing 14 studies, describes two phenomena: people withhold, soften, or delay bad news, and those who receive it may refuse to hear it. Willingness to report drops where people are punished for it and grows when the messenger does not have to fear blame Keil et al., 2014. A green report is therefore not proof that everything is fine. It is like a warning light in a car that someone has covered with tape.

An honest picture tends to be amber. Of 227 major government projects in the United Kingdom, as of March 2024 only 11% were rated green, 72% amber, and 12% red IPA, 2024. If all your projects are green, ask why.

Ten traps and how to spot them

These are recurring patterns of behavior that almost anyone can fall into under deadline pressure and worry about their own reputation. So set up project governance in a way that lets you catch them in time.

Who to trust with a project: behavior matters, not self-confidence

A project often goes to whoever is the highest performer, the loudest, or the best technically. That choice has its reasons, but it does not guarantee that the person can openly report bad news too. A study of salesperson promotions in 131 companies showed that companies promote mainly on performance in the current role, and the best salespeople then lead weaker teams on average as managers. The authors link this to the so-called Peter principle Benson, Li, and Shue, 2019. The data comes from sales, not IT, so treat it as an analogy: people are chosen based on results in a different job from the one they will then be doing.

So choose based on proven behavior on past projects: how they reported problems, whether they ever scaled something down or stopped it, how accurate their estimates were. Ask former colleagues and reviewers as well. Also watch what kind of environment they create around them: psychological safety, the feeling that it is safe to say something unpleasant, is linked to how a team learns Edmondson, 1999. A higher number of reported problems therefore does not have to mean a worse project. It may point to more open reporting.

Horizon: for twenty years, nobody believed the people who reported errors

One of the worst British IT scandals did not arise because the system had bugs. Every system has bugs. It arose because the institution for years did not believe the people who pointed them out. The British Post Office introduced the Horizon accounting system in its branches, and according to the public inquiry, branch operators began complaining about incorrect data almost immediately after it was introduced. The Post Office demanded that they make good the shortfalls and brought criminal prosecutions. According to the inquiry, hundreds of people were wrongly convicted and thousands more were held liable for losses that never actually occurred Horizon Inquiry, Vol. 1, 2025. In 2019, the court found that the original Horizon “was not remotely robust” Bates (No 6), 2019.

Timeline sources: the judgment Bates (No 6), 2019, the public inquiry Horizon Inquiry, Vol. 1, 2025, and its 2026 progress update Horizon Inquiry, 2026.

Which traps came into play:

• blind trust in the system: Horizon’s output served as evidence against people,
• deafness to warnings: complaints from branches were treated as excuses, not as reports of a possible bug,
• information asymmetry: known bugs from the vendor’s internal records did not reach the accused,
• institutional ego: the Post Office defended the system and its earlier decisions instead of checking them.

What would the right approach have looked like? A user complaint is treated as grounds for checking, not as a nuisance. Repeated complaints are investigated by someone independent of both the vendor and the department that introduced the system. If the system’s output serves as evidence against people, those affected have access to the logs and to the record of known bugs. In the end, the court did exactly that: it read the records of errors and reached the opposite conclusion to the Post Office.

What works: safeguards that let the truth travel up

• Independent reviews at key points. The British Gateway Reviews are short reviews by an independent team that assesses how likely the project is to be completed successfully. They are inexpensive: the NAO estimated the cost of reviews of high-risk projects in 2008–09 at GBP 8.3 million, against GBP 10.5 billion in annual spending on 42 projects NAO, 2010. They only work if they cannot be bypassed and a red rating has consequences.
• Estimates based on comparable projects. Instead of estimating only from inside your own plan, look at how similar projects turned out and adjust your estimate accordingly (reference class forecasting) Flyvbjerg, 2006. This also takes into account the extremely bad outcomes mentioned at the beginning.
• Psychological safety. It is safe in the team to admit a mistake and say something unpleasant. Psychological safety does not mean low standards. It starts with management that admits its own mistakes and recognizes whoever points out a problem.
• Stop criteria agreed in advance. They are set before sunk costs build up, so nobody negotiates over them under pressure. You will find a template in chapter 19.
• Separating management from assessment. Whoever runs the project does not assess its status. The assessor reports directly to you and has access to the data.
• Whistleblower protection. An internal whistleblowing system under Act No. 171/2023 Coll. protects a person who reports unlawful conduct Act No. 171/2023 Coll.. It is the last safeguard, not the first: for bad project news, you need an ordinary channel that works earlier.

Premortem: imagine the project has already failed

A premortem is a meeting where the team assumes the project has turned out badly and looks for the reasons why Klein, 2007. It also makes room for criticism that nobody would otherwise voice. Hold one before approving the project or a major stage. Plan for 45–60 minutes and 6–12 people: the project manager, key people from the team, a user representative, and the vendor. It is facilitated by someone who did not push for the project. The following steps and times are a suggestion for you to adapt.

A good answer is specific: a name, a number, a date, a decision. A bad one sounds like “nothing major,” “we’ve already invested too much,” or “the system is robust.” Also ask the vendor how they will report bad news to you and whether they may escalate beyond your project manager.