skip to primary navigation skip to content

Improving Improvement

A toolkit for Engineering Better Care

 

Important Topics

A number of important topics typically arise in the context of improving of complex systems, regardless of the improvement model used or system perspective taken.

Contents

 

Introduction

The following short sections are intended to describe a range of topics that are important in the successful delivery of system improvement. They are intended to bridge the gap between the broad principles embodied in the sections on Improvement Approaches , Improvement Model and Improvement Stages, and the activities and tools described in the section on Improvement Resources, while remaining relevant to other established improvement approaches.

The topics described here are not intended to be an exhaustive set sufficient for all improvement, rather they represent a starting set that cover the topics that the Toolkit authors have particular knowledge of in practice or have seen the Toolkit users struggle with during training sessions. More topics will be added in time as the users of this toolkit identify further areas of interest for the improvement community.

Planning Meetings

Meetings may take many forms, but all draw people together for a purpose. As a result there is always a need to plan meetings carefully to ensure that they fulfil expectations, whether they are for team building, fact finding, designing or reviewing. Typically, one or more activities define the purpose of the meeting, which then has to be carefully choreographed to ensure that there is:

  • Clarity of purpose and a concise, time-stamped agenda,
  • A shared expectation of what can be achieved in the time available,
  • An appropriate list of attendees to match the purpose and expectations,
  • A suitable location to accommodate the activities planned,
  • Clear guidance for the meeting chair and facilitators,
  • Pre-prepared presentations, posters, prompts and other resources,
  • Appropriate communication to participants before the meeting,
  • Adequate time for reflection and analysis after the meeting.

Experience shows that the best meetings are the result of careful preparation and planning with the team facilitating the improvement programme, key stakeholders and the meeting hosts. Similarly, it is important to spend time to reflect on the meeting when it is fresh in mind and later, when further analysis of the material generated has been completed, in order to:

  • Discuss things that went well or could be improved,
  • Identify people who were not present or should be included in the future,
  • Consider how the meeting contributed to the overall improvement programme,
  • Identity needs for further action or immediate follow-up,
  • Discuss preliminary plans for subsequent meetings,
  • Draft a summary communication to the meeting participants.

Again, experience shows that the best overall outcomes are the result of timely reflection by the team facilitating the improvement programme, key stakeholders and the meeting hosts. Above all else, the role and limitations of meetings should be understood in the context of the wider improvement programme and the activities required to deliver sustainable success.

Characterising Stakeholders

An important activity within any improvement programme is the identification of system users and stakeholders. They have a unique role in understanding and improving systems, and may have interest in, concern about, influence on, permission for or expectations of changes proposed to a system. There is particular value in identifying users and stakeholders in the early stages of a programme and ensuring the team continuously update knowledge of their needs. Personas may be developed to capture important characteristics of representative users or stakeholders.

A Stakeholder Map may be used to group stakeholders. Patients or user stakeholders are often shown at the centre of the map, while other stakeholders may be categorised as internal (within the system of direct interest) or external (outside the system), although these conventions need not be strictly applied. Stakeholders may have multiple needs, interests and influences which can be captured on a Stakeholder Influence grid and Stakeholder Needs table.

The Stakeholder Map is a living document which may be used in electronic form, as a large poster or an interactive worksheet.

Successful improvement involves and depends on a wide range of stakeholders and system users who, at any point in time, will have different levels of interest in and power to influence such improvement. There is value in characterising these stakeholders, in terms of their interest and power, to ensure that they are sufficiently informed, engaged or managed at all stages of an improvement programme. A Stakeholder Influence grid may be used to capture these characteristics.

Stakeholders are also defined by their role, needs and reasons for those needs. It is useful to capture this information in the form “ As a … … I need … … so that … where these statements provide insights into needs and the rationale for them. Stakeholders may have multiple and diverse needs and associated rationales, which provides the basis, with their interest and influence, for early conversations to prioritise these needs. A Stakeholder Needs table may be used to capture these insights.

The Stakeholder Influence grid and Stakeholder Needs table are a living documents which may be used in electronic form, as a large poster or an interactive worksheet.

Useful toolkit resources: the Stakeholder Map worksheet, Stakeholder Influence worksheet and Stakeholder Needs worksheet, a Stakeholder Map poster and Stakeholder cards can be downloaded from the Resources section.

Building Teams

Effective teams work together to accomplish a common improvement goal. The composition of the team depends critically on the context of the challenge, the specific goal(s) and the stage of the improvement process. Teams are naturally dynamic and will vary over time due to changes in programme needs, individual availability and competence requirements. Typical teams will need one or more of each of the following roles1.

Clinical Lead: someone who understands clinical needs and current practice, the clinical implications of proposed changes, and the consequences such a change might trigger in other parts of the system. They will have authority within and across organisations to represent their peers and knowledge of the practicalities of improvement.

Technical Lead: someone who knows the topic of improvement well and understands the processes of care. They may also be an expert on improvement methods and provide technical support in helping the team to plan and deliver the improvement process, supporting data management and co-production of new care solutions.

