Distinction between outcomes and deliverables
Experienced programme managers know that their change initiatives should be outcomes-based. Ideally framed around a balance scorecard, the outcomes define what will be in place when a change programme is completed. In many respects outcomes define a future state. Deliverables are the things – the artefacts – that need to be created by the change programme to create the target outcomes. Deliverables can come in a variety of forms such as documents, training, software and premises. If based upon a balanced scorecard, the target outcomes define a combination of customer behaviour, organisational capability (people and process) and financial performance. It should always be remembered that deliverables are a means to an end, not an end in themselves. Equally, the quality of the deliverables significantly influences whether the target outcomes are achieved.
Defining target outcomes involves making choices, and some of these choices may be strategic. For example, if a target outcome represented a significant change of state and the programme aimed at achieving this outcome fails and as a result damages the business, it could be argued that the choice of the target outcome was strategic. Strategic in that once the decision was made it was impossible (or at the very least extremely difficult) to unwind.
Point 1: Some target outcomes are strategic.
Shaping a programme to deliver the target outcomes
Change programmes are temporary organisations created to produce deliverables aimed at achieving target outcomes. In designing a programme the choice of deliverables is key since an outcome can be achieved through a variety of different deliverables. To make large programmes (involving many deliverables) more perceivable and manageable they are broken down into a number of smaller projects. The structuring of a programme – including the choice of external delivery partners – requires skill and judgement to ensure that all deliverables are produced on time and collectively form a coherent whole. Structuring a programme is a design activity that involves making choices, where some of the choices have significant influence on whether the target outcomes are achieved. It could therefore be argued that some programme design choices are strategic, in that once made they are impossible (or extremely costly) to unwind.
Point 2: Some decisions relating to the design of a programme are strategic.
Making business architecture decisions explicit
Early change programmes focused on automating existing manual ways of working. Subject-matter experts from the business were assigned to a programme in order to give their views on how existing processes and practices could be improved. Initially focused on improving the efficiency of individual business functions, and more latterly business processes, they rarely took an enterprise perspective. Essentially the underlying business model did not fundamentally change and the risks predominantly rested in the programme team’s ability to deliver the business requirements. As technology became more pervasive the installed technology base became more complex as programmes attempted to interface existing systems and create a more integrated enterprise. Later programmes attempted to address this issue through the use of integrated packages and, more recently, business platforms. Over time an architecture, predominantly a technology architecture, for the enterprise emerged, which subsequently defined the business’s ability to change.
But architecture is not restricted to the technology domain. For example, if a target people outcome was highly engaged staff feeling that they work for one organisation (following a recent merger) then the architectural decisions could cover such things as common terms and conditions of employment, and organisational design. If a target outcome was a culture where staff felt accountable, empowered and open, then the architectural decisions would be the defined givens, values and beliefs that guide behaviour. Some of these architectural decisions could be strategic in that if the wrong choice was made it would be difficult to unwind.
A further example of architectural decisions is in deciding how and where work is done. If the target outcome was significantly lower operating cost, then two possible architectural decisions in the ‘operating model’ domain could be to move to a shared services model and outsource to an off-shore provider. Irrespective of how well the programme to implement these decisions was undertaken it could be that a shared services model and/or off-shoring was fundamentally wrong due to the nature of work involved.
In all change programmes decisions are made that define the future architecture of the business. Some of these are explicit, many not. Some are strategic, most not.
As enterprises become more integrated there is an increasing need to make architectural decisions that impact the whole enterprise more explicit. Furthermore, it is often argued that ownership of the enterprise architecture should reside outside delivery programmes and be governed by an enterprise-wide forum.
Point 3: Architecture decisions are often embedded in change programme and, as a consequence, may lack an enterprise perspective.
Point 4: Some architectural design decisions are strategic.
Point 5: The purpose of a change programme is to implement business architectural decisions that achieve the target outcomes.
The key questions are whether the choices that are strategic are made explicit and managed accordingly, and whether the architecture of the enterprise is being managed appropriately.
I welcome your thoughts.
 Defined as being able to hold the whole (components and interconnections) in mind at the same time.↩