Key Lessons Learned in Transformational ("Fitgap") BPO

In this paper I share some key lessons learned from my experiences in transformational Business Process Outsourcing (BPO), which is where transformation and outsourcing happen simultaneously. Transformational BPO is often referred to as "FitGap BPO" given that a process called FitGap is a key part of the overall journey.

My aim is to help anybody involved in such initiatives (clients, suppliers or intermediaries) avoid pitfalls which could see lots of money being wasted, and/or failure to realise the full benefits anticipated.

I will not cover general good practices of BPO (such as how to develop the business case, select the right partner, etc). These?activities are certainly relevant in transformational BPO, but I want to focus on the areas that make transformational BPO unique given that this type of outsourcing is relatively new and in my expectation will continue to grow in prominence.

Nor will I focus on the details any of the various transformational solutions?available (Robotic Process Automation (RPA), Software-as-a-Service (SaaS), etc). Such?techniques are certainly exciting and potentially very powerful, but there is plenty of intellectual property available that covers these subjects and plenty of people who are better qualified than me to describe them in detail. I am a programme manager, so this paper focuses on how to ensure that a transformational BPO initiative is managed successfully, whatever its particular objectives. To this end, I cover the nuts and bolts of what are the best practices to employ and what are the key errors to avoid.

Most if not all of what I say will also apply to internally-delivered transformation initiatives, where BPO is not in play. Even in internal arrangements, there is usually a "pseudo-commercial" model set up between the part of an organisation which will supply the transformed services and the part that will receive them.

The article was fist published in Outsource Magazine (www.outsourcemag.com).

Transformational BPO

I should begin by describing what I mean by “transformational BPO” and how it differs from other forms of outsourcing.

At root, outsourcing is “commercial change” involving a transfer from client to supplier of contractual responsibility for delivering a certain scope of work. But this commercial change is always connected to some degree of “operational change” – a change in how the service is delivered in terms of process, technology, people, location, etc. The way the service is delivered I refer to in this article as the “operating model”.

The relationship between commercial change and operational change can be seen in this simple graphic:

Different types of outsourcing vary in the amount of operational change they incorporate (the commercial change is always the same). In the early days of outsourcing, many initiatives involved very little operational change. For example, in an early IT Desk-Side Support or Payroll arrangement the location of the work might remain unchanged, as might the ways of working and the people performing the work. Yes, the employment of the people would be transferred from the client to the supplier and a service management environment would be introduced but fundamentally the operating model that existed prior to outsourcing would remain in the post-outsourcing environment.

Then came along “lift and shift” arrangements, starting in the 1990’s and continuing to this day. The main feature here is the re-location of work to a remote delivery facility, often across international boundaries. In such circumstances, the operating model clearly has to change - process designs have to be tweaked around the handover points between client and supplier, “enabling technology” such as scanning is introduced and different people deliver the service. However, the core policies, processes and technology remain untouched – the operating model is basically “lifted” from the client and “shifted” to the supplier.

Transformational BPO is different in that, in addition to the operational changes described above, it does incorporate significant change to the core operating model. Whilst transformation in this sense is not new, in the past it has been run separately from the outsourcing process. The question has been whether the transformation should happen before lift and shift BPO (performed by the client, usually with the help of consultants) or after it (performed by the supplier with benefits shared with the client). In transformational BPO the commercial change of outsourcing and the profound operational change of transformation occurs simultaneously.

I have published a separate paper that examines and evaluates the various combinations and permutations between transformation and outsourcing. It can be found at this link: https://www.dhirubhai.net/pulse/in-house-outsourced-transformation-which-best-howard-spode/.

Now to the key lessons learned. I have grouped them by the usual phases of a transformational BPO programme – Design, FitGap, Implementation, Testing and Operations. Most of the lessons are in the first two phases, because this is where transformational BPO differs most from other types of outsourcing.

The Design phase

The design of the new operating model can be undertaken unilaterally by a supplier and made available to the market on a “plug and play” (sometimes called “platform”) basis, or it can be performed in a bespoke manner for a specific client. Large client-organisations have tended to take the latter approach and this is the scenario I focus on in this article. A new operating model is designed centrally and implemented in a standardised form across the various different business or geographical units of the client’s organisation.

The key lessons:

