INTRODUCTION

There are many tools and techniques available for the business analyst to use and, because of the nature of business analysis work, an overview framework is useful to place these in context and help determine the most appropriate technique for each individual situation. In this chapter we have set out a Business Analysis Process Model as a framework within which both standard modelling techniques and organisational templates can be used. This approach also incorporates the principles of Requirements Engineering to highlight best practice when defining system requirements.

AN APPROACH TO PROBLEM SOLVING

One of the requirements of business managers is that business analysts examine the entire business area and take a thoughtful, even creative, approach to developing ideas for solutions. Creative problem solving is vital in the business world as, increasingly, organisations need to develop innovative ideas in order to respond to changes in the business environment including actions from competitors. However, many people find this difficult; often because they feel under pressure to produce ideas very quickly. In this context, Isaksen and Treffinger’s (1985) original creative problem solving model, shown in Figure 4.1, provides a useful framework for understanding problems and developing creative solutions, particularly as the model emphasises the need to investigate and analyse rather than leap to quick, possibly premature, solutions.

This model proposes an approach that may be applied usefully to business analysis. In this section we describe the implications and suggestions the model has for you as a business analyst. The first stage, mess finding, is where we often begin when undertaking a problem investigation. In business analysis this stage is concerned with finding out about the complexity of the problem situation. Many problems are poorly defined or ambiguous, and each problem situation is likely to be complex and contain various issues and concerns. In other words, there is likely to be a ‘mess’ and different situations will have different components to that mess. Identifying this as the starting point in this model helps to emphasise that you need to gain some understanding about the complete situation before diving into options and solutions. The rich picture diagram, described in Chapter 5, is particularly useful to help document and analyse the ‘mess’ in problematic business situations. Rich pictures do not use a defined notation set and the flexibility this offers enables us to use them to represent any situation. Mind maps and fishbone diagrams are also described in Chapter 5 and are similarly helpful.

Figure 4.1 A problem solving model (after Isaksen and Treffinger,1985)

Data finding, the second stage of the model, is concerned with analysing the opinions, concerns, knowledge and ideas uncovered in the previous stage, in order to identify where this information can be quantified and supporting data obtained. It is often useful to examine the rich picture, mind map or fishbone diagram to clarify our thinking about the situation. It is particularly important to consider which information is factual and which is based on opinion. This can help lead us to the aspects that we can, and should, verify and also emphasises the need to divorce opinion, whilst useful, from fact. Chapter 5 explains some techniques that will help you to obtain quantitative data, such as surveys and activity sampling.

Problem finding then uses the work of the previous two stages to help uncover the heart of the problem. We now know the complexity of the situation facing us and have been able to quantify some data whilst appreciating that other information represents personal views or opinions. We may have been presented with a statement of the problem at the outset but at this point, having carried out the previous two stages, it is important to revisit this in order to understand fully where the problems lie. Finding the right problem to solve is often a necessary part of business analysis, as analysts are often pointed at symptoms and they have to dig deeper in order to find out where the real problems lie.

So, these first three stages are concerned with understanding the problem and they provide a structure for doing this. The next two stages focus on developing solutions.

First, there is idea finding during which business analysts try to generate a wide range of ideas. Analysts often use brainstorming approaches to uncover ideas but this can be difficult as it requires a group to generate ideas ‘cold’. Sometimes this works but often different approaches need to be used with brainstorming to stimulate ideas and so during this stage it may be useful to use some creative thinking techniques. Two examples of techniques that can provide stimuli for creative ideas are ‘Assumption Reversal’ – where assumptions about a situation are listed and reversed – and ‘Random Words or Pictures’ – where unrelated words or pictures are used to generate different ideas about a situation. More information about these techniques can be found in the creative thinking texts mentioned in the references and further reading.

Once some ideas have been identified, they can be evaluated and we can focus on those that could provide solutions to the problem(s). This is the solution finding stage and it is significant that this stage appears so late in the model. Business analysts are often expected to deliver solutions quickly, yet here we can see that it is important to resist the pressure to develop solutions at too early a stage; there are other aspects that need to be considered first. Also, Isaksen and Treffinger (1985) stress the importance of identifying criteria to help evaluate potential solutions and this would not be possible without the earlier work. Therefore, it is important to work through the earlier stages as they will help you to develop better, more appropriate solutions that will be more beneficial for the business situation.

