Strategic Sourcing for Digital Transformation

This article originally appeared in the Spring 2023 DevOps Enterprise Journal.

Over the course of sixteen DevOps Enterprise Summits, we have sought out and shared many stories of enterprise transformations. As a community and through the DevOps Enterprise Forum papers, we’ve identified many patterns and antipatterns that help people on this journey. Over the last few years, one of the patterns that kept showing up was that in the vast majority of successful enterprise transformations, the sourcing of the IT function shifted quite dramatically from outsourced to insourced.

The problem we recognized with this pattern is that it can’t be the solution for everyone. The outsourcing market continues to grow and is currently worth over $66.5 billion. That means a huge portion of the global population of IT workers are working either with outsourcers or for outsourcers, and those people are underserved by the current library of learning from the DevOps Enterprise Summit movement.

In 2022, we kicked off the search for answers with a talk on this topic, which we repeated live in Las Vegas, and ran a couple of workshops with attendees to gather more experiences and observations of this situation. This paper summarizes what we found, lays out the reasons DevOps transformations in outsourced ecosystems are more difficult than those in insourced ecosystems, and provides seven actions readers can take to improve their chances of success.

The primary intended audience for this paper is those involved in setting up the ecosystem: the leaders of Procurement, the IT function, Finance, HR, and those involved in the sales and delivery of IT services to large enterprises. We believe a shared understanding of the content of this paper by all those listed above is a critical success factor in setting up the ecosystem for success.

Most IT leaders pursuing a DevOps transformation are trying to change the sourcing mix of their IT workforce, but many don’t know what their strategy should be. Sourcing is evolving, and everyone is at different points on their journey, but many organizations that have predominantly outsourced IT functions have a common starting point. I’ll use a fairly typical public sector organization as an example to bring this to life.

Large Public-Sector Organization

This organization has a long-running contract with a multinational systems integrator to support all of the live systems and end-user devices. They have another contract covering all their development needs with another global systems integrator. For major programs, they typically bring in one of the big consultancies to help them with design and delivery. The in-house skills are limited to procurement, supplier management, and business partners who act as conduits for business needs and issues. The organization wants to own their IT strategy and architecture but has struggled to recruit and retain the people required, so they only have two people in this space at the moment. They have three major programs, each run by a different consultancy. Each program has its own design authority. Let’s explore some of the problems we often see in scenarios like these:

In-House Capability

The two in-house architects attend the three program design authority meetings and another meeting hosted by the development systems integrator running all the smaller work. There is no way the architects can keep pace with activity, so they are either just a sign-off bottleneck or they are ignored. They’ve tried to combine several design authorities into one but the big programs are running at pace and don’t have time or incentive to review each others’ designs, so they generally agree to disagree and carry on.

Operations Contract

The Operations contract comes out of the OpEx budget, which is heavily constrained, so it has been let with a heavy emphasis on price. The current services have been procured with a monthly run cost to meet SLAs, keep software up to date, and penalties for any downtime. Change is difficult to define, so the contract asked the bidders for a rate card, which the group will use to determine the cost of new work.

This type of procurement drives the supply market to minimize operations cost to the bare minimum to keep the lights on. To win it might even be a loss leader with the supplier needing to make up the deficit through the change work packages. As the saying goes, “You get what you pay for,” so this ends up with Operations being run very lean—the group’s goal is simply to keep things running, and they work under a motto of, “If it’s working, don’t touch it.” 

There is a huge amount of change coming in from the three big programs and the projects under the development contract. This is Operations’s opportunity to learn about the systems they are supporting and raise their overall profit to where it needs to be. Of course any change needs to be very carefully implemented to avoid breaching an SLA for live services. So getting changes into production is very expensive and very slow. It can take months of back and forth as the department and the operations provider fail to agree on the effort estimates and therefore cost of the work packages, which has to happen before anything gets done. Then, the activity starts with a huge amount of discovery as the operations provider brings on more skilled people to make the changes, people they can’t afford to keep there for the under-priced “keeping the lights on” activity.

 Finally, the enterprise demands only experienced people from its supplier, no learning on the job. This results in an unsustainable workforce model and forces the supplier to make excessive use of the contract market.

Development Contract

The multi-year contract for development across all the smaller contracts was let on the basis of the ability to provide specific skills required for the various dev stacks and a rate card. As skills are common among the large multinational suppliers, the contract was won by the bidder who had the lowest rates. This drives the supplier to provide large numbers of low-skill, low-cost people. As we know, fewer, more capable people get work done quicker, better, and cheaper than many low-skill workers. The sum of day rates is not a good proxy for overall development cost, let alone value.

What’s Next

So, in this scenario, there is nothing in this model that incentivizes the suppliers to make each other look good. In fact, it’s quite the opposite: they all stand to get a bigger share of the future revenue if the others fail, so sharing, enabling, trust, and collaboration are in short supply. All the things we talk about in the DOES community are impossible to implement.

