The Software Outsourcing Show, Episode 5: 15 Management Risks Associated with Software Outsourcing Pt. 2

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.

This podcast 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 5 Jim Marascio, Chief Delivery Officer of Accelerance and Bobby Dewrell, Vice President of Delivery of Accelerance really dive into those management risks discussed in Episode 4 and how the failure to ensure that software development goals are pursued with intentionality and clarity often lead to failure. Listen to identify and avoid the common pitfalls with your software development outsourcing project.

Transcript:

Announcer: Welcome to "The Software Outsourcing Show", brought to you by Accelerance, the global software outsourcing authority.

Bobby: Hello, everyone, and welcome to the show. My name is Bobby Dewrell. I'll be your host here on "The Software Outsourcing Show", and I wanna thank you for joining us here in episode number five. It's been a great couple of four episodes to get us to number five because really that's kind of how accounting works and how we get here. But along the way, we've had some great discussions. I know we started talking about software outsourcing and really what is it about, and how do you do global development and work with teams. We had a great interview in episode two with Steve Mezak and Andy Hilliard, two founders of Accelerance Inc., the global software outsourcing authority, where they really kind of gave us a state of how software development globally has been moving over the last few years and kind of where we are.

And the last episode, starting around episode three, we started really focusing on the software outsourcing lifecycle and the things to know about there as you get ready to engage in your software outsourcing. And we talked a lot about how you start with plan, you get connected to the right partner, you move in, and get those alignments with that partner, and then you really get a opportunity there to start off on the right journey and getting everything up to speed. And joining me for most of those conversations has been Jim Marascio, Chief Delivery Officer at Accelerance. Jim, how are you?

Jim: It's good to be back, Bobby.

Bobby: Hey, it's good to have you back. It's good to have you back. You know, the last time we sat down together, Jim, we really started talking about that planning phase and about the risks, and what to watch out for as you get ready for the engagement. And we talked about risk across three different dimensions being your business risk, your management risk, and technological risk.

And I thought maybe this episode, what we could do, we could spend some time today and really kind of dive into those management risks and what they are. And so I believe when we talked about it last week, we really said what management risk is, it's when management fails to ensure that software development goals are pursued with intentionality, clarity, and a healthy team dynamic. Do you agree with that definition, or...?

Jim: Yeah, I absolutely do. I think it's really about initiating a project with your eyes wide open?

Bobby: Okay, eyes wide open. I like that. It's knowing exactly where you're going, how you're gonna get there, how you're gonna do it, and really kind of the best way about it, right?

Jim: Exactly, exactly. So, when we approach it, we start with some questions to really understand where the organization is. And here's a couple examples I'll talk about, really understanding what can you afford to spend on this? Have you built anything like this in the past? What evidence do you have that what you're trying to do is gonna be able to be achieved, created with a budget that you have? How many team members do you have to do this? And what do you need to do that? How long is it gonna take to build?

When you start discussing those types of things, you start realizing how aligned the organization is around this and are expectations realistic. And I think pretty much anybody out there that's built software at some point has encountered a situation where there was not good understanding or consistent understanding of what the expectations were, and what the time frame, and how something was going to be achieved. So, everybody wants to do it faster, quicker, and cheaper. And the reality is that it can't always be done.

Bobby: So, it's really, you know, one of those key risks that we're talking about, and I think that's what you were hitting on there is unrealistic expectations, right?

Jim: Exactly.

Bobby: Do we know what we're gonna do and how? And I, you know, I know I've experienced that, right? I think we probably all have had that one project or that one program where something kind of takes off and you get going, and everybody expects, "Oh, you know, you can do so much in an amount of time that's just unrealistic." And I know that happened with us on one program of work where, you know, working with a team that had purchased, you know, a website or a web platform, if you will, from someone else.

