I grew up playing chess and have always been fascinated by the number of possible moves. Each chess player starts with 16 pieces: one king, one queen, two bishops, two knights, two rooks, and eight pawns. Each piece is governed by rules on how it can move. For instance, rooks can move horizontally and vertically while knights move in an L-shape. There are also 64 squares on a chess board. Even with a finite number of pieces and squares on the chess board, the number of possible moves is far from finite. Some argue it’s infinite. As each player takes a turn (a chess ply is one turn taken by a player), the number of possible games explodes exponentially.

An American mathematician named Claude Shannon calculated the number of possible games after each ply. The first player has 20 possible moves to start the game. The opponent has an equal number of 20 possible moves equating to 400 possible games after 2 plies. After 5 plies, the number of games rises to 4,865,609. Go to *https://en.wikipedia.org/wiki/Shannon_number *to read more on the Shannon number. I would classify chess as *complicated* due to the rules and set number of pieces. It would be *complex* if the rules changed every fifth move and if players could choose the movements of their pieces (pawns moving like knights). The modern car engine is also *complicated*. A gas combustion engine has a finite number of parts such as the engine block, pistons, and spark plugs. An engine is *complicated* but not *complex* because its behavior is predictable. Engineering and physics govern how the engine works and we can calculate things like horsepower, torque and fuel consumption.

Large scale projects are usually late and over budget due to *complexity *and* randomness *(more on randomness later). We need to take complexity seriously. Managing a project is more complex than playing chess. Let’s say you are responsible for bringing a technical product to market. Below are a few variables tied to the product development.

- Number of individuals on the project team: 15
- Number of product components: 10
- Number of Tier 1 suppliers: 10
- Number of Tier 2 suppliers: 20
- Number of individuals on Tier 1 project teams: 5 team members per supplier or 50 individuals (10 suppliers X 5 members)
- Number of individuals on Tier 2 project teams: 5 team members per supplier or 100 individuals (20 suppliers X 5 members)
- Potential industrial customers: 6

The seven bullet points above highlight more individuals are involved than the number of pieces on a chess board. Even though there are business practices such as accounting, product test methods, and quality measurement systems, projects and people don’t follow defined rules like chess pieces do.

Project managers typically calculate the number of communication channels for a team. A single communication channel is defined as the two-way communication between two people. For a two-person team, there is one communication channel per the formula N X (N-1)/2 where “N” is the number of individuals on the team. For our example above, our project team has 105 communication channels or 15 X (15-1)/2 or 210/2. Complexity shows its extreme effect when you start to consider the communication channels between the suppliers and potential customers.

As the engineers on your team work on the product design, there are several options to consider such as part tolerances and materials. Positive and negative results may occur after lab testing and field testing. During the product development, the sponsoring customer may change their mind and request design changes (scope creep). Project teams can use tools such as Gantt charts and change management processes to estimate completion dates and manage change requests.

Modern society is becoming more interdependent and complex. We can only *estimate* and *manage*, but not *control* complexity. We should acknowledge its existence and face it head on with simplicity. Simplify processes, simplify designs, simplify rules. Use *elimination* where possible. In other words, remove the *b.s.* to give yourself a chance against complexity.