8 Soft systems methodology

This module will explore a systems approach to integrating all the different components within the project environment, to create a comprehensive approach to solving the problem.

Background

Broadly speaking, a systems approach is used to create an understanding of the interrelationships between different components within the environment, the project, and the stakeholders. Through a generalisation of the different components, the project team is better able to understand the interdependent nature of the factors (Cleland 1997; Meredith and Mantel 2011; Kerzner 2017). Additionally, the systems approach allows the project team to understand the situation in its entirety, including resources, materials, market conditions, organisational needs, stakeholders and so forth. By understanding these factors, the project is better able to meet the project objectives and keep the end-state in mind throughout, to ensure that the approach is the most efficient and effective process possible.

This is a disciplined way to view the environment and identify potential solutions to problems while being open to opportunities. These opportunities can be realised through understanding that everything is related to everything else in the environment or organisation.

A system is a composition of numerous related and dependent components which, through interactions with one another, create a whole. Therefore, a system is a compilation of distinct factors or components which form a complex whole. Although this definition is general, a key element of a system is how the collection of factors or components come together to produce an outcome (INCOSE 2015). This outcome is not attainable by the individual elements – an outcome can only be created  through the interactions between and across the components and factors.

By applying a systems approach to project management, the view of the project changes from a set of tasks and activities to a combination of sub-systems which work together to make a broader system (Cleland 1997; Meredith and Mantel 2011; Kerzner 2017). The broader system’s effectiveness and performance is impacted by the corresponding performance of the sub-systems of which it is comprised. Therefore, by viewing the project management process as a system which operates as an entity comprised of sub-systems, project managers can identify areas within the project which could lead to success or failure. However, the sub-systems which comprise the project are not limited to internal factors within the organisation – external components or factors play a significant role within the systems approach.

Through a systems approach, a project manager, project team and the broader project organisation are empowered to consider the impacts of the environment when implementing changes or projects. The context surrounding the project should be established at the outset as this will provide a viewpoint of the system. This viewpoint will support decision-making throughout the project, encourage realignment of resources as needed and trigger changes in response to the environment.

Considerations

Before a project manager considers applying a systems approach (Cleland 1997; Meredith and Mantel 2011; Kerzner 2017), there are several components which need to be considered:

• How all tasks, activities, processes, and deliverables within the project depend on one another needs to be documented. However, consideration is needed to understand the properties of the individual components outside of their dependencies.
• Project goals need to be clear; each component of the project should be working towards those goals.
• Resources supporting the project should be consistent throughout. Where additional resources are required, the impacts on the outcome need to be considered. This includes impact on quality, scope, budget, and schedule.
• Uncertainty is expected within a project. Consideration is required to provide support in managing and responding to uncertainty as it arises (for example, risk and issues management processes).
• Resources should be allocated roles and responsibilities based on their skills and experience. These resources can work together as part of a sub-project team, to support the development of different deliverables. For each deliverable, a different approach may be required to manage the needs and complexities.
• Visualisation can be used to support documenting the complexities.

Through a systems approach, project managers are supported to ensure they are aiming for the project’s goals and objectives.

How to apply a systems approach

In addition to using traditional project management methodologies, the systems approach can be used to effectively manage a project. Based on systems theory, there are 4 primary tools and principles which can be applied from the Systems Thinking Iceberg, recreated in Figure 28.

_{Figure 28. Systems Thinking Iceberg, by Carmen Reaiche and Samantha Papavasiliou, licensed under CC BY (Attribution) 4.0}

Based on Figure 28, below are 4 principles and tools which can be applied to projects to support the systems approach to project management (Cleland 1997; Meredith and Mantel 2011; Kerzner 2017).

• Events. This level seeks to understand what is known, and what are the causes, triggers, and side-effects if a problem occurs. Not all projects are created equally, and as a result not every problem can be resolved or understood easily. Therefore, a thorough exploration and analysis is required to delve into the deeper patterns/trends, the underlying structure, and the mental models (Cleland 1997; Meredith and Mantel 2011; Kerzner 2017;). To achieve this, the project team needs to document:
  •  a detailed problem statement
  •  triggers, causes and side-effects
  •  the reactions of the different stakeholders
  •  links between problems and solutions previously attempted.
