The Cloud First Strategy
General change and projects need to be self funded. I’m going to say that again – they need to be self funded. The cost of IT should be the cost of the provision of the known service. The unknown cost of change is given to the business to empower them to choose the priorities and provide the flexibility to select services not provided by IT.
IT should not be scaled to provide endless change and project support, but should be scaled to be the technical conscience of the business: facilitating change, translating business need to technical deliverables, engaging 3rd parties and providing an oversight into the IT elements of change.
Think SME not 3rd Party
Engaging with a 3rd party for delivery does not force you down the consultancy route. Think of the SME approach – dynamic, agile, best of breed skills to best of breed solutions.
Suppliers will thrive in this environment if they are allowed to part of the team and part of the journey. The relationship with suppliers must be sustainable and based on trust between both parties. Suppliers must be able to make a viable and sustainable profit and should run open book integrated into the IT accounts.
Remember: there is little point engaging with a supplier based on the lowest possible cost. Underbidding suppliers run the risk of attempting to make up the money with change control, delivering a valueless service, or withdrawing from the contract.
It may even be viable to export any existing delivery team via special purpose vehicle (SPV) to allow them to work more dynamically, realistically with efficiency and energy.
Moving to an SPV could also be a quick enterprise that moves money around the balance sheet and reduces the headcount numbers. An outsource may also achieve the same result, but costs will need to be carefully controlled and understood – change is often used as a source of profit in such enterprises.
Move away from bespoke code
Poorly executed Agile and similar methodologies often create swathes of poorly documented bespoke code. With projects being self funding the sustainability of the solution must include on-going run costs. Bespoke may be cheap to write, but it’s not cheap to maintain or support.
In the SPV model, the SPV is incentivised to pursue efficient, sustainable delivery models by owning the maintenance of the code and solutions. Inefficient, undocumented, or poorly designed solutions will be financially and materially expensive to support and maintain. The SPV will quickly have to become more efficient or loose contracts to 3rd parties.
The back catalogue of legacy and bespoke code created using agile or similar methodologies is likely to follow this SPV. A contract for maintenance and support must be provided and at a fixed, but sustainable cost. The risk owned by the SPV with clear incentive to reduce and remove the costly bespoke code elements.
Compensations drives behaviour
The move to SPV or outsource must have effective incentives for the staff and SPV. The business may need consistency for a number of years after the structural change or the business may require immediate cost savings, either way, the team moved into the SPV must be motivated to achieve these goals. The SPV route is a great way to move constrained exec’s out of the core and give them the flexibility to excel as a commercially driven arms length body.
What about general day-to-day change?
It would be fair to assume that in the everything-as-a-service model there is strong reliance upon the need for the contracts with 3rd parties to include the cost of maintenance and support change. These elements are needed to ensure that services are compliant with regulatory and security standards and to ensure that services can continue to interoperate.
The contractual obligations of 3rd parties should also be extended to allow the IT team to plan and organise change between the various solutions and 3rd parties. This is standard IT practice, but here the intelligent customer becomes more relevant. It requires a strong understanding of enterprise architecture, governance, the contractual commitments and a timetable of key business events and priorities.
Remember that purchasing on cost alone will fail in this model. Whilst this is not unique to this model, purchases do need to be made on value to the business and support the everything-as-a-service model. Excellence is required in supplier and contract life cycle.
Allow the business to change direction
Once in a while the business will need to change direction. To scale up or down. To create a new branch or brand; or to remove a few. IT should not constrain the business from doing what it needs to do. The contracts put in place with 3rd parties should be designed to allow the business high flexibility.
Services procured could be based on metrics key to the business: the number of products, staff or turnover. This variation of the standard usage model often applied by suppliers may require significant negotiation and contractual skills. Not all 3rd parties will be keen to work differently, so careful and pragmatic selection is required.
Key take away points
Change is embraced as part of the everything-as-a-service IT model through the use of 3rd parties that are incentivised to be more performant, flexible and cost efficient.
How to manage change in XaaS IT:
- Cost of change is given to the business to empower them to set priorities
- IT must not constrain the business from doing what it needs to do
- Use dynamic and agile 3rd parties for delivery
- Remove bespoke code by accounting for whole life cost of services
There is an opportunity to move existing delivery teams into a special purpose vehicle (SPV):
- Allow radical reduction in delivery headcount
- Allow constrained exec’s to flex their wings
- Facilitate cost reduction through the removal of bespoke code
- Facilitate competition with 3rd parties
Cloud First Strategy: Read the next article Part 3 – Moving from legacy support to supplier management go to the INDEX or go back to Part 1 – Impact on the IT organisation