And on the covers, it looks great, but when you broke those covers back and looked it was all on declining technology. It was all on poor coding standards. It was all this the stuff that we're gonna have to refactor and rewrite, and no one understood what that time commitment was. And every time we went back to the management team or the leadership team and said, "Hey, you know, we're gonna need four more weeks to work on this." The answer would always get negotiated to "Fine, we'll give you four more weeks, but here's six more weeks of stuff that we want you to do in that four more weeks."

Jim: Exactly. Exactly. It's the old nine women can't make a baby in one-month scenario.

Bobby: Correct. Correct. Yeah, that was fun and I'm sure I'm probably not the only person that's had an experience like that. But that's what I think of when I think of unrealistic expectations. It's just no matter what you do, you can't get on the same page, right? Is that...?

Jim: Yeah, I think that's spot on. I think it's important for everybody to understand and get organizationally be aligned with respect to what's being done, when it's being done, how it's being done, and identifying upfront where there's some inconsistencies in those expectations.

Bobby: Yeah, okay. That makes sense to me now. So, unrealistic expectations, that's a good part. I, you know, another one that we talked about, and we kind of hit on last episode too, was unfocused leadership.

Jim: Yeah. So, unfocused leadership is really when the organization...it's exactly what it says, isn't focused on it. That could be that there's one stakeholder that's running with it, and everybody else isn't, you know, again, aligned, I use that word a lot, with the organization. It can also be in what we run into probably the most often is a change in focus. Is that old squirrel thing, "Oh, look over there. There's something shiny and new." And so I think we've all been involved in engagements where there wasn't enough discipline around agreeing to what was being done and sticking to it.

So, a good example I can think of is, Bobby, you and I were both involved in engagement just this year with a division of a large organization that would define what was going into a release, and then as we got closer to that release, they would decide to change the scope of what was in the release. And it became this mad scramble of what can be cut in order to get this done. And so QA might not get completed somewhere, features might not be executed optimally. So, they might be functional, but it doesn't scale. So, things like that.

So, I think, again, I mentioned some questions earlier to ask around unrealistic expectations. I think some questions that we like to look at when we're talking about unfocused leadership or what departments and teams in a company are directly impacted by this because we need to involve those people. Are representatives from each of those assigned to the project? If they're not, then it's likely to become problematic later down the road. Is the right level of representative involved in those?

Sometimes what we'll see is they'll say, "Yeah, so and so from this department is involved." But it's not somebody who is at the right level of decision-making or communicating capability, who's assigned to this engagement, but overloaded with respect to a certain project. So, they're probably not going to participate at an optimal level. And there's a bunch of others in there that we like to look at. But I think, again, any of those can very quickly identify that priorities aren't consistent. We don't have focus around leadership buy-in to what's happening.

Bobby: Right, right. Yes. And I've seen that, too. And I think that was a good example that you are providing in there too, or when you were talking about some of those questions that sometimes it...we're not saying it's unfocused leadership across the entire organization. Maybe it's just one unit, or one division, or one group that doesn't have the right level of leadership involved that will end up creating some problems.

Jim: Exactly, exactly. Or the right discipline on behalf of that leadership. If we agree, you know, I'm not saying you should never pivot and things don't evolve, but if we agree to a short-term goal, something we're gonna do in the next 30 or 60 days, or the next two weeks of tasks, and we start changing the scope of that midstream, then there are some organizational challenges that need to be addressed in order for that not to occur on an ongoing basis, and potentially totally derail a project.

Bobby: Well, and I think that's a good point, too, that we could talk about there. Using unfocused leadership and going into what we see as a next risk. And we say another one of those management risks that we see all the time is unclear milestones, right?

Jim: Exactly. Exactly.

Bobby: And so that...?

Jim: So, an example I like to use is if we're on the East Coast of the United States, let's say we're in New York City, we have to go to San Francisco, it's easy to say, " We need to go to San Francisco," you know, whether...yeah, but let's assume we're not flying, and there's some places we need to stop along the way. And it's important to understand when, where, and how we're going to make those breakpoints so that we have those as interim targets.