• Trends and patterns of behaviour. Based on what was outlined in the events analysis, the project team needs to consider which different trends or patterns are associated with the problem (Cleland 1997; Meredith and Mantel 2011; Kerzner 2017). This includes:
  •  when it occurs (frequency)
  •  who has been impacted
  •  steps taken to rectify
  •  interactions between the event and other factors or events
  •  identifying potential causes
  •  testing potential solutions.
• Underlying structure. Determining the current system structure (Cleland 1997; Meredith and Mantel 2011; Kerzner 2017), the project team needs to consider:
  •  environmental elements within the system
  •  causes of the behavioural patterns
  •  stakeholders within the system
  •  underlying interactions between stakeholders, environment, and causes.
• Mental models. This is a consideration of the underlying assumptions, beliefs, expectations, and values within the system structure (Cleland 1997; Meredith and Mantel 2011; Kerzner 2017). This requires the project team to understand:
  •  what supports the underlying structure
  •  the values, expectations, and beliefs within the system and broader environment
  •  how the problem is understood
  •  the proposed solutions and how will they be implemented and analysed.

Systems approaches can be applied through a cyclical method which considers the relationships between each component of a project phase. See Figure 29 for examples.

_{Figure 29.  Examples of the cyclical approach that can be used to support systems approaches to project management, by Carmen Reaiche and Samantha Papavasiliou, licensed under CC BY (Attribution) 4.0}

By applying the systems approach, organisations can understand the interactions between different areas, documents, and tasks and activities. By using a systems approach:

• Project managers are able to realise the need for a holistic approach to prepare, plan, and implement a project.
• The multidimensional components which have an impact on the outcomes of a project (for example, technological, financial, resources, cultural, etc.) can be documented.
• Project managers can understand how different dimensions or structural components will influence the stakeholders and their expectations, and how the market and environment can change swiftly and significantly. This is commonly in response to economic factors, ecological issues, stakeholder values, news cycles and so forth.
• The end-to-end interactions between tasks, activities, resources, stakeholders and so on, are considered and work together to reach the common goals and objectives of the broader system (or the project).

Therefore, when the systems approach is applied to a project, project managers are better able to respond to the conditions outside of their control, and create efficiencies within their projects boundaries to maximise outcomes.

Soft Systems Method

Soft Systems Methodology (SSM) is an approach which is used to create structure in complex problems and develop changes which are both feasible for and wanted by all the stakeholders. These stakeholders include internal stakeholders (employees, developers) and external stakeholders (users, clients, competitors). As a result, everyone provides different insights into and solutions to solve a problem (Checkland and Scholes 1990; Checkland 2000; Checkland and Poulter 2006).

To support the understanding of SSM, a soft system can be defined as a human activity system (HAS). This HAS is purposeful and organised in that groups of people work collectively to achieve a purpose or outcome.

SSM was designed to allow each heterogeneous group of stakeholders the opportunity to provide their insights into the problem. Each group or stakeholder can document the problem in their own way and provide their insights into feasible or desirable outcomes or solutions (Checkland 2000).

Through collaboration, a solution can be created that is agreed upon by all stakeholders. It supports quicker decision-making through consensus. The approach is used to show the links between the real world and the considerations and components documented within the systems world.

The 7 steps to SSM

There are 7 steps to SSM (see Figure 30). These steps are not necessarily carried out in linear order and some steps may not need to be completed. These steps should be used to support collaboration, decision-making and problem-solving.

_{Figure 30. SSM 7 steps, by Carmen Reaiche and Samantha Papavasiliou, licensed under CC BY (Attribution) 4.0}

Step 1. Identify the problem situation  

This step involves gathering relevant information to understand the problem situation. There are several tools which can be used to support information gathering (Checkland and Scholes 1990; Checkland 2000; Checkland and Poulter 2006), including:

