Strategic thinking to understand organisations and the services they offer

In this post, ITGP authors Brian Johnson and Léon-Paul de Rouw discuss the importance of considering all stakeholders in collaborative business service design (CBSD).

Brian Johnson is ITGP’s author of the month for June 2018.


Stakeholders and requirements

An enterprise is populated with stakeholders. In CBSD, we want to understand how stakeholders come together and can be explicit about their requirements for any service offering.

Requirements are specifications from stakeholders of what should be implemented and signed off by general management or the board. They are descriptions of the properties of a service offering and how service offerings should behave. The stakeholders with the wallet often have different requirements to those of operational stakeholders.

This concept is central to the CBSD approach. CBSD uses the concept of stakeholders coming together and exchanging ‘transactions’ or ‘requirements’ – high-level requirements, not detailed development points – to build up the specification for a service design. Transactions occur between stakeholders, and are composed of processes, activities and resources. These are analysed and collated in the service design statement (SDS). To support this approach, we developed a generic canvas for the CBSD approach.

A canvas for CBSD: the service constellation

Like stars in the sky, stakeholders make up a constellation in the organisation. People trying to find some order in the sky made images by connecting the stars as patterns, and labelled them Orion, the Plough, etc.

Like stars, your stakeholders exist in a nebulous ‘organisation’ (or constellation) that has connections. It is your job to establish the pattern and simplify the reality of your organisation into a basic diagram. First, identify the principal stakeholders that are key to the development and delivery of a service. Although there are many stakeholders within an enterprise, to produce useful services that are purchased or built and consumed by users, you need to focus on four groups of principal stakeholders: the board, customers, providers and users. Each has control over a specific domain of the enterprise.

Second, place yourself – the business service coordinator (BSC) – at the centre of this mini universe as shown in figure 1.

The CBSD stakeholder constellation

Figure 1: The constellation



The pattern might not be as pretty as stars in the night sky, but you can now identify stakeholders from the perspective of those who are responsible for services that must come to fruition (or even come to an end) or must be maintained. This, of course, differs in every enterprise and in every service that you would like to design. Managing the complex relationship between stakeholders requires a role that takes on the responsibility of maintaining a long-distance view of the enterprise. That role is the BSC.

The service delivered defines the stakeholders involved. If we want to define services from the perspective of the BSC (and therefore the senior responsible owner (SRO)), we must position the BSC in the middle of the group of stakeholders, as shown in figure 1.

Your role is to seek an optimum balance between needs and the services available, or those that must be developed.

Perspectives on delivery: the final canvas

The needs of customers, users and management are not necessarily identical. Users want maximum support and no unexpected costs because of delays or failures. Customers (the group that manages the budgets) will explicitly look at the costs in relation to the quality of service. Directors, or general management, will wish to address the achievement of enterprise objectives and social or political interests. External service providers want to earn as much as possible from the contracts with customer organisations or seek to strengthen their position as a preferred supplier. Internal service providers wish to establish their organisational unit as the primary supplier to the enterprise, ideally creating and delivering services but at least acting as a trusted broker.

Figure 2 illustrates that each quadrant of the canvas has different perspectives. All these perspectives have to be summarised in a service design that is fit for purpose. The outcome is the focus of the business mission and vision and should be the umbrella of all outputs that result from the different actions in the enterprise. So, the output of each service should add value to the strategic direction. The output is the service delivered by providers to the users.

The CBSD canvas

Figure 2: The CBSD canvas


The canvas should be reviewed in an anti-clockwise direction, starting with ‘Users’. Users are often paying consumers, or are consuming internal services – perhaps a ‘digital workplace’. They consume the products that are delivered by the suppliers. Suppliers can be internal, for example, your friendly IT department.

The CBSD canvas helps you to extract all the information necessary to come up with the SDS, an overall view that guides the development, implementation and maintenance of the IT-driven service offering.

Why bother

So, why bother? Well, as we have discussed, there are many enterprises and many types of stakeholders. You will find that, whatever the diversity, this basic canvas will help you to analyse the required (strategic) specifications, which are then summarised in a relatively simple SDS.

CBSD should be considered a practical checklist to make sure that the essential stakeholders have been identified and consulted, and are in agreement.

Making sure that you come up with an SDS that is created and agreed by all stakeholders (or their committed representatives) and signed off by the SRO minimises the risk that somewhere at the end somebody is not satisfied.

Collaborative Business Design and Collaborative Business Design: The Fundamentals are available to order from ITGP. Get 15% off when you order in June 2018 – enter discount code JUNE15 at the checkout.

To stay up to date with the latest news from ITGP, sign up for our newsletter.