The Software Outsourcing Show, Episode 6: How to Avoid Business Risks in Software Development Outsourcing (Pt. 3)

In this week's episode, Bobby Dewrell, Vice President of Delivery of Accelerance speaks with Steve Mezak, Chief Executive Officer of Accelerance about the business risks associated with software outsourcing. Listen as Steve and Bobby discuss how the improper identification of business risks will negatively affect your software development outsourcing project. Let us teach you how to avoid these risks and ensure a successful outsourcing engagement.

The Software Outsourcing Show is on a mission to explain best practices for strategies, partner selection and ongoing management of outsourcing your software outsourcing development.

The Software Outsourcing Show is the #1 source for information, lessons learned, and exclusive insights into outsourcing. The show is produced by Accelerance, the leading consulting firm dedicated to helping companies reduce risk with software outsourcing.

Transcript:

Bobby: Hello, and thank you for joining "The Software Outsourcing Show." My name is Bobby Dewrell and I'll be your host. Today, we're gonna talk about business risks. And if you recall in our series that we've been talking about, the 15 common risk factors that could doom your software project before it begins, that we see those 15 risk factors across three different dimensions, management risks, business risks, and technology risks. Now, we've previously talked about the management risk and covered that with Jim Marascio last week. And this week, I had the opportunity to sit down with Steve Mezak, Founder of Accelerance, author of "Software Without Borders" and co-author of "Outsource or Else!" and also has recently written some blogs featured on cio.com about these very subjects. And so Steve and I had the opportunity to talk about some business risks and I wanted to share that conversation with you this week. Good morning. How are you doing today?

Steve: Hey, great. Thanks Bobby. Looking forward...

Bobby: I really appreciate you joining me today and coming in and talking about this. You know, I know in the past, Jim and I have talked about it before, we kind of introduced the concept of the, you know, the 15 risk factors that we [inaudible 00:01:10] might want to see, and then talked about the three dimensions that we see them across, you know, being the management risk, business risk, and technology risk. And I, you know, I really wanted to bring you in, because I know you recently had that article featured on cio.com, you know, really talking about business risk and how that can impact software outsourcing. I really wanted to say, you know, like where do we start? Like what are business risks? What do we mean by that?

Steve: Well, I think the focus with outsourcing has always been, and the issues with it, has always been on the technical side and people rarely look in the mirror, the decision makers, to see, well, wait a minute, what is it that I'm doing or what is it that we're really trying to do as a business and why are we using outsourcing? So, it has to do with...it's not so much a technical thing, it's more of really understanding your business and how the software will impact it, how it relates to the business, your growth, your desire for growth and making sure all of the factors are considered and covered as you're engaging with a great software development team.

Bobby: Well, can some of that be the realization today that, you know, I've always kind of laughed about the notion of IT alignment with making sure we get aligned and, you know, I made the comment a few years back that, you know, I think we're at a point in the world where we're all to some degree technologists, right? I mean, technology just permeates every bit of the business.

Steve: Right. Business and personal life too. I mean, even my grandmother's using, you know, an iPhone. Well, not my grandmother, but you know, I mean, I'm a grandfather and I'm using an iPhone.

Bobby: Great, yeah. Absolutely, I got where you're going. Yeah, you're right. I mean, it's technology is everywhere, you know, and it's an integral part of business today. And so...

Steve: And I think it's a lousy excuse for business executives to say, "Well, I'm not technical, I'm not going to bother with that level of detail." Well, we're not asking you to write code and debug code, we're asking you to understand the relationship of the technology to your business and the impact it has on your customers and clients. That's the main thing.

Bobby: All right, so let's talk about that. If we talk about that and take our five types of risks, sort of those archetypal types that we've put out there, I think first, you know, we always talk about metrics, right? And not having a clearly-defined metric.

Steve: Right, now on the technical side it's lines of code, it's features per sprint, things like that. That's not what we mean here. We mean what metrics as it affects your business, do you define or not define as the case may be? So, I think a good example is adding features to an application so that when a user logs in, he or she can do valuable things, useful things. But forgetting about how you are acquiring those users, you know, in a growth hacking type of scenario and that often requires features to be added to the software so there's a metric, you know, growth of users per week, per month, whatever the metric is, or even having some...in the growth hacking world they talk about having a North Star metric, one that you're really aiming for with the application in your business. And, you know, for someone like Airbnb it's bookings per month, it's not features and, you know, different things like that. It's how many bookings can we have and what do you have to have in the software in order to enable the achievement of that metric? So, that's the kind of metric that sometimes going into software development that business executives are not thinking about.