•  interviews
•  surveys
•  brainstorming sessions
•  historical and current data
•  news articles
•  document analysis
•  organisational structure
•  control policies
•  observation sessions.

Through the information gathered, analysis should support understanding the possible components and factors which could influence or impact the problem situation.

Let’s go through the rest of the steps using a sample organisation: Lugano. Lugano is a financial firm that offers digital services to clients. This organisation is experiencing decreased overall use of digital services and significant increases in the need for support provided by frontline employees by telephone. It is unclear what is causing this increased need for support. Information is gathered via employee and user feedback, data and document analysis. Lugano will  be used as an example in the following step.

Step 2. Describe the problem situation

From Step 1, the analyst has sufficient information to understand the problem space and document the situation through pictures or diagrams. The tool recommended in SSM is the rich picture diagram (Checkland and Scholes 1990; Checkland 2000; Checkland and Poulter 2006). This diagram outlines the problem situation using a graphical representation of the different relationships, communication mechanisms, processes, structure, people, concerns, conflict, and climate. A rich picture can incorporate images, text, symbols, and icons.

Figure 31 provides an example of part of a rich picture. This example highlights Lugano’s relationships between the digital services provided to users, and the support mechanisms in place to provide guidance when needed. The problem situation Lugano is the increased requirement for support and the decreased use of digital services. The problems highlighted in Lugano’s example include the need for skills development and training for users, accuracy and relevance of information and records provided, and access to services.

_{Figure 31.  Example rich picture from a digital service offering perspective, by Carmen Reaiche and Samantha Papavasiliou, licensed under CC BY (Attribution) 4.0}

Step 3. Develop key definitions

Once the rich picture has been created, the next step is to determine the best way for the system to function. This process starts with creating root definitions which provide an ideal view of the key systems and structures (Checkland and Scholes 1990; Checkland 2000; Checkland and Poulter 2006). This commonly follows the CATWOE elements (Checkland and Scholes 1990; Checkland 2000; Checkland and Poulter 2006). Using the sample organisation:

Customers: Who are Lugano’s clients, and the users, stakeholders, and key players within a system?

Actors: Who are the employees within the organisation who support the transformation process?

Transformation: Which process will be transformed by Lugano, specifically considering what the output is and how the problem will be solved?

Worldview/Weltanschauung: What is the bigger picture or the environmental view of the situation, specifically the stakeholders within the environment who can influence the transformation?

Owners: Who within Lugano can make the changes or has the power to approve the start and end of the project or transformation?

Environmental constraints: What are the elements within the environment which influence Lugano and have the capacity to impact the system negatively, and how should they be managed?

CATWOE supports the creation of the root definition, which is defined as the representation of the problem situation to be addressed. Therefore, a root definition is defined as a statement which concisely and clearly describes the system of interest (or under review). It commonly starts with a single sentence that begins with ‘A system to’ followed by ‘all key elements of the system’.

_{Table 7. A CATWOE example using Lugano}

_{Table 8. A root definition example using Lugano}

Tables 7 and 8 provide an example of CATWOE and creating the root definition for the digital service example. This example shows the key players and the aim of the transformation within the root definition. Through this approach, the problem became clearer, and the system of interest became the digital service and surrounding environment.

When applying SSM its important to understand the transformation component correctly, especially in relation to inputs and outputs (Checkland and Scholes 1990; Checkland 2000; Checkland and Poulter 2006). This is outlined in Figure 32, which shows that Input (I) should support the transformation and lead to the Output (O). A common mistake is incorrectly identifying the system input (the entity change) with the resources required to implement the change.

_{Figure 32. Inputs create transformation which leads to outputs, by Carmen Reaiche and Samantha Papavasiliou, licensed under CC BY (Attribution) 4.0}

Forbes and Checkland (1987) provided some definitions and rules to support the documentation of the transformation:

•  (T) transforms the Input (I) into Outputs (O).
•  The input must be present in the output; however, it will be in a different or changed state.
•  An abstract (intangible) input will create an abstract (intangible) outcome.
•  A tangible (concrete) input will create a tangible (concrete) output.

