Why isn’t systems thinking one of the first techniques any IT change agent reaches for? Most change professionals have not been trained in applying systems thinking techniques because it is viewed as an engineering or academic practice. It provides a framework for the introduction of lean techniques, which have become popular to deliver the maximum business value. Lean provides tool and philosophy and systems thinking provides the breadth of scope to apply those tools. Systems thinking provides process improvement with both a scope by defining what a system is and a business related goal for improvement, to improve the delivery of business value.
Affecting processes, systems and the environmental elements that are outside of the change agent’s control is difficult, requiring the development of influence and political capital outside of their comfort zone. For example, in an organization that is delivering a product that requires a hardware and software combination, a change that shortens the length of time needed to deliver the software may not impact the delivery time of the product if the hardware development does not keep pace. For another example, 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. The changes can be made moot by department boundaries within IT as easy as by processes and systems outside of IT. A few years ago, I observed a group of business analysts who 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.
Process improvement begins by identifying opportunities. In order to use a systems thinking approach to process improvement we need to ensure that the boundary for process improvement is a whole system, a whole value chain, and provides the means to affect the output of the whole system. This helps ensure that any changes improve the overall performance of IT. One, simple approach I use to identify systems thinking process improvement opportunities begins by assembling a cross-functional team (or teams, for large supply-chain systems) that includes representatives with experience from the whole system – beginning to end. This is similar to the process described in our discussion of value chain mapping. I facilitate the team through one or two sessions using a combination of affinity diagramming (brainstorming and mute-grouping) and mind mapping in order to identify the variables impacting the system. Affinity diagramming is a technique of driving out and grouping large amounts of data though 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, the cross functional team can take a holistic approach to making change. After we drive out the variables, I have the team work through building a desktop model to identify which variables the team feels will impact the ultimate performance of the system. For the variables selected, I ask the team to identify trends underway in these variables and any external trends that impact these trends. This generally requires a bit of research and the collection of performance data for the variables. Experimentation, like building mathematical models and process pilots, is used to determine if the identified variables will have a positive impact on the output of the system being studied.
Systems thinking is a powerful concept. However, the breadth of vision required to address even the small process improvements is intimating to many managers. So, they 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.