Bobby: Right. And so, it's like, you know, what I just heard you say is it's those quantifiable business opportunity metrics, right? Whether your bookings per month have nothing to do with what technology you're using. It's about gaining market share, it's about increasing your transaction speed, or, you know, how do you work with customers quicker and faster, right, and that kind of thing.

Steve: Yeah.

Bobby: Excuse me. You know, it's one of those and I think you mentioned it in your article too, it's following the old Peter Drucker, right? And I know I'm gonna absolutely kind of just mess up the phrase but, you know, "If you can't measure it, you can't make it better." So, to paraphrase him.

Steve: Yeah, exactly. Almost exactly.

Bobby: Close enough, right? So, we talked a little bit about undefined metrics. And that's really sort of that phases that you need, sort of [crosstalk 00:06:14] builds from. And then, you know, number two, we talk about inconsistent priorities.

Steve: I think it's related to the metrics because, you know, the bookings per month, or users per week, or whatever it is, might be an important priority for the marketing executive, but not necessarily for the technology executive, or even the CEO, who may have other, you know, ideas or a different vision. So, whoever has the ear of the development team, well, we can't get what's done, what actually gets implemented and so it's important to have that agreement amongst the team that's leading the company as to what the software should do.

Bobby: And I think, you know, some of that was sort of the misconstrued notion of what agile or what continuous integration, or continuous deployment can mean. Because, you know, I've found that sometimes that when business leaders hear the concept of, you know, agile and we can do stuff in sprints, well, that means I can change my mind every sprint. Or with continuous integration, or continuous deployment, "Hey, I just read an article about this. I've got this great idea. Let's put it in. I want it in there today on the first appointment." Is that...

Steve: Yeah, I mean, that's a good example of trying to implement continuous deployment, some sort of technical aspect of it, you know, microservices, whatever, is that the priority? Well, that's a very low-level technical thing, but if that's what the development team is focused on, rather than something that really impacts the functionality and the growth of your business, then, you know, it would be an example of an inconsistent priority between the different leaders on the team.

Bobby: Right. And so, I think, you know, to your point, the way they tie in, if you don't know exactly what you're measuring, if you haven't clearly defined those metrics, you don't really know what's important, or you haven't said what's important so, now, you're kind of shifting back and forth and ebbing and flowing in different ways, right?

Steve: Yeah. Yeah, I think another good concept here to introduce at this point with priorities is the idea of every release of your software to, you know, real users or even to the set of test users should have kind of a hypothesis that you're testing. It's a set of features that you're implementing now because you think that users will have this need and will have taken advantage of this, but sometimes...and so, you don't know for sure so you make the release, you essentially test it out with the user base and see what they think. And then using that information, you can help change your priorities based on what you learn. So, that's the advantage of agile, it's not that you can randomly change, you know, every sprint or every other sprint. Use what you've released and what you've learned in order to make those changes.

Bobby: Right. And it's a very methodical and it's a well-thought out approach. And it's not really a change in priority, you're still going after the same priority. I mean, really when we talk about it, you know, having spent some time in product management and program management, I, you know, I told somebody at one time I felt more like a hostage negotiator than an actual technologist sometimes, right. And outsourcing doesn't really change that, right? I mean, that's not something that you're gonna change with outsourcing, these are just fundamentally things that you need to know whether you're gonna do it in-house, whether you're gonna do it out of house, whichever way you go.

Steve: Yeah, we're talking about business priorities here that a development team no matter where they are not really gonna know and they'll just do what you tell them. I mean. A good development team will push back especially when it comes to technical decisions, but in terms of the business decisions they don't necessarily know especially if you're like doing let's say a financial application and you outsource it to a formerly communist country, or even it's still a communist country, they don't have the same business concepts built into their lives, their careers. I remember one time we had a heck of a time explaining the difference between a purchase order and a back order to a team in St. Petersburg, Russia. You know, because it's just, you know, it's just a concept they just were not familiar with.