Step 4: Create conceptual models

This step requires creating a conceptual model which is used to analyse the activities which need to occur to undertake the transformation. The activities outlined should only be based on actions taken by actors (internal to the organisation). These activities need to link back to the root definition and be limited to a project group to control (Wilson 2001). All activities need to achieve the objectives of the transformation, and activities must include monitoring the transformation and providing feedback. It should consider what is meant by success, how it is measured and who will measure it.

The key activities required for the digital services example include:

1. Determine what factors influence digital service use.
2. Assess actions required to improve these.
3. Take action.
4. Measure behavioural change.
5. Measure impact of change on the environment.
6. Report results.
7. Monitor and manage the system performance, recommend improvements.

_{Figure 33. Example draft of the digital services conceptual map, by Carmen Reaiche and Samantha Papavasiliou, licensed under CC BY (Attribution) 4.0}

As outlined in Figure 33, there are clear operational activities which need to be taken to activate the transformation. Each activity should be monitored to ensure it is easy to follow and that there is a clear process in place. The conceptual model outlined in Figure 33 is in draft state – it shows a starting point for developing a complete model.

Within a conceptual model, Forbes and Checkland (1987) recommended:

•  having 7+/-2 activities of the same size
•  describing each activity using a verb
•  using arrows to show logical dependencies
•  numbering activities to reaffirm the dependencies.

Conceptual models are made to document HAS, which are softer models (Tavella and Hjortso 2012). This is because it is difficult for human behaviour to repeat and reproduce the same actions repeatedly with the same results. Therefore, there is an innate variability in the human activities and performances outlined within the conceptual models. These still require monitoring and controlling to support the transformation and ensure that changes are made as required. The overarching structure of a HAS is outlined in Figure 34, and this approach can be used to support improvements to the conceptual model. This calls out the operational system within the organisation’s control (operational subsystem) and the elements which occur outside of the direct control of the organisation, this being the response to the implemented change. These are tracked and monitored and as changes are required, they are implemented.

_{Figure 34. HAS overarching structure, by Carmen Reaiche and Samantha Papavasiliou, licensed under CC BY (Attribution) 4.0}

This monitoring and controlling process should follow the 3Es: effective, efficient, efficacy (Wilson 2001; Checkland 2000). When planning, the transformation needs to consider:

•  Effective: Is the system acting in the way it should be? Does the system contribute to the broader organisational goals?
•  Efficient: Does the system use the least number of resources? Does it use the resources appropriately?
•  Efficacy: Does the system provide the expected results?

Using the 3Es, a project manager is better equipped to determine what level of monitoring and controlling is required and how it could be completed.

Another critical component of a conceptual model is the use of feedback loops (Checkland 2000; Wilson 2001). Within conceptual models, there are commonly two forms:

•  Internal feedback loop. This loop highlights how the actors (or the individual completing the work) need to alter how they work to meet the transformation.
•  External feedback loop. This loop looks at the links between the inputs and the outputs, specifically interested in how the system is performing.

Therefore, an effective project manager needs to clearly define their success measures for the transformation and ensure that they are built into the system.

Step 5. Compare conceptual models to reality

Conceptual models are developed through applying theory; however, they are not necessarily representative of reality. Therefore, Step 5 requires an understanding of how much these models reflect the real world (Checkland 2000; Wilson 2001). This requires an analysis of the gaps, to determine whether the provided solution will meet the needs. This analysis is required to understand:

•  conceptual model activities
•  the real world
•  what can be completed.

Table 9 is an example of the analysis for the digital services transformation, using 3 columns based on the above analysis questions.

_{Table 9. Example conceptual model vs. real world comparison (digital services example)}

Step 6. Assess feasibility and define changes

Based on the results of Step 5, a feasibility assessment is required of the suggested changes (Checkland 2000; Wilson 2001). The changes are normally classified as a change in:

•  organisational structure
•  procedures and processes
•  attitudes or behaviours.