Over the last fifteen years, we’ve seen a huge amount of progress, particularly in government. GDS (Government Digital Services) was born in 2011, when the drive to break up the monolithic contracts for IT services began. It’s still going on, but today, many of the bigger departments have a much wider range of IT suppliers. Most of them have more in-house capability than they had back then, and some of them have thriving academy programs growing their own IT talent. Much the same can be said for the private sector over that period.

Most enterprise CIOs we have spoken to are trying to grow their internal IT capability. That shouldn’t be a surprise—the total IT capability they need is ever increasing. Software is still eating the world and an increasing number of firms are realizing that, like it or not, they are in the IT business:

• Business agility is fundamental to survival.
• First-mover advantage has been surpassed by fastest-mover advantage.
• Businesses need to be built to constantly change rather than built to stay stagnant.
• Changing anything in a large business requires technology.
• So survival depends on the ability to deliver technology change fast and reliably.

The question many of these enterprise CIOs are asking is: “Do I have to insource to accelerate my DevOps goals?” There is a lot of evidence out there that suggests the answer is yes. Most of the stories you will hear at the DevOps Enterprise Summits will be about organizations that have had success by building in-house capability. 

The Project to Product Transformation paper from the DevOps Enterprise Forum in 2019 studied fourteen enterprise journeys. Here are some of their top findings:

• “Most companies went from 70% outsourced/30% insourced to 30% outsourced/70% insourced.”
• “To maintain an innovative critical edge, it is recommended that the product team members be employed engineers (insourced) and not temporary contracted resources(outsourced).”
• “Internal intellectual property will accelerate innovation and speed to market…”
• “The most innovative ideas that will drive your business forward come from motivated individuals who feel ownership and a sense of personal connection to the solutions they create and the problems they solve for their customers.”
• “The quality of code will inherently improve if engineers have long-lived experience with the product they own.”
• “In-house engineers will have a better understanding of the overall architecture and ecosystem…”
• “An insourced team of engineers who own a product end-to-end will generally have passion, motivation, and creativity to innovate quality solutions…”
• “You need your teams to have an owner, not renter, mindset. This is very difficult with outsourced teams.”

But insourcing isn’t always practical for organizations that have relied on application and development contracts. Dev and Ops contracts are coming to an end. Growing internal capability is hard and can’t be done overnight, so these organizations need to procure some sort of outside support while they try to grow their in-house capability.

Another question enterprise CIO’s are asking is, “Can the current supplier help?” Global systems integrators that have built their business on AD AM contracts like we described above have some big challenges if they are to be enablers of their clients’ DevOps journeys:

1. A huge DevOps transformation of their own workforce: This can be a much bigger challenge than most organizations because the systems integrators’ workforce is split over many accounts and they are not able to dictate the ways of working. So, each client team has a different transformation journey. This transformation journey has to be a joint effort between the customer and the supplier. In most cases, that requires a very different relationship and a significantly different contractual basis for it.
2. Contracts are won with a huge focus on cost reduction and transfer of Development risk or Operations risks: To obtain that different contractual basis, the change needs to be led by the customer’s procurement function, and they are not often at the forefront of DevOps transformations.
3. Alignment of Procurement, IT, and the business customer (a customer they almost never get to speak to): The transformation will require alignment as the group drives new ways of working across Procurement, IT, and their business customer. This is difficult for the supplier to drive even if their contract with IT encourages them to.
4. Alignment of incentives: Ultimately, most senior management at global systems integrators or consultancies are rewarded on growing the revenue and margin on their accounts and increasing the security of that revenue. Those objectives generally don’t align with what their clients want from them in this new scenario: Helping grow client capability and reducing dependency. Using automation to reduce the effort required. Collaborating with other suppliers in multi-supplier environments and helping everyone deliver their A game

Finally, the last question on many enterprise CIO’s minds is, “Is insourcing easier than fixing the extensive problems above?” Truthfully, insourcing isn’t without its challenges, either. Most enterprises with aspirations to grow their internal IT capability fall short of their goals for two reasons: the what and the how.

“What” problems include:

• The digital transformation is a vague aspiration without a plan or concerted effort.
• Leadership does not agree about what “digital transformation” means or the priorities of such a thing.
• HR does not collaborate with leadership/IT or share ownership of the initiative.
• There is a lot more to growing a sustainable internal capability that the current scope.
• The company struggles to put a compelling proposition to the market.

Growing internal capability and increasing headcount will attract the attention of HR and Finance, so it’s important for CIOs to clearly articulate their plans and get agreement from their peers in both these functions. And because the existing workforce will be involved in recruitment and onboarding, they must also understand the vision. Here’s what you need to make the case:

 A view of the company as is: that is, how many people from each discipline are working on delivery today? What does business demand look like for the next few years and what changes do you want to make to the as is?

Your Company’s Current Capacity

Your Company’s Desired Capacity

Above is the bare bones of a plan that could be used to get the finance director on board. The work is assumed to be staying roughly the same and there is no increase in overall headcount, just a shift to more in-house capability. This should show a saving in overall spend.

