Clouds at dawn

A system can paint many different outcomes.

Part 1

We should be guided by theory, not by numbers. – W.E. Deming

Many process improvement programs falter when, despite best efforts, they don’t improve the overall performance of IT. The impact of fixing individual processes can easily get lost in the weeds, the impact overtaken by the inertia of the overall systems. “Systems Thinking” is a way to view the world, including organizations, from a broad perspective that includes structures, patterns, and events, rather than simply events. “Systems Thinking” is all about the big picture. Grasping the big picture is important when approaching any change program. Grasping the big picture becomes even more critical when the environment you are changing is complex and previous attempts to change have been less than successful. The world that professional developers operate within is complex even though the goal of satisfying the project stakeholders, on the surface, seems so simple. Every element of our work is part of a larger system that visibly and invisibly shapes our individual and organizational opportunities and risks. The combination of complexity and the nagging issues that have dogged software-centric product development and maintenance suggests that real innovation will only come through “Systems Thinking.”

“System Thinking” requires thinking broader. The Waters Foundation suggests a set of “Habits of a Systems Thinker.” The habits[1] are:

  • Seeking to understand the big picture
  • Observing how elements within systems change over time, generating patterns and trends
  • Recognizing that a system’s structure generates its behavior
  • Identifying the circular nature of complex cause and effect relationships
  • Changing perspectives to increase understanding
  • Surfacing and testing assumptions
  • Considering an issue fully and resisting the urge to come to a quick conclusion
  • Considering how mental models affect current reality and the future
  • Using an understanding of system structure to identify possible leverage action
  • Considering both short and long-term consequences of actions
  • Finding where unintended consequences emerge
  • Recognizing the impact of time delays when exploring cause and effect relationships
  • Checking results and changing actions if needed: “successive approximation”

I would suggest that the central theme of these habits tells us that systems are complex and to really create the change you need to take the overall process into account and test all of our assumptions before we can know that our change is effective. 

An example presented at MIT’s System Design and Management (SDM) program on Oct. 22 and 23 drove the need to address complexity through holistic solutions home. A hospital scenario was described in which alarm fatigue has occurred leading to negative patient outcomes.[2] Alarm fatigue occurs when health professionals are overwhelmed by monitoring medical devices that provide data and alerts. The devices don’t interoperate therefore all of the data and alerts just create noise which can hide real problems. Any IT manager that has reviewed multiple monthly project status reports and updates can appreciate how a specific problem signal could be missed and what the consequences might be. 

“Systems Thinking” applied through the filter of the “Habits of a Systems Thinker” is tailor-made to help us conceptualize, understand, and then address complex problems; to find solutions for problems that seem elusive or that reoccur in an organization.

Why isn’t “Systems Thinking” one of the first techniques any IT change agent reaches for?  I would suggest that it begins with training. Most Change Professionals have not been trained in applying “systems thinking” techniques because it was viewed as an engineering or academic practice. “Systems Thinking”, while applicable to any type of system, has primarily been applied in science, engineering, and economics. The introduction of lean techniques has provided a bridge to evolving craft/engineering practice of IT just as it has for other ideas such as Kanban. Even when introduced, the application is complicated because most IT change professionals have a limited span of control. As noted earlier, a system includes all structures, patterns, and events required for an outcome. Affecting systems that are outside of the change agent’s span of control is difficult, requiring the development of influence and political capital outside of their comfort zone. Consider a set of process improvements meant to quicken the pace of requirements definition and evolution that feed into a classic stage gate for approval. As an example of change that was made moot by boundaries, I recently discussed a scenario with a colleague in which a group of business analysts embraced an iterative process for requirements elicitation but still had to provide a single complete requirements definition document before the project could progress. They had not been able to engage the owner of the stage-gate process to fashion a scenario in which parts could be passed through the barrier as they were completed. Therefore little of the increased pace was transmitted to the overall process. 

One method I use to identify innovation opportunities taking a “Systems Thinking” approach is to use the combination of affinity diagramming (brainstorming and mute-grouping) and mind mapping to identify the variables impacting the system (e.g. project delivery). Then, I identify trends underway in these variables and trends that impact these trends. Affinity diagramming is a technique of driving out and grouping large amounts of data from a group through the use of seed questions and brainstorming followed by team grouping exercise done without talking. Mind mapping is then leveraged to mine the data for non-linear relationships and to prompt for completeness. Combining the two techniques in a team environment leads to taking a holistic approach. 

“Systems Thinking” is a powerful concept, however, the breadth of vision required to address even the small system incentivizes many managers to stay focused on their individual part of the process. We have been taught that focusing on specific issues will help us improve what we do over time. Unfortunately, focusing on a narrow view of a complex system rarely provides enough information to affect overall customer experience or satisfaction. When improving development and maintenance processes, what really matters is that we deliver what we promised, when we promised, and for what we promised. Then be in a position to do that as many times as required. That last requirement means that our interactions, processes, and people must be consumed in a holistic and sustainable manner. Building a backlog of process and human debt by focusing on steps rather than the whole does not deliver sustainable products.