• Anticipate a reasonable amount of local variation. There is natural tension between the desire for a completely standard global model and the need to reflect local specificities. The former objective should of course win out on the whole but there will always be circumstances where features of the local environment cannot be changed to accommodate the global model - for example because of legal constraints. An 80/20 ratio is probably a good rule of thumb for the global/local balance. As long as any proposed local variations are subjected to proper scrutiny in the FitGap phase (see below), these matters can be worked through in a controlled fashion. However, I have seen some global Design teams adopt and espouse the mind-set that no local variation is going to be tolerated. This is just macho and silly - a 100/0 ratio is not feasible and this will quickly become apparent during FitGap. Perhaps in such circumstances the global Design team is attempting to grab some high ground before an expected battle with the local business units, perhaps it has been working in too much isolation (or, indeed, an ivory tower). Whatever the reason, the adoption of such attitudes results in the design losing credibility, “stand-offs” occurring between the local and global communities and even clandestine local workarounds being adopted down the line.?
• Don’t build your operating model from scratch. Just as an 80/20 rule is a good starting point on the global v local question within an organisation as described above, so too it may be for the question of how similar one organisation’s operating model is to any other organisation’s. Some consultants and BPO suppliers are very happy for a client to spend lots of money with them on the design of a new operating model from the bottom up, but to a great extent, HR is HR, Finance is Finance, etc, regardless of industry, geography and specific organisation. This is especially true for the more transactional activities likely to be the focus of BPO. I have seen the same design teams that do not accept the concept of any local variation within their organisation seem quite happy to be convinced that their organisation’s operating model has to be totally different from any other organisation’s. I do not believe this is true. Yes, maybe 20 per cent of an operating model is specific to a particular organisation and has to be actively designed for that client. But the rest is already out there and pretty freely available.
• Ensure your Design team considers true best practices. The aspiration of transformational BPO is usually not only to introduce a standardised way of working across an organisation, but also for this way of working to deliver a step change in effectiveness and/or efficiency compared to the as-is. There are some genuinely exciting innovations in the market and whilst these might not all end up being incorporated into a client’s operating model (one size may not fit all and there is always a question of leading edge v bleeding edge), at least they should be made available for consideration. For example, Robotic Process Automation (RPA), Artificial Intelligence (AI), the various technology components now available “as-a-service” and some truly powerful analytics. If a Design team is not bringing forward these types of best practices, it is time to question the value being added.?
• Project manage the design phase. It is usually not a matter for debate that good project management is required in the Implementation phase, just as it isn’t that good operational management is necessary in the Operations phase. However, I have seen the Design phase of some programmes progress in what seems like the absence of any project management at all. As if Design was some kind of art form not subject to management control. But I guess even Michelangelo was working to a budget and a timescale when painting the Sistine Chapel. Notwithstanding the points made in the paragraphs above, a significant amount of budget is going to be at stake during the Design phase, and the milestones of the later phases of the programme are obviously dependent on the design being completed on time. Without proper project management, time and money will haemorrhage to the extent that serious sub-optimalities have to be endured downstream – release of solutions that are not fully thought through, key resources cut from implementation teams and operational go-lives that are forced to occur before they should. I offer further thoughts on this matter on my paper on project management of transformation/BPO initiatives: https://www.dhirubhai.net/pulse/ten-life-hacks-project-managing-transformation-bpo-howard-spode/.

The FitGap phase

FitGap sits between the Design and Implementation phases. It compares the new global model with the existing local practices in each organisational unit in order to identify the differences (“gaps”) and determine what actions are necessary. It usually takes the form of a facilitated workshop attended by the global Design team and the local communities. As mentioned above, there will always be tensions between global standards and local realities and because FitGap is where the rubber first hits the road in this regard, it can be quite a sensitive time.

The key lessons:

• Master the methodology. All gaps fall into one of a small number of categories. For example, items where the local practice has to change to accommodate the new global model (often called “impacts”), items where the local practice is thought to be unchangeable for some insurmountable reason (often called “exceptions”) and a couple of other types. This categorisation is crucial because the different types of gap are processed in different ways – for example, impacts are passed to the local team to get on with planning the specific actions required, whereas exceptions go into a formal review process (see below). But time and again I have seen the categorisation not fully understood by key players in the programme. To be fair, there are grey areas between the categories that take brainpower and experience to figure out, but mastery of the methodology always allows the right decision to be made. This mastery comes only through sound thinking, proper preparation and accumulated experience on behalf of the leaders of FitGap. Without such mastery, the local communities can get confused (genuinely or deliberately) and gaps end up missed or in the wrong categories. This is always going to cause trouble - for example any exceptions not properly identified at FitGap are sure to pop up as unexpected and unwelcome dinner guests later on.?
• Focus on the to-be. I have noticed a tendency for FitGap facilitators to start proceedings by asking the local community to describe the “as-is” ways of working. This may be because the facilitators feel it is a sensitive way of initiating dialogue and showing respect. It is also the natural consultancy modus operandi. In actuality, however, the practice wastes time and sends the wrong signals. The mission of a transformational BPO programme is to implement a global operating model in as pure a form as reasonably possible. Certain elements of the as-is are going to be pertinent to this goal, but only in the light of the to-be. The as-is is not at all interesting in its own right – the majority of it is going to be eradicated anyway when the new design is introduced. In similar vein, it is best not to invite people to represent the local community who have for many years been performing the process in the “old” way. Unless you want to hear in excruciating detail how things have been done for the last X years and why they cannot possibly change. Yes, knowledge of the current ways of working is required, but so also is the ability to accept that change is coming and contribute in that spirit. If really deep knowledge of the as-is is required, it can always be accessed on an on-demand basis.
• Set up strong governance around local variations. Any proposed exceptions emerging from FitGap are potential departures from the global model and they therefore need to be scrutinised closely. Such items should be reviewed and decided upon by an appropriately informed and empowered governance body. This is also true of any open questions arising from FitGap that the global Design team could not answer at the workshop (another category of gap often called “Clarifications”). Unfortunately, I have experienced this process as anything but smooth – lack of clarity on what format of output is required from FitGap, unclear responses provided by the governance group, long delays etc. As a result, confusion abounds, confidence in the solution is eroded and momentum in the programme is lost. Assuming an effective and efficient governance process can be put in place (and to do so is not rocket-science), a really good practice is for the facilitators of FitGap to spend time cleansing the output documentation before it is formally submitted. This is not to modify the content of course, but to ensue that it is totally clear and therefore fully accessible by the various parties that are going to review it. It takes real commitment and professionalism to spend an additional hour at the end of an intense day of FitGap carrying out this activity, but it certainly pays dividends.
• Anticipate “local solutioning”. Any approved Exceptions will exist into the to-be environment alongside the new global model. How this residual as-is activity will be “woven in” to the new landscape will need to be thought through. For example, who will perform it (the client or the supplier), how will the old processes connect to the new ones, how will the data get into the new systems? This localisation is crucial – both the local and global elements of the future operating model have to work and they have to work together. It is therefore essential that the programme anticipates this effort and provides the necessary time and resources.?

The Implementation phase

Implementation in a transformational BPO initiative calls for the same kind of disciplines as it does in any other type of large-scale organisational change – project structure, project plan, project management regime, etc. Nevertheless, there are a couple of key lessons that apply specifically for transformational BPO:

• Don’t finalise the plan before FitGap is complete. From the description above, it would seem pretty obvious that the finalisation of the detailed implementation plan for a business unit is dependent on what is found in FitGap and what is decided in Local Solutioning. However, I have seen go-live dates committed to by senior stakeholders before FitGap has even started. Of course there should be a programme plan with target dates for the various phases, including Implementation, but to commit to an operational go-live without understanding the full complexities involved is just asking for trouble.
• Manage all moving parts through one programme structure. Transformational BPO is significantly more complex than Lift & Shift and consequently requires the contribution of more and different parties – Design, Technology Configuration, etc. Basic good practice demands that in all phases, all strands of activity are co-ordinated and run through one programme structure. This may seem obvious. And indeed it should be. Yet, for example, I have witnessed a Design Team continuing to tweak global products even after Implementation has started and to promulgate these to local communities without the knowledge of the Implementation team.

The Testing phase

