Alignment Of Sourcing Models
The latest evolution of the technology Operating Model, Enterprise Product, offers significant advantages delivering greatly improved technology and business agility. But speed to market often requires the support of third parties, and traditional sourcing models either constrain collaboration and flexibility or fail to provide the safeguards clients need. In this paper, we discuss models for aligning sourcing models with Enterprise Product.
Outsourcing is common in every aspect of our lives, both at home and at work. We regularly engage third parties to help us solve problems, be that with the help of electricians, builders, plumbers, or highly specialist software engineers.
Why do we outsource?
- To address skills gaps or capability shortages
- To achieve something faster than would otherwise be possible
- Because we think someone can do something better than we can
- Because we think they can achieve more for less
- Because the task in hand is not core to our skillset
Of course, whatever the motivation, there is always a commercial imperative to ensure value for money. With this in mind, contracts have at various times been tensioned on, amongst other things, cost, quality, and commodity (e.g. standardised services potentially subject to SLAs).
When working within an Enterprise Product model, the main tension is that of flexibility. If the contractual model does not allow teams to collaborate and quickly adapt to address customer needs, the business will be constrained. However, ensuring value for money involves a number of other considerations: the need for the right level of capability and expertise; the level of quality delivered; and of course, that the desired outcome is delivered i.e. the teams are working on the right things.
This implies a potential paradox – the ideal modern contract should tension on the outcome (i.e. the value delivered), but it is the client Product Managers who are best positioned to provide the value insights and be accountable for achieving that value. As a result, over the last ten years, we have seen the supply of contingent labour on a time and materials basis become the norm as the need for flexibility has ruled, but this is neither ideal for the client nor the supplier.
In an Enterprise Product Model, the client and supplier should work collaboratively together to drive value, and contracts should be appropriately tensioned. This requires a high degree of trust between the parties and continual, collaborative alignment on intent.
From Specialists to Value
Unsurprisingly, there is no one size that will fit all when sourcing, and organisations will mix and match their approach and evolve their models to meet emerging requirements. Below we discuss the options available, from individuals working under the full direction and control of the client organisation, to the ideal of full teams, working to achieve value.
Sourcing Individual Specialists
The simplest form of outsourcing is that in which individuals are contracted to work within teams, very much akin to permanent employees, fully under the direction and control of the client organisation. This approach provides complete flexibility to the client but makes delegation of responsibility for the achievement of outcomes difficult – product teams are multi-disciplinary and work collaboratively together to deliver value; focusing on individual contributions creates a barrier to collaboration and reduces team flexibility.
As such, sourcing of individuals is typically on a time and materials basis with little “protection” for the client. Of course, a number of individuals may also be contracted from a single supplier in a similar way without this constituting a team.
Sourcing Teams and Applying SLAs
As the footprint of third-party suppliers become larger within an organisation and they take on more responsibility as a team or teams, it is possible to delegate some level of outcome. For example, if a supplier were to provide all the Software or DevOps engineers in a particular area, it is then possible to attribute specific measurements (KPIs) to their success and include aligned SLAs within the contract (see below). These measures are, of course, only leading indicators to the overall outcome, and not directly attributable to customer value. They also typically only represent part of the value delivered by the team. However, such a contract will provide a level of quality measure relating to the value of the service provided, and hence some confidence to the buyer.
The final progression is for third parties to supply full teams or squads, in addition to analysts, engineers, DevOps engineers and testers. This may also include SMEs. However, as discussed above, it is unlikely that the outsourced team will provide the Product Owner or Product Manager, and therefore the decisions regarding how best to meet the customer needs and deliver value remain firmly with the client. As such, it is difficult to tension the contract on value, as this is not fully under the Supplier’s control. Instead, it is more likely to remain focused on the leading indicators within the control of the supplier.
Of course, if a “full” product team is measured according to a whole range of quality and throughput KPIs, this will provide a good indication of performance. And, if the Product Manager and SMEs are doing their jobs, the product teams should be optimised for value.
Example KPIs
There are many different metrics that can be used to provide an assessment of the quality of the software development process through engineering, DevOps, testing, and deployment. Importantly, most can be objectively measured and therefore can be used in Service Level Agreements. For example:
- Waste: How much time is wasted due to bottlenecks and hand-offs in the process. This measure is a good proxy for throughput.
- Code Coverage: This metric measures the percentage of code that is covered by automated tests. A higher code coverage indicates that more of the code has been tested and is less likely to contain defects.
- Code Duplication: This metric measures the amount of duplicated code in the software. Higher code duplication can indicate that the code is less maintainable and prone to defects.
- Bug Density: This metric measures the number of defects per unit of code. Higher bug density can indicate that the code is more error-prone.
- Deployment frequency: This metric measures how often code is deployed to production. High deployment frequency is a sign of a well-functioning DevOps team.
Other measures include lead time for changes, mean time to recovery, change failure rate, cyclometric complexity, and code test coverage, to name a few.
Tensioning for Value Outcomes
The ideal for enterprise product (And other product-aligned operating models) Is that sourcing be tensioned on value, ensuring both parties are continually aligned and collaborate to maximise outcomes. The approach is relatively simple and relies on the basic tenet that the client Will always be focused on achieving value, and if a portion of the client fees are contingent upon achievement, both parties will be aligned in their collaboration – it is in both parties’ interests to succeed.
Of course, what is required to achieve the value will change over time, and this must be addressed through the appropriate process. However, such a “change” process should not over-incumber the teams, reducing flexibility.
Critical to the success of this approach is the identification of clear value metrics that can be achieved within reasonable timescales (i.e. timescales that are acceptable to both parties). If only a portion of the fees are contingent on achievement of value the supplier may be willing to accept a delay in recognition of the up-side.
Importantly, value measures are typically those that are used for Board reporting and therefore less open to gaming or incorrect interpretation. They, therefore, make a good basis for contractual agreement and measurement.
Impact
The following tables summarise the considerations of each model, and the impact they have within the Enterprise Product model.
It’s Time to Optimise Your Sourcing
Business agility requires adaptability and speed to market in technology, Enterprise Product offers this. But like the challenges of legacy systems, outdated approaches to sourcing will constrain teams, significantly reducing their ability to succeed.
When developing a model, it is important to balance the tensions of flexibility and collaboration with value for money, but this can be achieved through the application of value-based sourcing models, or to a lesser extent, the use of SLAs applied to KPIs. Of course, mutual trust is the primary enabler of super-charged, collaborative relationships.
Get in touch with our team to learn more about our services, explore partnership opportunities or discuss how we can help with your challenges.