Project Lead: the driver of the improvement programme, ultimately responsible for the delivery of change in practice. They will understand not only the details of the system, but also the potential effects of making change(s) in the system. They will have leadership experience of improvement and need to be able to work effectively with the team leads.

Systems Lead: someone who understands systems approaches to improvement2 and appreciates the architecture of the care delivery system. They will be expert on improvement methods and provide guidance and mentoring to the team to plan and deliver the improvement process, directly facilitating the co-production of new care solutions.

Project Sponsor: someone with executive authority who can provide liaison with other areas of the organisation, serve as a link to senior management, and provide resources and overcome barriers on behalf of the team. A successful improvement team needs a sponsor who can regularly engage with them, advice on direction and review progress.

An effective team will contain people who fulfill all these roles. In a smaller team, individuals may take on more than one role, while in a larger team more than one person might share one of the roles.

Effective teams work together to accomplish a common improvement goal. While there is much written about successful teams and how to build and maintain them, albeit rather less relating to health and care improvement2, there is no attempt to reproduce all that work here. However, there is value in focusing briefly on the dynamic nature of teams, particularly those that are formed across traditional operational boundaries, and how that can influence their ability to deliver real impact3.

Teams all work in different ways. They differ in size, scale of the challenge, geographic spread, level of individual engagement, and sense of common purpose. However, they all share the characteristic that they take time to reach their full potential, and that this can be disrupted as the team membership evolves and changes over time. This is recognised across many organisations, particularly those that require the building and disbursal of teams on a regular basis, for example, consultancies and improvement agencies. One model of team behaviour identifies and characterises the key stages of team formation and operation as a means to describe the inevitable challenges a team might face4.

Forming: when a new cross-disciplinary team forms, individuals may be unsure of the team’s purpose, how they fit in and whether they will work well with one another. They may be anxious, curious or excited to get going, looking to develop the sense of ‘team’.

Storming: during the subsequent team development stage, people may start to push against the established boundaries, or storm. Conflict or friction can arise as team members reveal their true characters and ways of working, and there may be challenges to the team’s purpose or management.

Norming: in time, the team is likely to move into the norming stage, where people start to resolve their differences, appreciate one another’s strengths, and respect the team leadership. Communication improves and a sense of ‘team’ with a shared purpose emerges.

Performing: finally, a team should reach a sense of flow and will be perform to its full potential, with hard work and structured processes. This team is likely to achieve its goals.

A particular value of this model is that it highlights the storming stage as a normal and expected element of team development. With this knowledge, storming should be expected and even appreciated as a step towards a team that really performs and delivers. In practice, teams may revisit earlier stages as the programme progresses or the team changes.

Footnotes

  1. How to Improve. Institute for Healthcare Improvement, 2023. https://www.ihi.org/resources/Pages/HowtoImprove/default.aspx.
  2. NHS Introduction to Team development. Leadership Academy, 2023. https://www.leadershipacademy.nhs.uk/wp-content/uploads/2013/04/7428f23d7207f39da1eda97adbd7bf34.pdf
  3. NHS Impact. NHS England, 2023. https://www.england.nhs.uk/nhsimpact/
  4. Developmental Sequence in Small Groups. Tuckerman, 1965. Psychol. Bull. 63(6), 384-399.

Co-producing Improvement

People and communities are at the heart of everything a health and care system should strive to do. Hence, working with people and communities to create the health and care service is critical to offer personalised care that is tailored to the needs of each individual and which works for everyone1.

Integrated care systems provide an opportunity for providers to collaborate on working with communities, both within primary, secondary and tertiary care, and with other partners (e.g., local authorities, social care providers and voluntary, community and social enterprise organisations) that already have links to and knowledge of communities.

Working with people across places (specific localities) enables services to be tailored to meet their needs and preferences, so that they are designed and delivered more effectively. This ensures that locations, opening times, models of care and patient information are suitable for the communities they serve.

Local involvement helps to prioritise resources to have the greatest impact, leading to better decisions about changing services, and information from involvement activities can be used alongside financial or clinical information to ensure that services are delivered in a way that works for patients and their carers within a particular area.

Real change, or impact, is most likely to be the result of evidence-based improvement methods, underpinned by a systematic approach to continuous improvement, that strive to:

  • Build a shared purpose and vision,
  • Invest in people and culture,
  • Develop leadership behaviours,
  • Build improvement capability and capacity,
  • Embed improvement into management systems and processes.

When these components are consistently used, systems and organisations create the right conditions for continuous improvement and high performance, responding to complex challenges, and delivering better care for patients and better outcomes for communities2.