The final stage in the model is acceptance finding which is concerned with gaining business acceptance of the solution. This aspect is critical to the success of any change project. Chapter 8 considers the importance of ensuring changes align with the business architecture. Chapter 9 considers how the feasibility of proposed solutions may be evaluated and how a robust business case may be made in order to obtain approval from the business.

THE BUSINESS ANALYSIS PROCESS MODEL

One of the aspects that makes business analysis work so interesting is the range and nature of business analysis projects. The business systems under consideration can be very varied; for a particular project business analysts may need to apply several techniques and analyse a number of different stakeholder views. Sometimes the project may be to investigate a problematic part of the organisation and produce outline recommendations for ways forward. Other projects may require the business analyst to analyse and document specific business or system requirements. So, the challenges faced in developing a process model are to offer something that is sufficiently flexible while providing a framework that will help people to carry out their work. The process model shown in Figure 4.2 is intended to meet these challenges.

Figure 4.2 The Business Analysis Process Model (Reproduced by permission of Assist Knowledge Development Ltd)

The top stripe of the process model shows the importance of understanding the business context. Within this context, we need to be aware of the Mission, Objective, Strategy and Tactics (MOST), as described in Chapter 3. However, there is a more fundamental aspect of which we should also be aware and this concerns the underlying values of the organisation. For example, does the organisation genuinely value aspects such as quality and customer service? Or, are low costs more important? Does it comply where necessary with legislation regarding equality of access or really embrace the importance of accessibility for all? Recognising the values of the organisation and being aware of the MOST, will help us to have a clearer understanding of the stakeholders and their priorities.

The process model sets out the key stages for a business analysis project with each stage representing the areas that need to be considered. However, it should be noted that whilst some projects may require a detailed exploration of all of the stages, other projects may focus on a subset of the model, possibly just one stage. One of the most important aspects of a business analysis project is to decide what the focus is and which areas need to be investigated. For example, on some projects the focus may be to explore possible improvements to how part of the organisation works. In this case, we might begin by examining all of the current working practices, including the staffing and job roles, and the work may focus on analysing and evaluating the options for the future business system. Another project may focus on the IT system needs and whilst understanding the situation and all of the stakeholder perspectives is important, the potential for the use of IT to improve the business system will dominate the analysis. The rest of this chapter describes the stages of this process model.

INVESTIGATE SITUATION

This stage is concerned with uncovering issues and problems. The terms of reference for the project, or possibly a more detailed project initiation document, are needed in order to set out the context within which the business analysis work will take place. The OSCAR mnemonic can be very useful when clarifying the terms of reference if none exist. This stands for the following:

A key area for the analyst is to clarify the objectives of the study and tailor the approach accordingly – often a task that requires a good deal of skill. During the initial period of business analysis work the analyst may be presented with a statement of ‘the problem’ but this statement may not be correct. It is important to investigate the situation further in order to determine where the real problems lie, and ensure that symptoms of the problems are not confused with the real issues. It is also vital that the analyst does not make false assumptions or accept all of the information provided without question. To perform this work effectively, it is important that the business analyst has an understanding of the business context during the investigation stage. Once the analyst has begun to understand the situation and clarify some of the ambiguity that exists, it will be necessary to create documentation recording the findings. This will be required for future reference and also to help other members of the team understand the situation.

Investigation techniques

There are many investigative approaches that business analysts can use and these are explored in detail in Chapter 5. It is important that we consider the range of possible investigative approaches and choose those that are most appropriate to the work in hand.

The level of detail required during this stage may vary considerably depending on the focus of the business analysis work. If the analyst is trying to gain an overall appreciation of the business area, for example, to identify the key stakeholders and acquire an understanding of their views and opinions, or to appreciate the nature of the work and the range of people and skills, then often the techniques used will be those that provide an overall perspective and generalised view; interviewing, observation and workshops would be particularly useful. However, if the work is concerned with eliciting more detailed information such as data requirements or the flow of a business process then the most appropriate fact-finding techniques are those that focus on the detail such as document analysis, scenario analysis or prototyping. Much of the information gained during the initial investigation may be subjective, so should be quantified through more detailed analysis. In this case, techniques such as record searching or surveys may be very useful in order to quantify some of the information put forward.

Documenting business situations

