How to Determine Whether There is a Business Case for Transformation / BPO

This paper lays out?an effective and efficient process for deciding whether a proposed transformation and/or Business Process Outsourcing (BPO) initiative makes sense or not.

Over the years, I have helped a long list of organisations to run “rapid but robust” feasibility studies to discover whether there is a business case for transformation/BPO initiatives. I reckon I have run about 30 such projects in all, and in the course of so doing I have developed a set of tried and trusted approaches which now constitute a powerful methodology. I own the intellectual property but I am happy to share it for the benefit of clients, suppliers and intermediaries in the transformation/BPO industry.

In the pages that follow I introduce the main approaches?and the main supporting tools. Then, to bring all the conceptual stuff to life, I describe the key mistakes that I have seen organisations make in this area - all of which can be avoided by following the approaches I recommend.

The contents of the paper are as follows:

• The relationship between transformation and BPO
• The high-level business case and where it sits in the overall “route map” for a transformation?BPO programme
• The basic business case “equation”
• Systematic approach for ascertaining whether there is a business case
• Checklist for assessing current operations
• Checklist for envisioning the “blueprint” for the future state
• Structure of the financial model
• How to run a feasibility study
• The key pitfalls to avoid

The relationship between transformation?and BPO

Let’s take a quick look at these two concepts, which often get a bit mixed up. The definitions of and relationship between the two are shown in the graphic below:

?I have used this diagram in several other papers so I won’t dwell too long here. In short “outsourcing” is commercial change – a transfer of contractual responsibility from client to supplier for delivering a certain scope of work, whereas “transformation” is operational change – new processes, technologies, locations, etc. Often the two are combined in some way but the methodology described in this paper is equally applicable whether transformation with or without outsourcing is being contemplated. Or even outsourcing without any transformation at all - but that’s pretty rare.

I will not comment here on the generic pros and cons of “in-house transformation” versus “outsourced transformation” because to do so would distract from our main purpose, and, as it happens, I have a separate paper that focuses squarely on this subject: https://www.dhirubhai.net/pulse/in-house-outsourced-transformation-which-best-howard-spode/.

The high-level business case and where it sits in the overall “route map” for a transformation/BPO programme

As I have already alluded to, the ethos for an initial investigation into the feasibility of a specific BPO/transformation proposition is “rapid but robust”:

• “Rapid” in that the answer is got to quickly and with the costs of the investigation controlled
• “Robust” in that the final recommendation can bear the weight of review by relevant stakeholders and thus provide a platform for a go/no-go decision on the next stage - which will very likely involve some significant spend.

So, in the first phase of a potential transformation/BPO programme, we are talking about the development of a high-level business case. And its purpose is to evaluate - there may be a hope or even an expectation that a positive case will be established, but there should be no assumption of this.

Where this high-level business case or feasibility study fits into a typical “route map” for a BPO/transformation programme is shown (in red) below:

If the proposition being reviewed is found to be feasible and a “go” decision is made to continue with the programme, the business case will become more detailed - so for example, the “assessment of current operations”, which is one of the components I shall describe below, will evolve into some sort of “due diligence”, and the “blueprint for the future state” (another component), will evolve into a “detailed solution design”.

The purpose of the business case will evolve too. It will continue to be an evaluation tool until the point where a final commitment is made to implement the to-be model (for example when a contract is signed with a BPO supplier). Its purpose will then become one of justification - i.e. justifying to key stakeholders why the course of action in question is being followed. And eventually, when the to-be model has been implemented, the business case will become a mechanism for benefits realisation – “are we achieving what we originally said we wanted to achieve?”.

The basic business case equation

There is a fundamental “equation” at the heart of every business case. This examines whether the positive aspects (“benefits”) of a proposed change outweigh the negative aspects (“challenges”) to the extent that there is a “net prize” of sufficient magnitude to justify the change, compared to other possible courses of action and to the ever-present “do nothing” option:

The generic benefits (green) of transformation/BPO are:

• Cost – reduction, increased visibility, fixed versus variable
• Quality – improvement, consistency, increased visibility
• Mitigation of existing risk – e.g. of loss of key skills in small teams
• Focus – i.e. increased attention by key staff on high-value activities
• Other – e.g. organisational flexibility.

The tangibility of these benefits (as defined by the ability to quantify them) decreases from the centre of the green concentric circles outwards, but this does not mean that their importance necessarily decreases.

Moving on to the challenges (red), these fall into two categories:

• Downsides – these are negative things that will happen – e.g. investment, people displacement
• Risks – negative things that might happen – e.g. implementation overrun, service delivery failure, change resistance.

My use of terms such as “equation” and “net” may imply that the focus is solely on financials but this is just shorthand. As we have seen, “cost” is only one of the potential benefits and a good business case should be holistic in that it at least considers both financial and non-financial factors even in the cases where cost is the dominant factor. I return to this theme later when talking of the key pitfalls to avoid.

Systematic approach for establishing if there is a business case

As mentioned, over my years in the industry I have developed a systematic approach that allows the business case “equation” to be “solved” effectively and efficiently. Graphically, it can be represented as follows:

It looks a bit complicated but basically it:?

• Compares the “as-is” situation - large grey box on left
• With the proposed “to-be” model - large grey box on the right
• In order to ascertain whether there is a business case - the “conclusions” small grey box in the lower middle
• And if there is a business case, the way forward is mapped out, in terms of the programme “route map” - blue arrow at bottom (of which we have already seen an example).

There are 12 steps in all, each of which can be seen in the graphic. The steps are:

1. Reflect “Top-Level Strategy”. Ultimately, all proposed organisational change should be evaluated in the light of the organisation’s mission, vision, values and strategic objectives.
2. Reflect “Functional Strategy” – ie the strategy of the Finance function, the HR function, the Customer Services function, etc. If there is such a strategy. If not, the key principles should be drafted out as part of the business case development process.
3. Reflect the organisation’s “Sourcing Strategy” – the high-level principles, policies and parameters for sourcing across the organisation. If there is one.
4. Assess “Current Operations”. Once strategic context is clear, a critical assessment of the effectiveness and efficiency of current operations needs to be undertaken.
5. Specify the “Need for Change”. This is not the proposed solution at this stage, but a statement of the criteria and parameters that “possible futures” will have to adhere to.
6. Undertake a “Review of the External World”. What are the key market trends, what are the best practices, what are other organisations doing, who are the potential suppliers and what are their competences and ways of working? etc.
7. Envision the to-be “Operational Model” - “how would the service work?”
8. Envision the to-be “Commercial Model” - “who would be responsible for what?”
9. Envision the “Transition Approach” – “how would we move from the as-is to the to-be?” Together, the Operational Model, the Commercial Model and the Transition Approach constitute the “blueprint” for the future state, which I explain below.
10. Identify the “Risks” associated with moving to the to-be model and develop appropriate risk management actions.
11. Draw the “Conclusions” by comparing as-is with to-be in order to determine whether there is a business case. The conclusions would include a financial model, but, as mentioned, they should be holistic.
12. If there is a positive case for change, lay out the “Route Map” for the selected option - “how would we make it all happen?”

As well as providing the basis for a systematic approach that will result in a rapid but robust evaluation of the business case, this methodology has the added advantages that it provides a natural structure for:

• The project plan for a feasibility study - ie by pretty-much following the above 12 steps in chronological order.
• The final report to governance - ie by structuring that document around the 12 steps.

Checklist for assessing current operations

The “Assess Current Operations” phase is one where it is very easy to get the “rapid but robust” balance wrong. I use the approach below to shape the investigation and structure the write-up:

• “What?” What services are provided? A list
• “Why?” This list can then be cross-checked against the top-level and functional strategies to test the rationale for the existence of the services – maybe some of them should not feature in the to-be model, maybe new services should be developed
• “How?” How are the services provided, in terms of:?Process, Technology, People, Organisation and Infrastructure
• “How many?” What are the key volumetrics?
• “How well?” What are the key performance metrics – both in terms of efficiency and effectiveness (i.e. quality)?
• “How much?” What are the costs?