Ten principles for working with people and communities are1:

  1. Centre decision-making and governance around their voices,
  2. Involve them at every stage and feed back about how it has influenced activities and decisions,
  3. Understand their needs, experiences, ideas and aspirations for health and care,
  4. Build relationships based on trust, especially with marginalised groups,
  5. Work with the voluntary, community and social enterprise sector,
  6. Provide clear and accessible public information,
  7. Use community-centred approaches that empower, making connections what already work,
  8. Have a range of ways for people and communities to take part in health and care services,
  9. Tackle system priorities and service reconfiguration in partnership with people and communities,
  10. Learn from what works and build on networks, relationships and activity in local places.

There are many different approaches which can be used at different stages of a project to embed these principles in practice and build a more detailed picture of what matters to people and what improvements can be made. These include mechanisms to inform, consult, engage, co-design and co-produce3:

Inform: Sharing information about proposed changes so people understand what they mean (e.g., letters, emails or social media, and information on notice boards in local community facilities),

Consult: Asking for people’s opinions on one or more ideas or options (e.g., formal public consultation to gather views, including webinars, public meetings and surveys),

Engage: Listening to people to understand issues and discuss ideas for change (e.g., focus groups or interviews, citizens’ panels, patient and public engagement in decision-making, and advisory groups),

Co-design: Designing with people and incorporating their ideas into the final approach (e.g., service redevelopment tools such as Experience Based Co-Design),

Co-produce: An equal partnership where people with lived and learnt experience work together from start to finish (e.g., asset mapping, appreciative inquiry and community conversations).

Footnotes

  1. Working in partnership with people and communities: Statutory guidance. NHS England, 2022. https://www.england.nhs.uk/long-read/working-in-partnership-with-people-and-communities-statutory-guidance/#a1-different-ways-of-working-with-people-and-communities
  2. NHS Impact. NHS England, 2023. https://www.england.nhs.uk/nhsimpact/
  3. Co-Producing and Co-Designing. Robert, Locock, Williams, Donetto and Goodrich, THIS Institute, 2023. https://www.cambridge.org/core/elements/coproducing-and-codesigning/157832BBAE1448211365D396CD110900

Mapping Systems

An effective systems approach to improvement relies on the communication of information to describe and interpret the current system, and any proposed changes to it, from a variety of different perspectives. There are a plethora of formal and informal diagramming and mapping approaches available to assist these activities, where each approach is likely to accentuate some features of the system it is used to describe and to ignore many others. It is therefore important to select the diagramming or mapping approach(s) best suited to the information that is to be captured and shared.

Diagrams highlighting the structure of systems can be particularly useful in conveying an understanding of how things are connected, where the nature of the connection may be represented as a simple link or a directional or causal relationship. Similarly diagrams examining the behaviour of a system provide a richer picture of the nature and performance of people, processes and information flows in the system, and may range from static representations to dynamic simulation models.

In all cases, diagrams and mapping are typically limited to representing certain perspectives of a system and seldom capture everything. Multiple maps and diagrams may be required and a mix of formal and informal approaches may also be appropriate. For example, storytelling can provide a rich narrative when formal interview approaches or focus groups would be difficult to convene. In all cases, the process of building the pictures with the right team can provide significant benefit in itself, enabling a consensus view of the system to emerge.

A rich picture of the patient journey can be very helpful in identifying the key steps of such a journey, particularly in terms of their location, the patient’s condition at that point in time, and the people and treatment involved. A Design Wall is a graphical device that can assist in the capture of such a picture and its visualisation by the improvement team. The design wall is readily extensible to suit the length of the journey and can be drafted by an individual or, more usefully, the whole improvement team.

The Design Wall includes reference to the following key elements:

  • Step: describe the particular step in the patient journey
  • Summary: summarise the overall experience of the delivery of care associated with this step
  • Place: describe the location(s) where this step happens
  • Stakeholders: describe the stakeholders involved in this step
  • Diagnosis: describe the primary diagnosis that the patient is likely to have at this step
  • Function: describe the patient’s current level of functioning at this step
  • Symptoms: describe the patient’s symptoms at this step
  • Changes: identify causes of changes to the diagnosis/function/symptoms and if they are reversible
  • Prognosis: describe the quality-adjusted life-years that might be achieved if changes were reversed
  • Wishes: describe how the patient wishes to be cared for at this step
  • Plan: describe the current management plan for the patient’s future care
  • Information: describe where the patient’s information is recorded and/or how it is communicated
  • Resources: describe the NHS and other resources being used at this step
  • Social: describe the extent to which the patient’s social network is able to provide appropriate care

The design wall is a living document which may be used in electronic form or as a worksheet.

Useful toolkit resources: the Data-flow Diagram worksheet, Influence Map worksheet, Rich Picture worksheet and Design Wall worksheet can be downloaded from the Resources section.

Defining Requirements

The delivery of an effective improvement process requires careful management of the translation of the aim of the improvement into realisable system requirements. This is often a complex, iterative process in its own right, but one that is critical to success.

Every improvement should have a clear aim. This will not only align with the existing or proposed purpose of the system, but also with the desired improvement in quality to be delivered by the system. The aim may include a number of facets, relating to clinical and cost effectiveness, patient safety and patient experience, that align with the broad definition of quality commonly used in health and care. The aim will also be bound to the expectations of the service commissioner and relevant external targets.