So, if I'm leaving New York and I'm heading west, I might set some stopping point in Pennsylvania, Ohio, and then St. Louis, and then Kansas City, and then Denver, and Salt Lake City, and eventually get to San Francisco. But if my goal is purely focusing on San Francisco, it's very difficult to know am I really on track here? So, it's important...again, we've got some questions that we like to look at, and we'll start with do the meetings have published agendas and are we following those agendas? Do people know what we're supposed to be doing? Does the project manager hold regular status meetings?

Because if we start breaking down those communication and we don't know what we're doing, if we don't have the key management people on the business side involved in what's going on, then what we'll start finding is that we don't realize we're missing marks, we don't realize that those milestones aren't being met, and in the end we'll find that as we're supposed to be coming to fruition of a project, we're probably nowhere near. And so it's important to have some of that structure, nail down what those things are, what those milestones are, and then put together processes to implement that so that we've got the right people involved, we're communicating right, and we've got the right agendas, and we're discussing those things, so everybody knows where that short-term problem is.

Bobby: Well, and so let's talk a little bit, so we've talked about the unrealistic expectations, maybe a lack of focus from our leadership, some unclear milestones. Another one that we that we see a lot and we talk about is a lack of team interaction.

Jim: Yeah, exactly. Some of the things I was just talking about a moment ago kind of start hinting into these type of things. So, especially when you're doing outsourced work, it's even more important to be intentional about how you interact.

Bobby: Well, that's any kind of distributed team, right?

Jim: Yes, any distributed team, but I think as soon as it becomes cross-organizational to some degree, even though your goal here is to create one team, as soon as you start introducing organizational dynamics for another one, it's really critical that there's an emphasis placed on team interactions. How do you hand off work from one to another? How do you verify that that was done? If you're working across time zones, how does that happen? What are the different cultural norms around communication, and what tools we're going to be using for communication? All those type of things are critical.

Bobby: Some of this that's that alignment that we talked about, right? When we talk about it in the outsourcing lifecycle. We talked about that you need to have alignment. So, this is really kind of that time of what are our communication plans, right? Do we have specific communication plans that we're gonna use? How are we working across? What are common definitions, right? What's the roles and responsibilities? When do I stop and when does someone else start? And how do we overlap, right?

Jim: Exactly. So, we like to do a couple day workshop with the client, and with the partner to sit down at the start of an engagement before any works being done to define and nail these things down. It's really critical. Otherwise, what tends to happen is people assume that the other party is doing something, or that the way they are doing something is going to be optimal for the other party. And as we all know, through other communication and process things, it's easy to drop the ball right in those scenarios. So, if we take the time intentionally upfront to define these things, and then agree upon how we're going to manage communication, and engagement, and interaction with an engagement, then we're much more likely to "A" start efficiently and "B" effective on an ongoing basis.

Bobby: Right. Right. And I know it's, you know, it's one of those things in some of these that we've been talking about. You know, here with lack of team interaction, I like to think having come from the operations side, you know, and being more of an operator and coming through release over into the development world and that, I know a lot of times we have the discussions around here of what is done, right?

Jim: Exactly.

Bobby: And there's a lot of times that it's an absolute disconnect on done and I know everybody laughs at me. I always say it, "It's done when it's in production and working, right?" That's the only time it's done. And, you know, a lot of other people say, "No, no, it's done when we're code complete, or it's done when it's QA tested, or it's done when it's ready for release."

Jim: I like the fact that you said, "And working." I've run into scenarios where it's in production. It's done. Well, no it's not. Just because you rushed it into production, right, without adequately testing doesn't mean it's done.

Bobby: Yeah, I mean, that's the old release Bobby coming in, right? Yeah, it's in production and working. I mean, let's be clear about it.

Jim: Yeah, unfortunately, we have to.

Bobby: Right.

