4 - Finding the Right Partner

It’s not unlike a marriage, the partnership. All the effort and good intentions in the world can’t make things right if you choose poorly in the first place.

The reality in pretty much every large organization is that you are not working alone. Somewhere in your organization, smaller or larger parts of your IT are either outsourced or at least have an SI helping you deliver the IT that is required to run your business. This must be managed correctly to make sure you retain sufficient IP while getting the benefits from working with an experienced partner.

There is a lot of talk in the industry about how important culture is and that Agile and DevOps are mostly cultural movements. You will hear a lot of stories and examples of how to improve the culture within your organization when you attend conferences or read blogs. I completely agree that your organizational culture is crucial to being successful, but I wonder why there is not more discussion on how to align the cultures of SIs and the organizations they work with. To date, most company–SI relationships are very transactional and driven through vendor management. Words like partner, partnership, and collaboration are often used, yet the results on the ground are too often a misaligned culture due to many reasons.

In this chapter, I want to help improve the situation based on my experience of being on both sides as an SI and as a client of SIs. There are ways to improve the relationship and make it more meaningful. And then there are certain pitfalls that you need to avoid. At the end of the day, both sides want the relationship to be successful—at least that is my experience. It is often a lack of context and limited experience that are preventing us from extending organizational culture beyond the traditional organizational boundaries.

Many organizations going down the path of Agile and DevOps determine that the best way to be successful is to transition to Agile and DevOps by initially relying on in-house capabilities due to the higher level of control over your people and the environment they work in (salaries, goals, incentives, policies) than you have over the people of your SI.

Unless you are really willing to take everything back in-house, you will at some stage start working with your SI partners. Fortunately, there are plenty of benefits to working with a partner. The right partner will be able to bring you experience from all the companies they are working with, they have relationships with your product vendors that are deeper than yours, and they can provide an environment that entices talent to join them that you might not be able to provide. IT is at the core of every business nowadays, but not every company can be an IT company. Strategic partnerships allow you to be a bit of both—to have enough intellectual property and insight into the way your system is built and run while permitting your strategic partner to deal with much of the core IT work. Be open and willing to delegate IT when needed in order to maintain balance—and success—overall.

The world of technology is moving very fast, which means we have to learn new technologies all the time. If you have a good relationship with your partner, you might be able to co-invest in new technologies and support the training of your partner’s resources; and in return, you might get reciprical benefits in exchange for a credential that the partner can use to showcase their ability with the new technology. My heart warms every time I see a conversation like that take place—where two companies sit together truly as partners to look for win-win situations. Taking an active interest in the world of your partners is important.

In some of my projects I was part of a blended team in which my people’s experience in technology worked together with the client’s employees’ intimate knowledge of the business. Those client teams could maintain and improve the solution long after we left, which is what real success looks like. We not only built a better system but left the organization better off by having upskilled the people in new ways of working. As discussed in the application portfolio chapter, there might be applications where you don’t want to build in-house capability and for which this approach does not apply.

For your innovation and workhorse applications, you want to leverage the technology and project experience on the SI side with the business knowledge and continued intellectual property around the IT landscape from your organization. You should avoid having vendors who do not align with your intended ways of working and those whom you don’t have visibility into their processes and culture to ensure they align with yours—otherwise, knowledge of your systems sits with individuals from these vendors/contractors, and most changes happen in what appears to be a black box mode. This makes it very difficult for you to understand when things go wrong, and when they do, you don’t see it coming. One way to avoid this proliferation of vendors and cultures is to have a small number of strategic partners so that you can spend the effort to make the partnerships successful. The fewer the partners, the fewer the variables you most deal with to align cultures. Cultural alignment in ways of working, incentives, values, as well as the required expertise should really be the main criteria for choosing your SI besides costs.

Your organization needs to understand how IT works and needs to have enough capacity, skill, and intellectual property to determine your own destiny. As we said before, IT is at the core of every business now; a minimum understanding of how this works is important so that you can influence how IT supports your business today, tomorrow, and the day after. But what does it mean to have control of your own destiny in IT? While there are some trends that take “headaches” away from your IT department (think cloud, SaaS, or COTS), there is really no way of completing outsourcing the accountability and risk that comes with IT.

You will also have to think about the tools and processes that your partners bring to the table. It is great that your vendor brings additional tools, methods, and so on, but unless you are able to continue to use those tools and methods after you change vendors, they can become a hindrance later if those tools are critical for your IT delivery. If they are not transparent to you and you don’t fully understand how they work, you have to take this into account in your partnering strategy, as you will be bound to them tighter than you might like.