The different stakeholders involved in the system and the improvement programme will inevitably have different needs, aligned with their interests and responsibilities. Any successful system will likely satisfy some of these potentially conflicting needs more than others. It is the job of the service manager or improvement programme manager to capture, assess and ultimately rationalise and resolve conflicts, thus defining a set of prioritised needs in response to the expectations embodied in the aim.

The prioritised needs can usefully be organised into a number of agreed themes that represent the essence of the things the system must do. These provide a practical reminder of what the system should deliver as a result of the improvement programme and how this might be measured. These themes are also likely to form the basis of the case for change, providing more detail on how the aim is to be achieved.

Finally, the agreed themes are translated into individual system requirements that provide detailed, realisable performance targets for the improvement team. These can usefully be expressed as either demands, i.e. things it is imperative to satisfy, or wishes, i.e. things it would be desirable to satisfy.

As with the improvement questions, the principles of the requirements pyramid can be applied to simple systems as well as more complex systems of systems. As the complexity of a system increases it is important to consider the design of the architecture of the system as a whole as well as the detailed design of the corresponding elements or sub-systems. The aim, needs, themes and requirements may then apply at all levels of abstraction of the system and should be consistent with those for the parent system and other adjacent or lower-level sub-systems. Any improvement will then need to satisfy the requirements at all levels.

The system architecture, as part of the whole system requirements, will not only need to describe the system decomposition into key sub-systems and their associated aims, but also carefully specify the nature of the interfaces between these sub-systems. As the sub-systems emerge they will need to be evaluated against their individual requirements, before their integration into a single system and evaluation against the whole system requirements. In practice, interface management remains an essential and critical part of any system development.

The system stakeholders are also likely to vary according to the system or sub-system under consideration. As a result, it is imperative that the decomposition and subsequent integration of the requirements pyramids reflects this map of stakeholders, particularly in the derivation of the system architecture with its associated aim, needs, themes and requirements.

Useful toolkit resources: the Design Requirements worksheet are included in the Resources section.

Designing Personas

Designing systems to meet agreed, prioritised stakeholders needs, particularly those of the system users, is an essential element of any successful system delivery process. This requires good knowledge of these needs and of the characteristics and capabilities of the stakeholders and users. There are numerous ways in which this can be achieved, ranging from direct engagement with people through to the use of appropriate descriptive data. Whilst there is no real substitute to working with people, the use of personas, or characterised descriptions of people, can provide useful support throughout the system design process.

Personas are fictional characters which are created, based on appropriate research, to represent the full range of different user types that might use a service, product, site or brand. Personas can help a team to understand stakeholders’ and users’ needs, experiences, behaviours and goals. The process required to create them can also help the team to recognise that different people have different needs and expectations, and help them to better identify with the stakeholders and users.

Stakeholder personas are useful to characterise the needs of specific stakeholder groups and may be used to accentuate the interests and influence such stakeholders have in the system to be designed or improved. They are a reminder of the full range of stakeholders and their likely diversity of needs. More than one persona may be required to represent each stakeholder group.

A number of user stakeholders may be essential to characterise the full range of system users, capturing variations in their situations, characteristics and capabilities. They often accentuate specific differences and can be designed as a set to represent the whole population of interest.

Personas relating to stakeholders may be based on the outcome of a full stakeholder analysis, describing key stakeholders with priority needs and/or particular influence on the improvement process. They serve as a reminder of the key people to be directly involved or engaged in the improvement process and are more likely to represent a qualitative sampling of the whole population of stakeholders. They should be designed to accentuate the characteristics of each stakeholder group within a credible and recognisable description of an individual, and should be identified by name and by role.

Personas relating to users should be based on the outcome of a user population analysis, describing the key dimensions of variation across the population that are significant to the improvement challenge. They may be selected qualitatively, to represent a range of notable characteristics, or quantitatively, to represent clusters of users that together constitute the whole population. In both cases, the set of personas is intended to facilitate proper consideration of the wider population of interest and will likely contain a range of average and boundary users.

The set of personas should ideally represent the full range of different user types and their needs, experiences, behaviours and goals pertinent to the system of interest. They should represent the socioeconomic status, race, ethnicity, language, disabilities and gender diversity expected in any population, as well as diversity in factors specific to the improvement challenge. For example, a set of personas designed to address digital exclusion might also seek to represent diversity in competence with technology, use of technology and attitudes to technology1; whilst that to address future domestic heating sustainability might seek to represent diversity in home situation, economic capability and attitudes to change2.

Useful toolkit resources: the Service User cards, Service Stakeholder cards and Service Improvers cards are included in the Resources section.

Footnotes

  1. Digital Personas, Inclusive Design Toolkit, University of Cambridge, https:/www.inclusivedesigntoolkit.com/digitalpersonas/
  2. Domestic energy consumer archetypes: segmentation profiles, Bridgement T and Snodin H, http://dx.doi.org/10.7488/era/741

