Disappointing results and failure to meet expectations are too often the outcome of ambitious business transformations. There are no silver bullets that guarantee that a programme will not go pear shaped but there are methods and techniques that can be applied when a business needs to move fast and the price of failure is high. This executive briefing looks at key issues that management might face in a business transformation that deploys well-established technologies to introduce a significant improvement in performance spanning multiple locations. The techniques and approaches described here are not merely theoretical speculations but real life strategies that are tried and proven.

Why Business Transformation is Different

Ambitious results can rarely, if ever, be delivered by means of new IT alone, however important technology can be as an enabler. This is because organisations are made up of people who are more complex than the machines that form one part of the total system. Business transformation therefore depends on orchestrating the various means available and focusing effort on critical issues. It is true that there are well established, engineering like disciplines that are sometimes applied to "IT" projects. In contrast the tasks of influencing behaviour, designing reward systems, modifying management processes and organisation structure are less susceptible to engineering rigour. This will be evident in every manager's experience, in that it would be unusual to find investment analysis, formal project management discipline or benefits measurement regimes that are expected for "IT projects" applied to a new performance appraisal system, a management restructuring, new job descriptions, or changes to staff skills. Yet these elements can be more significant in terms of either resources expended or strategic impact. A business transformation presumes a holistic approach that may deploy software as a vehicle for the effective orchestration of these components. This is not to say that an organisation should abandon disciplined approaches which might be characteristic of a traditional IT project. Rather the organisation must apply mature business judgement and all the combined management experience it can muster. These aspects do not naturally lend themselves to precisely definable timetables and planning -the imponderables of people's reactions are too complex and unpredictable to neatly fit an engineer's discipline. Management and control must be achieved by more subtle means. But, only by orchestrating all aspects in this way can success be made possible. For example, a business must have great sales management software, appoint and motivate people who have talent for winning new clients, establish a reward and recognition system which reinforces their effort and establish an organisational structure which releases them to pursue new clients without distraction to improve sales performance. If any of these factors is missing the effectiveness of the change will be in doubt. A business transformation budget will therefore be likely to include substantial sums for expert resources required to support the business in redesign of key processes, organisational structure and job definitions etc. That is not to usurp general management's territory but to bring to these aspects similar structure and rigour to that expected in "IT" projects and to promote sufficient coherence to seize the prizes.

Capability to Undertake a Business Transformation Programme

The second critical point to bear in mind is that, most organisations are focused on day to day operations and simply do not have in house dedicated experience of straightforward application development, let alone holistic, large-scale business transformation. This is almost certain to sound alarm bells in the mind of the reader. Let me then immediately qualify the point by adding that all parts of a business have much to learn and that the best way to learn is by setting out on the journey in a controlled and cautious way. To bring this down to earth a pilot provides the ideal device to allow the organisation to see tangibly what kinds of possibilities software or changes in structure might open up (for example the possibilities for workflow or the use of screen and report writer tools). It simultaneously allows the technical people to acquire the skills needed to support the systems, begins to clarify what is needed to redesign business processes and teaches the change team important lessons about matters as diverse as data migration, training, version control, communications and programme management. Equally it provides management with experience of the formal roles and reporting regimes appropriate in a programme management environment, makes transparent the need for business leadership of the design task and drives home what it means to be a sponsor. This organisational learning is not something that should cause embarrassment, quite the opposite, it is the most effective means for developing competencies which can then be scaled up.

Frameworks, Methods, Techniques

These factors need to be recognised up front and inform the programme definition, risk management plan and planning. Well established, industry best practice techniques are can be used to guide all these aspects of programme management (e.g. the public domain PRINCE methodologies). However most available materials have a strong IT bias and largely neglect the other aspects of a business transformation. To supplement this other materials should also be consulted. (For example  Process Innovation, Tom Davenport, HBR Press and Managing at the Speed of Change, Daryl Conner, Wiley).

Whatever guidance is used the programme management task is often perilously underestimated. A rule of thumb which has been proven in the field, organises the work into linked projects each of which has a full time project manager reporting to the (full-time) programme manager. The size of each project must be small enough to be manageable itself. Factors such as the complexity of the work, previous experience and the skills of the project manager are all relevant but any project that requires more than six people on the team or runs more than three months will be a candidate for reduction into simpler projects. If you are not willing to resource the work in this way aim for a less ambitious timetable or prepare to fail.

Implementation Waves

