This book is about the work involved in making a system—what a system is, and how to do a good job making one.
Part I presented a set of case studies that showed how system-building project can go well—or not. This leads to two questions: How does one build a system well? And how does one avoid the problems?
To start finding answers to these questions, consider three aspects of making a system: what a system is; the activities involved in making it; and the people who do the activities that make the system.
A system. A system is “a regularly interacting or interdependent group of items forming a unified whole”.[1] Other definitions speak to a set of items or components that work together to fulfill a purpose.
This definition includes some of the key aspects of a system.
For artificially built systems, the system is the outcome of all the work that people do to make the system.
Having a purpose distinguishes a system built by people from systems in nature. A natural system often just exists, and any meaning or purpose to it assigned after the fact by people. A human-built system, on the other hand, does something for someone. The purpose of human-built systems can be described in terms of what it does for someone, and why it is worth the effort to make a system do that.
Most systems are not static: they will evolve rapidly as they proceed from concept through design; once it is in operation, they will continue to evolve as their users’ needs evolve.
The next chapter, Chapter 6, discusses more about what a system is.
Making a system. The work of making a system can be seen as a string of activities, the life cycle of the system. It begins with an idea. That idea might be a user’s need, or it might be an idea for a new way to do something that might fill an as-yet-unidentified user’s need. The work proceeds to translate that idea into designs and then into a working system. This work goes through a number of steps, such as developing a concept, specifying its pieces, designing and implementing them, integrating the parts and verifying the assembly. Once a system has been built, it can be placed into operation. A system that has been in operation may change over time: users’ needs change, or technology changes. Eventually, every system is retired and disposed of.
All these activities are done by a team of people who are building the system, and the point of spending the effort is for the system, at when built and in operation, filling its purpose.
Chapter 7 discusses more about how to make a system.
Who does the work. A team of people working together does all the activities involved in making the system. For complex systems, the team can get large and may involve people at different companies and with different skills.
The team of people is itself a system: a set of people, whose purpose is to build the objective system, who interact with each other through discussion, documentation, and artifacts. A team that is functioning well is able to focus their efforts on the purpose of the system they are building. The team is organized so that its members have information they need each to do their part, and to communicate so that the pieces of the system that they create work together.
Key roles. A team that functions well, like any human-built system, does not happen by accident; it happens because someone takes the effort to design and implement it so that it works well.
In practice, there are three roles that do this work of organizing and running the team. These roles may be divided among team members in many different ways, but every team building a complex system needs the three roles filled somehow. The roles are:
The intersections. Having teased apart the ideas of system, system-building, and people, and the ideas of systems engineering, project management, and project leadership, the next step is to acknowledge that none of these things are in fact separate.
The objective of a project is to produce a system. The way to produce it is to do system-building work. The people in a team do that work. All three must fit together: the way that the work gets done determines whether the resulting system meets its purpose. How the team is organized, its culture and habits, govern how the people will do the work.
While systems engineering, project management, and project leadership are different roles and involve different skills, they work together. Leadership by itself gets nothing done; that comes from engineering and management. Leadership and management without systems engineering might produce a system but it probably won’t work. Leadership and engineering without management usually means a lot of engineers running around doing cool things but also wasting time and resources and not actually getting things done. Management and engineering without leadership isn’t able to make decisions or take responsibility.
The people filling each of these three roles also need to understand their counterparts’ roles. A systems engineer who designs something that would require more time or resources than the project has is not going to be effective. A project leader who does not understand the work the team does is not going to model good work practices. A project manager who does not understand the engineering is not going build a plan or schedule that makes sense.
Systems work, in the end, is about doing work that makes a coherent whole out of the parts it has to work with. The work of making a system is just as much systems effort as its product is. Only when the parts fit together does the work get done as it should.