Creating Concepts

While there is always the temptation to take the first thing that is thought of and develop a solution based on that ‘idea’, creativity should be an exploratory process that initially generates a large number of ideas, which are then gradually filtered, refined and coalesced, to deliver the ‘best’ solution. A thorough exploration of the solution space inevitably challenges assumptions regarding the problem to be solved, and this is true of both improvement and new service design challenges. Once the process of exploration and refinement has been completed, it is extremely unlikely that the idea initially thought of as the ‘best’ remains through to completion.

There are many creativity approaches and tools that inspire individuals or teams to come up with ideas. Most of these separate the initial creativity method from the inevitable filtering required to find ideas worth developing, and some focus particularly on avoiding fixation in order to maximise the search space. In all cases, the quality of the ideas created will depend critically on the understanding of the problem and the context within which it is set. This in turn allows the definition of a clear set of requirements and key themes for the improvement and new service design challenge. This is an iterative process that encourages the ongoing exploration of the problem alongside the exploration of the solution1, while accepting that the emphasis inevitably moves from the former to the latter over time.

Creativity may be the preserve of a few individuals or the whole project team. Yet, regardless of the origin of ideas, solutions typically endeavour to satisfy a range of prioritised stakeholder needs articulated through the problem statement and system requirements. Throughout the improvement or design process, evaluation of ideas, concepts and emerging solutions should be made against these needs and requirements in order to provide a transparent rationale for the filtering and selection decisions made. The formality of such a process can depend on the scale and complexity of the problem to be solved and the importance of evidencing the development of the solution. A simple meeting note recording key decisions may be sufficient for small, low-risk improvements, where a more formal considered process is required for complex challenges.

The House of Quality2 is a well-known process from product development that provides a framework for relating needs to possible solutions is such a way as to make the rational for selection decisions transparent. It enables the early evaluation of ideas before too much is invested in the development of deliverable solutions.

Useful toolkit resources: the Design Ideas worksheet, Design Solutions worksheet and Morphological Chart worksheet are included in the Resources section.

Footnotes

  1. Eleven lessons managing design in eleven global companies. Design Council, London, UK, 2007.
  2. The House of Quality. Hauser and Clausing, Harvard Business Review, 66(3): 63-73, 1988.

Using Prototypes

A prototype is a draft version of a product that allows exploration of ideas and shows the intention behind a feature or the overall design concept to users before investing time and money into development. A prototype can be anything from paper drawings (low-fidelity) to something that allows click-through of a number of features of a fully functioning service or technology (high-fidelity).

It is much cheaper to change a new service early in its development process than to make changes after deployment on site. Hence, it is worth considering building prototypes early in the improvement process to gather feedback from users while the solution (and problem) are less developed and more fluid.

Prototypes can take many forms, from a simple narrative account of a proposed new service to a physical mimic of a new technology or user environment. Patients and service providers can ‘act’ out new service pathways, highlighting particular needs and challenges alongside proposed changes in care1. The use of role play and personas can reveal as much about the problem as the proposed solution, and can be used to explore what would ‘delight’ and ‘disgust’ the users.

The developers of medical technology or the architects of a new ward may wish to mimic aspects of new solutions to investigate the appropriate positioning of features on an interface or elements of furniture and walls on a ward. Both may be done with low or high fidelity prototypes to test early or mature solutions2. Low fidelity will typically encourage exploration and reconfiguration, while high fidelity will encourage users to evaluate near final designs.

Prototypes may be used to mimic functions and concepts, features and forms, or the production and deployment of solutions. In all cases, the reason for the prototype should be clear, as well as the fidelity required in its design and the expectations of feedback in its evaluation.

Prototyping is an iterative, multi-stage process designed to understand the full range of user needs and challenges, and translate this through the generation of multiple ideas into viable solutions3,2:

Observation: understand the people you are designing for — identify patterns of behaviour, pain points and places where users have a difficult time doing something, and put the team in their situation so they can see what their experience is, and feel what they feel.

Ideation: brainstorm ideas with the team based on what was learned from the observations and experiences — come up with as many ideas as possible while remaining focused on the needs and desires of the people you are designing for.

Prototyping: build simple prototype(s) of the best ideas, choosing the fidelity that maximises communication of the idea while gaining user feedback as quickly as possible — the purpose is to make sure the solution is viable, rather that to create the perfect solution.

Feedback: deliver the prototype(s) into the hands of the people the team are designing for — this is a crucial stage of the design process, where input from the users helps the team to know if their solution is on track and provides direction to improve the design.

Iteration: use the information from the users to direct changes to improve the design — keep iterating, testing and integrating user feedback until the team have fine-tuned their solution and are ready to move on to the next and final stage.

Implementation: if the design is complete, get the solution(s) out into the real world — or go back to the observation stage and repeat the process until the solution(s) are fit for their intended purpose.