To this list, which focuses squarely on the “as-is”, is also added a look ahead to the likely ramifications of change:

• “When?” When change comes (if it comes), what will be the barriers and facilitators?

As for actually collecting the data, a variety of mechanisms are available. For example, paper- or web-based questionnaires, structured interviews, focus groups, etc.

A good as-is analysis encompasses “facts”, “interpretations” and “opinions”:

• The foundation of the analysis is the hard data collected – the facts
• These facts are then interpreted in various ways - for example by calculating key metrics and comparing these for different parts of the organisation (internal benchmarking) or against industry norms (external benchmarking) to identify hypothetical savings potential
• Ultimately the analysis culminates with opinions - ie conclusions about the overall state of the as-is, which flow to the next step of the methodology, which is the clear statement of the “Need for Change”.

Checklist for envisioning the “blueprint” for the future state

The Operating Model, Commercial Model and Transition Approach as introduced above together constitute the proposition that is being evaluated – or the “blueprint" for the future state.

I like to use the word “blueprint” because it reinforces the fact that not every detail will be in place at this stage, but that there will be enough clarity to compare the to-be with the as-is in a manner that is robust enough to support proper decision-making.

Here is a checklist of all the key sub-components. If each of these is considered it will guarantee that the blueprint is robust enough:?

The financial model

I will be brief on this subject because I have published a separate paper that explains financial modelling in detail: https://www.dhirubhai.net/pulse/how-develop-robust-financial-models-support-bpo-howard-spode/

A financial model of some sort is always going to form part of the conclusions, and its main components will be as follows:

• The baseline - the relevant costs of the as-is situation projected for the life of the model (at least 5 years is usual)
• The to-be operating costs – ie costs of running the to-be operational model projected over the same period as the baseline
• Investment – the costs of the transition approach, people displacement and any other one-off costs (eg retention bonuses, write-offs of defunct licences, etc)
• Investment appraisal – the financial appraisal of whether “to-be plus investment” is better than the “as-is”. There are various investment appraisal methods – for example: overall savings, payback period, Net Present Value (NPV), Internal Rate of Return (IRR).

Here is an example of a financial model:

How to run a feasibility study

Like any initiative that is worth doing, a feasibility study should be managed as a formal project. The environment does not have to be overly burdensome, but should feature:

• A simple but clear project charter.
• A dedicated project team, with members focusing on: subject mater expertise in the functions under review, technology, financial modelling, legal etc.
• Suitably competent external resource to advise the team and/or run the project (only if necessary, but usually it is necessary).
• A governance body to represent the appropriate stakeholders, oversee the project and decide on the final recommendation.
• A project plan – “what, when, who” for the whole of the project.
• A project management regime – ie mechanisms and routines for managing progress, resolving issues, reporting to governance, etc.

Here is an example of a project plan for a feasibility study. It can be seen how the plan follows the methodology:

Key pitfalls to avoid

To conclude, here is the “top ten” of mistakes I have seen organisations make when considering whether to launch a BPO/transformation proposition. I guess that most readers will have experienced at least some of these situations themselves. And hopefully it will be obvious how adopting the approach I have outlined above will ensure that these pitfalls are avoided.

Starting a transformation/BPO initiative without a clear business case

Believe it or not, I have seen sizeable transformation/BPO initiatives launched in the complete absence of what I would deem a compelling business case. A half-page Excel that isn’t even formatted properly, some rough savings projections, the as-is metrics (e.g. numbers of people currently employed) hopelessly inaccurate which rendered the to-be numbers meaningless anyway, non-cost benefits not considered with any rigour – just some vague spin about “making ourselves world-class”. Basically then, a “suck it and see” approach. Not a particularly wise way of working.

Keeping the business case secret

