The following is a case study demonstrating the use of Stafford Beer’s Systems Thinking model, the Viable Systems Model (VSM) which is being used to think strategically about a problem situation where Shadow IT is increasing in a medium sized organisation. The rise of Shadow IT is becoming a risk to the stability of the organisation and has the potential to create a death spiral dynamic if there are sudden unexpected changes in the organisations external environment (like legislative changes or data breaches).

The VSM is a method that can be used to model the principles or axioms that make a system viable, that is, an adaptive system (in this case an organisation) that can survive changes in its environment over time. It can be used in normative diagnostic sense to plan a strategic intervention, as demonstrated in this case study, or it can be used to design a viable system from scratch.

This is a part of a series of my blogs on how Systems Thinking tools and methods can be used in a transdisciplinary way within an area of practice. The VSM is of of interest in the context of DevOps and IT Service Management  as it can be used as a tool to model problem situations throughout this area of practice and is useful for thinking strategically about design or intervention by doing viable sense checks.

In order to properly understand the VSM, the reader will need to be familiar with the VSM’s 5 recursive systems. Here is some brief background reading as a primer to someone unfamiliar with the VSM. Further reading on VSM may be necessary to properly understand the case study.

Context

A System of Interest  is modelled in (Fig 1) as a VSM diagram showing the current layout of an operational system, the purpose of which is to create value for customers by creating new products. The meta-system is called  ‘Programme Delivery’ and it exists to create products that accommodate the variety of requirements that the organisation’s external customers have.

The Problem Situation

The problem situation contextualized by the Situation of Interest, ‘Shadow IT’ exists within this system. The internal ‘Engineering Projects’ teams require enabling IT tools and services in order for them to perform on the key value proposition, creating products for the customer. Where enabling tools and services are not available from the official channel, the internal ‘IT Enablement’ department, the product teams obtain them from service providers outside the organization.

There is a lack of visibility by ‘Engineering Projects’ management as to how severe the problem of ‘Shadow IT’ is.

The extent of the problem is not being quantified by the management.

There is poor coordination between ‘Engineering Projects’ and ‘IT Enablement’. The current interconnection goes directly via Programme Management and is ineffective. ‘IT Enablement’ does not have sight of an accurate and up to date pipeline of enabling tools and services that ‘Engineering Projects’ needs to create its products.

Due to the poor coordination and lack of visibility of the requirements, the management of ‘IT Enablement’ do not know what level of budget and resources they need to meet the needs of ‘Engineering Projects’, nor can they know how their management performance will be evaluated.

The proliferation of ‘Shadow IT’ has the consequence of there being a lack of control over the organization’s expenditure as well as the risk of sensitive business data ending up in the wrong hands.

If the autonomy of being able to use ‘Shadow IT’ is not reduced and continues unabated then the system may enter a ‘Death Spiral’  if environment changes occur rapidly.

For example, if data security legislation changes and the organisation has to immediately remediate, it may not have sufficient resources create the variety products that its customers are asking for and the customers may abandon it for more successful competition. Or if there is a data breach the organization may have reputational damage and penalties that may put it at risk of a death spiral dynamic.

Furthermore the proliferation of ‘Shadow IT’ is incrementally increasing the complexity involved in managing the organisation.

 

The Strategic Intervention

The following table of interventions is suggested based on a normative diagnostic approach illustrated using the VSM (Fig 2)

System of Interest	VSM System   Level	Suggested change and motivation
Engineering Projects	S4 Intelligence	Scan the ‘Product Team’ subsystems to understand what their emerging enabling tool and platform needs are and communicate via the coordination of S2 in ‘Programme Delivery’ management.
Programme Delivery	S2 Coordination	Add a new subsystem ‘Enablement Portfolio Management’ that manages via a project management subsystem the emerging enabling tool and platform needs of the ‘Engineering Projects’ product teams. The project team management will work with ‘IT Enablement management’ to feed the pipeline of requirements to its delivery subsystems, ‘Tool supplier team’ and ‘Platform service supplier team’.
IT Enablement	S3 Delivery	Based on the pipeline of needs being managed by ‘Enablement Portfolio Management’, the management of ‘IT Enablement’ can request a budget from ‘Programme Management’ and operate to an agreed resource bargain with performance measurement KPIs.
Programme Delivery	S3* Monitoring	‘Programme Delivery’ can skip a level of management to monitor the product team subsystems within ‘Engineering Projects’ to see whether the use of ‘Shadow IT’ is decreasing.
Programme Delivery	S4 Intelligence	‘Programme Delivery’ must scan the external environment and take action to attenuate the variety of customer requirements to slow down the demand placed on product development so that ‘IT enablement’ can play catch up to create the variety of enablers required on the existing in-flight ‘Engineering Projects’ to reduce ‘Shadow IT’.

Patrick Hyland