Footnotes

  1. FolksLab Toolkit, The people’s laboratory. NHS England, 2018. https://www.england.nhs.uk/sustainableimprovement/folkslab-toolkit/.
  2. Delft Design Guide. van Boeijen, Daalhuizen and Zijlstra, BIS Publishers, 2020. https://www.bispublishers.com/delft-design-guide-revised.html
  3. The Field Guide to Human-Centered Design. IDEO.org, 2015. https://www.designkhttps://www.designkit.org/resources/1.

Managing Risk

The management of risk is an important part of any successful improvement programme, where any likely reduction in expected quality may be seen as a risk to the delivery of the improvement itself, in addition to the risk of operational failure of the actual programme. There is a risk that any of a number of programme requirements and stakeholder expectations will not be met, corresponding to deviations in performance related to patient safety, patient experience, clinical and cost effectiveness, or the improvement process.

In this context, risk assessment is a key component of risk management which may be thought of as the process of identifying, assessing and controlling opportunities for and threats against the performance of an organisation, product or service delivery system, where such performance may relate to a range of quality, safety, operational, financial or reputational measures. Such assessment is a component of existing models of healthcare improvement, such as the IHI Model for Improvement, Lean Thinking and Six Sigma, and also has a long history of development in engineering and service delivery. The Royal Academy of Engineering report, Engineering Better Care1 highlighted risk as one of four key perspectives, alongside people, systems and design, necessary to deliver effective care.

Risk assessment, as a process to reduce the impact of threats against a system, involves a number of key elements which are usefully described by ISO/IEC 31010:2019, Risk management — Risk assessment techniques2. This standard describes a framework for risk management and introduces tools typically used in risk assessment.

In practice, risk management is a continuous process that begins at the inception of any improvement programme and can continue long after delivery. It may also be the trigger for improvement following an incident or routine safety review. The key to the success of the process is the availability of a clear and agreed description of the current system, and/or some future system, which can be systematically and rigourously assessed by a method attuned to the nature of that description. Such prospective risk assessment complements the more typical retrospective assessment and forms the heart of the ‘Safety-I’ approach to system safety management3.

The identification and exploitation of opportunities to learn from normal performance (including adaptations) represents the alternative face of risk management. This view, known as ‘Safety-II’, has gained much traction in recent years as an activity that complements traditional ‘Safety-I’ methods by focusing on the system’s ability to succeed under varying conditions1. In practice, both approaches should be used to encourage an holistic approach to reactive and proactive risk management. This requires a paradigm shift in the traditional priorities of safety management, expanding the focus beyond the need for incident investigations to active investigations into the variations in practice that might be exploited to consistently achieve good practice. The outcome curve for health and care practice needs to shift to the right.

Cultural and organisational change and adoption of knowledge of human factors, the discipline concerned with the understanding of interactions among humans and other elements of a system, are parts of the answer. They will facilitate a shift from a traditional Safety-I to a combined Safety-I and Safety-II approach, which aligns with the Assess and Seek questions described in the Engineering Better Care section.

Useful toolkit resources: the Risk Issues worksheet, Bowtie Method worksheet, Failure Modes and Effects Analysis worksheet and Structured What If Technique worksheet are included in the Resources section.

Footnotes

  1. Engineering Better Care, a systems approach to health and care design and continuous improvement. Royal Academy of Engineering, London, UK, 2017.
  2. ISO/IEC 31010:2019, Risk management — Risk assessment techniques. International Organization for Standardization, 2019.
  3. From Safety-I to Safety-II: A White Paper. Hollnagel, Wears and Braithwaite, The Resilient Health Care Net, 2015. resilienthealthcare.net/onewebmedia/WhitePaperFinal.pdf.

Delivering Resilience

The term resilience is derived from the latin resilio which means “to leap, to rebound, to recoil”. Over the years, its use has become radically divergent and has developed into a plurality of disciplines, notions and associated concepts. Nonetheless, resilience can generally be associated with a capacity or ability enabling a system to cope with uncertain conditions that can materialise into change or shock1.

From an engineering perspective, resilience is seen as the ability of a system to return or to bounce back to a previous or normal condition or state of functioning in the aftermath of an event. This view stresses concepts such as stability, reliability, and equilibrium: the more impervious the system was to changes over time in the face of external pressure or shocks, the more resilient it could be considered.

From an ecological perspective, resilience is recognised by more than one possible stable state (or regime) for a system. Rather than bouncing backward, the system is bouncing forward once external pressures have pushed the system to a certain threshold. Therefore the bigger the shock required to change a system’s structure and function, the more resilient that system would be deemed to be.

From an evolutionary perspective, resilience stresses the ability to address disturbance and change without compromising the system’s function, structure, and feedbacks. Complex systems are subject to multiple, often simultaneous, internal and external pressures for change and are constantly evolving and reconfiguring where there is no equilibrium for the system to go back or forward to.

Resilience in health and care systems borrows attributes from all these definitions and may be viewed as the process by which these systems can face change and shocks in such a way that they evolve and innovate to drive and maintain agreed outcomes. Key properties of flexibility, agility, robustness and adaptability facilitate the delivery of resilience2.