Bobby: My story that I love to tell is, is trying to explain the difference between a bribe and a tip. So, all right. So, undefined metrics, right, or not clearly defined metrics, some inconsistent priorities. And then this one, and we see it a lot, it's not having enough executive champions, right? Not having enough people in the high enough levels to kind of move some of those...

Steve: Right, right. Whose project is this anyway, you know, kind of a feeling or it becomes...I think one example is where the application was developed by one team, but the operations team led to host it and make it available to all the users within the company was not on board and so they didn't have all the right equipment or the right resources. They hadn't been brought into the whole process soon enough in order to plan, plus they had their own budget issues and whatnot. So, this pet project of somebody else is the way we think of it. You know, we just don't have time for that, but yet, you know, it was critical for the business.

Bobby: Yeah, you know, I actually I had an example of that, you know, in prior lives working with a big financial institution and they had...the owner of the data warehouse had come up with this great idea to serve one market segment and, you know, we were trying to work through this and everybody, "Oh he's, you know, he's the business champion, he's the business champion." But in the end he didn't really have the business, right? And so, when we sat down with the business leaders and said, "Hey, we're struggling with this one little concept, what's here?" And they basically said, "You know what? We've been doing this in spreadsheet for 10 years and I don't have any inclination of ever leaving my spreadsheet." And you kind of go, "Okay well..."

Steve: I have this better mousetrap, and yeah. Well, and that's a good example I think of, you know, not being aligned with what the customers or the market would need, and having people on your own team that can help prioritize the features and be, you know, really be a champion for the right features and functionality. That's what's needed. It comes down to, in a way, to the culture of your business as well. Is everybody working together? Is the CEO or the ultimate leader of this bringing everybody together to make sure everybody's pulling in the same direction? That's what can often derail an outsourcing engagement or any software development engagement, but it's easier to point fingers when you're outsourcing over there.

Bobby: Right. Right. So, now, let's talk a little bit about, you know, sort of so maybe we have some executive champions and we've got the right level, you know, the next kind of gotcha that we can get is a lack of team engagement. What do we mean by that exactly?

Steve: I agree with you, Bobby, but I don't have time to work on that thing. Yeah, yeah, yeah. It's that kind of a thing, or even the next level down there can be issues where often technical people in your employment feel threatened by working with people from outside. We had one client in Denver, they're developing an application and doing some testing and the head of QA called a meeting with the outsourced QA team at 3:00 in the afternoon for Denver time. Unfortunately, you know, she didn't realize it was at 3:00 in the morning in India, the teams they were using. So, like, you know, it was really a lack of understanding, a lack of engagement with the whole idea of outsourcing to get the job done and the adjustments you have to make in order to have that work. You know, so that was one example. So, assuming even the executive team may be aligned or working together, then the next level down, there has to be an engagement. And people have to take the time to do what's required. Another example is where the development team, let's say, the beginning of a sprint has a lot of questions about priorities and what should be next, and there's no response from the client. This is another issue that often comes up and needs to be corrected immediately.

Bobby: Well, and this is really, I mean, in a way, this is kind of one of the hardest ones and probably one of the most frequent ones because, you know, one of the key reasons to outsource is, you know, that you need that extra help, right? You don't have enough time to get everything done, but that doesn't mean that, you know, suddenly you get to walk away from it all, right?

Steve: Yeah. And I think the distance in between is what leads to that attitude and a key element of overcoming this issue, we wrote about this in "Outsource or Else!" too, the book, the business fable that we wrote, is going and visiting the outsourced team. So, it's not like those guys over there, wherever it...in some exotic place it is, they're real people, you know, they have families, they, you know, they love the technology as much as you do, but it's developing that personal relationship so that you know if you're talking to Sanjeev, or Luis, or Andre, you know, that person, who they are and what they're all about.

Bobby: Yeah, absolutely. I agree with you there and I know...you know, it's made a difference for me when you get to meet people, it humanizes the whole aspect of it, right?

Steve: Exactly.