There are a number of useful techniques for documenting and visualising the initial investigation of a business system. It is typical that a high-level overview of the situation will be required during the initial investigation, particularly where the issues are complex and originate from different causes. As we mentioned earlier, a ‘rich picture’ can be very useful in capturing the essence of a situation. An alternative, but similar approach, is the ‘mind map’; this also allows for a degree of structuring of the information. Fishbone diagrams can also be very useful during investigation as they help to uncover the root causes of problems. These techniques are described in further detail in Chapter 5. Other techniques may also be useful where specific issues have been identified. For example, if there are issues with the business processes then process modelling (described in Chapter 7) will be relevant.

Stage summary

Procedure

• Study background material – project initiation document, terms of reference
• Carry out initial investigation with key stakeholders
• Document the results of the investigation – using meeting reports plus diagrams such as a ‘rich picture’, mind-map or fishbone diagrams

Inputs

• Terms of reference or project initiation document
• MOST, statement of business values

Outputs

• View of the existing business situation, including meeting reports and diagrams such as rich pictures, mind maps and fishbone diagrams
• List of issues/problems

Techniques

• Investigation techniques such as interviewing, observation and workshops
• Quantitative investigation techniques such as surveys, sampling and document analysis
• ‘Rich pictures’ (from Soft Systems Methodology, developed by Checkland (1999))
• Mind maps (Buzan and Buzan, 2009)
• Spaghetti maps
• Fishbone diagrams (Ishikawa – these are also known as Ishikawa diagrams after their inventor Kaoru Ishikawa (1985))
• Business process models

CONSIDER PERSPECTIVES

This stage is concerned with analysing stakeholders and their perspectives on the business situation. Many stakeholders hold very strong views about why problems exist, what needs to be done to improve the situation and where the focus of the business system should lie. Where some of the issues arise from differences in stakeholder views it is vital that they are explored and where possible taken into account when making recommendations for the way forward.

Stakeholder identification and analysis

Every business situation will affect a range of individuals and organisations. Among this group there will be people or groups with varying levels of interest and power. Some stakeholders may be directly affected by any recommendations and may hold strong views on how the systems and working practices should be changed. Others may be affected only indirectly and, whilst having opinions, may be less concerned about the nature of the new system. The range of possible stakeholders and mechanisms for stakeholder analysis and management are discussed in detail in Chapter 6.

Stakeholder perspectives

Stakeholders often have different views on what is important about a business system and, as a result, have different ideas about the improvements that are needed. These views are often contradictory and can lead to hidden agendas, conflicts and inconsistent priorities. As business analysts it is important that we are aware of the potential for such conflicts and are alert to situations where these might arise. We can often detect where the different stakeholder conflicts might originate by considering the underlying set of values and beliefs they hold. For example, we might reflect on what an individual stakeholder considers to be the main focus of the business system and, critically, why this is the case. Understanding these values and beliefs allows the analyst to approach issues and problems from an informed position and hence have an improved chance of resolving the situation. Chapter 6 considers the importance of analysing stakeholders and their perspectives and explains how they may be analysed by considering the world view of each stakeholder. This includes an explanation of the CATWOE technique, originally developed by Checkland (1999).

Business activity modelling

The stakeholder perspectives can be analysed further by considering the business activities that would be required to fulfil a particular perspective. This approach, developed from Checkland’s work, and extended by Wilson (1990), allows analysts to build a conceptual model of a business system as envisaged by a particular stakeholder. For example, where a manager believes an events organisation should focus on quality then there would be an emphasis on activities such as:

• the recruitment and development of highly skilled staff;
• the introduction of customer-focused processes;
• monitoring of customer satisfaction levels.

An alternative view could be that the focus should be on ‘no frills’ events and in this system the emphasis would be on the following activities:

• keeping costs low;
• monitoring the number of attendees at events.

This approach allows business analysts to consider where the priorities lie and what the focus of the new, improved business system should be. One stakeholder’s view may take precedence over the others or several models may be synthesised to provide an agreed business activity model. The business activity modelling technique is explained further in Chapter 6.

Stage summary

Objectives

The objective of this stage is to take stock of the range of stakeholder perspectives about the business system under investigation. These perspectives may then be analysed to uncover stakeholder values and beliefs, and developed into business activity models. However, where there is a narrow remit for the business analysis work, for example if we are concerned primarily with improving a particular process, while it will be important to identify and manage the stakeholders, consideration of the entire business system may be beyond the scope of the business analysis work.