This requires an analysis of 3 primary elements: feasibility, priorities and risk analysis.

Feasibility

Feasibility requires understanding how the different activities will be undertaken. A feasibility analysis will need to consider whether something is achievable (Checkland and Scholes 1990; Checkland 2000; Checkland and Poulter 2006), based on:

•  Cultural feasibility: Will the employees or actors involved be able to complete the work?
• Technical feasibility: What is the required support or modern technology required to implement the change?
•  Dependencies: Are there links between the organisational and technological systems? What order do updates need to go in?
•  Win-Win: Do the recommended changes make it easier for the organisation, employees, and clients?

Priorities

This is a vital component; the changes need to be prioritised based on what impact they will have on the desired transformation, what risks they pose and how difficult they will be to implement. This can follow Kaplan and Norton’s (1993) balanced scorecard approach – an example of factors is outlined in Figure 35.

_{Figure 35. Example of the balanced scorecard for the digital services example, by Carmen Reaiche and Samantha Papavasiliou, licensed under CC BY (Attribution) 4.0}

According to Kaplan and Norton (1993) there are 4 primary elements within the balanced scorecard and successful organisations, projects, and transformation find a balance between each of these components.  Each component provides a different view of the organisation to operate efficiently and effectively. These components are:

• Financial perspective: outlines the different cost measures involved in the organisation, project and or change.
• Client perspective: outlines how client satisfaction, retention and market share will be measured and improved.
• Internal processes perspective: outlines what the change will cost and how it will impact the quality of the internal business processes.
• Innovative perspective: outlines measures of employee satisfaction, knowledge management, improvement rates and number or percentage of employees included in the improvement.

These 4 components or perspectives are interlinked – they do not function in isolation. Using the scorecard approach, the factors within the perspectives need to consider:

•  objectives: organisational objectives and strategies
•  measures: following the objectives, how you will measure progress
•  targets: what is the objective aiming to achieve
•  initiatives: actions taken to meet the objectives.

Risk analysis

The third tool to support feasibility assessment is the completion of a risk assessment. Risk analysis is the process which determines the likelihood and impact of a risk occurring. The assessment considers how the risk will impact the project schedule, quality, budget, and scope. The analysis technique recommended in SSM is the risk analysis matrix.

The risk analysis matrix assesses the likelihood of a risk occurring and the overall severity if it were to occur. These are classified by importance and impact. Likelihood and consequence (impact) are measured as low, medium, high, or very high (Vose 2008), as shown in Figure 36.

_{Figure 36. Example of a risk analysis matrix, by Carmen Reaiche and Samantha Papavasiliou, licensed under CC BY (Attribution) 4.0}

Each risk should be identified, analysed, and considered as part of the feasibility assessment.

To complete the assessment, the project manager should understand the potential feasibility of the changes, the priority of each change and the level of risk associated. This should be used as a guide to help determine which changes should be implemented.

Step 7. Take action to implement proposed changes

The final step is to implement the proposed and agreed upon changes (as outlined in Step 6). The implementation should follow the required steps outlined within the conceptual model (and reality analysis). Once implemented, there is a potential for the system changes to provide new opportunities and problems that require responses. As a result, the process would need to start again.

Advantages of SSM

There are several advantages to applying SSM, including:

• provides a structure for complex problems or situations
• easy to follow steps
• rigorous testing required
• encourages multiple iterations.

Disadvantages of SSM

There are several potential disadvantages to applying SSM, including:

• requires organisational change, which can be difficult to convince stakeholders of
• solutions can be narrowed down too early
• rich pictures are challenging to create, due to their lack of structure
• actions are expected quickly; however, the process can be time consuming.

In sum, SSM provides an analysis tool and technique which outlines the different requirements for the system transformation. This module outlines the 7 primary steps required to implement the methodology. SSM is a systems approach which can be used to undertake problem-solving and analysis of complex situations. Therefore, a cycle of research, learning and reflection is recommended based on the perceptions of all the stakeholders to better provide solutions for the problem space.