In some cases I have experienced the business case being kept secret for the duration of the programme – only seen by a small inner circle of client and supplier executives. Perhaps some of the detailed financials may be commercially sensitive, but to keep the key principles hidden from the people affected removes the possibility for the business case to be used as a powerful justification tool as described above. Without proper justification, change resistance can flourish – for example, when the inevitable teething problems are encountered even in the best-run programmes, rumours such as: “this is terrible and it’s probably costing us more money than it was before” are likely to abound. Readers might want to take a look at my paper on how to get Change Management (OCM) right in BPO/transformation programmes – especially the section entitled “Don’t Patronise”, which gives an example of how in one programme it was decided not to communicate that cost savings were a key driver for the change because this was “not a good message”: https://www.dhirubhai.net/pulse/getting-ocm-domain-right-bpo-projects-howard-spode/

Insufficient strategic context

Ideally both Sourcing Strategy and Functional Strategy will be in place to provide the link between Top-Level Strategy and the business case for a particular sourcing proposition. However, this is often not the case.

The absence of Sourcing Strategy can be understandable because the need for it might not be obvious before an organisation has contemplated or even implemented a few specific sourcing initiatives. But once an organisation has done this, it makes sense to develop a set of principles to guide future sourcing decisions based on the experience gained.?

As for the absence of Functional Strategy, this is a bit more surprising. Nowadays, any key business support function should really be asking itself tough questions about what it should be doing and how it should be doing it, in the light of the mission, vision, values and strategic objectives of the organisation it is part of. And then documenting the answers somehow.

It is beyond the remit of this paper to explore this subject but the point here is that if no such strategy is in place, then it is very good practice to "reverse engineer" at least the bones of one as part of the BPO/transformation feasibility study, in order to provide that strategic link.?

Here for example is an outline strategy for a Finance function that was created as part of a feasibility study because no such analysis had existed previously. It was not a major piece of work, just a brainstorming session at a workshop, but hopefully it can be seen how the principles developed could be of use in guiding the subsequent shaping and consideration of the transformation/BPO proposition (and indeed in numerous other contexts):

Assessment of Current Operations at wrong level of detail

The “Assess Current Operations” step of the methodology is one where it is very easy to get the “rapid but robust” balance wrong. I have experienced situations where there has been too little emphasis on the as-is, and situations where there has been too much.?

As for too little emphasis, one programme sponsor once said to me: “I don’t care about the as-is, I only care about the to-be”. I think I understand the underlying sentiment, but if one is planning a trip to Brussels, it makes a real difference whether one is setting out from Bristol or Baltimore. And in the absence of a good understanding of what constraints and challenges from the as-is may carry over into the to-be, most suppliers will be forced to price for the worst-case scenario – ie with some “padding” just in case.

And as for too much emphasis, I have seen a multi-million Euro budget devoted to a totally unnecessary exercise of producing a complete set of detailed as-is process maps as the first step in a transformation/BPO programme. The large household-name consulting firm who performed this work must have been delighted to get so many of its junior staff off the bench.?

Using the checklist for assessing current operations described above will of course achieve a Goldilocks-accredited “just right”!

Future state designed without need for change specified

Different stakeholders will have different views of what the future should be like and some of these are likely to be inappropriate pre-suppositions that have not flowed from the strategic context through the analysis of current operations as per the methodology. For example, I have seen senior stakeholders strongly debating where a future operations centre should be before any other aspect of the to-be blueprint had been discussed (“scope” for example) and even before the as-is assessment had been completed. The Need for Change “keeps people honest” because it is a specification for the to-be state, not a description of the to-be state itself, so it prevents premature discussion of the to-be and, when the time for discussion of the to-be does arrive, it sets the key parameters – “hang on; didn’t we say we needed a future state that will XXX? So why are we contemplating something that would YYY?” It’s a bit like the rather-sensible practice of agreeing the rules of a game before starting to play it.

Future state designed without adequate review of external world

People in client-side organisations responsible for transformation/BPO initiatives are not usually deep experts in these fields (why should they be?). Moreover there will always be new developments in the market (technologies, locations, suppliers). Some of these will inevitably turn out to be vapour-ware despite the analysts getting all excited, some will be a bit bleeding edge, but some of which will have genuine potential to deliver real benefits. For these reasons it’s essential to invest quality time in getting to know what is out there – hence the “Review External World” step of the methodology.