Fortunately, there is a trend toward open methods and standards, which makes it a lot easier to communicate across company barriers. Agile methodologies like the Scaled Agile Framework (SAFe) and Large-Scale Scrum (LeSS) are good examples. It is likely that you will tailor your own method based on influences from many frameworks. When you make using your method a condition for working with your organization, it helps you keep control. You do, however, need to make sure your methods are appropriate and be open to feedback from your partners. Your partners should absolutely bring their experience to the table and can help you improve your methods.

Standards are also important on the engineering side. Too many organizations have either no influence over or no visibility into how their partners develop solutions. Practices like automatic unit testing, static code analysis, and automated deployments are staples. Yet many organizations don’t know whether and to what degree they are being used by their partner. Having the right structure and incentives in place makes it easier for your partner to use those practices, but it is up to you to get visibility into the engineering practices being used for your projects.

One practical way to address this is to have engineering standards for your organizations that every team has to follow no matter what, whether it’s in-house, single vendor, or multivendor. These standards will also provide a common language that you can use with your partners to describe your vision for IT delivery (for example, what your definition of continuous integration is). Luckily, there is a lot of work out there that you can leverage to describe these standards; you don’t have to reinvent them from scratch. For inspiration, look into popular software engineering books such as Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble and David Farley; The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas; and Release It!: Design and Deploy Production-Ready Software by Michael T. Nygard.

In the past, contracts with system integrators had something mildly Machiavellian to them, where a company creates a terrible work environment in which nobody wins. One of the models that suffers from unintentional consequences over time is the develop-operate-transition (DOT) contract. I am not sure how familiar you are with this contract term, so let me quickly explain what I mean. DOT contracts work on the basis that there are three distinct phases to a project: a delivery phase, where the product is created; an operate phase, where the product is maintained by another party; and a transition phase, where the product is brought back in-house.

Many organizations use two different vendors for development and operations, or at least threaten to give the operate phase to someone else while working with a delivery partner. There are a few things wrong with this model. First of all, if you have a partner who is only accountable for delivery, it is only natural that considerations for the operate phase of the project will be less important to them. After all, the operate activities will be done by someone else. The operate party will try to protect their phase of the project on their side, and you will likely see an increasing amount of escalations toward hand-over. There is no ill-intent here, it is just a function of different focuses based on the scope of the contracts.

The second problem is that many DOT projects are run as more or less black box projects, where the client organization is only involved as the stakeholder and, until it gets to the transition phase, has not built internal knowledge on how to run and maintain the system. This causes problems not only during transition but also when navigating misalignments between delivery and operate parties. With just a little tweaking, we can bring this model up to date. Choose a partner that is accountable for both the delivery and operation. You can change the incentive model between the two phases to reflect the different characteristics. Make sure that there is team continuity between phases with your partner, so that people who will operate the solution later are already involved during delivery.

Across the whole project life cycle, embed some of your own people into the team so that you can grow your understanding of the solution and what it took to create and support it. Ideally, have tandem roles where both your partner and your own organization put people in (e.g., project manager, delivery team lead, system architects) to share responsibilities. In this model, the downsides of the old DOT model are addressed, and you can still leverage the overall construct of DOT projects and combine it with DevOps principles. My best projects have used this model, and the results have been long lasting, beyond my involvement.

As mentioned earlier in the book, I have been on both sides of a partnership as a system integrator (SI) providing services to a client and in staff augmentation roles, where I had to work with SIs. It is quite easy to blame the SIs for not doing the right thing—for not leveraging all the DevOps and Agile practices and for not experimenting how to do things better.

The reality is that every person and every organization does what they think is the right thing to do in their context. No one is trying to be bad in software development. Unfortunately, sometimes relationships have been built on distrust: because I don’t trust you, I will have a person looking after what you are doing. The vendor then creates a role for someone to deal with that person, and both sides add more process and more documents on each side to cover their backside. More and more process, roles, and so on get introduced until we have several levels of separation between the real work and the people talking to each other from both organizations. To make things worse, all this is just non-value-added activities as payment for the distrust between partners.

But imagine you trusted your SI like you trust the best person on your team. What processes and documents would not be required, and what would that do to the cost and speed of delivery for you? Despite these potential advantages, there is way too little discussion on how to make the relationship work. How could we create a joint culture that incentivizes all partners to move toward a more Agile and DevOps way of working, and how do we do this when we have long-lasting relationships with contracts already in place?

First of all, I think it is important to understand your partner; as in any good marriage, you want to know what works and what doesn’t work for your partner. And when I say partner, I mean partner. If you do the off project with a vendor and it is purely transactional, then you don’t have to worry about this. But if you work with the same company for many years and for some of your core systems, then it does not make sense to handle them transactionally. You want to build a partnership and have a joint DevOps-aligned culture.