The delivery of resilient health and care systems may be viewed as a process driven by four questions:

Resilience for what? — refers to the purpose of the system and its ability to survive and to recover;

Resilience of what? — identifies the elements and actors which define the system that is to act resiliently;

Resilience to what? — addresses the uncertainties, changes and shocks the system is likely to face; and

Resilience through what? — defines the resources or activities by which resilience is delivered.

The first two questions identify the system, its boundaries and expected performance, while the final two focus on the potential disruption to the system and the means proposed to mitigate such disruption. Resilience may be delivered through a combination of robust, adaptable, flexible and agile elements, where the choice of solution will be influenced by the ability to forecast future disruptions and the relative cost of specific solutions3.

The continued delivery of resilience for a system is dependent on an iterative process of: (I) anticipating the need for resilience; (II) accommodating change through robustness and adaptability; (III) responding to change with flexibility and agility; (IV) learning from the experience; and (V) transforming the system to maintain future resilience. Within a changing operating environment, resilience becomes a proactive and strategic process, balancing future expectations and needs with the pragmatic cost of delivery.

Resilience as a concept may also be applied to the delivery of a common service from a variety of sources. In this case, robustness refers to elements where the approach to delivery must be the same, adaptability to elements where the approach may be adjusted to suit local variation, and flexibility and agility to elements where the approach can be changed easily and rapidly. This combines appropriate standardisation with local adaptation for critical services.

Useful toolkit resources: the Resilient Systems worksheet and Resilient Operation worksheet are included in the Resources section.

Footnotes

  1. On the Resilience of Sociotechnical Systems. Taysom and Crilly, 2018. Systemic Design 8. Springer. https://doi.org/10.1007/978-4-431-55639-8_6
  2. Design for changeability (DfC): Principles to enable changes in systems throughout their entire lifecycle. Fricke and Schulz, 2005. Syst. Eng. 8. https://doi.org/10.1002/sys.20039
  3. Comparison of ilities for protection against uncertainty in system design. Chalupnik, Wynn and Clarkson, 2013. J Eng. Des. 24(12). https://doi.org/10.1080/09544828.2013.851783

Developing Competence

Effective systems change is both systemic, thinking about the whole system, its context and stakeholders, and systematic, following a structured approach to understanding the core challenge and realisation of an improved system. Hence, the delivery of effective systems change requires a combination of expertise, including appropriate knowledge of the system(s) to be changed and competence in the process of change. However, knowledge of the system(s) is typically more common than knowledge of the process and while it is important to develop the means to improve and maintain knowledge in both areas, there is a particular need to develop competence in the process of change. Yet, not all people need equal levels of process competence, as illustrated by the stages of learning.

Systems Awareness comes from an introduction to the elements of a systems approach to health and care design and continuous improvement, encouraged by reference to a series of questions relating to people, systems, design, risk and management perspectives on a systems approach. This cycle of questions promotes systems thinking and enables the first steps towards systems practice.

Systems Knowledge comes from learning how the elements of a systems approach to health and care design and continuous improvement can be applied to real challenges, facilitated by reference to a set of improvement activities and associated tools. These situate the original questions, relating to people, systems, design, risk and management perspectives, within an iterative improvement process.

Systems Practice comes from the experience of applying the elements of a systems approach to health and care design and continuous improvement to a variety of real challenges. The use of problem seeking and problem solving approaches, founded on the original questions, supports all the stages of the improvement process, with particular focus on the development of a practical improvement plan.

Systems Leadership comes from knowledge and practice-based mastery of all the elements of a systems approach to health and care design and continuous improvement1,2. The combination of extensive practical experience of systems improvement, knowledge of systems improvement approaches and successful leadership of imrovement programmes is a mark of systems leadership.

An organisation’s competence to deliver effective systems change depends on individuals with competence in systems leadership and practice, along with the majority who ideally have a degree of systems knowledge or awareness. The precise description of the level of individual competence needed to achieve each of these stages should be defined within the organisational context. The training, mentoring, coaching and practice experience processes required to reach each stage can then be determined, along with the measures to be used to see that they are reached. A process to identify those who would benefit from such an approach and to manage their learning trajectories will increase systems leadership and organisational competence in delivering change.

