BLOG POST

Tech & Sourcing @ Morgan Lewis

TECHNOLOGY TRANSACTIONS, OUTSOURCING, AND COMMERCIAL CONTRACTS NEWS FOR LAWYERS AND SOURCING PROFESSIONALS

Complexity in sourcing transactions relates to the interdependence between the parties executing a program. However, “complexity” can be a surprisingly nuanced concept whose meaning can vary under different circumstances. Here are a couple of these nuances.

What Is Complexity?

If you are buying a physical product, the transaction is not truly “complex” if it can be described completely in the contract, although the product itself may be complicated. For example, a rocket ship is a complicated product, but with specifications that can (and probably should) be described in perfect detail, there is no requirement for an overly complicated contract structure, and the relationship between the parties may not be complex. Contrast this with an engagement that involves business process redesign accompanied by software development and implementation like an enterprise resource planning (ERP) implementation, or a large-scale robotic process automation (RPA) initiative. Although the contract can specify the desired result, in many cases the results will depend on both parties working together to realize that result. This interdependency makes the relationship complex and requires a more nuanced procurement and contracting process.

A program that may be complex for one company may not be complex for another. This may be overly simplistic, but the difference frequently depends on which side of the contract the most expertise to execute resides, as well as which side will bring the grassroots change enablers. In the case of outsourcing, one could argue that the relationship is always complex because of how the deal economics work. However, putting deal economics aside, reviewing the execution of any type of procurement, varying levels of “complexity” emerge.

Exploring Complexity

If the substantive and organizational change management (OCM) expertise sits on the customer side, arguably the execution of the program will not be terribly complex. Success, in this case, will largely depend on creating a structure where the supplier provides personnel with the necessary technical skills as and when they are required, along with an ongoing operational model that establishes service level metrics and risk allocation. The procurement process will be largely transactional.

In this scenario, there are still attributes of complex relationship but the complexity is on the customer side. In other words, someone must still determine how to get all the moving pieces to come together, engage in process optimization, implement change management that drives positive behaviors, etc. However, those pieces can be orchestrated and executed by and for the customer using customer resources.

If the substantive and OCM expertise is split, which is the most common scenario, then the program becomes more complex operationally, and is a more challenging sourcing exercise (but not as challenging as the third scenario where all or most expertise sits on the supplier side). Both of these scenarios are highly complex, and require a nuanced sourcing process.

Complexity and the RFP Process

Complex programs are much more likely to work if there is real alignment between the parties and a contract that reflects such a relationship. Many parties try to achieve this by going to market with a proscriptive request for proposal (RFP), forcing the supplier into a mold and hoping the supplier performs in line with that mold (and does not just accept the mold for sales and presentation purposes). This approach can result in too much dependence on the up-front requirements of the contract, a model that often does not work well for complex relationships.

A more effective procurement process uses a request for solution (RFS) or similar process that describes the desired end game, and then works with the potential suppliers to fully develop the processes and requirements and ultimately discover which suppliers are naturally aligned with the customer’s program – technically and culturally. This has the advantage of laying the foundation for a long-term relationship based on alignment and trust, building problem-solving channels during the buy process, and jump-starting the OCM program. The disadvantage is that it requires skill to execute and can feel ungrounded if not executed well – particularly if the team is accustomed to a more formalistic RFP process.

Final Thoughts

In our experience, communication is key to making this work. The process should be designed to be iterative, encourage discussions with the suppliers, and include requirements of refinement and supplementation processes. Frequently, once the customer team begins using a more exploratory process, they become quite comfortable with it. Particularly for the team members who are not accustomed to being at the negotiating table, a process like this can be appealing –the RFS process can flesh out real, actionable solutions while weeding out the poor-fitting suppliers, all without the drama or contention so often associated with competitive RFP processes and negotiations.