The term "implementation waves" is used by some consultancies to describe something akin to what, in the public domain, has been known as (within the IT industry) an evolutionary approach. A business transformation will draw on IT methodologies with caution since these generally do not give sufficient attention to the behavioural and business process design tasks which are more challenging than the software design. Nonetheless the rationale underpinning the evolutionary model applies. The evolutionary model delivers at each stage an operational quality deliverable satisfying a subset of requirements. The order of delivery is determined by the value to the business of what is delivered. This approach is very well established and can be traced back to the 1980s in the context of IT. Business process redesign first became widely known in the early 1990s, which is when evolutionary methods were extended to process innovation.

Following an evolutionary approach, implementation of new software, business processes, organisational structures, jobs, reward and recognition systems and management processes are progressively built up to move toward the vision already articulated. Pragmatically the sequence in which this runs will depend on the value assigned to each piece of work and any natural dependencies (for example you cannot introduce new management or individual performance appraisal regimes without the management information systems to track the achievement of redesigned targets). A critical business input is therefore judgement regarding the ranking of propositions for the way in which the business transformation is taken forward framed in terms of the value expected from each proposal. This will be akin in format to a high-level prioritisation exercise. These proposals take business transformation forward through work on redesign of key business processes, behavioural levers (performance appraisals and job definitions) and organisational structure. To think of the evolution principally in terms of extending system functionality would be to misunderstand the essential nature of a business transformation programme.

Finally, it is worth pointing out that an evolutionary approach provides more opportunities to check that the progress and benefits can be made as anticipated and is therefore a safer investment strategy than a single big hit. In practice it is much safer, the business world is littered with grandiose schemes that failed and most organisations will have examples of this.

Change Management

In selecting methods and approaches attention is not often given to the human factors that underpin successful change. This is now pretty much universally accepted best practice and a body of techniques and frameworks have been assembled for this purpose. In regard to business transformations the vital need to embrace this aspect is self-evident in that such a programme typically:

• crosses multiple locations or departments where there may be no history of co-operation on this scale
• spans multiple functions again perhaps without established precedent
  
• demands active commitment (hearts and minds) for success not passive acceptance
• in a knowledge worker context, will affect an organisation in which very many individuals have the power to openly or covertly oppose and derail a change they do not subscribe to
• proposes to radically alter organisational structures and jobs thus affecting individuals profoundly and provoking resistance (which must be recognised as natural and appropriate)

• devoting attention to establishing vigorous, sustained and effective sponsorship at a level which brings together the functions and locations. (This requires working to develop a shared commitment by all the cascading sponsors).
• Promoting the cascade of sponsorship so that it is not merely assented to but internalised by sponsors, their reports and onward. (This of course presupposes that right sponsorship structure is created).
  mobilising change advocates
• stimulating coherent communications that reinforce sponsorship (e.g. road shows, newsletters, appointment of a communications manager)
  stimulating dissatisfaction with the status quo sufficient to rule it out as an option for the future
• encouraging evocation of a future which has the desirability to sustain people through the trauma of the change
• engendering extensive and widespread participation

Some Key Techniques

Some of the key techniques that may not be familiar to an organisation but which will be potentially vital to a business transformation include:

Benchmarking

The immense value of benchmarking is not to be underestimated. It provides a powerful mechanism that:

• introduces a disciplined and structured approach
• identifies the aspects of the business that require change
• develops insights into the nature of the change required
• gives a means of attaching a scale to the expected improvement
• demonstrates the legitimacy and viability of the change
• provides a structure for involvement and harnessing of internal knowledge and experience

Timeboxing

Timeboxing is a vital tool to maintain progress and focus for the work although it can cause considerable misunderstandings for individuals who have not been exposed to current software development techniques. (Timeboxing is not limited to software development but resistance is more likely form people who have had experience of earlier generations of software development methodologies). The technique deals with the overarching need to maintain a schedule and deliver on time, realistically recognising that a trade off exists between functionality and speed of delivery. It is more realistic than previous approaches that assume that design is wholly known in advance (see above). It provides a discipline for retaining control of the development process by rescheduling work in a planned way as appropriate recognising an 80/20 lore applies in development as elsewhere.

Rapid Application Development ("RAD")

Although many business transformations rely on implementing packaged software these increasingly include what can be thought of as akin to a simple (so-called 4th generation) development environment. Deploying RAD style techniques in the "development" or customisation of the package is a major advance on earlier development approaches and allows delivery in shorter time scales and to higher quality. The approach depends on assembling a joint team of technical and user personnel who employ prototyping as a means for improving communication, enhancing design and exploring the potential. It must however be employed in a disciplined way to prevent degeneration into slipshod work, inadequate design and poor programming. The prototype is a communications device that must go no to be replaced by a robustly constructed live application subject to all the usual quality control steps. Strict discipline must also be maintained to avert the risk of scope creep that is particularly prominent in this technique.