Deciding when to discuss Peter Senge’s fifth discipline of Systems Thinking is always a little difficult. In his book, The Fifth Discipline, Senge presents the concept up front since it serves as the foundation and the structuring concept beyond the other four disciplines. But I have delayed the discussion in this series because nimble project managers always understand Systems Thinking at a deeply intuitive level, even if they can’t articulate what they know. I also believe a nimble project manager needs to have mastered at least some of the disciplines of personal mastery and mental models in order to be able to successfully articulate a systems thinking perspective to others.

Previous articles in this series

The first three articles in our exploration of Peter Senge’s core disciplines discussed personal mastery and introduced the concept of mental models:

Adopting and practicing the discipline of Systems Thinking is a significant departure from how many of us see the world. Most of us learned to approach a problem using the traditional linear analytical techniques that tell us we can understand a system by breaking it apart and looking at the pieces separately. In fact, the word “analysis” actually comes from the root meaning “to break into constituent parts.” Systems Thinking, in contrast, focuses on the interactions between the various elements of the system in order to understand the unique relationships these interactions produce. The key factor to understand in Systems Thinking is that the whole is not only greater than the sum of its parts, but it is also fundamentally different than the sum of its parts.

The Butterfly Effect
From the perspective of the nimble project manager, Systems Thinking is applied to organizations and problems that are assumed to be both complex (multivariate, with multiple linkages and feedback loops) and adaptive (able to respond to an environment of constant change without either stagnating or dissolving). Additionally, all complex adaptive systems are assumed to be non-linear.

“Fundamental to chaos theory is the phenomenon of sensitive dependence on initial conditions, commonly referred to as the Butterfly Effect. A butterfly flaps its wings in Peking, and weather in New York is different.”—Ian Malcolm

The above quote is a mantra within the complex adaptive systems (CAS) community. We’ve all had it drilled into our heads that we need a well-defined requirements document, a highly detailed project plan, and an all-encompassing risk plan, etc. But this knowledge comes to us through the doctrine of observed best practices within an assumed linear system. What a non-linear paradigm tells us is that because of the “sensitive dependency on initial conditions,” no two projects will ever be the same. There will always be differences and unexpected/unforeseen occurrences that will happen on any project. What a non-linear paradigm tells us is that our well-defined requirements document is probably a 70 percent waste of paper, that our 2,000-line Gantt chart will be obsolete before we even start the project, and that managing risk is something we do every day, not just when we pull our risk plan together.

Asking the Five Whys
A system is defined as a “group of interacting, interrelated, or interdependent elements forming a complex whole.” This means we can be sure that the problem our project is intended to address has its roots in more than one cause and is having both direct and indirect effects within our company. In order to truly understand our initial conditions, we should begin every project by asking what Senge calls the Five Whys. In basic Senge parlance, this technique is simply to ask the question why five times in order to elicit more and more information and to expose hidden assumptions. While this works as a general technique, we can apply the technique to project management by using the Nimble Five Whys instead:

  1. Why are we doing this project?
  2. Why do we think the identified problem really is the problem?
  3. Why do we think this is important to solve now?
  4. Why do we think this proposed action would solve the problem?
  5. Why do we think this action won’t make anything else worse?

In general, these questions are best asked in a group setting with the appropriate stakeholders in attendance as soon as the project has reached the proposal stage. What you call this meeting when you schedule it with your stakeholders is completely up to you. I usually present it as the first in a series of joint application design (JAD) sessions. In a healthy project environment, I haven’t gotten a lot of push back. Asking these question isn’t always easy, and in some cases the stakeholders will absolutely refuse to answer in a meaningful manner—but even the lack of an answer can help refine the initial area of order.

In addition to the Five Whys, Senge presents another key assertion when discussing Systems Thinking: Senge believes there are a number of archetypal mistakes that we make in our attempt to resolve a systemic problem. Senge categorizes them into two classifications: Limits to Growth and Shifting the Burden.

Systemic problems
There is a concept in economics called economies of scale. The premise is that for any particular undertaking (like an auto assembly line) there is an optimum size. If the line is too small in relationship to the fixed costs, unit costs will be too high for the market. If the line is too large, excessive variable costs will once again drive the unit cost above optimal. Senge’s premise in defining Limits to Growth as an archetypal problem is that there comes a time in every system when doing more of the same simply doesn’t work. From the perspective of the nimble project manager, this is a shorthand message that says “beware of nth incremental improvement project.” At some point in the life of every system, the time comes to throw it away and revisit the problem area.