Jim: It's important to agree upon those things in advance. Otherwise, you start running into scenarios where people debate and argue what's fair and what's foul. I wouldn't wanna go out and he'll be playing basketball, or baseball, or football, or something, and then have somebody, you know, throw a flag or blow the whistle and say, "You're out of bounds." But, you know, the reality is, I didn't know that was out of bounds. I thought it was over here.

Bobby: Right. And, you know, I think that's, you know, one of the other things that I would come back to and really what rounds out the end. We kind of bleed it over and talking about it. But weak processes, I mean, that's kind of the fifth area or fifth risk factor that we look at within this dimension of management risk, and that's those processes, right?

Jim: Exactly. And what we're talking about here really is having effective SDLC or software development lifecycle. And make sure you've got the right people involved in the requirements gathering process. It's ensuring that you're ranking and prioritizing your requirements and going all the way down through the SDLC. Looking at UX. Looking at UI, looking at the capturing requirements I talked about there, testing processes, coding processes, documentation around all these things.

Is all of that clearly defined? Do you have rules for how it gets done? Is there a process for what happens when it's new technology needs to be introduced? You don't have the right solution, you need a new database, for example, and we need to decide what database we're going to use. How does that happen? Is one developer just making a decision and doing it, or is there some other process that comes into play where certain things are vetted and decisions are made based on certain requirements are gathered there. And if you don't define that stuff upfront, you will have problems.

So, when we're working with organizations, and we're trying to define these risks, what we do is go through all these different things that we just talked about, and start asking questions and looking for areas where we think there's excellence and areas where there's some gaps, and then obviously, coming back to them and suggesting here's some things you need to improve. And if you don't, there's a likelihood of problems.

Bobby: And this would be another one of those things that we...this one especially, that we really try to cover in that couple of day workshop, right? I mean, that's just kind of a recommendation that when you're starting out, let's go through and define these things. Let's understand them. Let's...?

Jim: Absolutely. Absolutely. It's, again, aligning organizations in both internally and externally with others that you're going to be working with, whether it's cross-departmental or cross-organizational. Having that level of alignment, understanding the rules to the game, and then making sure everybody understands what those are and what the processes around those things is critical. If you're not doing that, you will "A", be slower, you'll be less effective, and you're gonna introduce problems.

Bobby: Right. And you've gotta get to that one-team concept. And so some of this stuff while it is done, you know, officially and formally, it also, I think, goes back a little bit like back in Episode Two, when I was talking to Steve and Andy, they talked about getting together, breaking bread, eating with one another, taking that time to go outside of work and kind of understand some of these things. And I think some of that helps loosen this risk too, right? Or less...

Jim: Yeah. If you're working in an office together for eight hours or more a day, you get to know the people, and you understand how to interact. If you're doing it, you know, across a continent or just across the city even, it's important that you get together on occasion and discuss these things and understand the people that you're working with, so you can be most effective.

Bobby: Yeah, okay. Well, Jim, hey, listen, I really appreciate it. Thank you for joining me for this episode. I'm sure we'll have you back on more episodes.

Jim: Thanks. It's been fun.

Bobby: But, yeah. Hey, I appreciate it. Well, everyone, with that we're gonna wrap up our time here. I tell you what, what we've got that we'll be providing for you as part of this episode. If you go out to software outsourcing show and look, you can download our 15 risk indicators PDF for more detailed information on management risk. It will also include those business and technical risks that I'm sure will be in our next couple of episodes coming up.

I wanna thank you for listening to The Software Outsourcing Show and taking your time here. Please tell a friend and invite some others that might wanna listen. You can always find our latest podcast episodes and show notes out at softwareoutsourcingshow.com as well as we're out on iTunes and SoundCloud, so please subscribe and please come back and listen to us more. So, thanks so much and we'll see you on upcoming episodes.

Announcer: 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. Show notes, links, and materials discussed on today's show may be found on our website at softwareoutsourcingshow.com. That's softwareoutsourcingshow.com.