Effective Transformation Programme Design
A large multi-year, or multi-phase, transformation programme on an operating model needs to be carefully designed to ensure the capabilities come together in a complementary manner if the programme is to be a success. For a transformation programme across many operating model capabilities this can be a challenge because few staff may have an understanding of the big picture and may not have the technical expertise to engineer a new ‘to-be’ operating model.
For a transformation programme to proceed at pace there is the challenge of avoiding rework on requirements whilst at the same ensuring all the completed capabilities will operate as a cohesive whole. This page sets out a transformation programme can be organised logically to have the best chance of success.
Risks to maintaining programme momentum
An Agile project life-cycle can be significantly impacted by repeated revision to capability design requirements.
A transformation programme will have been funded and resourced for a set number of sprints. Rework will be factored in as Agile is an iterative process, but revisions beyond the rework allowance will result in reduced scope delivered, or under-engineered solutions.
The consequence if deployment proceeds is efficiency impact from workarounds and technical debt reducing the amount of capability which can be delivered in subsequent releases as the workaround are rectified.
A logical pathway through requirements is important to minimise rework and technical debt in a transformation programme.
Logical requirements sequencing
The logical pathway to minimise design rework and subsequent changes being made to completed work has three parts:
establish the holistic design guidance in the first stage of the project to sufficient detail that lower level design can continue within set parameters,
establish the distinct ‘modules’ in the operating model and specify the interfaces and outcomes from each module,
establish a logical path through the modules, which is most likely working from the incoming business object which is being processed through the modules.
This logic is easier said than done because it can result in capture of information if there is a deployed release which does not yet have the subsequent modules created to use it. This necessitates a release operating model and potentially backlogged services for later modules making use of the additional data which may already have been collected.
Note: ‘holistic’ means referencing ‘the whole’ - how all the parts relate to each other. It does not mean ‘summary level’. A holistic requirement may mean the logical schedule of work is a granular description of the operating model elements which relate to connection between the parts - one example being the data architecture. The data architecture is determined by the information which needs to be available to meet the operating model goals. The goals are met by use of ‘services’ which may access one or more capabilities. The logical order for design is likely to be goal - service - information - data - capability.
Effective modularisation
A modular system comprises a number of independent sub-systems (modules) which are designed to work together through their interfaces but are separately designed within their modules. The alternative approach is an integral design where all the parts are highly interwoven and inter-dependent.
The challenge with an integral design is that a change to one component often requires changes to other components which adds to time and cost of change. In contrast, a modular design allows faster change within the modules, but requires that the interfaces between the modules are carefully designed to allow this otherwise the resulting system will still have integral design characteristics.
As operating models are made up of inter-related capabilities the basis for modularization exists at capability level. The boundaries of a module are determined by the breaking down the capability sub-systems such that the break is ‘clean’, e.g., there are no activities or other elements at a lower level which are not completely within the capability, or should be part of another capability.
The key capability elements to consider in modularisation is that after the action which defines the capability is complete there is a business object which has a status of ‘complete’. The lowest level of modularisation is a single act capability where the resulting business object is complete and meets the purpose of its stakeholders. Multi-act capabilities add internal hand-off elements between actions but still result in a business object which must have a status of ‘complete’.
Maintaining design cohesiveness
Maintaining alignment to the holistic operating model design - from a summary level down to granular level - is an important role in a large scale or phased transformation programme. Depending on the nature of the transformation practices are typically either to assign the responsibility to a Transformation Office or to the Business Architect. Whoever has that responsibility needs to be ensuring that the stakeholders are involved through the process and manage the inevitable conflicts and compromises, and obtaining signoff from the respective governance committees and accountable executive.