Shifting the Burden is one systemic problem that IT departments regularly encounter. In fact, I’ll go so far as to contend that 90 percent of all systems shelved prior to implementation or scrapped because the users refuse to use them failed because they shifted the burden. A classic example of this archetype was a project I worked on several years ago for a major software company. Management was concerned that they were spending a lot of money on training without achieving any clearly measurable benefit. Corporate training responded by proposing a measurement system when the next release of the HR system was installed. Three months later, we cancelled the project because what sounded like a simple upgrade of software was going to affect every single employee in the company, take about 18 months to implement, and cost between $3 million and $8 million. From the perspective of the training department, the proposal made sense. From the perspective of the rest of the company, implementing a high-overhead process in order to help training justify their existence was utter madness.

From the perspective of the nimble project manager, understanding that shifting the burden never ends up being successful is one of the first great lessons. The bottom line is this: If the end user isn’t asking for the solution, you are solving the wrong problem. This translates to the hard-and-fast rule that if you can’t get a user steering committee to support your project, or you feel your user representatives are too isolated from the real work the software system is designed to support, try to force the project into either an early deliverable or into the status of a feasibility project where you can either fix it or kill it.

Area of order
Returning to our opening premise about sensitivity to initial conditions, the next thing we learn from our system thinking perspective is that in a system, everything is linked together and a change in one factor in the system automatically creates a change in another part of the system. From the perspective of software development, this means that once the software is developed and deployed, the basic needs that drove the desire for the application have changed. This is the premise that underlies all rapid application development (RAD) or agile development methods, and it’s also the reason that a lengthy requirements-gathering process on any software project is probably a waste of time.

The statement above should not be interpreted as supporting the pointy-haired manager from Dilbert when he says, “I’m off to get the requirements, why don’t you start coding while I’m gone?” Rather, it’s an understanding that there are diminishing returns related to overspecification.

The most common situation is that the users ask for X. The project team dives in and does a thorough analysis of the problem and decides that what the users actually need is X1, which uses newer technology and, if they’re going to be writing code, why not get it solved right the first time even if it takes a little more up front work? The nimble project manger takes a slightly different approach, using the principle of Systems Thinking. Rather than trying to ensure that all the Ts are crossed and the Is dotted, the nimble or agile approach says to define the minimum acceptable functionality required to solve the problem, get it done quickly, and then enhance from there. The key point to understand here is that the decision to solve the immediate problem quickly and cheaply is based on the premise that once that portion of the problem is solved, the definition of the problem will have changed.

Tugging on the string
One of the real strengths of Systems Thinking is that it rescues basic process work from the scrap heap of old ideas. The best way to understand this is to visualize the company’s current processes as a tangled mass of string. In order to effectively solve the problem your project is designed to solve, it is your job to tug on the appropriate string and see where it goes. What departments are affected by the string; where does the string loop back on itself and get tangled up?

In the old days, we called it documenting the as-is process. We also invested the time and effort to identify the to-be process and then double-checked that the process made sense before anyone ever wrote a line of code. Today, process work has fallen out of favor because people believe it’s unnecessary, time consuming, and yields little value. From the perspective of the discipline of Systems Thinking, we know the problem isn’t with its value. Instead, the problem is only with how it’s done. Essentially, if you don’t understand the current system and the reach of the problem. your proposed solution will probably miss the mark.

Another factor that Systems Thinking tells us is that all systems will strive to maintain their current sense of balance. This one statement highlights an absolutely critical difference between nimble project management and conventional project management. Organizations are not assumed to be change resistant; rather, they are assumed to be trying to maintain balance in order to avoid slipping over the “edge of chaos.” A healthy system and the people within it are perfectly capable of adapting when circumstances require it, but homeostasis is the preferred norm.

Systems Thinking
According to Senge, the discipline of Systems Thinking can be approached on three distinct levels:

  • Practice
  • Principles
  • Essence

Senge views these as a pyramid that an individual can ascend by first mastering the basic practices, then understanding the articulated principle, and finally by realizing (or, to borrow a very old term from Robert Heinlein, “groking”) the essence.

This view of ascent is one place where I have to disagree with Senge. I believe that It’s just as easy to go from the essence to the practice as it is to go from the practice to the essence. It just depends on how your mind works. Around 20 years ago, when I first began hiring analysts and project managers, I recognized that only about 25 percent of the people I interviewed seemed to have the right mind-set to do the work I wanted them to do. At the time, I didn’t have the right words to describe either what I was looking for or what it was I was seeing in the people I did hire. I now know that it was the instinctive ability to approach the world from the perspective of a systems thinker. Unfortunately, 20 years ago I only had the ability to hire or not hire; I couldn’t train or grow personnel who weren’t instinctive systems thinkers.

Senge’s fifth discipline has removed those barriers and effectively leveled the playing field. Becoming a nimble project manager is now a choice that is open to everyone who wishes to understand and practice the discipline of Systems Thinking. The next article in this series covers the discipline of Shared Vision.