Procedure

• Identify key stakeholders whose perspectives are important to the business analysis project
• Investigate the values, beliefs and priorities of the key stakeholders
• Develop and analyse the stakeholder perspectives
• Build conceptual models of activities to fulfil the stakeholder perspectives
• Explore and resolve conflicts between stakeholder perspectives
• Synthesise conceptual models into one view of the desired business system

Inputs

• Terms of reference or project initiation document
• Business values and MOST
• Identified stakeholders (from the documentation of the existing business system)

Outputs

• Power/Interest grid
• Stakeholder perspectives
• Business activity models based upon stakeholder perspectives
• Consensus business activity model

Techniques

• Investigation and negotiation techniques
• Stakeholder identification and analysis
• CATWOE
• Business Activity Modelling

ANALYSE NEEDS

The focus of this stage is to identify where improvements can be made to the business system. The approach used is known as ‘gap analysis’ whereby a current or ‘as is’ view is compared with a desired, future or ‘to be’ system. This method contrasts with the traditional, more systematic approach to business or systems improvement where new features are added on to an existing set of procedures or IT system functions. With gap analysis the emphasis is on understanding where we want to be and, by looking at where we are now, identify what needs to change to take us there.

Analysing activities

Where you have developed a business activity model from a stakeholder perspective, this can be used to carry out a detailed analysis of the desired business system by examining each activity in turn. This analysis allows us to identify where there are issues that need to be addressed in any solution that we recommend. As the model provides a conceptual picture of the desired business activities it allows the business analyst to see where the current business system is lacking. When examining the model, the range and extent of the gaps found will vary from activity to activity. Some activities may be in place and operating satisfactorily. However, others may be inadequate in the current business system and some may not exist at all. There may be good support for the activity from the organisation’s information systems or this may be poor and in need of improvement. Identifying the gaps at this level will help us to determine the potential for change to the business system and the degree to which this is required.

The business activity model may identify a range of areas to be considered in the light of the current business situation. However, it is possible that some aspects may be beyond the scope of the business analysis work.

Analysing business processes

At a more detailed level, gap analysis focuses on the business processes that are applied within the business system. Whereas the activities modelled on the business activity model show a conceptual view of what activities should be within the desired business system, the business process models allow us to consider how the work is carried out. Therefore, the analysis is conducted at a more specific level of detail and, rather than being conceptual, is much closer to the physical reality of the business system. A business process is initiated by a business event, which is sometimes called a ‘trigger’, and concludes when the goal of the process has been achieved. This view of the business situation cuts across departments and job roles in order to show a more results-oriented view that is focused on meeting customer needs. The approach we take to this work is to model the current business process and then to consider possible changes to the process before finalising the required process. Hence, we develop a current or ‘as is’ model that provides a basis for developing the required or ‘to be’ model. When redesigning a process we can look for small changes that affect one or two process steps or we might decide to design a completely new process. The business process modelling technique is explored in further detail in Chapter 7.

Gap analysis is conducted as a comparison between the current and desired business systems. The objective is to identify areas where action is needed to deal with the gaps. This may require changes to the organisation structure, people skills, processes or technology. Chapter 8 considers gap analysis and the importance of aligning any changes with the business architecture for the organisation.

Stage summary

Objectives

To explore the differences between the current and desired situations. To identify the opportunities for business change by analysing these differences or ‘gaps’.

Procedure

• Examine the activities on the business activity model
• Consider how well each activity is carried out in the current business system and how well it is supported by the organisation’s information systems
• Identify the key business events to be handled within the business system; develop ‘as is’ business process models for the key business events
• Develop ‘to be’ business process models for the key business events
• Analyse the gaps between the existing and the desired business systems. Use these as a basis for identifying potential business system improvements
• Ensure any potential improvements align with the business architecture

Inputs

• Agreed business activity model
• View of the existing business system
• Business values and MOST

Outputs

• Analysis of activities, including identified areas of weakness
• ‘As is’ and ‘to be’ business process models
• List of potential improvements to the business system

Techniques

• Gap analysis
• Activity analysis
• Business process modelling

EVALUATE OPTIONS