The International Council on Systems Engineering (https://www.incose.org/) describes systems leaders (systems engineers) as being at the heart of creating successful new systems. They are responsible for the system concept, architecture, and design. They analyse and manage complexity and risk. They decide how to measure whether the deployed system actually works as intended. This aligns with the description of a systems leader as someone who understands the perspectives of people, systems, risk and design described in Engineering Better Care, and their application in practice.

Systems leadership is also described as the art and science of balancing organisational, cost and technical interactions in complex systems3. It is related to the description of a chief engineer, who, at any stage of a project cycle, works with and between their team(s) and the other teams at equal, lower, and higher system levels to ensure a smooth technical program, with no surprises or adverse consequences4. It can also be thought of as a set of skills and capacities that any individual or organisation can use to catalyse, enable and support the process of systems-level change, combining collaborative leadership, coalition-building and systems insight to mobilise innovation and action across a large, decentralised network5.

Useful toolkit resources: the Systems Leadership worksheet is included in the Resources section.

Footnotes

  1. System leadership. Fillingham and Weir, The King’s Fund, 2014. https://www.kingsfund.org.uk/publications/ system-leadership.
  2. The practice of system leadership. Timmins, The King’s Fund, 2015. https://www.kingsfund.org.uk/publications/ practice-system-leadership.
  3. NASA Systems Engineering Handbook. NASA SP-2016-6105 Rev2, 2007. https://nasa.gov/sites/default/files/atoms/files/ nasa_systems_engineering_handbook_0.pdf.
  4. INCOSE Systems Engineering Handbook. INCOSE-TP-2003-016-02, Version 2a, 2004.
  5. Systems leadership for sustainable development. Dreier L, Nabarro D and Nelson J, Harvard Kennedy School, 2019. https://www.hks.harvard.edu/sites/default/files/centers/mrcbg/ files/Systems%20Leadership.pdf.

Changing Culture

The crisis in health and social care, alongside political pressure on waiting times, has spawned a scramble for new ideas and innovations that can help save the system. However, there is no escaping the fact that turning things around will require a sustained period of investment and action to increase staffing at all levels. While there are no quick fixes, there are things that could be done to make a difference. Although technical innovation is important, there is much to be gained by making better use of existing technology or improving processes to speed up hospital discharge and improve patient flow. However, such changes are difficult when resources are limited and the nuances of local challenges require local, or adapted, solutions1.

A particular challenge is that with staff and services stretched to the limit, many organisations are struggling to put these kinds of changes in place and achieve the impact needed. A change of thinking is required, both at the individual and organisational level. Much has been written about cultural change and while there is much divergence in thinking in the literature2, there are practical guides that provide pointers towards the development of cultures that are likely to me more conducive to innovation3.

Culture change is complex and success is determined by the quality of leadership, as well as by the efforts of the wider workforce. Much of the guidance available, although structured differently, broadly fits into categories of risk taking, resources, knowledge, goals, rewards, tools and relationships. These provide a simple framework for guidance on the application of principles that contribute to the delivery of culture change in the context of innovation and improvement.

Risk taking is about establishing an organisational climate where people feel able to try out new ideas. A healthy organisational culture requires leaders who show they are quick to provide emotional support to those willing to try something new and have a mature approach to learning from failure.

Resources signal that an organisation is taking innovation and improvement seriously. The provision of time at all levels in an organisation or system is particularly important, as is the ‘resource’ of authority and autonomy to act on innovative ideas.

Knowledge is the fuel for innovation and when information, both from within and outside the organisation or system, is widely gathered, easily accessible and rapidly transmitted, good innovation and improvement will follow.

Goals should signal that innovation is desirable in specific areas and challenge others to find ways to realise the vision. Linking these to strategic priorities and being able to articulate a clear, multifaceted case of need, further signals the importance of the call for innovation and improvement.

Rewards recognise innovative behaviour and should appeal to people’s intrinsic and individualised motivation. They signal how much value is given to the efforts of individuals and teams who come up with new ways to help an organisation or system achieve its strategic goals.

Tools used in the context of an established innovation or improvement process encourage risk taking in the creative exploration and co-design of novel solutions to old challenges, and support rigorous approaches to delivery and evaluation.

Relationships between people in an organisation or system, where there is a wide range of backgrounds and points of view, provide rich soil for the growth of innovation. A sense of common purpose within a trusted ‘team’ will further enhance the potential for effective change.

Footnotes

  1. Innovation is being squeezed out of the NHS. Gerhold and Horton, The Health Foundation, 2023. https://www.health.org.uk/news-and-comment/blogs/innovation-is-being-squeezed-out-of-the-nhs
  2. Making Culture Change Happen. Mannion, THIS Institute, 2023. https://www.cambridge.org/core/elements/making-culture-change-happen/AB1E89CABE939DAB47C641BFDE56F150
  3. Creating the Culture for Innovation, a Practical Guide for Leaders. Maher, Plsek, Price and Mugglestone, NHS Institute for Innovation and Improvement, 2010. https://www.england.nhs.uk/improvement-hub/wp-content/uploads/sites/44/2017/11/Creating-the-Culture-for-Innovation-Practical-Guide-for-Leaders.pdf

Feedback

We would welcome your feedback on this page:

Your name:


Your email:


Your comments:


Please leave this field blank (it's a spam trap):
Submit feedback

Privacy policy. If your feedback comments warrant follow-up communication, we will send you an email using the details you have provided. Feedback comments are anonymized and then stored on our file server

Read more about how we use your personal data. Any e-mails that are sent or received are stored on our mail server for up to 24 months.