In a real partnership, you understand how the SI defines his or her success, and both sides are open about what they want from the relationship. Career progression has been one of those examples, and I have been lucky, as most of my clients understood when I discussed the career progression of my people with them and why I needed to move people out of their current roles. From a company perspective, they would have preferred to keep my guy in the same role for many years; but for me, that would not have been good, as my people would have looked for opportunities somewhere else.

Of course, all of this goes both ways, so you should not accept if the SI wants to behave like a black box—you want the relationship to be as transparent as you feel is right. You have the choice to buy a “service” that can be a black box with only the interface defined. In this case, you don’t care how many people work on it or what they are doing; you just pay for the service. This gives the SI the freedom to run independently—a model that works well for SaaS—and you might have some aspects of your IT that can work with a XaaS mind-set.

For other projects that include working with your core IT systems and with people from your organization or other third parties, you want transparency. A vendor that brings in their own tools and methods is basically setting you up for a higher transition cost when you want to change. You should have your own methods and tools, and each SI can help you improve this from their experience. You don’t want any black box behavior. Fortunately, common industry frameworks such as SAFe or Scrum do help get to a common approach across organizations with little ramp-up time.

Thinking about partnerships, you should remember that you cannot outsource risk. I have often seen that the client is just saying “well, that’s your problem” when an SI brings up a possible situation. The reality is that if the project fails, the client will be impacted. Just closing your eyes and ears and making it the SI’s problem will not make it go away. Think of the disaster with the Australian census, where the delivery partner took a lot of negative publicity,1 or Healthcare.gov in the United States, where vendors blamed each other for the problems.2 Even if the vendors were at fault, the organizations took a huge hit in reputation in both cases; and given that they were public services, it created a lot of negative press.

In Agile, we want flexibility and transparency. But have you structured your contracts in a way that allows for this? You can’t just use the same fixed-price, fixed-outcome contract where every change has to go through a rigorous change control process. Contracts are often structured with certain assumptions, and moving away from them means trouble. Time and materials for Agile contracts can cause problems because they don’t encourage adherence to outcomes—something that is only okay if you have a partner experienced with Agile and a level of maturity and trust in your relationship.

Agile contracts require you to take more accountability and be more actively involved in the scope management. In my experience, the best Agile contracts are the ones that are built on the idea of fixed capacity aligned to some outcome and flexible scope (the delivery of a number of features for which some details are defined as the project progresses).

There are ways to create Agile contracts that work for all parties, so let’s explore some basics of a typical Agile project. While Agile encourages teams to deliver production-ready code with each sprint, the reality often means that the delivery process is broken down into four phases:

With that in mind, a contract should reflect these four phases. As a departure from the common deliverable- or phase-based pricing, where your partner is being paid based on deliverable (such as design documents) or completion of a project phase (such as design or development), these contracts reflect user stories as units of work. Each story goes through the four phases described above, and payments should be associated with that; a certain percentage should be paid as a story achieves the definition of ready and the different levels of done. Here is a sample breakdown that works well:

With this contract model in place, we have a contractual model that ties the delivery of scope to the payments to the vendor. In my experience, this model is a good intermediate point of having flexibility while only paying for working scope. There are things that you want to provide as part of the contract too: an empowered product owner who can make timely decisions, a definition of the necessary governance, and a work environment that supports Agile delivery (physical workspace, IT, infrastructure, etc.). Very mature organizations can utilize time and material contracts as they operate with their own mature methodology to govern the quality and quantity of outcome; less mature organizations benefit from the phased contract outlined above.

Another aspect of contracts is aligned incentives. Let’s start with a thought experiment: You have a really good working relationship with an SI over many years, but somehow, with all the legacy applications you are supporting together, you didn’t invest in adopting DevOps practices. You now want to change this. You agree on a co-investment scheme and quickly agree on a roadmap for your applications. A few months in, you see the first positive results with demos of continuous integration and test automation at your regular showcases. Your SI approaches you at your regular governance meeting and says he wants to discuss the contract with you, as the average daily rate of his overall team has changed. What do you expect to see? That the average daily rate of a worker has gone down thanks to all the automation? I mean, it should be cheaper now, shouldn’t it?

