There are many aspects of building a multi-supplier model that must be managed concurrently. This post focuses on the governance and operational conditions that must be established for successful Service Integration and Management (SIAM) and Systems Integration (SI). Not least of these is the skills and attitude needed within the retained governance.
Transition
No service transition is trivial. This is occasionally overlooked by those who wish to think that it should be easy to swap out under-performing suppliers. Unfortunately, this operational fact of life still exists in these times of the Cloud and capacity available at the flick of a switch. If anything, the job of transition project management will be harder in the new world where service offerings are more a la carte than before. Many SMEs with limited breadth of experience and skill are engaged. Discovering that there are gaps that cannot easily be addressed can be painful.
It seems to be wise to establish the Governance regime first, closely followed by SIAM. This provides a context and environment into which other towers are then progressively introduced. Once the foundation infrastructure has been built, services may progressively be transitioned to use it in anger. In reality, life is messy and the initial construction may well be led by one service, with others following. If this is the case, an early survey of the needs of all should help to manage the risk that the initial configuration is good for the first service, but bad for those following.
It is common to find two worlds within an IT department, with strained communication (if there is any) between them. These are the realms of Projects and Operations. It is advised that an operations-type person should be assigned to the transition project team as Transition Manager. This person should be charged with conducting the Operational Acceptance Tests and making sure that the service artefacts (e.g. the Service Design Package) are prepared to an acceptable standard. This appointment should be made early on!
Collaborative Environment
A a good contract is necessary for success in service delivery, but is not sufficient. A good contract defines the obligations to which suppliers are later held to account. I have worked with two senior IT leaders who thought that they could busk it with a contract known to be bad, and sort out the mess afterwards. One was in the middle of a crisis at the time too! Such an approach places suppliers under immense strain as if there is a difference between what the contract says and what the customer wants, and things end up in dispute, it is always what the contract says that rules. Better always to contract as best one is able and manage changes when necessary.
A recent report by the Institute of Government bemoaned “Gaming” whereby service providers deliver the easy cases and park the difficult ones.1 A contract author must think things through from the perspective of the other party, and a good alert governance body must look out for it and promptly deal with it.
Some aspects of collaboration are expensive for suppliers to implement. If a customer does not recognise these up front, write obligations around them and acknowledge that they must be paid for or sacrificed, they are likely to be disappointed. The areas in which I have seen this most acutely are around configuration management and maintaining ordered information. These need careful design to make sure that the essentials are in place, but that onerous and unproductive paperwork is avoided. Many of us related to service management have seen tooling projects get hideously overblown. I know a service director who would turn from delightful charmer to screaming wreck at the mention of “CMDB”. The discovery efforts at the start of even the smallest changes can be horrible where there is no reliable configuration and the architects cannot be sure that the design information is the latest issue. Such information benefits all, and must be maintained by all, so obligations and policing action are needed.
The most important aspect of maintaining a collaborative environment is that of establishing the appropriate behaviours. Research shows unsurprisingly that threatening behaviour undermines trust and collaboration in a commercial relationship.2 The exercise of punitive actions by a party, following non-compliance by the partner, is seen everywhere in practice. The paper notes that where punishment is justified by clearly founded performance information and avoids the vindictive use of power, the performance effects are positive. I have seen an aggressive CIO kill collaboration between his suppliers, to the surprise of nobody, and to the detriment of his users. This is why it is suggested that the governance arrangement should be established from the start, and used to set the tone required. The appointment of people with the attitudes desired is essential.
Clarity and consistency of role and obligation is essential for collaboration. Part of this rests with the contract, part with process, some with behaviour. Where people know what is expected of them, they can confidently perform. This does not happen by accident, but needs continual work and vigilance. Stepping over the line into someone else’s role may be done from the best of motives to keep things moving, but can fatally undermine them and the relationship, especially when a senior steps into a junior’s remit. If the junior is not performing, deal with it. If the contract is not in line with what you need to see, write a CCN if it exceeds the boundaries of daily give-and-take.
Manage the Essentials
It is taken for granted that all suppliers will be contracted to work consistently with ITIL. This in itself is no guarantee of success. The lead organisation, probably the one performing the role of service integrator (or SIAM), should determine the approach and standards being taken within this customer, publishing them in an ITIL Framework. An examination of ITIL within the context of the customer’s business need should identify the critical success factors for each process, emphasising those that are necessary for successful end-to-end service delivery. Depending on the way the boundaries are drawn between the service providers, there will also be dependencies between the suppliers. These need to be identified early in supplier engagement, examined critically and included in contract or OLAs as appropriate. In some cases, these may require funds to be transferred between to reflect the value of work done. The SIAM will need to ensure that these obligations are delivered.
Beware of gaming in which suppliers seek to transfer the obligations for expensive work to others, whilst retaining the revenue attached.
Governance
A customer’s IT leaders can never abrogate accountability for performance to the business, if only because they appointed the supplier and have the task of holding them to account. The processes of governance may be characterised as:
- Financial management; approval and resource allocation, value assessment
- Contractual change; interpretation and holding to account for delivery of obligations
- Relationship management; managing and coordinating at the levels appropriate
- Performance management; identifying current performance, exceptions and trends
All within the context of leadership, establishing direction, allocating resources, managing risks and approving commitments. Governance needs to be predictable and organised, with each body having clearly defined roles to which they consistently adhere. Authority may be delegated to junior bodies and staff to accelerate and reduce the costs of transactions.
There needs to be at least one body that takes an overview of all aspects of IT service, balancing competing requirements. This should address projects, operations and commercial aspects and bring together all delivery organisations, determining the optimum trade-off to deliver the best overall benefit and outcome to the business as a whole. It needs always to focus on the capture of benefit, articulated in business cases and regular reports of benefits capture.
The skills to staff such governance bodies and perform the roles can be a challenge for those who are used to their receiving service outputs integrated by a prime contractor. Whilst a skilled SIAM can develop a deep understanding of the aims and priorities of the retained governance, they still need a context of coherent direction. When they present questions for resolution by the retained governance, they need prompt and clear decisions that are consistently worked through. The making of such decisions requires a combination of understanding of the issues, a mature approach to risk management and an attitude of accountability. This can be a challenge for many organisations, that must build these skills and understanding over time.
Systems Integration
Whilst the above discussion has focused on the world of service management and governance, this is not always where the greatest challenges and opportunities lie. A recent client spent substantially more on project delivery than it did on operations, reflecting the nature of their business environment. They also suffered from a risk-averse culture that was manifest in excessively bureaucratic procedures for the acceptance of project work into live operations. The programmes director estimated that this drove 70% of his costs, a claim that was difficult to validate, but in any case was known to be substantial. This observation drove the need to identify the sources of these obstacles and led to the proposal to apply Lean techniques to simplify without the loss of essential protection of the estate.
Collaboration between parties is just as important in project delivery as it is in service management. Good systems integrators are effective in defining statements of work for each party, measuring delivery to those obligations and focusing attention where it is needed. Whatever the development method used (Agile, Waterfall etc.), there must be one party that takes an end-to-end perspective of the delivery and ensures that the products perform to deliver the benefit expected. They need tools and information to flow between the delivery partners to facilitate this. Many of these (e.g. CMDB, Definitive Media Library) can be shared with operations.
This review does not pretend to be exhaustive. It is hoped that there are enough pointers to important aspects to make it useful. It is only when all work together that the service is integrated. Without that, you have a bag of bits and some unhappy users.
—————
References
Image: Shutterstock – Oleg Zhevelev
