Wicked problems need a systemic approach to problem-solving that investigates and models problems from a human-activity perspective before attempting to define solutions. In IT design, we tend to define requirements for a solution with very little inquiry into the problem. Systemic approaches spend more time on inquiry – the solution just follows from the definition of the current problem. I emphasize “current problem” because a systemic approach recognizes that wicked problems are too complex to define or resolve all at once. We therefore need a divide-and-conquer approach to problem-solving, as shown in Figure 1.
Figure 1. A Systemic Problem-Solving Approach
Any effective approach to solving wicked problems must be iterative. It must identify subsets of the problem, investigate these, model how various elements of the problem are related, and then develop a shared vision across stakeholders for how to resolve this subset of problems, before taking action to implement the negotiated solution. At each stage, you may need to revisit aspects of the problem determined at a previous stage:
- As you explore and model problem elements, you may need to perform more investigation in order to understand these elements better;
- As you develop a shared vision for the solution and agree how to resolve these aspects of the problem, you may need to explore problem elements in more detail and revise the models of how they are related, both to other problem-elements and to the business environment and goals;
- As you take action to resolve the problematic situation, you may need to revise your scope or focus, as the feasibility or implications of change become clear. At this point, you may need to revisit the shared vision and priorities with stakeholders, to resolve these constraints;
- Following implementation of the agreed solution, you will need to investigate and appreciate the situation now. Making changes means that the “big picture” problem will have changed.
Any systemic changes have waves of consequences, only some of which can be anticipated and modeled in advance. Other consequences only become apparent after a time-lag, at which point remedial action may be required. We therefore need an iterative planning approach – one that models how the organization works now, at the start of each cycle of change. This is shown in Figure 2.
Figure 2. An Iterative Approach to Systemic Change Management
The spiral follows the stages of analysis shown in Figure 1. Each cycle breaks off a different subset of problems, which are modeled, defined, and refined in the second stage. Of course, there is feedback between stages – as shown in Figure 1 – because you need to explore stakeholder perspectives in more detail as you produce problem cause-and-effect models, or rework the clustering of problems into different “sub-systems” of work activity, as stakeholders explore the implications of clustering problems in this way. The third stage produces a set of IT and work-design prototypes that allow stakeholders to explore the implications of defining problems in this way. Once they are agreed that this is how they wish to change things, the fourth stage implements changes across the organization and evaluates the outcomes. We then come full-circle, to investigate what problems we face now …
