0 UTSOURCING

Developing business-led

or the past few years it has been hard to pick up some IT trade journals F without seeing an article dedicated to

outsourcing. In its early days, outsourcing was often represented as the panacea for all of the problems that beset IT projects. Budget overruns, late delivery, poor performance-all of these and more could be avoided by letting an IT supplier provide the whole package for a regular, fixed service charge.

Many first-generation outsourcing projects are now reaching maturity. It is clear that, while outsourcing has potential benefits, many companies which have outsourced their IT have not seen these potential benefits fully realised. Even where projects have been technically successful, the business benefits that were hoped for have often failed to materialise. A recent survey by PA Consulting Group':' suggests that only 5% of companies questioned

'"Strategic Sourcing 1996', PA Consulting Group, 123 Buckingham Palace Road, London SWlW 9SR

ENGINEERING MANAGEMENT JOURNAL

If outsourcing; is to achieve its future potengal, it is the benefits actually delivered that must serve as the measure of success and the basis for payment.

by Nick Thornton

were getting full benefit from their outsourced IT without experiencing one or more of the problems that outsourcing was meant to avoid.

The reason for this may lie in the contracts which are used to define and control out- sourced IT projects. Outsourcing contracts can concentrate too closely on the technology-to the detriment of the real objective of the project which is to deliver some business benefit to the organisation. At best, this makes the service difficult to manage; at worst, it can mean being locked into a contract that will never achieve meaningful benefits. This article sets out a method by which the business benefit, rather than the technology, can be made the focus of the project and its governing contract.

Contract for business benefits, not for system characteristics

Outsourcing goes under several names: facilities management, service contracting or, in the public sector, the public finance initiative. Each of these has its own nuances, but they are

FEBRUARY 1997 21

OUTSOURCING

all essentially similar-means by which the financial and technical risks of providing a service are transferred outside of the organisation that will use it. In many cases the service provider takes on existing systems, facilities and staff and agrees to maintain a certain level of service. In others, where a new system or service is required, the service provider also makes the initial investment in design and development, and then recoups these costs through a service charge payable over the life of the system. Although we are here concerned with IT services, the principle is being applied to services as diverse as park maintenance and prisons.

One of the common characteristics of all forms of

once initial approval has been obtained. Even if the benefits being sought are recorded in the project’s terms of reference, they are often translated into functions and procedures far too early in the specification process. This means that the project is pstzfied on the basis of the business benefits that it is to deliver, but is then specified and manuged in terms of the functions and procedures envisaged by the user. Once implementation is underway, it is the functions and procedures that are tested, and the business benefits are left to follow as they may.

To enable an outsourcing project to deliver the benefits that are used to justify it, each of the

project documents, from the statement of reauirements

outsourcing is that the organisation requiring the service specifies the service level needed, rather than the equipment used to provide it. Specifying ithe nature and quantity of the equipment, and the associated risk of getting it wrong, is the responsibility of the service provider.

Most existing outsourced services are largely deter- ministic-thar. is, for each set of inputs, there is a defined set of urocesses and

The initiation of most outsourcing projects, indeed most IT projects,

depends on whether a

convincing business case can

be made I

a predictable result. Service levels are specified as a number of simple parameters: number of trans- actions, availability, response time etc. For such services, the transaction records of the delivery system can provide an adequate means of service management. In the future, however, outsourced services are likely to be far less deterministic. Where the productivity or accuracy of a transaction cap be indeterminate at the time the transaction takes place, the value of transaction accounting is questionable. Because of this, it is the target benefits set out in the business case, and not a set of low-level technical parameters, that should be used as a basis for service contracts.

Use the business case throughout the project The initiation of most outsourcing projects,

indeed most IT projects, depends on whether a convincing business case can be made. All too often, however, the achievement of the business benefits that justified the project are ignored

to the service reports, needs to be derived from the business case. The earlier in the procurement cycle that this planned flow-down begins, the more productive it is likely to prove.

If prospective service providers will not contract to collaborative delivery of the benefits sought then the probability of achieving those benefits must be questioned. If such a commitment cannot be obtained during the competitive phase of a tender, it is unlikely to be

forthcoming once the contract has been awarded. Putting more of the responsibility for delivering the target benefits onto the service provider can reveal problems while there is still an opportunity to address them.

Writing the business benefits to be delivered into the contract also encourages proper consideration of how to divide responsibilities between service provider and service user. This division may be straightforward in contracts where the service provider takes on an existing system or department, but is less so where the service user retains an influence on the effectiveness of the service (where operators remain in the employ of the purchaser, for example). In such cases, there may be a legitimate reluctance on the part of the service provider to enter a contract that specifies the benefits to be delivered. However, with proper decoupling of responsibilities, this reluctance should be surmountable.

22 ENGINEERING MANAGEMENT JOURNAL FEBRUARY 1997

0 UTSO URCING

Make the contract productive, not prescriptive

