The Software Outsourcing Show, Episode 4: 15 Risk Indicators in Software Development Outsourcing Pt. 1

The Software Outsourcing Show is your #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.

Episode 4 features our guest, Jim Marascio, Chief Delivery Officer of Accelerance discussing the 15 Risk Indicators in software outsourcing across three functional areas business, management and technology--  You’ll learn how to keep those risks buttoned up and increase your probability of successful software development outsourcing.

Transcript:

Bobby: Welcome to, "The Software Outsourcing Show" brought to you by Accelerance, the global software outsourcing authority. Hello everyone and welcome back to this show. My name's Bobby Dewrell. I am your host as always and joining me in the studio yet again is Jim Marascio. Jim, how are you doing?

Jim: I'm doing great. It's good to be here.

Bobby: Yeah, it's good to talk to you again. It's been a little while since our last conversation.

Jim: Too long.

Bobby: Yeah. Yeah. But, you know, I'm looking forward to really talking some more and helping some people out here. And you know, one of the things that we've talked about was a software outsourcing life cycle and, you know, that important. And, really what we hit on in the beginning there was the difference between high-performance and low-performance outsourcing, right?

And, we talked about the four phases in the software outsourcing life cycle that gets you to high performance. It's the planning, it's the partner selection, it's the launch, and it's the management, right? It's really those four key phases is what makes high performance. Now we did say, you know, hey, without doing that, you know, sometimes you can knock one out of the park, sometimes you get it right, but, you know, we didn't take too much time to talk about why they could fail or why it could fail before you start. And so that's one of the things that I thought we could talk about today is, what is that? What can make the software outsourcing fail before it really even starts?

Jim: Sure. And I think most clients don't think about failure before they start.

Bobby: I would agree.

Jim: It's just not even on their radar. So they're jumping in and they're looking ahead. And what we try to do is bring them back to the beginning and say that there's a level of assessment that we've identified, 15 different risk indicators that we can look at and help them understand their business and identify potential areas where they may stumble with respect to software development outsourcing before they actually start.

Bobby: So what is a risk indicator? I mean, what do we mean by that when we say risk indicator?

Jim: Well, so risk indicators are basically factors that impact the success or failure of their outsourcing engagement, and we break them down into three different areas: management, technology, and business. So we work with our clients and we'll talk about it here a little bit to understand which in those three areas, management, technology, and business, again, are things that they need to plan for when they're doing a software development outsourcing engagement and help them, again, identify where there might be challenges internally before they even introduce a partner to do work.

Bobby: So this is really an inward client focused assessment that we're talking about here, right? It's sort of a gap analysis or sort of an understanding of your.

Jim: Yeah. To some degree, that's exactly what it is. You know, our goal here is to understand where our gaps are so that we can do one of two things. Either find a partner that can fill those gaps or introduce something with internal practices, internal people to address them before they become problems. So it's, identify challenges before they become problems.

Bobby: Okay. Okay. So true, right? Like if we go back old school and we talk about the difference between a risk and an issue, a risk is a potential failure and an issue is a realized risk, right?

Jim: Exactly.

Bobby: It's identifying those risks before they become issues is what it is.

Jim: Exactly.

Bobby: So, you said they break down across three categories. We talk about management, technology, and business. So, what exactly do we mean by management risk?

Jim: So a management risk is really organizational, around having the right expectations. What are we developing, what are we building, why, how? And a lot of times what we find is, that's not clear. They think it's clear, but when we break it down, it's not clear. They may have or not have buy-in across the leadership team. So it may be an initiative that's driven by one organization or even one individual, but it's not in alignment with organizational goals, and what they'll find is down the road that that'll be a challenge.

It can be unclear milestones. So a situation where, again, something's not clearly defined of when something's got to...they know what they need, but they don't know when they need it or it's not clear at a granular enough level that a partner can break it down and achieve it.

Again, looking back at kind of organizationally, not being aligned organizationally, if you've got team interaction or team dynamics that aren't supporting it, not just even at a leadership level but at a group level. So as an example, maybe internal software developers aren't supporting something. Even if it is a organizational initiative, how do you address that? And then the big one and, you know, it's never fun to talk about is process, or it's not fun for most people to talk about is process, and having the right processes around things to ensure success.

Bobby: Well, now, you know, I enjoy me some good processes. You know I'm all about the process.

Jim: Yeah, unfortunately, I do know that about you, and it's a good place to have you because you're really good at it.

Bobby: Yeah. That's yeah.

Jim: But most people don't.

Bobby: I know.

Jim: And at least you can acknowledge that now.

Bobby: That's true, which is always amazing to me because I've just always had such a process-oriented mind. So I think, you know, it's kind of, from what I'm hearing, it's really...it's ensuring that we have those goals that are pursued with clarity and structure and a healthy team dynamic, right, if we kind of set it at a high level.

Jim: Yeah, at a high level that we're talking about. Absolutely. So what we do is we encourage businesses to dig into those things and make sure that they've got the right organizational alignment, that they've set the proper goals, that people are bought in the right places, that they understand what they're doing and when, that they've got the process to support it, all of those types of things. Because if you don't, then you can introduce the best partner and you won't be successful.