This stage is concerned with examining the potential improvements identified so far, developing some business options and evaluating them for acceptability and feasibility. The analysis of the gaps between the existing and desired systems will have produced some ideas for improvements and the work now is to develop these ideas into business options. These options may include options for changes in a number of areas; for example, they may change the business processes, the job roles, the management structure or the IT systems. At this point, the changes are likely to be defined in outline only, but in sufficient detail so that a business case may be developed to support the recommendations and provide a basis for decision-making. Once the work to define the changed areas begins in earnest, there may be a need for further consideration of options. For example, where changes are required to the supporting IT systems, this may be agreed in principle at this stage but it is likely that the detailed options for the new IT system will need to be evaluated, and the business case revisited, at a later date.

Identify potential options

The first step is to identify possible options by considering where improvements might be made and which ones would result in the greatest potential benefits. Once a number of options have been identified these can be reduced to a shortlist of options to be defined in further detail. The business values, MOST and business architecture need to be considered as part of the development and evaluation of options as they must be supported by, and aligned with, any changes.

Assess feasibility

All of the options that are to be considered in detail need to be evaluated for business, technical and financial feasibility. Chapter 9 explores these aspects of evaluation in further detail. In addition, areas such as the impact of options on the organisation, and the risks that may be associated with an option, also need to be considered as they will affect the acceptability of the option. Impacts and risks may give rise to additional costs that need to be fed into the cost–benefit analysis for the option. Consideration of the business values and MOST should also form part of this work as any new business system will need to be aligned with the values and strategy, and support delivery of the business objectives.

Stage summary

Objectives

The objective of this stage is to collect together the range of potential changes into packages of improvement actions. These packages form the basis for developing a set of options that are then developed and documented in further detail. They are then presented to business managers for consideration.

Procedure

• Identify range of business options
• Explore acceptability of options and reduce to a shortlist
• Develop and document each option in detail. In particular, consider the business, technical and financial feasibility of each option
• Develop business case, including presenting options and recommendations to business managers

Inputs

• Project initiation document/terms of reference
• Business values and MOST
• List of potential improvements to the business system

Outputs

• Shortlist of business options
• Business case including options, feasibility assessment and recommendations

Techniques

• Business options identification
• Cost-benefit analysis, including quantification of costs and benefits; investment appraisal techniques
• Impact analysis
• Risk analysis

DEFINE REQUIREMENTS

This stage is concerned with gathering and documenting the detailed requirements for changes to the business system. These changes may be to any (or all) of the four aspects of a business system described in Chapter 1: the business processes, the supporting IT systems, the people carrying out the work and the organisation structure. Where the changes are to the business processes, the modelling techniques described in Chapter 7 should be used to define how the new processes should look. If the recommendations include the implementation of redesigned processes, this is likely to require changes to the structure of the organisation and the job roles, plus development of the staff skills. It is sometimes the case that the improvements to the business system can be made through limited changes such as improved job definitions or additional training for the staff. However, more extensive change is usually required, for example to the business processes, and it is likely that this will necessitate enhancements to existing IT systems, or even the introduction of a new IT system. Business analysts have a responsibility to define the requirements accurately, as their documentation will form the basis for the development of the new processes and system. If the requirements are not documented clearly then this is likely to cause problems not only during the development of the system but also once the system has been implemented. It is vital therefore that the requirements may be related directly to a business need and will support the business objectives.

Requirements engineering

The requirements engineering approach has been developed as a response to the lack of rigour often found in requirements documentation. Requirements engineering proposes a framework to help analysts improve their requirements work by highlighting the need for proactive analysis, organisation, documentation and management of stated requirements. The requirements engineering approach is described in Chapters 10 and 11.

Modelling systems

There are many modelling techniques available to business analysts. These techniques originate mainly from systems analysis and design approaches such as the Unified Modeling Language (UML). Each modelling technique provides insight into a particular aspect of the IT system. For example, techniques such as class modelling and entity relationship modelling provide a clear and unambiguous means of documenting the system data; techniques such as activity diagrams provide a clear representation of processes. Business analysts find such techniques extremely useful when exploring requirements as they help to build rigour into the requirements analysis activity. Building and comparing models of a system will help generate additional questions, and uncover omissions, errors and inconsistencies. Chapter 12 provides an overview of some of the more popular modelling techniques used by business analysts. There are many books devoted to explaining systems modelling techniques in detail, some of which are listed in the further reading for Chapter 12.