One of the characteristics of outsourcing projects is the increased involvement of an organisation’s contract department. This should be seen as an opportunity rather than an overhead. By increasing the cross-over between contract and technical skills it is possible to generate contracts that are productive instead of just prescriptive. While this may be of marginal benefit in supply contracts, it is vital in service contracts where the service-level management and compensation provisions of the contract are in day-to-day use over the life of the service. A number of simple measures can be taken to encourage the formu- lation of productive, busi- ness-led contracts.

Use project specific contracts for greater flexibility

The deliberate use of multi-disciplinary contract development teams can prevent the translation from business benefits to func- tions and processes occurring too early. It also avoids reliance on vague ‘strategic alliance’ agree- ments which can prove difficult to quantify and enforce. An integrated, project-based approach also

Link payments to high-level benefits, not to low-level transactions

The nature of IT systems often militates against direct measurement of high-level benefits. Engineers often feel more comfortable dealing in ‘hard’ system parameters (such as availability, transaction numbers and response times) than in more conceptual factors such as business benefits (even when these can be expressed quantitatively). Similarly, many systems are more suited to recording low-level events (such as the number of transactions processed over time) or measuring basic statistical parameters (such as availability). However, these low-level factors can have

By increasing the cross-over

between contract and technical skills

it is possible to generate contracts that are productive,

prescriptive not just

encourages re-examination of the ‘boiler-plate’ clauses that are often used by default, and which can be hopelessly inappropriate to outsourced services.

Find the parameters that drive the target benefits

A substantial part of any service contract is concerned with specification of the parameters to be used in assessing perfor- mance. Often there are conflicting objectives in selecting such parameters. In general terms, the service provider’s interests lie in specifying low-level parameters, whereas the service user’s interests lie in specifying and managing high-level parameters. For most non-trivial services, the objective of the service user should be to specify the service parameters as close to the business case parameters as is practical.

little significant influence on whether a service achieves its target benefits.

This disparity becomes more apparent as services become less deterministic, particularly where the value or productivity of a transaction is not known at the time the transaction takes place. In such services, there can be a complete mismatch between low- level system parameters and the factors that determine the benefits achieved.

Maintain independent verification

A good rule of thumb in U

avoiding a disparity between benefits and payments is to ensure that performance parameters are taken from the user’s business domain (and terminology) and not the supplier’s. This implies that the means of measuring the performance of a service, or at least of verifying it, should be outside of the service itself. If this seems an unnecessary complication, consider the problem of measur- ing performance if the service provider can’t (or won’t) provide the required data.

A recent application of these principles is illustrated in Fig. 1. This shows the different levels of parameter found in an automatic fingerprint identification service. To reflect the business benefits sought, the principal performance parameter needed to be defined in terms of the number of fingerprints processed through a defined set of functions each day, at a specified level of accuracy and with a specified level of administration support-in other

ENGINEERING MANAGEMENT JOURNAL FEBRUARY 1997 23

0 UTSO URCING

strategy

Fig. 1 High-level parameters benefit service users

objective

business led I user’s business

user’s objective

function led supplier’s business domain

words, the serviceability of the overall business system.

In this example, if a fingerprint search did not result in an identification, it could have been because there was no corresponding fingerprint in the database, or because of a fault in the system. There were no practical means of establishing this from the transaction account- ing records or the availability figures for the system components. Had the contract been specified in terms of low-level parameters (such as availability and transaction numbers) the service user would have risked paying for a service that was not performing any useful work.

From the service provider’s position, it is often far more attractive to track lower-level parameters such as availability and database accesses than accuracy and hit rates. This isolates the service provider from the less deterministic aspects of the service and ensures that the service charges are payable even if the transactions themselves are of no value to the user.

Similar conditions to those found in the fingerprint system can arise in any service where the value of individual transactions to the end user is unknown at the time of processing. Such services include data trend analysis, data mining, biometric identification, forensic analysis and signature recognition. In all of these services, there may be no link between the number of transactions processed and the business benefits delivered.

Set a range of penalties for a range of problems

Of course, choosing the parameters is only half the story. Once a suitable set of targets has been selected, the penalties that will apply if

these are not met need to be specified. For once, the old adage of ‘speak softly and carry a big stick‘ is not sufficient-for effective manage- ment, a mixed bag of big sticks and little sticks is essential. Several years’ experience of defining these mixed bags has yielded the following lessons:

0 Very punitive penalties can prove unwieldy in use: While huge penalties can look attractive to a purchaser anxious to get the maximum protection from poor service, they can prove unwieldy in use. If penalties are too severe, the supplier can become confident that they will not be applied. In such cases, the likely outcome is the use of ad hoc waivers to the contract terms. While superficially effective, using such waivers is fraught with danger.

0 Penalties must address the ‘balance of power’: The outsourcing of any non-trivial service introduces some dependence on the service provider. If problems arise, this dependence can be used by the service provider as a defence against penalties. To address this problem the contract provisions for non-performance should include measures that would ease the transfer to an alternative service provider (or, where it is more appropriate, a return to in-house provision). These ‘enabling actions’ could include, for example, the translation of the user’s data into non-proprietary form.