In a Lift & Shift BPO programme, the main way of managing risk around an operational go-live is to transfer transactional volume gradually from client to supplier. This is often called “Ramping”. But this approach is not available in transformational BPO because it is not practical to manage x% of the transactions in the old way and y% in a radically new way. Piloting is an option, just as it is in Lift & Shift, so one organisational unit at a time for example, but within each unit the go-live has to be a “big bang”. For this reason, the main testing strategy in Transformational BPO is to run some kind of simulation of the new operating model in a controlled environment prior to go-live. Various approaches exist, including “Model Office”, “Parallel Running” and “Service Rehearsal”.

How to design and run this kind of simulation would be a meaty article in its own right so juts a few illustrative lessons here:

• Make the simulation representative. Obviously, a simulation has to simulate reality to a meaningful degree. So, for example, the testers should work without any help that will not be available to real participants of the process after go-live. No doubt there will be a strong desire within the programme for the simulation to go well. Sometimes I have seen this lead to a level of “support” that detracts from the simulation’s usefulness.
• Think “rehearsal”, not “test”. Simulations should always be expected to go well, because they should benefit from all the conditions that will be in place after go-live. All components of the new operating model should have been properly designed, implemented and where relevant tested in their own right. Yes, a few items will always come out of the woodwork and these can be dealt with, but the core objective of the simulation is not to identify defects, it is to rehearse for what will very soon be a reality. In case this is sounding a bit philosophical, here is a tangible illustration. I have seen technology testing in a programme restricted to the basic functionality of the new systems, as opposed to also incorporating the data in the systems. The Technology Team assumed (erroneously) that it was within the Service Rehearsal Team's mandate to?pick up any data issues. Serious data challenges manifested themselves during the simulation and completely de-railed it. So then the Technology Team had to finish the job it should have finished originally - all parts of the technology landscape should have been tested and de-bugged before the simulation began.
• Act on the results. There is of course a need to feed the results of the testing into a formal governance process with decision-makers who are able and willing to make the tough calls such as “go” even though some stakeholders might be nervous or “no-go” even though there are various kinds of psychological and financial pressure to go live.

The Operations phase

In Transformational BPO, as in all outsourcing, it is the Operations phase where the true value of an initiative is realised. Strange then that Operations is often viewed as the least glamorous element of a programme but I guess that is a topic for a different article.

The key lessons for me:

• Don’t cut and run before Stabilisation is achieved. The operational go-live is of course where the rubber really hits the road. Even with rigorous testing (see above), a few glitches may slip through the net. Moreover, some proportion of the Operations Team will probably be newly-recruited or at least newly-trained and stakeholder interest may well be heightened. For these reasons, it is very wise to keep some part of the Implementation team on hand in a formal capacity to provide post-go-live support to Operations as and when the need arises. A period of reducing intensity lasting from go-live up to 3 months is a common approach. But I have seen programmes planned with no Stabilisation at all, the Implementation Team withdrawn immediately after go-live and Operations left to fend for themselves. Operational teams are usually highly resilient and resourceful so usually they manage to make things work eventually, but it’s hardly an ideal situation for them to be fire-fighting from Day One when they should be concentrating on delivering service to customers.
• Realise benefits across the board. In transformational BPO, the new operating model will be holistic in that it will encompass the advisory and specialist elements of the service as well as the transactional ones, and it will include also the customer’s role. So, for example, back office services like HR and Finance tend to establish “Business Partner” and “Centre of Excellence” roles as well as “Transactional” and require End User to engage in "self-service" for basic transactions. If the new model is holistic and the business case to justify it is holistic, then benefits realisation efforts need to be holistic too. However, for one reason or another (commercial, psychological, political) there is a tendency to focus only on the outsourced element. This is always a mistake. Firstly, it obviously risks leaving a portion of the anticipated benefits on the table; secondly, in order to function correctly, the outsourced element requires proper inputs from the other elements of the service (garbage in, garbage out) and thirdly, it establishes a negative culture of blame and “us and them”. So, all governance and benefits realisation mechanisms need to apply holistically to a meaningful extent. These include all the usual suspects such as: Service Level Agreements (SLAs), Key Performance Indicators (KPIs), escalation mechanisms, budgets, reporting and management oversight.

? Howard Spode, 2015

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/
• How to Determine Whether There is a Business Case for Transformation / BPO https://www.dhirubhai.net/pulse/how-determine-whether-business-case-bpotransformation-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/

?

?

?

?

?

?