Category: problem-analysis

  • Systems Thinking

    Systems Thinking

    Typically, systems requirements analysis fails because of two reasons:

    1. The analysis is not sufficiently systemic – it reduces a complex system down to a subset of activities and work-goals that can be understood.
    2. The analysis is too focused on what can be computerized. It does not analyze what needs to change, but what the IT system should do to support an [implicit] set of changes.

    Why are systems changes counter-intuitive?

    The human mind is not adapted to understand the consequences of a complex mental model of how things work. There are internal contradictions between future structures and future consequences, that become difficult to balance when multiple mental models are involved. Most people are “point thinkers” who only see part of the big picture. It is easy to misjudge the effects of change, when you only base your arguments on a subset of cause and effect. Systemic thinkers analyze interactions between various factors affecting a situation, to understand cycles of influence that affect our ability to intervene in changing the situation.
    An example of counter-intuitive set of influences is shown in the “systemic” view of a limited social welfare system, given in Figure 1.

    Image showing interconnections between elements of local society affected by raising social welfare payments: business attractiveness, response of wealthy, affect on tax-base, and impact of no. of people seeking work
    Figure 1. A Systemic View of A Limited Social Welfare System

    We have two opposing “vicious cycles” of influence, in this model:

    • The left-hand cycle reinforces the argument that raising welfare payments encourages “entitlement” and disincentivizes work.
    • The right-hand cycle supports a counter argument, that raising welfare payments attracts job-seekers and increases employment, raising tax base revenue, to provide a net benefit (as well as humane assistance).

    Unless a complete view of the whole system of interrelated processes is obtained, well-intentioned changes have unintended consequences. It is necessary to understand the system as a whole, rather than individual effects between factors, to understand these “vicious circles” of cause-and-effect. Tweaking one element will affect others, with knock-on effects as the two cycles interact. The only way to ensure a specific outcome is to intervene to break the cycle of influence (change the relationship between factors), or appreciate the interaction effects, so you can predict the outcome.

    In the pages that follow, I explore Soft Systems Methodology (SSM) – an approach that provides a philosophy and a set of techniques for investigating an unstructured problem situation without the constraints and blinkers that come with systems requirements techniques. SSM investigates an organization as a system of work-activities that may or may not require computer-based system support in solving problems with this system of work. Most methods for Information Systems requirements determination place the investigator (the systems analyst) in the role of “expert”. In other words, the analyst attempts to understand the organizational situation, determines what computer system functions are required by interviewing potential system users and/or managers, then draws on their expert knowledge of other computer systems to specify a hardware and software “system”, based upon their understanding of the organizational situation and tasks. If the analyst’s understanding is incorrect or incomplete, this is usually not detected until the system is tested by its organizational users, which may not happen until the system has been installed. This situation occurs because system users do not normally possess sufficient technical knowledge to understand and question the highly-technical system specification documents which the analyst produces, so any misunderstandings are not revealed until the system is built. One way of avoiding this problem is to produce a system prototype, where the system designer builds a trial version of the system for the users to try out. Comments and criticisms are fed back to the designer, who changes the system and produces another prototype; this process is repeated until both designer and users are happy with the system’s operation. However, prototyping is not appropriate for all development situations (such as very large, complex systems, where each user will only understand a very small part of the system’s operations) and also, a great deal of effort in producing and modifying inappropriate prototype systems can be avoided if a more effective investigation is performed into the system requirements in the first place.

    The advantage of SSM in such cases is that it models explicitly the different value-systems (perspectives) of various people in the organization, representing different people’s differing beliefs about the effectiveness and purpose of the organization (or their part of the organization) and their perceptions of current information systems within it. When organizational problems are difficult to define, many problems can be due to work “systems” (for example a department) prioritizing one set of organizational objectives at the expense of another set of objectives. For example, a computer-based system for the authorization of traveling expenses, used by staff in the accounts department may have been designed to reject claims which do not conform to low-cost criteria. Use of this system will force (or “encourage”) staff to use the form of travel which has the lowest cost (e.g. train rather than car) even when the company may lose business by someone not being able to reach a business client before a competitor. The use of SSM for the analysis of requirements for a traveling expenses system would make this conflict explicit, leading to the specification of an alternative system which was able to flexibly approve the expense on the joint criteria of cost and urgency.

  • 4. Explore Conceptual Models

    Step 4: Conceptual Models

    Deriving a conceptual model is a method of analyzing the activities which need to take place in order to clearly define what the actors need to do in order to achieve the transformation. Do not include activities performed by anyone other than the actors whom you have named in the root definition (and if possible, limit the actors to one group of people – activity-monitoring becomes very complicated when more than one group are involved). Again, disciplined thinking is required – list the activities needed to achieve the objectives of the system. It is important also to include activities which monitor the system and feed-back results, so that system activities may be performed effectively. Ask: what defines success for this system? how can I measure that success? what do my actors need to do, to measure success?

    I have chosen to provide a conceptual model for transformation (7), in the two examples below. The Root Definition for this system is:

    A system owned by Local Government Administration, where a combination of parking restrictions, to alleviate congestion at bottlenecks, and public transport provision, to make driving less attractive for short journeys, reduces the number of cars on the road and so improves air quality and traffic flow on major routes.

    The list of activities which I perceive as necessary for this transformation are:
    1.  Determine the extent of the problem (congestion & emissions), by major traffic route
    2.  Assess potential impact on these factors by managing parking, or implementing public transport
    3.  Take those actions that produce these impacts
    4.  Measure the number of people who transfer from cars to public transport
    5.  Measure the impact upon the environment of that transfer
    6.  Report to the public on the results.

    In Figures 4-1 and 4-2, I contrast a weak attempt at a conceptual model with a strong(er) attempt, for Transformation 7: Traffic congestion causes high C02 & particulate emissions ⟶ Easy and convenient public transport replaces need for short car journeys on local routes.

    Weak Conceptual Model for Transformation 7 (Alleviate congestion & high emissions with electric public transport)
    Figure 4-1. A Weak Conceptual Model for Transformation 7.

    The conceptual model shown in Figure 4-1 would be considered weak because each activity in the conceptual model is defined minimally. The activity defines what is to be done (the basic steps of the transformation), but not how to do it so that the purpose of the transformation (the combination of transformation, worldview/rationale, and evaluation of outcomes is achieved. Even the evaluation of the subsystem of activity is minimal, using only a single indicator to evaluate success.has fallen into the “consultancy mode” trap. What I have defined here is not what needs to be done, but how I, as a consultant, intend to find out what needs to be done and then take action. This happens whenever you do not have sufficient information from the stakeholders about what actually needs to be done – so you fudge the set of requisite activities! This is a core part of the “appreciating the situation” work of step 1.

    As part of the step 1 analysis, you need to interview as many stakeholders as you can, to gather perspectives and to understand what they would like to happen – and why this system-purpose is important to them. This is often an iterative process: you define a transformation from one perspective, explore what needs to be done to achieve it , then realize that you need more information from stakeholders to understand the “hows” and “whys” of these activities. Having iterated a couple of time, you can then define a much more informed – and feasible conceptual model, as shown in Figure 4-2.

    Let us imagine that I have done this – and the core stakeholders suggested two main strategies for achieving transformation (7):
    – Increase fines for driving offenses and cross-subsidize public transport with the revenue raised.
    – Make driving more difficult and time-consuming than public transport by rationing road use and policing parking at bottlenecks.

    Strong Conceptual Model for Transformation 7 (Alleviate congestion & high emissions with electric public transport)
    Figure 4-2. A Strong Conceptual Model for Transformation 7.

    This conceptual model shown in Figure 4-2 is stronger, as it defines activities in terms of what needs to be done, and how, to achieve the desired purpose of the transformation. Each activity is defined from the worldview of why this transformation is important to the success of the system as a whole (of which it reflects one perspective). At each stage of the sequence of activity, evaluation criteria are considered – for example, when cost-benefit analyses are used to prioritize traffic routes for change implementation. This analysis of activities produces multiple indicators by which we can evaluate success, which allows us to tweak both activities and success criteria, on each cycle around the steps of this subsystem (which would be repeated multiple times, over the duration of the change project).

    An important element of conceptual models are the feedback loops. There are normally two feedback loops in any conceptual model:
    1. An internal feedback loop, that permits actors involved in the human-activity system perspective modeled to adjust how they perform their work (in this case, this loop is between the first and last “Measure traffic flows, congestion-points, CO2 and particulate emissions, in key places along each route” activities, enabling the state of the system at the start of the activity to be compared to the state of the system at the end of this round of activity). This feedback loop (the dotted line inside the model boundary) permits the people doing the work to evaluate their performance.
    2. An external feedback loop, between the inputs and the outputs of the activity system model for this perspective. This feedback loop (the heavier dotted line outside of the model boundary) permits external managers to evaluate the performance of the system from this perspective. To permit the effective management of any system, you need to define measures of success for each transformation-purpose of the system. There is rarely a single measure that will indicate success – instead, use compound measures to evaluate complex outcomes – as shown to the right of the conceptual model in Figure 4-2.