0 Smaller penalties provide scope for quick response: When specifying the small sticks, there are two factors that should be considered: -it is unlikely that all minor problems will

-any service shorftall needs to be addressed be foreseen

24 ENGINEERING MANAGEMENT JOURNAL FEBRUARY 1997

0 UTSO URCING

implementation review

function led

business opportunity

business case c

business benefits

business led

promptly to avoid claims that the user is affirming acceptance of the poor service through continued use.

Both these points can be addressed by including a default service charge credit that is applied unless waived by the service user. This discretionary percentage should be clearly designated as being for ‘user satis- faction’ and not subject to appeal by the service provider.

project life cycle, the business case is shelved once the project has been approved. The reauirement analvsis is then based on

Fig. 2 Business case flow- ~ ~ ~ ~ i ~ ~ l i v e r s business

functional decomposition, and results in a functionally-oriented (or procedural) require- ment specification. This neglects the nonlinear way in which value is added to the product or service produced by the service user.

Analysis methods which focus entirely on function direct the majority of the effort to the most complex function, irrespective of whether

Define the project by business stream, not by function

Successful business-led outsourcing depends on expressing the business case objectives in each phase of the project. In the traditional

ENGINEERING MANAGEMENT JOURNAL FEBRUARY 1997

that is also the function that adds most value. Once this die has been cast, the focus of the contract, the acceptance tests and the payment and penalty scheme is inexorably drawn in the same direction. The contrast between this

25

OUTSOURCING

function-led approach and the business-led approach is illustrated in Fig. 2 (which, for the sake of clarity, omits the rework cycle).

Identzfy the functions thut add real value In the business-led approach, the business

case is prepared as usual but, once it has been approved, the benefits described are extracted and expanded into a statement of target benefits. Each of the target benefits is then decomposed by business stream rather than by function.:+ The emphasis during this task is on how the target benefits can best be achieved, not on how the existing functions and procedures can be automated. The result is a requirement specification whose structure and content emphasise the areas of the service that will generate most value to the organisation using it. The business streams are then further decomposed so that the contribution value of each business stream element to the overall target benefit can be estimated.

Evaluute and munage according to contribution value

The estimated contribution values are sent out to prospective service providers, along with the service-level requirement and the specifica- tion generated from the decomposition of the business streams. At this point, prospective service providers have all they need to assess how best to provide the benefits being sought by the purchaser, without being subject to unnecessary technical constraints.

The resulting proposals are evaluated using the contribution values as a guide to attributing priorities to each different aspect. If performed correctly, this ensures that the greatest priority is given to the factors that contribute most to the target benefits.

The contribution values are also used in the contract as the basis for the payment and penalty scheme. Penalties for poor performance are derived from these values to provide a direct link between poor performance and lost benefits. Any statutory obligations (such as data protection compliance) are kept separate from these, however, and are enforced by the appropriate legislation.

‘cTo illustrate the distinction with a very simple example, the functions of an insurance company could include logging of customer requests, preparation of quotations and payment of claims, but the highest level business streams could be property, car and life insurance.

Vulidute the benefits, don’t just ve$y the service

The service specification and the service contract should also specify a pilot business stream. The early milestones should include the testing of a vertical slice through one of the business streams of the overall service. This is used to validate the proposed service against the statement of target benefits, instead of merely verifying a set of functions and procedures. If done rigorously (and this means from a sound contractual basis), it provides an early indica- tion of whether the business case will be met- as opposed to whether the system will work.

A number of advantages arise from the early delivery and assessment of benefits:

If all is well, at least some of the benefits come on stream early in the implementation period. Any minor changes required are likely to be easier and cheaper to implement if they are identified early.

*Valuable feedback from the users can be gained from an end-to-end prototype. This feedback can then be applied to the other business streams. If all is not well, difficult choices (up to and including replacing the service provider) can be made before the whole service is transferred.

Conclusion Traditional methods of defining and

managing systems through low-level para- meters and functions must be adapted when they are applied to outsourced services. As services become less deterministic these methods need to identify the aspects of the service that deliver most value.

Service providers need more opportunity to add value to the services being offered. Service users need management tools that link pay- ments to the business benefits achieved. Both of these needs can be satisfied by using multi- disciplinary contract teams capable of defining service level agreements that are productive and not just proscriptive.

Once a business-led outsourcing contract is in place, the progress of the implementation project and the success of the service can be judged against the benefits actually delivered. If outsourcing is to achieve its future potential it is these benefits that must serve as the measure of success and the basis for payment. 0 IEE: 1997 Nick Thornton is a Managing Consultant with PA Consulting Group and canbe contacted on0171-730 9000.

26 ENGINEERING MANAGEMENT JOURNAL FEBRUARY 1997