Bobby: Well, and you know, I just...I don't want to dive too much on each of these because I think, you know, later we can really get in and dive into a lot of them at a much deeper level. But you know, like unrealistic expectations, I mean, that's one of those, right, where you're... I mean, do we have a good example of maybe just that one?

Jim: Well, yeah. We've probably all been in experiences where somebody underestimated what something was or somebody who didn't have a good handle on it, you know, often at a leadership level, so this has to be done. And here's...it has to do X, Y, and Z, and it needs to be done tomorrow. And the reality is that saying that nine women can't make a baby in a month. So if the goal is to make a baby in a month, then that's an unrealistic expectation.

Bobby: Right? That's the mythical man month, right?

Jim: Yes.

Bobby: You can't take 100 hours of programming and do it in an hour with 100 people.

Jim: Yeah. So we're not saying don't challenge people, or don't be aggressive, or don't have lofty goals. Shoot for the moon, absolutely, but be realistic on putting together a plan to execute that trip to the moon.

Bobby: Correct, yeah. Don't shoot for the moon in a 747, right? It ain't going to happen.

Jim: Sure, or you go.

Bobby: Right. So that was a little bit about management risk and it is, it's about the structure around it, right? So let's talk a little bit about technology risks. What do we mean by technology risk when we say that?

Jim: So similar type of thing. Rather than looking cross-organizational, let's look within the technology team. And it's things like understanding the skill set. What's the skill set of your organization and the bandwidth related to that, the availability of that skill set, and identifying where those gaps are so that can be addressed. How are you going to support it? What are the operations and is it something that you can do internally? Do you need to train for that? Do you need to staff up for that? Are you ready for it today? Do you need a partner that can do that? Do you need somebody else to support that? So defining how things are going to be supported throughout development, but most importantly, post-development, what's the design? Understanding how people are going to use it.

You know, there's a lot of companies out there that have had tremendous success, because their design has been outstanding when their product from a feature set standpoint might've been inferior to some other things. And conversely, there's been some phenomenal products out there with great features and poor design. So not taking the time to understand usability UX, UI, that type of thing can be a huge risk from a technology standpoint.

Bobby: Well, and, you know, I've seen that. You know, earlier in my career working in some mobile applications, right? Without understanding that design, we had a rich feature set that allowed you to do a lot of work. And what no one really thought about from the design perspective was it kind of a...traditionally and within the sector that I was in, it was kind of a hierarchical methodology, right? So you needed to be within this segment and within this component, and within this thought process to do it. And so that's how it got arranged.

And it was one of those things that the typical user, it was going to be one of the most often used things, but it was buried about four layers deep, right? And so all of a sudden it was four or five clicks to do something that really should have just been at the top level. I mean, it made total sense where it was located, where you could find it, but it was just for the amount of time that you were going to use it, it was just in the wrong spot.

Jim: Absolutely. Yeah. Successful software applications have a user focus, a user emphasis, and if you don't think about usability, it won't scale. So that's one of the things that we need...that they need to be looking at. So, is the organization ready for that? Is the solution ready for that before you...or do you need a partner to help you do that or some other third party to help you do that? Or is that something you're gonna bring people in-house to do?

Quality assurance testing, what's your plan for that? You know, anybody who's been around software at all has been in a scenario where regression testing wasn't completely done.

Bobby: Well, we never have time for it.

Jim: A, we added this new feature and we tested the new feature but we didn't see what it did for the rest of the environment. So what's your plan around QA? Understanding, again, the software developers that you hire may be able to bring together a QA team, however, if you need people on your business side to support that, then you need to plan for that. And a lot of businesses don't bring the expertise to the table. They farm it all out and they don't plan that support role.

Bobby: Well, and they don't understand it well enough to adequately always provide the time for it, right?

Jim: Absolutely. Absolutely. It's one of the most probably underestimated things because everybody says, "Oh, the developer is going to do everything perfect." Well, the reality is they're human and the reality is as things grow and evolve, more things have interdependencies on other things and you need to test those interdependencies, you know, more than just that new feature.

Bobby: Right. So the law of unintended consequence, right?

Jim: Exactly. You've never experienced that enough?

Bobby: No. Never, never.

Jim: So, and then the last one we like to dive into is technical debt. And what technical debt essentially is, is when something wasn't done right the first time, and now you have to continue to work with it on an ongoing basis.

Bobby: Wait. So you mean like those band-aids we put on everything? Is that what...

Jim: Exactly, exactly. So as an example, something, you may introduce a new feature into something and the architecture that was designed before didn't anticipate some new feature and so you have to go back and re-architect things. Well, that takes longer because that architecture may affect other things. So a lot of times those band-aids that you were just talking about get put in place, code gets bloated, it's not super efficient, and it grows and grows and grows, and at some point you're taking more time to build around all the band-aids or to keep putting band-aids on things than you would to really architect or do it right.