Possible sources of insight include: web research, asking acquaintances to other organisations, attending conferences and seeking the advice of advisors. But to me an essential part of the mix is to engage with potential suppliers, even in the feasibility phase, in a mature, open, non-committal manner.

This is pretty counter-cultural because many if not most advisors like to position themselves as i) the essential gatekeeper between their client and those nasty suppliers and ii) the fount of all knowledge. But when I act as an intermediary I certainly do not presume to know more than the suppliers – after all, they are the people who “do this for a living”. And I do not see myself as a gatekeeper – more of a facilitator. I have run many effective exploratory sessions between clients and suppliers – even with multiple suppliers in the same room as the client, in a round-table format.

In such cases the “groundrules” have to be clear of course – the supplier is not there to sell, but neither is the client there to get a bunch of free intellectual property or a head-start on any future commercial negotiation. But such interaction can certainly form part of the supplier selection processes, because the client can really start to see the ways of working and cultural styles of different suppliers.

Transition plan not robust

I lost count long ago of the number of times I have seen unrealistic transition plans. In my view there are two main reasons why this happens and the problems can often start when developing the Transition Approach during the development of the high-level business case.

The first reason is basic inexperience amongst the project leadership, even externals who claim to be experts. One such person once proudly said to me “we have a 1000-line plan”. I presume this was meant to give me confidence, but the project in question was only a lift & shift BPO of one function from one country, so 1000 lines was way too heavy – a classic case of trying to cover underlying incompetence with a spurious level of detail. I managed a global transformational BPO with a template plan of about 125 lines, adapted a bit by each of the regional teams within the organisation. These examples are from the transition phase of a programme of course, but as mentioned the seeds are often laid in the feasibility phase.

The second reason is inappropriate incentivisation of key stakeholders - so for example personal bonuses for hitting a deadline but with no account taken of the other key project parameters such as scope, quality, budget, risk, etc. It’s pretty easy to tell from personal behaviours when key members of the supplier or client teams are driven in this way! Sometimes deadlines are even committed to in the high-level business case, prior to any due diligence or interaction with suppliers, let alone actual experience from the early stages of implementation.

As for the best way forward…well, make sure that true expertise is available – this means people who have the knowledge, the experience and the personal qualities to be able to give sound advice and facilitate proper agreement between stakeholders. Seek to get the thinking correct?from the outset but build in sufficient flexibility given that the level of detail will increase as the programme progresses. And be prepared to stay mentally-tough?even when the pressure is on.

I have a separate paper dedicated to the project management of BPO/transformation initiatives. It can be found here: https://www.dhirubhai.net/pulse/ten-life-hacks-project-managing-transformation-bpo-howard-spode/.

Not enough or too much risk management

There is a “just right” to be had in risk (and issue) management too, which sits between not devoting anything like enough attention to it and devoting far too much. Again, the tone is often set in the feasibility stage when first identifying and processing the key risks.

In terms of not enough attention to risk and issue management, it’s often a case of senior sponsors paying lip service to the subject - proclaiming how they want to be rigorous in seeking out and dealing with problems, but when problems do emerge, their getting nervous that this might reflect negatively on their reputation and so proceeding to talk the problems down or try to sweep them under the carpet. This is especially prevalent when incentivisation is misaligned as described above – if you’re getting paid for hitting a go-live date you don’t want any uninvited guests spoiling the go-live party.

In terms of too much attention, some project managers like nothing better than to make an entire industry (and a good living) out of risk and issue management. These are usually the ones who believe they can manage projects from behind a desk. We don't need a scenario where hundreds of irrelevant problems are identified with religious zeal and allocated out via some clunky system to unfortunate victims across the organisation who often do not have the means to bring about resolution. As the pile of problems gets higher and higher, a culture of problems not being properly addressed can arise and key problems can get completely missed... just biding their time to gate-crash the go-live party.

