A SIAM Trilogy Part 3: Keeping the ecosystem healthy
In our latest blog, SIAM Professional Lead Architect and Scopism eConsultant Michelle Major-Goldsmith looks at the third part of an organization’s SIAM journey. You can read part 1 here and part 2 here. In this blog, Michelle explains how to keep your SIAM ecosystem in good health once it’s been defined and implemented.
Part 3 – Implement and Run & Improve
In my last blog, I wrote about the approach required for the Plan & Build stage of the SIAM roadmap, where the focus is to create an adaptable, scalable model that is responsive to the inevitable changes within the business and service provider environments. This final blog in the trilogy looks at the last two stages, Implement, and Run & Improve.
After the ecosystem is created, how do you implement it and how do you keep it in good health?
The objective of the Implement stage is to establish the transition from the organization’s ‘as is’ current state to the ‘to be’ desired future state, the new SIAM model. The timing for the start of the Implement stage can be influenced by events in the existing environment. For example, implementation could be triggered by:
- The end of an existing service provider’s contract
- An existing service provider ceasing to trade
- Organizational structure changes due to corporate restructure or takeover
In reality, the customer organization (who commissions the SIAM model) may have limited control over the timing of these events, so the preparation done in the earlier stages (Discovery & Strategy and Plan & Build) will identify and manage the risks associated with the factors that might force a swift implementation. At the end of the Implement stage, the new SIAM model will be in place and in use, and the focus will then be on managing its health and the quality of service being delivered to the customer organisation (Run & Improve)
So, on to the tips….
Tip 1: consider a suitable implementation approach
“And suddenly you know: It’s time to start something new and trust the magic of beginnings.”
― Meister Eckhart
Of course, a key decision here is to agree upon the implementation approach. This involves considering the available options as well as any specific associated factors and risks to the customer organisation. There are two possible approaches to implementation:
- ‘Big bang’
As in all decisions relating to the SIAM transition, one size does not fit all.
Consider a ‘big bang’. This approach introduces everything at once, within a specified, limited timeframe, including the service integrator, the service providers (with new or amended contracts), new services and new ways of working. It requires robust planning and consideration of the elements I’ve previously alluded to as key elements of the earlier roadmap stages. This might become necessary, perhaps due to the start or end of specific key contracts or when a very clear start or end to a new approach is required. The benefits of this approach mean that if things go well the organization has their new model in place quickly and can achieve a steady state, likely lowering costs and risks and hopefully creating a positive user experience. It provides an opportunity to make a ‘clean break’ from all legacy issues and undesired behaviours and introduce the collaborative, end-to-end SIAM practices across all services and all providers ‘at once’. There are some risks, however. Using a big bang approach means it becomes almost impossible to see if the transition has fully captured all the requirements until it is released.
Exposing a whole organization to a new model can cause fear and disruption. The mechanisms defined in the Plan & Build stage, such as organizational change management and stakeholder management become important here, both in managing the transition of new service providers, systems and services, and in controlling the ‘people’ elements of the change.
Adopting a big bang approach may lead to an increased level of risk to the integrity of the new model and to the existing services that are being delivered. The customer organization and its users will expect existing service levels to be maintained and this can be challenging with so much change afoot. The suitability of this approach will depend on several factors such as:
- Time and resources available to test processes, interactions and tooling before the transition
- Level of knowledge sharing (required and possible) and the handover of authority across the ecosystem
- Appetite for risk and change readiness.
The alternative option is a phased approach, which counters some of the risks associated with a big bang approach. For a phased approach, a series of phases are defined, with deliverables at the end of each phase.
A phased approach can more easily exploit Agile practices. A transition project can be worked on in ‘sprints’, with each sprint deploying extra functionality, new services and new service providers within different organizational functions. Using a phased approach means that if an element fails, addressing it is not as time consuming or as complex, and it is unlikely to affect users as severely as with the big bang approach. Managing in phases is easier, as real-time feedback can be given at regular intervals on necessary adjustments.
Techniques like Scrum can be useful here. Scrum is a framework used to organize work into small, manageable pieces which can be completed by a cross-functional team collaborating within a prescribed time period (called a sprint, generally two to four weeks long). So, as a technique this is useful to perhaps transition service by service or cluster provider types together into logical groupings.
The phased approach still has challenges, especially if phases relate to strategic service providers tasked with delivering core business functions or services. In this instance, it is not always possible to limit the potential impact on core services. It is critical that an overall end date for the phased approach is specified, with clear and regular communication to and from users. This allows it to be clearly understood when the SIAM model is created and the Implement stage is complete. The Run & Improve stage then begins, and is where business as usual commences. Of course, changes within the environment or changes to customer needs prompt a requirement for various stages of the roadmap to be revisited.
Adopting a phased approach might provide a decreased level of risk, but has a similar level of complexity for all layers in the SIAM environment. With a phased approach, it can take longer for benefits to be delivered so the benefits realization planning needs to be carried out carefully to take this into account.
When considering if this is the best approach consider how possible it would be to:
- Establish the SIAM model and collaborative working methodology in phases
- Manage business demand and customer satisfaction during a phased approach which will have less impact but over a longer period.
So, my tip here is to understand what the approaches are and consider their limitations and benefits fully. Look to the SIAM Professional BoK which gives real practical advice on when, and under which circumstances, an approach might make more sense.
Tip 2: maintaining staff morale and motivation
“Adopting the right attitude can convert a negative stress into a positive one.”
― Hans Selye
The management of staff within an outgoing service provider or where staff are retained but their roles and responsibilities change and the maintenance of morale towards the end of a contract is particularly challenging for even the best of managers. There can be a struggle to maintain concentration on business as usual obligations and service levels, and at the same time there are demands on the existing service staff to participate in knowledge transfer and other requirements from the incoming service provider. Strong management support will be required.
My second tip is based on a positive experience I had working in a transition team in a large multinational organisation. The organisation took over another smaller company whose IT had been wholly insourced. Given the global nature of the mother organization and its complex web of providers, it decided that to support this new business, it would move to a SIAM model using the services of a renowned service integrator. This external organization was to take the service integration role as well as responsibilities for the service desk, based in India.
A staff consultation period commenced, with HR, legal and union representatives. These stakeholders were engaged many months before the planned transition. No staff chose to take roles in India and it was agreed that staff would be displaced over an 18-month period, to allow for a smooth handover. Several of the incumbent staff went to India to support new staff with the transition during a period of early life support. The transition went well, largely due to the investment in good staff, robust training and the gradual testing and transition elements. The incumbent, displaced staff were generously rewarded for their service during that critical period. It is difficult to motivate staff who are losing their jobs. In this instance, the additional experience they gained as well as the opportunity to work overseas was coupled with a financial reward. Although incumbent staff were unhappy to be losing their jobs, they also acknowledged the company’s care in handling the situation. They spoke favourably about the experiences with their previous employer, helping it to maintain a good market reputation for the organisation within the UK.
The key point here is, early and ongoing purposeful, timely communication, as well support from HR, legal and union representatives, can be a make or break factor. Do not assume that an employee will be ‘difficult’ after being made redundant. Personal pride means that this often not the case and positive and fair treatment will help. Often employees welcome a new opportunity or a financial settlement.
My final tip: promotion of collaboration and innovation
“If everyone is moving forward together, then success takes care of itself.”
– Henry Ford
So, now to an implemented SIAM model. How do you sustain positive relationships and promote proactive working and innovation? This is certainly a challenge. Within a SIAM ecosystem the structural elements provide stability, support and governance, enabling collaboration activities, easing smooth running and focusing on continual improvement.
There are a number of structural elements defined within SIAM, which take the form of Boards (whose focus is on decision making: strategic, tactical and operational), Process Forums (with a set & regular meeting frequency, aligned to a specific process and focussed on improvement thereof) and Working Groups (ad hoc, convened to discuss and resolve specific issues). Each spans the SIAM layers which means that they provide opportunities for relationship building and collaboration.
At an operational level, they help to establish relationships and encourage communication between service providers and the service integrator. Process forums provide excellent opportunities to evaluate the overall effectiveness of the processes and the collaboration in everyday life, and allow the service integrator to identify operational challenges and drive continual improvement. They also allow the fostering of required culture or behaviours. One key tenet here is the concept of ‘fix first, argue later’. A necessary approach for establishing a service culture and to create an understanding that the focus is on restoring service failures not pointing fingers. The concept is not suggesting that there should be any argument. Rather, it suggests that the initial focus needs to be on fixing the issue at hand. Discussions on who was responsible for the issue (‘argue’ in the phrase) will take place after resolution (or at least once there is a reduced urgency) and should be focused on improvement and prevention of future occurrences, rather than punishment of mistakes.
In complex environments with many different service providers, more Boards might be created to address specific areas of governance. Conversely, there may be fewer boards within an ecosystem which has smaller service providers with fewer staff who can contribute. To reduce the overhead on these service providers, it might be necessary to reduce the number of meetings by combining Boards or Process Forums, or reducing the meeting frequency. For example, a problem management forum may exist that has within its scope an action to convene a ‘working group’ when a major problem is identified or indeed a problem record backlog needs to be acted on. It assumes the working group role rather than creating a separate meeting. Similarly, process forums can be amalgamated, for example an integrated change and release forum. In each instance of adaption, it is necessary to ensure understanding of the scope and intent of the group, and undertake ongoing value measurement.
The service integrator must work to balance the requirement to bring teams together against the impact on service delivery. It is necessary to ensure that they do not create a challenge where the overhead of participation may be too much, as this will negate the value.
The tip here is don’t blindly follow ‘best practice’. Create these groups, and define their scope, contribution and effort, based on the scale of the SIAM ecosystem in order to maximise their worth.
“There is always one more thing to learn.”
– Steve Jobs
So, this brings me to the end of my SIAM trilogy. I could write a million blogs and still never be able to capture all the wisdom of the SIAM Foundation and Professional BoKs. Although the concepts of service integration were not new, the BoKs have codified the information, providing reference books and guidance for business and service managers. They are crammed with advice, examples and anecdotes from over 45 world class SIAM experts.
SIAM has evolved in response to business problems, and there isn’t one solution, nor is there intended to be, but the BoKs provides answers to a common challenge. SIAM is designed to provide support in complex multi-provider models. Service and supplier landscapes that many service management functions were set up to manage are now subject to significant change. This necessitates a shift in the way that these services and their suppliers are managed. For me it is refreshing to see a collective view of SIAM and some practical guidance on how to apply it, in different circumstances. If you’d asked for formalized guidance on SIAM eighteen months ago, it would not have been available and you’d have received ten different opinions about what it was all about.
The SIAM BoK’s can help not only to start a conversation with an organisation about why SIAM might be a good operating model but it also provides a step by step roadmap led approach to creating a solution. If you haven’t done it yet, I encourage you to download both BoK’s and take a look…