Well, let’s look at it together. The average daily rate is the average rate calculated on the basis that less-skilled work is cheaper and work that requires more skills or experience is paid higher. The proportion of those two to each other determines the average daily rate. When we automate, what do we automate first? Of course: the easier tasks that require fewer skills. The automation itself usually requires a higher level of skill. Both of these mean that the proportion of higher-skilled work goes up and, with it, the average daily rate. Wait … does that mean things become more expensive? No. Since we replaced some work with automation, in the long run, it will be cheaper overall. If you evaluate your SIs based on the average daily rate, you have to change your thought process. It is overall cost, not daily rates, that matters.

The diagram in Figure 4.1 might help you visualize this counterintuitive outcome. While the average daily rate increased for the same piece of work (relative proportion of higher-cost work increases), the total cost decreased (as there is less overall work to be performed manually). Too many organizations use average daily rate to evaluate their partners and hence incentivize a push for more low-skilled manual labor instead of increased automation. Automation is actually a win-win scenario, as the systems integrator reduces their risk from manual activites while maintaining higher average day rates. At the same time, the client also benefits from the reduced risk and a lower overall cost point.

Figure 4.1: Overall costs versus daily rates: Automating work reduces overall cost but increases average cost rate

I also want to look at the company–service provider relationship from the other side—the side of the system integrator. This perspective is not spoken about much, but given that it is usually my side, I want to show you how we think and what our challenges are.

The influence of DevOps culture has started to transform relationships to be more open. Even in the request for proposal processes, I can see an increased openness to discuss the scope and approach to delivery. I have worked with government clients for whom, during the process, I was able to help them shift the request to something more aligned with what they were after by adopting an Agile contract like the one I mentioned earlier. Originally, they wanted to pay per deliverable, something unsuitable for Agile delivery. Together, we can usually come up with something that works for all parties and makes sure you get what you are after.

As system integrators, we are still relegated too often to talking to procurement departments that are not familiar with modern software delivery. Contracts are set up with such efficiency that there is no room for experimentation, and where some experimentation is accepted, only positive results are “allowed.” If you think about your relationship with SIs, I am sure you can think of ways to improve the relationship and culture to become more open and aligned with your goals. I have added a little test to diagnose your culture alignment in the exercises of this chapter.

I want to spend the last part of this chapter on partner evaluation. Clearly, you don’t want your partner to just take your money and provide a suboptimal service to your organization. So what can you do to govern the relationship while considering the open culture you are trying to achieve? And how do you do that while still having means to intervene if the performance deteriorates?

In the example of a project being done by one SI, you can use a balanced scorecard that considers a few different aspects:

One of them is delivery; in this area, you care about quality and predictability of delivery. How many defects slip into production, how accurate is the delivery forecast, and how are the financials tracking? You might also want to add the evaluation of delivery quality by stakeholders, potentially as an internal net promoter score (NPS, which quantifies the percentage of people recommending your service) of business stakeholders. Cycle time and batch size are two other metrics you should care about to improve the overall flow of work through your IT.

The second aspect is technical excellence. At a bare minimum, you want to look at the compliance with your engineering methods (unit testing, test automation, continuous integration, continuous delivery …). If your delivery partner is taking shortcuts, technical debt will keep increasing, and at some stage, you will have to pay it down. In my experience, clients do a good job checking the quality of the end product but often fail to govern the engineering pratices that prevent technical debt from accruing. Providing a clear set of expectations around engineering methods and regular inspection (e.g., showcases for test and deployment automation, code reviews, etc.) reduces the chances of further technical debt. I have had great discussions about engineering strategies with clients during such showcases.

The third aspect is throughput; you can approach this from a story point or even stories per release perspective. I assume, though, that your releases will change in structure as your capabilities mature. In light of this, cycle time and batch size are better measures. The interesting aspect of cycle time is that if you optimize for speed, you tend to get quality and cost improvements for free, as discussed earlier.

You should also reserve a section of the scorecard for improvements. Which bottlenecks are you currently improving, and how are you measuring against your predictions? You can add costs per service here (e.g., the cost of a deployment or a go-live) to see specific improvements for salient services in your organization.

Last but not least, you should have a section for the interests of your partner. Career progression, predictability, and market recognition come to mind as some of the noncommercial aspects of the relationship. Of course, revenue and profitability are two other areas of interest that you want to talk about from a qualitative perspective—is this a relationship that is beneficial for both? I recommend having a section of the scorecard where you track two or three priorities from the partner perspective and evaluate those together on a regular basis.

First Steps for Your Organization

Horses for Courses—Determining the Partners You Need

This whole chapter is about finding the right partner that fits your ambition and culture. But the truth is that you probably need different partners for different parts of your portfolio. If you have done the application portfolio activity in chapter 2, this exercise will be easier. There are three different types of applications for the purpose of this exercise:

Differentiator applications: These applications are evolving very quickly, are usually directly exposed to your customers, and define how your company is perceived in the marketplace.
Workhorses: These applications drive the main processes in your organizations, such as customer relationship management, billing, finance, and supply-chain processes. They are often referred to as enterprise or legacy systems. They might not be directly exposed to the customer, but the company derives significant value from these applications and continues to make changes to them to support the evolving business needs.
True legacy: These applications are pretty stable and don’t require a lot of changes. In general, they tend to support your more stable, main processes or some fringe aspects of your business.

Based on these classifications, review your partner strategy to see whether you need to change either the partner itself or the way you engage with the existing one. For the first two categories, you want to engage strategic partners. For legacy applications, you are looking for a cost-effective partner who gets paid for keeping the system running. The incentives for your strategic partners are different. Your partners for the workhorse applications should be evaluated by the efficiencies they can drive into those applications; for the differentiator applications, you want someone who is flexible and will co-invent with you. The outcome of this activity will feed into the second exercise for this chapter.

Run a Strategic Partners Workshop for Your Workhorse Applications

Organizations spend the majority of their money on their workhorse applications. This makes sense, as these applications are the backbone of the business. For this exercise, I want you to invite your strategic partners who support your workhorse applications (and possibly the differentiator ones) to a workshop. You can do this with all of the partners together, which can be more difficult, or by running separate workshops for each partner. It is important to tell them to assume that the current contract structure is negotiable and to be open-minded for the duration of the workshop.

The structure of this workshop should be as follows:

Explain to your partner what is important for you in regard to priorities in your business and IT.
Discuss how you can measure success for your priorities.
Let your partner explain what is important for them in their relationship with you and what they require in their organization to see the relationship as successful.
Workshop how you can align your interests.
Brainstorm what the blocks are to truly achieve a win-win arrangement between your two organizations.

The key to this workshop is that both sides are open-minded and willing to truly collaborate. In my experience, it will take a few rounds of this before barriers truly break down—don’t be discouraged if all of the problems are not solved in one workshop. Like everything else we talk about, it will be an iterative process, and it is possible that you will realize that you don’t have the right partners yet and need to make some changes in the makeup of your ecosystem.

Do a Quick Self-Check about Your Partnering Culture

A quick test to evaluate your DevOps culture with your system integrator:

Are you using average daily rate as indicator of productivity, value for money, and so on?
+1 if you said no.
Do have a mechanism in place that allows your SI to share benefits with you when he improves through automation or other practices?
+1 if you said yes. You can’t really expect the SI to invest in new practices if there is no upside for him. And yes, there is the “morally right thing to do” argument, but let’s be fair. We all have economic targets, and not discussing this with your SI to find a mutually agreeable answer is just making it a bit a too easy for yourself, I think.
Do you give your SI the “wiggle room” to improve and experiment, and do you manage the process together?
+1 if you said yes. You want to know how much time the SI spends on improving things by experimenting with new tools or practices. If she has just enough budget from you to do exactly what you ask her to do, then start asking for an innovation budget and manage it with her.
Do you celebrate or at least acknowledge the failure of experiments?
+1 if you said yes. If you have an innovation budget, are you okay when the SI comes back to let you know that one of the improvements didn’t work? Or are you just accepting successful experiments? I think you see which answer aligns with a DevOps culture.
Do you know what success looks like for your SI?
+1 if you said yes. Understanding the goals of your SI is important, not just financially but also for the people who work for the SI. Career progression and other aspects of HR should be aligned to make the relationship successful.
Do you deal with your SI directly?
+1 if you said yes. If there is another party involved, such as your procurement team or an external vendor, then it’s likely that messages get misunderstood. And there is no guarantee the procurement teams know the best practices for DevOps vendor management. Are you discussing any potential hindrance in the contracting space directly with your SI counterpart?

If you score 0–2 points, you have a very transactional relationship with your SI and should consider getting to know him or her better to improve the relationship. If you score 3–4 points, you are doing okay but with room for improvements, so you could run a partner workshop to address the other dimensions. If you score 5 or 6 points, you are up ahead with a real partnership that will support you through your transformation. Well done!

This concludes part A, which is about creating a thriving ecosystem for good IT delivery. The material in this first part is of strategic nature, which means changes here will take time and require efforts across your whole organization. Don’t try to change everything today—I’d rather you understand the ideas in this part of the book, do some of the activities, and then, as you put your plans together for the next year, next quarter, or next month, start addressing some of the things you’ve learned. None of these are quick fixes, so steady wins the race. In the next part, I will talk about the people dimension. People are at the center of everything you do, so providing them with the right support is crucial to your success.