Stage summary

Objectives

The objective of this stage is to produce a well-formed requirements document setting out the business requirements for the new business system. This document must include clear textual descriptions of the requirements and sufficient information to trace each requirement from its origin through to its resolution. Modelling techniques may be used to represent the process and data requirements diagrammatically and hence improve the rigour and clarity of the requirements definition.

Procedure

• Gather the requirements:
  • elicit and analyse the business requirements for the new business system;
  • document and manage the requirements;
  • validate the documented requirements.
• Document the requirements for the new business system, including as appropriate:
  • business process models;
  • catalogue of business requirements;
  • models of the IT processing and data;
  • glossary of terms.

Inputs

• Selected option for revised business system
• Business values and MOST
• Terms of reference/project initiation document

Outputs

• ‘To be’ process models
• Job definitions
• Revised organisational structure
• Validated requirements document including:
  • requirements catalogue;
  • models of business process and system requirements;
  • glossary of terms.

Techniques

• Business process modelling
• Job design
• Investigation techniques
• Requirements elicitation, analysis and validation
• Requirements documentation and management
• IT systems modelling techniques

DELIVER CHANGES

Once the business analysts have investigated and analysed the situation, considered the stakeholders and their perspectives, developed options for improvement and defined the requirements to be fulfilled, it is important to consider how the business changes will be delivered and implemented, and the business benefits realised. In the main, this work is not solely the responsibility of the business analyst but some tasks, such as providing support to the stakeholders, does fall within our remit. Figure 4.3 shows this extended version of the business analysis process model including where the business analyst works to support the delivery of business change.

Figure 4.3 Extended Business Analysis Process Model (Reproduced by permission of Assist Knowledge Development Ltd)

Delivering the requirements

The requirements will need to be developed into the business change solution. This solution may include process, people, organisational and IT system change. The lifecycle and approach to be adopted to develop and deliver the changes will need to be determined. This decision will have an impact upon the roles of the project team, the deliverables to be produced and the techniques to be used. Chapter 13 discusses these issues. The extent of the business analyst role will depend upon the lifecycle and approach adopted on the project.

Implementing the business changes

The delivery of the business solution will need to consider aspects such as the emotional impact of change and the realisation of the business benefits. These issues are discussed in Chapter 14. The business analyst may be heavily involved in tasks such as designing and documenting the new tasks and procedures, supporting user acceptance testing and reviewing benefits to assess their realisation.

Stage summary

Procedure

• Decide the lifecycle and approach to be adopted
• Design and develop the business change solution
• Support the planning and implementation, in particular the development of the required learning materials and the delivery of training for the business staff
• Review the predicted benefit
• Identify any actions required to realise the benefits

Inputs

• Business change process and organisation design
• IT software solution
• Business case

Outputs

• Business change plan
• Communication plan
• Training approach and materials
• Revised job roles and descriptions
• Benefits plan
• Benefits review document

Techniques

• Use case descriptions
• Decision tables
• State charts
• Benefits planning

SUMMARY

Business analysis projects are usually concerned with improving the working practices within business systems. This may involve changes to a range of aspects that form the business system including staff capability, business processes or the supporting information systems. Increasingly, business analysts are also required to support the development of solutions, delivery of business changes and realisation of business benefits. The business analysis process model is intended to help business analysts in deciding how to structure and conduct their assignments. The model also includes references to some of the techniques in popular use and identifies when these techniques may be particularly useful.

REFERENCES

Buzan, T. and Buzan, B. (2009) The Mind Map Book. BBC Books, London.

Checkland, P. (1999) Systems Thinking, Systems Practice: Includes a 30 year retrospective. Wiley, Chichester.

Isaksen, S. G. and Treffinger, D. J. (1985) Creative Problem Solving: The Basic Course. Bearly Limited, Buffalo, NY.

Ishikawa, K. (1985) What is Total Quality Control? The Japanese Way. Prentice Hall, Upper Saddle River, NJ.

Wilson, B. (1990) Systems: Concepts, Methodologies and Applications, 2nd edn. John Wiley and Sons, New York, NY.

FURTHER READING

de Bono, E. (2009) Six Thinking Hats. Penguin Books Ltd, Harmondsworth.