Turning to the “just right”, all the key risks and risk management actions pertinent to the high-level business case can be identified by running a workshop with the right people lasting about a day. I have a structured approach and agenda that I have used successfully many times but I wont include it here for reasons of space. The right tone needs to be set at this point for how problems will be dealt with in the programme. Relevance, rigour, relentlessness, etc. And in the implementation phase (since I mentioned it above) it is perfectly possible to run a regime where risks and issues are identified, assessed, prioritised and responded to in an effective and efficient manner employing fit-for-purpose tools, common sense and personal energy and whilst maintaining goodwill all round.

Conclusions not “holistic”?

As mentioned, the conclusions should be holistic in that they cover all the relevant benefits and challenges. Often cost is the dominant factor on the benefits side but it is usually the case that other factors are in play too, even where cost is the main driver. Sometimes for sure cost is the only factor, but this is pretty rare. And sometimes cost is not a major factor at all. For example, let’s imagine a smallish company where the Payroll team consists of only four people, one of whom is approaching retirement and another of whom has started looking for another job because of certain life-changes. Here the main driver for potential Payroll outsourcing could well be the removal of the risk of service failure due to skills loss. Cost savings and quality improvements may be way down the list – perhaps the client would even be happy to see costs go up.

So, again, watch out for people using the phrase “business case” to mean “financial model”. At best, it’s a sloppy way of speaking; at worst it signals a one-eyed view of the drivers for transformation/BPO.

It’s always good practice to try to put numbers on non-cost data of course. For example “the process will be completed to x% accuracy y% of the time” is an example of a quality metric couched in very quantitative terms. It’s possible to do this with various other non-financial elements but business is not science and there is a place for purely qualitative information too – statements of vision, concern, expectation; conclusions, recommendations. After all, the decision of whether or not to launch a BPO/transformation proposition is ultimately a matter of opinion – opinion based on facts and interpretations for sure, but opinion all the same.

Project team not formalised

It’s important to set up a dedicated project team to run a feasibility study. “Dedicated” does not mean that the members have to be full-time, but they have to have enough time carved out of their day-to-day responsibilities to be able to do the work, and they have to have the mind-set that the project is different from that day-to-day work. Unfortunately, I have experienced several situations where one or other of these criteria is not in place and inevitably it has led to the project not progressing at the right pace or with the appropriate degree of rigour.?

As for external help, the key is to get resources with the right knowledge, experience and personal skills. It is wise in the feasibility phase to minimise the external support. One person should be enough, with the rest of the team drawn from within the client organisation. This will generate a high level of ownership of outcomes, form a nucleus of in-house expertise to manage the project if it proceeds to later stages and, of course, keep the costs down.

? Howard Spode, 2015

A version of this paper was originally published in Outsource Magazine (www.outsourcemag.com).

My other papers on LinkedIn:

• Transforming Technical Training with Academies https://www.dhirubhai.net/pulse/transforming-technical-training-academies-howard-spode-e15le/
• Checklist for Transforming Learning & Development https://www.dhirubhai.net/pulse/check-list-transforming-learning-development-howard-spode-wvdae/
• Ten Life Hacks for Project Managing Transformation / BPO initiatives https://www.dhirubhai.net/pulse/ten-life-hacks-project-managing-transformation-bpo-howard-spode/
• How to Develop Robust Financial Models in Support of Transformation / BPO Initiatives https://www.dhirubhai.net/pulse/how-develop-robust-financial-models-support-bpo-howard-spode/
• In-house or Outsourced Transformation – Which is Best? https://www.dhirubhai.net/pulse/in-house-outsourced-transformation-which-best-howard-spode/
• Getting the Organisation and Change Management (OCM) Domain Right in Transformation / BPO Initiatives https://www.dhirubhai.net/pulse/getting-ocm-domain-right-bpo-projects-howard-spode/
• Key Lessons Learned in Transformational ("Fitgap") BPO https://www.dhirubhai.net/pulse/key-lessons-learned-transformational-bpo-howard-spode/?