This book began as many presentations and short documents that I put together for different projects over the years. Those presentations covered topics from basic requirements management to good distributed system design to how to plan and operate a project that was regularly in flux. A few of the documents were retrospectives about why a project had run into trouble or failed. Others were written in an attempt to head off a problem that I could see coming.
I have worked on many projects. Most of these have been about building a complex system, or one that required high assurance—ones where safety or security are critical to their correct operation. Some have gone well, but all have had problems. Sometimes those problems led to the project failing. More often they have cost the project time and money, or resulted in a system that was not as good as it should have been. In every case the problems have required unnecessary effort and pain from the team working on the project.
This raised the question: what could be learned from these projects? How can future projects go better?
I began to sense that there were some common threads among all the education and advice I was putting together for these teams, and the problems they were having. With the help of some colleagues who were working their own challenging projects, I began to sort through these impressions in order to articulate them clearly and gather them in one place.
I have found that many of the problems I have observed have come at the intersection of systems engineering, project management, and project leadership. Building a complex system effectively requires all three of these disciplines working together. Most of the problems I have seen have arisen from a breakdown in one or more of them: where there is capable project management, for example, but poor systems engineering, or vice versa.
The intersection is about how each of these disciplines contributes to the work of building a system. The intersection is where people maintain a holistic view of the project. It is where technical decisions about system structure interact with work planning; where project leadership sets the norms for how engineers communicate and check each other’s work. It is where competing concerns like cost versus rigor get negotiated. And it is where people take a long view of the work, addressing how to prepare for the work a year or more in the future.
I’ve worked with many people who were good at one of these disciplines, but didn’t understand how their part fit together with others to create a team that could build something complex while staying happy and efficient. I have worked with well-trained systems engineers who knew the tools of their craft, but did not know how or, more importantly, why to use them and how they fit together. I have worked with project managers who had experience with scheduling and risk management and other tools of their craft, but lacked the basic understanding of what was involved in the systems part of the work they were managing. I have also worked with engineers and managers who were tasked with assembling a team, but did not understand what it means to lead a team so that it becomes well-structured and effective.
In other words, they were all good at their individual disciplines but they lacked the basic understanding of how their discipline affects work in other disciplines, and how to work with people in the other disciplines to achieve what they set out to do.
And that brings me to the basic theme of this book: that making systems is a systems problem, an integration problem. The system that is being built will be made of many pieces that, in the end, will have to work well together. This requires at least some people having a holistic, systemic view of the thing being built. The team that builds the system is itself a system, and its parts—its people, roles, and disciplines—need to work together. The team is something to be engineered and managed, and it needs people who maintain a holistic view of how its parts work together.
This book is not a book on systems engineering or project management per se. Rather, it provides an overarching structure that organizes how the systems engineering, project management, and leadership disciplines contribute to systems-building. While I reference material from these disciplines as needed, do not expect (for example) to learn the details of safety analyses here. I do discuss how those analyses fit with the other work needed for building a system, and provide some references to works by people who have specialized in those topics.
This book is for people who are building complex systems, or are learning how to do so. I provide a structure to help think about the problems of building systems, along with ways to evaluate different ways one can choose to solve problems for a specific project. I relate experience and advice where I have some.
Using this book. This book covers two topics: the system being built, and how to go about building that system. These topics are intertwined, because the point of going to the effort to build a system is to build a well-functioning system.
The first two parts of this book are meant for everyone, and to be read first. They provide a general foundation for talking about making systems. That is, they present a simplified but holistic view of making systems. They present a short set of case studies to motivate what I’m talking about (Part I). Part II presents models for thinking about systems and the making of systems at a high level, along with recommended principles for both.
The two parts that follow provide more detailed discussions of what systems are (Part III) and what systems-building is (Part IV). These parts expand on the material in Part II, providing more structure for talking about each of their subjects. These parts are meant to be read after the foundational parts, but need not be read in order or all at once.
Defining what a system is, in the abstract, intersects with the work of making a system in what I call the system artifact graph. This is the realization in one physical form or another of the abstract model of a system—how it is written down. Those artifacts are also what the work of building the system produces.
The remaining parts go into depth on concepts and tools that help with building complex systems. These include topics like project life cycles, system design, team organization, and planning. These parts use the language built up in the first parts. The later chapters are meant to be read as needed: when you find you need to know about a topic, dip into relevant chapters.