Bobby: Which I know sounds like a crazy thing to say. But it is a lot easier when you don't know somebody to just assume that they're evil incarnate, right?

Steve: But you go and visit and you realize, you know, they don't have horns, right?

Bobby: Exactly.

Steve: On their cars maybe, but not on their heads.

Bobby: So, now we come to number five and number five is no partnership contract. So, let's talk about that a little bit because I know that one's...everybody's thinking, "What are you talking about? We signed an MSA, we signed an SoW.

Steve: Right, right. Yeah, and a lot of times I think there's a history of coming at outsourcing from a purchasing perspective and from a contract negotiation perspective, then this acronym SLA or service level agreement just does not really make sense in a custom software development engagement because, what is the level of service that you expect? Is it a certain velocity? Is it a certain number of features or achievement of business metrics? It's really hard to push those kinds of metrics on to...you know, in a very analytical way, on an outsourced development team. So, that's why we think of it as not so much as a contract with your outsourcing company, but as a covenant. You know, when you get married, you don't have a contract. Well, maybe you have a prenup, but you know, the relationship itself is governed by a covenant. It's an agreement to work together, to do things together, and communicate and talk things out. That's exactly what software development is all about. And that's a good way to look at it.

Bobby: Right. And I like that idea of a covenant because it's more encompassing, right, than just a contract. And I mean, we need to make sure that we have the same methodical approach, that we're in this together and it's that concept, I know we've talked about it a few times on the show and I know we talk about it all the time with engagements, but it's that one team. That's what we're really pushing for.

Steve: Yeah, I've seen there's a movement about five, six years ago about, what was it, results-oriented outsourcing and we're really making it clear that this is the goal, this is why we're outsourcing and therefore outsourcing company, you should participate in the success or failure of that initiative. That's really hard to do with custom software development. Yeah, if you're installing a large application like SAP and you have to get it up and running by the end of the year, and it has to achieve certain goals with the number of purchase orders you have in it or something, I don't know, you know, you might be able to do that with a packaged app, but with custom software development where you're kind of making it up as you go along or sprint by sprint it's really impossible, I think, to use that kind of a metric to govern your relationship.

Bobby: Right, right. And again, you know, it's a relationship, right? So, if we kind of followed along, and we know the people, and we're there, and we're a little more invested, this is the kind of thing that we're talking about.

Steve: Right. Exactly.

Bobby: So, Steve, so we talked about the five, all within the kind of business category, and it's knowing those metrics and making sure they're clearly defined, having some consistent priorities, making sure that we've got the right people at the right level that want the product, right, or the service or want what we're doing, that the team is engaged and that we have that, and I will, I'll use that word covenant, right, that we have that agreement, that strong agreement between the two and that really will make sure that we've mitigated these business risks as much as possible, right?

Steve: Yeah, you know, and as you went through that list I'm thinking, yeah, yeah, yeah. Okay. Great. I get it, sort of, you know, if I'm a listener to this, and these are not really impossible problems to solve, but I think it points to the need or the benefit of having a third-party come in and really look at your organization and be able to judge and help you objectively see what's really going on, and where you're strong, and where you're weak. That's what our coaching service is all about. So, you know, you may think your swing is just fine, but when a coach is looking at it from over there, instead of from in your own head, you get a different perspective and an improved performance. And that's what we're all about.

Bobby: Yeah, absolutely. And it's about trying to make it as successful and the best that it can be.

Steve: Right, exactly.

Bobby: Steve, thank you so much for your time. I look forward to talking to you next week.

Steve: Okay, great. Thanks, Bobby.
Bobby: Thank you again for joining us here on "The Software Outsourcing Show" today. I hope you enjoyed the conversation that we had with Steve Mezak about those business risks. And remember, next week, we'll be talking about technology risk and wrapping up the series. But for now, you can download our 15 risk indicators PDF for more detailed information on all the risks that we've talked about across all three dimensions: management, business, and technology. Also we'll have links to the articles that Steve wrote in the show notes. As always, thank you for listening to the show, I hope you have enjoyed it. Please feel free to give us feedback or comments at podcast@softwareoutsourcingshow.com, and you can also find the latest episodes and show notes on iTunes and SoundCloud, and as always, at softwareoutsourcingshow.com.