Image Image Image Image Image Image Image Image Image Image

Outsource magazine: thought-leadership and outsourcing strategy | July 25, 2017

Scroll to top

Top

No Comments

Lessons Learnt in Transformational BPO (Part 3)

Lessons Learnt in Transformational BPO (Part 3)
Howard Spode

This is the final article in a three-part series. To go to the beginning of the series, click here.


 

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 detailed implementation plans 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 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.

Testing

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 just 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 customers of the service after go-live. No doubt there 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 that the Service Rehearsal Team would pick up any data issues. Unfortunately, they had to: serious data challenges manifested themselves during the simulation and completely de-railed it. All parts of the technology 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.

Lessons learned in 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 three 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” (both onshore/offshore, outsourced/retained) and give power and responsibility to end-users for a certain contribution (eg provision of data or initiation of 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 or otherwise) 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.

About the Author

Howard Spode 150Howard Spode has worked in BPO since the mid-’90s when the industry began. He is hands-on familiar with every stage of the life-cycle, from all angles of the market (client, supplier, intermediary), in numerous geographies, sectors and business functions. He is the Managing Partner of BPOpronet, an organisation that provides advice and support to help BPO initiatives be evaluated, initiated, implemented and operated.

Submit a Comment