Business analysts, change managers, and IT systems analysts are in a no-win situation. They are expected to understand myriad interpretations of the business strategy, reconcile conflicting viewpoints on how business processes work, and – somehow – define a coherent set of change objectives that pleases everyone. While the stakeholders of change each understand only a fraction of what the business does.
The co-design of business & IT systems is like piecing together a jigsaw puzzle without the picture. You get an edge here and there, part of a building outline, or a connecting feature, but mainly you are assembling bits and pieces that are tacked together in whatever way makes sense at the time. Most people fudge this by kludging viewpoints together under a single goal, with multiple objectives that reflect the main things that stakeholders seem to value. Objectives move in and out of the picture, as the focus shifts. Analysts have to understand multiple business domains, as stakeholders pull in different directions like the wild horses in the site header. Even business managers don’t really understand their processes – and know very little of the processes they interface with. Conflicts, priorities, and omissions in change objectives are seldom realized as current analysis methods don’t provide ways to map out the full scope of change, or to present this to business managers for input.
Systemic analysis uses a divide-and-conquer strategy. The parts of the jigsaw puzzle are assembled separately, then the analyst can piece together the whole. Conflicts, priorities, and omissions from the change requirements become obvious because of the way in which the whole picture is explored. This allows the change analyst and — more importantly — the managers, system users, victims, and beneficiaries of change to understand the scope and priorities of what will change.
This website provides a tour of how to enable IT-related change in complex business organizations (nonprofit and for-profit). It is focused around improvisational design, as improvisation is the result of dealing with wicked problems. We can never resolve (or even agree) such complex problems in one go – as Horst Rittell  argues, the best we can do is to take action, evaluate whether we made the situation better or worse, then try to fix the things we did not fix the first time. Goal-based design is a myth. Organizational change requires repeated cycles of learning (inquiry into the situation), change, and evaluation – until the design is good enough. Not perfect – and certainly not optimal – good enough is good enough .
2. Rittel, H.W.J. “Second Generation Design Methods,” Reprinted in N. Cross (ed.), Developments in Design Methodology, J. Wiley & Sons, Chichester, 1984, pp. 317-327., Interview in: Design Methods Group 5th Anniversary Report, DMG Occasional Paper, 1, pp. 5-10.