This book is about both what a well-built system is and how to make that happen. To begin, I’ll start with a simple story: building a small cottage model out of Lego™ bricks.
This story is made up, but it reflects some of the situations I have found in real projects I have worked on. It deliberately illustrates problems in a simplified and perhaps exaggerated way to make them clear. The simplifications include: a very small team, and one that doesn’t need to grow during the project; customer “needs” that are simple; and a project that does not need to consider real emergent properties like safety, security, or even mechanical strength.
3.1 The request
A customer wants a small cottage model, built out of Lego™ bricks. They would like the cottage to be white. They would like it to have a window. They have a base plate they would like it to fit on.
Someone on the team works with the customer to get this information and understand the needs. This results in a sketch, which the customer agrees reflects what they have asked for (Figure 3.1).
3.2 Building the cottage
The project gets its team together, and they begin discussing how to design and build the cottage. Based on the sketch concept, they decide to split the work: one person for each of four walls, and one person for the roof.
The team discusses some basic design parameters. The decide on the length and height of each of the walls, based on the size of the base plate and the rough ratio of the sides in the sketch. They also decide which wall will get the window.
Each person on the team then begins designing and building their part, based on the sizes they have agreed on. The result is a set of five assemblies (Figure 3.2).
Right away there are some visible problems.
- The wall with the window is missing bricks to the right of the window. The person building that wall segment couldn’t figure out how to connect those bricks.
- Another wall segment has red stripes, because the person designing that segment liked the look of stripes better.
The team then try to integrate the assemblies together to make the cottage. The result is not good (Figure 3.3).
There are integration problems.
- The roofs are unsupported. It’s unclear whether the triangle-shaped sections under the angled roof segments are part of the roof component or part of the wall below them.
- Some of the wall segments are designed to interlock with the ones adjacent to them, but not all. Some people determined that interlocking at the corners adds to the strength of the cottage structure, but they did not coordinate this interface with the people building the adjoining wall segments. The segments that are designed to interlock don’t do so in compatible ways.
At this point, the team addresses some of these issues. They add roof supports to the front and back walls, and redesign all the walls to interlock at the corners.
The result is a structure that integrates all the components (Figure 3.4).
There are still problems with the integrated cottage.
- The cottage is supposed to be white, but there is a red brick on the side.
- There is a brick on the side that doesn’t fit in its place.
- The cottage lacks a door.
The problems with the side wall come from one of the team members rushing to rebuild that wall after they were reminded that the cottage was to be all white and not have red stripes.
The missing door is a specification problem that came to light when the customer saw the completed cottage. The original sketch developed with the customer didn’t include a door—it only had an annotation about a window. People implicitly know that cottages need doors but builders may miss out on the door if it isn’t explicitly specified.
After some systems work, the team corrects the problems, fixing the side wall and adding a door. Correcting the problems involved taking the cottage more than halfway apart and rebuilding it. The result meets what the customer wanted (Figure 3.5).
3.3 Retrospective on building
There were several problems that the team encountered building the cottage.
The team did not work with the customer to develop a thorough understanding of the customer’s needs. The team only had a minimal writeup of the needs, and that writeup left an important need implicit (the need for a door).
Next, the team did not develop a concept of the system (the cottage) and check that concept with the customer. For example, the team could have made a more realistic drawing of the cottage, and talked with the customer about how the cottage would be used. Checking a concept would have probably caught the missing implicit requirement for a door.
To their credit, the team decomposed the cottage into components (walls and roof), defined some dimensional requirements each would meet, and assigned someone to design each component. Unfortunately the team did not work out and document the interfaces between components. This meant that no one looked at how the walls would be joined (interlocking or not), and no one looked at how the roof would be supported on some walls.
One of the team members building a wall did not follow requirements about color—or perhaps the color requirement was missing or unclear.
Finally, the team members did not communicate with each other. Ideally, each one would have shared abstract designs for their component with the people building components connecting to that component. Sharing these designs would likely have caught that each team member had different understandings of how their components would be joined together.
The outcome was that it took longer than it should have because there was rework that could have been avoided.
Of course, this story is simpler than building a real building would be. A real building has multiple internal component, such as electrical, plumbing, or HVAC systems, that would create many more interfaces among components. A real building has to be designed to be mechanically sound; this requires systematic analysis to ensure that the building will stay up event in unusual events like storms or earthquakes. A real building also has safety concerns, like fire safety. Finally, building a real building is regulated in most places, requiring permits, inspections, and approvals from external authorities to ensure regulatory compliance.
3.4 Adding to the cottage
Some time passes, and the customer decides that they would like a larger model cottage, and they make a request to add on to the initial version. The team that built the original cottage has moved on to other projects.
A new team talks with the customer to learn what the customer wants. How much larger do they want the extended cottage to be? Should it be extended horizontally or vertically? The customer indicates that an extension adding between 50% and 100% of the original floor area would be sufficient, and the customer prefers a horizontal extension.
The team next has decisions to make about the overall design of the extension. They settle on an approach that matches the style of the original part and adds a little over half the floor area. They suggest to the customer that a window in the extension would be a good idea, and the customer agrees.
The new team does not have access to the team that made the original design decisions. They have to reverse engineer the design approach used by examining the cottage as built.
The original cottage was located toward the back of the base plate, and the team has decided that the extension should be at the back of the original. This implies that the team will have to move the original cottage forward. The team examine the original structure and determine that it can be moved on the base plate without problems.
The new team works together to design and build the extension. They have learned about the problems that the original team had, and so they manage the interfaces between walls and with the roof better. However, they don’t have access to the decisions that the original team made about interlocking the walls for strength, and so they build the extension as a separate unit.
3.5 Retrospective on addition
This illustrates a common scenario: that changes are made to a system long after it was originally built. The changes can be complex projects on their own. The original team may be long gone, or they may no longer remember details that were not written down. Knowing the design decisions and their rationales for the decisions affects how the changes are designed.
The changes not just add features (new space), but add interfaces between new parts and the original, and can change the interfaces within the original.
The team that build the original cottage did not document the design decisions they made. The team building the addition had to reverse engineer the design from the built cottage. The lack of information about the rationale for how walls were connected led to a different, less structurally sound approach for connecting the addition to the original structure.
The project to build the addition took longer than it could have if the team had not had to reverse engineer the design. The lack of design rational led to a structural solution that is sufficient for plastic bricks but would not work in a real structure.
In this story, the new team did learn from the original experience that they should do systems-level work. They worked through the interfaces between new parts, and this led the new project to go more smoothly than the original. The lesson is that learning over time matters.
Once again, this story is a simplification of a real building project. A real building would have far more interfaces: electrical circuits and plumbing might need to be extended. The structure of a real extension would have to be integrated into the original structure.
This story did not show the value of designing the original to be expanded. In the example, the original cottage could have been placed forward on the base plate so there was space for a later addition. In a real building, by analogy, designing the electrical main panel to have space for additional circuits and enough capacity to add more usage would make an addition easier.
3.6 Principles
As I present these stories, I will link them to the principles in Chapter 8 that can provide solutions.
Project leadership. Some of the problems in this story relate to how the cottage-building project was led. The most relevant principle is Section 8.1.3—Principle: Systems view of the system. The original team’s work would have gone more smoothly if they had had someone responsible for ensuring that the system made sense as a system.
System-building tasks. Some of the problems related to how the original team went about its work—which resulted in problems with the final system product.
- Section 8.2.1—Principle: Start with a purpose before doing work. A team should have a thorough understanding of what they trying to build and why before setting out to build it.
- Section 8.2.5—Principle: Document things so there is a future. Most systems-building projects produce a system that will outlast the people who initially build it. The team that documents essential information, especially design rationales, will help the teams that will come along later to evolve the system.
- Section 8.2.6—Principle: Build in checks. Defining regular points when the project’s work will get checked helps catch errors early, minimizing the cost of undoing and redoing work.
The team. This story does not illustrate many problems with the team itself. However, the team building the original cottage built each of the components in isolation, and did not discover that their parts would not integrate until the parts had been built.
- Section 8.4.4—Principle: Define regular communication paths. If the team had followed this principle and planned out regular communications to check integration they might have avoided some of the problems.