Skip to content

Introduction

This book is built around a single observation.

The people who hold the most accurate information about what an engineering programme requires are rarely the people who make the decisions that determine whether it succeeds. And the people who make those decisions rarely bear the full cost when they go wrong.

That observation is not new. Its consequences - the committed dates that were never achievable, the risk registers that were reviewed and filed, the failures attributed to execution rather than governance, the lessons drawn that make the next failure more likely - have been documented by writers and practitioners going back decades. The knowledge has existed for a long time.

What has not existed, or not existed clearly enough, is a framework that addresses the structural conditions that prevent the knowledge from being applied. That is what this book attempts to provide.

What this book argues

Engineering programmes fail for a reason that is rarely named honestly. The people who make delivery commitments are not the people who have to keep them. When programmes fail - and they fail predictably, in ways engineers foresaw and flagged - the accountability travels downward onto people who never made the original commitment. The organisation draws the wrong lesson. The next programme gets tighter control, less trust, and fails faster.

This cycle is not inevitable. It is structural. And structural problems have structural solutions.

Firmitas is a philosophy-led framework for engineering delivery. It is built on the conviction that sustainable engineering performance requires three things to be true simultaneously: that delivery knowledge is respected and acted on, that commitments are owned by the people who make them, and that the systems surrounding engineering teams are designed to make good outcomes possible rather than merely to measure the absence of them.

The framework is not a process to be installed. It is a set of structural positions - about where authority should sit, how risk information should be treated, what governance is actually for, how estimates should be made and used - that together address the conditions that produce the failure pattern this book describes.

How the book is structured

The book is in three parts.

Part One: Why Programmes Fail makes the diagnosis. It opens with a composite programme - drawn from patterns observed across many real programmes in defence, industrial systems, IoT, and telecoms - and follows it through the sequence that will be familiar to anyone who has been on a programme that failed predictably. An honest assessment produced at week three. A risk register with three red items. A programme board that noted the risks and moved to task status. A window that closed. An outcome that nobody wanted and that everyone involved had enough information to prevent.

The subsequent chapters of Part One explain why that sequence is so consistent. Chapter 2 examines the sandbag assumption - the belief that engineering estimates are padded and that pressure will extract the real number - and shows why it is almost always wrong and always damaging. Chapter 3 examines the committed date - where it comes from, why it is so rarely made by the people who have to keep it, and what the commercial and contractual reality means for how the gap between commitment and honest estimate should be managed. Chapter 4 examines the six interacting systems that together produced the failure. Chapter 5 examines the learning cycle - why the lessons drawn from each failure compound the conditions that produce the next one.

Part One ends with Chapter 6, which introduces the systems thinking foundation and the twelve principles that form the philosophy layer of the framework. These principles are not values. They are structural positions earned by what the preceding five chapters described.

Part Two: The Framework presents the structural response. Every chapter opens with a connection to the specific failure mechanism it addresses. The framework is not presented as best practice - it is presented as the direct answer to a named problem. Leadership and governance, commitments and estimation, risk and issues management, requirements engineering, the delivery model, quality, teams, communication, technical debt, capability, portfolio management, AI in regulated delivery - each element is grounded in the diagnosis that preceded it.

Part Two is the majority of the book. It is where the practical guidance lives. Readers who want to move directly to a specific element - the risk register treatment, the estimation approach, the delivery model - can do so. The connections back to Part One are there for context, not as a requirement for understanding any individual chapter.

Part Three: Making It Stick addresses adoption, sustainability, and the honest limits of the framework. It includes the Firmitas Delivery Diagnostic - twenty-six questions that assess how the conditions in a real programme compare to what the framework requires. It addresses the leader who recognises their own behaviour in what the book describes, the common failure modes in adoption, what the framework cannot fix, and what sustainable delivery looks like over the long term.

How to read this book

Different readers will come to this book from different positions. The following is a guide to where to start based on where you are.

If you are sceptical that your organisation has a structural problem - if you believe the issue is execution competence, team capability, or insufficient process discipline - start at Chapter 1 and read Part One in full before engaging with Part Two. Part One is written for you. It makes the structural argument from evidence rather than assertion and asks you to read it with your last failed programme in mind.

If you are already convinced that the problem is structural but want the practical framework - you can start at Part Two after reading Chapter 6, which provides the principles and the layered model that frame everything that follows. Part One will still repay reading, but Part Two can stand without it.

If you are a senior leader who governs engineering programmes - Chapters 3, 8, 9, 10, and 24 are the most directly relevant to the decisions you make and the conditions you create. The diagnostic in Appendix B will give you a rapid assessment of your current programme against the framework’s requirements.

If you are an engineer or architect who has experienced the failure described in Part One - Part One will confirm what you already know. Part Two will give you the language and the structural argument to advocate for the conditions that would have changed the outcome. Chapter 24, in particular, is addressed to the leaders around you rather than to you directly - but it is useful to understand what the framework asks of them.

If you want to assess your organisation before reading in full - the Firmitas Delivery Diagnostic in Appendix B is designed to be used independently. Twenty-six yes-or-no questions with evidence checks. The score and the clustering of your answers will tell you which parts of the framework are most urgent for your context.

What this book is not

It is not a methodology. There is no prescribed sprint length, no mandatory ceremony schedule, no certification path. The process layer of Firmitas is intentionally variable - it adapts to context. What does not vary is the philosophy.

It is not a universal solution. The honest limits of the framework are addressed directly in Chapter 28. There are organisational contexts - the very small startup, the highly compartmentalised security programme, the large multinational where decision authority is structurally separated from delivery knowledge by design - where Firmitas either does not apply or can only be applied partially. A framework that cannot tell you when it is the wrong tool is not a framework. It is a belief system.

It is not a criticism of any individual or profession. The commercial director who committed to the unachievable date, the programme board member who noted the risk register and moved on, the project manager who built the reverse-engineered plan - none of these people are the villains of this story. They were responding rationally to the systems they were in. Changing those systems is what the book is about.

A note on the word Firmitas

Vitruvius, writing in the first century BCE on the principles of good architecture, argued that any structure worth building required three properties: firmitas, utilitas, and venustas - solidity, usefulness, and beauty.

Firmitas came first. Not because the other two do not matter, but because without structural integrity nothing else can stand. A beautiful building that cannot bear its own weight is not a building. A useful process built on a system that undermines it is not a solution.

The name reflects the thesis. Before methodology. Before process. Before governance frameworks and delivery models and maturity assessments - the structure must be sound. The conditions under which engineering work happens must be designed to make good outcomes possible, not merely to measure whether they occurred.

Structural integrity in engineering organisations means the same thing it means in physical structures. Not rigidity. Not permanence. The capacity to bear load without failing - and to flex under pressure without losing the properties that make the whole thing stand.