You must get HR’s buy-in, since attracting and retaining these new skills into the organization and making the capability sustainable may require some new pay scales and incentives and a new learning and development plan. Your can’t simply hire people and call that a day; you must have a plan to continue the development of those hires and to grow some talent underneath them to create a sustainable workforce.

There is also a need to create a strong proposition and market it. Show how the recruits will be able to work on interesting stuff. Talk about how they will be given the freedom to transform your ways of working and help you introduce modern tool sets—not just to make them more effective but so they are gaining relevant skills. Making the work publicly visible often helps with the employee proposition too. Will they be able to speak at conferences about the progress being made? Several large organizations at the DevOps Enterprise Summits have shared how they’ve used conferences as a recruitment tool and attracted people by open-sourcing some of their developments.

There also needs to be a good scheduling function for project work that considers the internal teams’ development needs when looking at upcoming roles and prioritizes them. Often, the business will want the most experienced person for the job and might ask for a person from the supplier who has done it before, but this should be resisted as it will stall your internal capability build.

Finally, alignment with Procurement is required as the internal capability build cannot succeed unless it is supported by the rest of the ecosystem involved in project delivery. This ecosystem has to feel like one team and have high trust to enable the fast flow we seek. It won’t work for the internal staff members to compete for roles with the contingent labor or the suppliers. Given those suppliers have sustainable workforces with the skills the internal build is focused on, they should be able to help their customer with setting up the environment required for success—but this needs to be part of the commercial scope they are procured for.

Analysts agree that organizations strategy for application development/application maintenance (ADAM) outsourcing must change. The “your mess for less” outsourcing era is dead. It is changing, noticeably faster on the AD side than the AM, where the perceived risk is slowing progress.

Ways Organizations are Procuring 

As contracts end, some of the ways we see organizations trying to fill the gap and align with their internal capability building goals are: Procure help into capability centers of excellence aiming to increase their capacity and improve the practices of these communities, hoping that in doing so these communities will thrive, break down silos by sharing, and present better opportunities for their own people and those they are trying to recruit to develop and learn.

Firms are moving from pure capacity via individual contractors to managed services with a service wrapper that include community and capability advancement. These are usually pure time and materials contracts. There is a lot buyers need to consider to set these up for success so their capabilities grow over time:

Commercially managed service providers are incentivized to grow margins and secure long-term revenue. This is the opposite of the buyer’s goals

As mentioned above, organizations need to quickly mature some kind of scheduling function so the roles that best suit the development needs of their permanent staff are prioritized for them.

Avoid competition for roles. Your staff need to feel like they’re on one team. Having multiple suppliers for the same capability makes this more difficult and makes a coordinated capability development wrapper more difficult to realize.

Organizations need to appreciate that the managed service provider also needs to be developing a sustainable workforce, so they cannot just ask for experts and need to accept that people will learn on the job. When they demand only experts, it often drives the supplier to use contingent labor, which erodes the benefit of procuring a managed service with a capability-
build wrapper.

The center of excellence needs to balance the power in this model with the cross-functional product teams they supply. Long-lived product teams are an enabler. If the center of excellence holds too much power, the product teams cannot put together and keep the teams they need. If the product teams have too much power, the center of excellence cannot plan their strategic growth and must only react to demand. In this case, they often fail through neglect. The main factors to look at are how each is funded (power follows money) and where people feel their “career home” is.

The most evolved example we’ve seen is where HR and IT jointly procured a managed service that included running their academy to develop the internal pipeline of talent and reduce the dependency over time.

Many DevOps evangelists will call out “functional outsourcing” as a constraint rather than an enabler. An alternative many organizations are testing is to procure a managed service for pods or ready-made cross-functional teams. This model also has its own challenges:

1. Do you buy time and materials teams or try to procure the outcomes the business desires from the product or platform? Procurement will usually favor the latter, but this can make inserting the organization’s permanent people to learn from the service provider more difficult.
2. It’s easier to grow product knowledge in this model but less obvious how you grow the capability expertise you need on this in-house side.

So to summarize, whichever model you choose, I think some of the keys to success are:

• Being intentional. Create a sourcing strategy and get leadership alignment across the organization around it, and publish it.
• Get HR on board and actively supporting the capability build.
• Work with procurement and suppliers to define value in a measurable way and work out how this can be included in future procurements.
• Start growing your own talent at the same time as hiring experienced talent. Without skilled teams underneath them, the experienced talent won’t stay long.
• Ask potential partners what models they are currently using and don’t try to buy something that isn’t already in their business model.
• Have open dialogue about the organizational goals and the goals of potential supplier organizations, not just at the organizational level but down to how their people are incentivized to achieve those goals. This understanding is fundamental to building trust, and trust is a critical enabler of DevOps, which contracts often get in the way of.
• As the number of suppliers, or partners, increases, look at how the buyer can incentivize them to help each other shine. Collaboration and trust between supply chain partners is hard, but also essential.

- About The Authors

Ben Grinnell

Evangelist for modern IT practices that help organisations use their technology to learn & act fast, safely and at scale

Follow Ben on Social Media

• 
•