This is the third in a series of three articles. Read Part 1 here, and read Part 2 here.


Business process outsourcing (BPO) transitions are hard. This fact doesn’t change regardless of whether the transition involves more traditional, labor-based services or a technology-based solution. Likewise, the steps associated with a technology-related implementation are broadly the same. What does change are the points of emphasis when transitioning—what to expect and how to best support that transition effort to ensure it goes as smoothly as possible.

With technology-based BPO implementations, everything is changing at the same time. On the surface, this doesn’t sound dissimilar from the more antiquated “lift and shift” approach, where the number of elements changing simultaneously, while daunting, is limited to mostly people and location—legacy processes and technology largely remain intact (although there is always some amount of process and technology change required when moving activities, especially offshore).

With a more transformational, technology-based BPO implementation, the number of variables increases. Provider systems are used, and clients become more reliant on the “standard” provider processes that enable and accompany those systems. This creates the need to think differently about the activities, timeline and resources required to transition effectively to a transformed, automated future-state.


Before Moving Forward, Take a Step Back

Before undertaking any planning or execution activities, it is important that the buyer of a technology-based BPO service understands and appreciates the nature of the solution being provided. Ideally this happens prior to a contract being executed, but it is not unusual that the buyer’s understanding of technical and functional capabilities of the solution is based on the marketing collateral provided, salesperson descriptions and high-level product demos performed during the selection process. These tend to seduce a buyer into believing that the capabilities are more robust, the results are more impactful and the implementation effort is more straightforward than may actually be the case.

Once the detailed design discussions commence, there are often customization and configuration requirements to align the capabilities of the tool with the business processes of the client, which adds to the complexity and implementation effort. Taking a “deep dive” into the tool prior to proceeding with execution provides an understanding about how client requirements drive deviations from a standard configuration and helps to ensure costs, timing and resources are planned for in an informed manner.