And so it's really important when you're developing, designing, and planning to have the end in mind and at least anticipate to whatever degree where you're going with it and invest adequately. You don't build a house and build a foundation for a 1000-square foot house and then decide to make it a 5,000 square foot house by doing 60 in addition. So at some point, you end up with stairways all over the place and it's that...I forgot the name of the castle in California.

Bobby: Oh yeah, the Hearst Mmansion.

Jim: That part, it doesn't matter.

Bobby: The Winchester. Yeah.

Jim: Where doors don't go to anything and it's totally inefficient to get around. And so I think from a development standpoint, it's really important to understand and plan for technical debt.

Bobby: Yeah, absolutely. So I think from, again, if we go back to the high level, we said management risk is about pursuing those goals with clarity, with structure and a healthy team dynamic. Technology risk is...it's really those things that look at the tools, the methods, and the approaches that the IT team has to control, right?

Jim: Absolutely.

Bobby: So that's two of our risks, right, management risk, technology risk. Then we talk about business risk. What do we mean by business risk? What are we looking at there?

Jim: So those lie outside of technology and project expectations and start playing into the actual business. And what I mean by that are things like undefined metrics. How are we going to measure success, when are we going to measure success, who's doing it? That type of thing. Things like inconsistent priorities.

Bobby: Oh, we've never had that, right?

Jim: No, no, no.

Bobby: Like today I want you to work on this and tomorrow...yeah.

Jim: Your sales wants this and operations wants that and finance wants this. And at some point, the business needs to be aligned with respect to that. And it's different than getting the business behind the initiative, and in more general sense, it's getting the business behind the specific priorities. It's understanding the product and product management rather than project management, which we talked about a little bit so far.

It's things like not having executive champions. It's important that this isn't something that's being driven by one group within the organization if it's affecting many groups. You need the right support at a high level, otherwise, other things will trump it, and you're likely to fail because other things become prioritized over this. Things like team engagement and understanding who's going to be involved internally and externally and making sure that they're committed to the project. And finally, having a partnership contract, working with a partner with clear direction.

Bobby: Wait. We actually...we need to call out having a partnership contract. Surely there's not people out there that do this without partnership contracts, right?

Jim: Never happens. Never seen them once. No, no. Seriously, it's important to have that level of alignment as well. And if you don't have these things that we just talked about, 15 different items here, if you don't have those buttoned up, each one introduces a risk and increases your probability of failure.

Bobby: Right. Yeah, absolutely. So really business risks are kind of those things outside of technology altogether, right? It's the project and the product execution disciplines, right? It's above the... It's the holistic approach, right? Is that...

Jim: Yeah. I think that's a good way to put it.

Bobby: So, in understanding, this is a little bit of a trick question, but which one of these categories is the most important?

Jim: Whichever one's not working right now. No, no, they're all important. It's not something you can prioritize one over the other. If any of these things isn't in place, then they have pretty much an equal probability of introducing issues, which become problems which become...result in failures. So, it's important to, again, before you select a partner or before you do some of these other things and you start an engagement, it's important to understand where you're coming from, where you're standing so that you can anticipate these things. You can't fix them all, you can't button everything up, but it's important to understand where those potential pitfalls lie so that you can plan for them, start getting the right buy-in and anticipate challenges and address them before they're encountered.

Bobby: Right. Right. So, you know, I think if we could pull them all together, I think probably business risk is the most broad and general, correct, or maybe the top level. If you were looking at it like a funnel, you have the broad business risk which are really about the executive leadership, about the goals, about the direction, about the engagement, about the contract. It's really that top level. And then from there, you know, that leads into what we see as your management risks, which are taking those priorities and goals and then establishing some milestones, making sure that we get the proper interaction between an engaged team, that the priorities align to realistic expectations. And that we've got some strong processes that we can follow and meet what's really been set at that business level.

And then if we break it down even further, we come into technology, and that's where, okay, you know, we've got a team engaged, we got the right interaction, but can they do the work, right? And have we defined it appropriately, do we have a good design, do we have the right quality steps and are we making sure that we don't have too much technical debt, right? So, do they kind of fit all together like that? 

Jim: Yeah, I think that's a really good synopsis.

Bobby: Okay. Well, cool. Well, I think with that, that's our time for this week. So as always, you can find show notes and transcripts out on softwareoutsourcingshow.com. We'll also give you a link out to our 15 risk indicators and software development outsourcing talking about those business, management, and technology risks, and what we see as those five examples really under each of those. You can listen to us and find us, subscribe on iTunes, SoundCloud, or the other places that we are out there. Please tell a friend, join us back for more episodes and, you know, thanks for joining and listening in. Jim, thanks for joining me in the studio today. I appreciate it.

Jim: Thanks for having me.

Bobby: All right. Have a good week.

Jim: Take care Bobby.

Bobby: Thank you for listening to, "The Software Outsourcing Show" brought to you by Accelerance, the global software outsourcing authority. Do you have a topic you'd like covered in a future show? Then send us an email at podcast@softwareoutsourcingshow.com, podcast@softwareoutsourcingshow.com. Show notes, links, and materials discussed on today's show may be found on our website at softwareoutsourcingshow.com. That's softwareoutsourcingshow.com.