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

As the final part of our 15 Risk Indicators Series, Jim Marascio, Chief Delivery Officer of Accelerance, joins Bobby Dewrell, Vice President of Delivery for Accelerance in the virtual studio to discuss the third dimension of our 15 Risk Indicators: technical risks.  Listen as Jim and Bobby break down how to avoid these risks and properly handle technical issues with your outsourced software development team.

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 welcome back to the show. My name is Bobby Dewrell, and I am your host here on The Software Outsourcing Show. We've had a couple of great weeks talking about different risks that could impact your software development outsourcing and we've talked in the past about business risks. We've talked a little bit about management risks and now we're in that third category of technology risk. And technology risk can actually contribute to your software development outsourcing failing, and actually we had a recent article on cio.com, and you can find that, we'll provide it in the show notes about what technology risks cause software outsourcing to fail, and you'll have to take it out and take a look. And that's really what we're talking about this week. And joining me again in the virtual studio is Jim Marascio. Jim, how are you?

Jim: Hey, Bobby. I'm doing well. It's always good to be back.

Bobby: It's great to have you back. You know, I've noticed you've kind of become my permanent guest. I don't know if that's a case of just no one else wants to be on or if you're shivving people in the parking lot to be on here.

Jim: Can't tell you, it's a secret.

Bobby: You can't talk. It's what I figured. It's what I figured you would say. So, Jim, technology risks? I know we've talked about this before and in those three risk categories that we say impact everything. You know, tell me a little bit, what is a technology risk? What do you see that as?

Jim: So, technology risks are really around the overall organization. I'm gonna use organization in a really broad sense right now. That could be internal, it could be outsourced organizations, it could be if you're integrating with other systems and other organizations that aren't truly outsourcing but somebody you're working alongside of. Ensuring that everything about them from a technological standpoint is in order. And we'll talk in more depth in five different areas that we've identified through almost 20 years of doing this, where companies either make assumptions or figure out that they'll do it later or just under equip themselves and it becomes a problem.

Bobby: Well, and so, I think these are really, in terms of tools, methods, approaches, it's within the IT team itself, right, that they control. It's not the, not necessarily the broader business, right? Or general management or the project, like, we've talked in the past. This is specific to the technology and the design.

Jim: Yeah. Exactly. It's getting into architecture and not staffing from a personnel space, but from a skill standpoint and dealing with technical debt and things like that.

Bobby: Okay. So, let's talk a little more about that. And we did say there was five categories of these technology risks, and we'll definitely talk about those. But first, it's really about skill set, right? About having the correct skill set, the adequate squeals, do they have the right technical experience? Are people adequately trained? How do you know? Right?

Jim: Yeah. Great question. And this one might sound obvious, but in our experience, what happens is, companies will focus on certain skills, but not all skills. Or, they'll have one person that has adequate skills, but they won't have the bench around that person to support them. And ultimately, that's a challenge. So it's really critical when you're defining what you're doing with your software, whether this is in house or out of house, to understand what skill sets, what technology stack you're going to be using, what level of skill? How advanced are you going to be going into that? So, how many experts do you need to have in that space? Do you need people with certifications or not? What you're going to be having in house versus out of house through a partner or a vendor, or somebody else that they're going to be providing those technical skills? And how do you know that they're really qualified?

Yet in today's age, people inflate things on their resumes, and say they've been doing things. So what are you doing to ensure that your people, whoever, you know, if those are internal or external, your people, have the right skills, and what are you doing up front to identify what necessary skills there are?

Bobby: Right. And I think you hit on that really well too. It's getting past that title inflation that we see honestly happening everywhere, right? There used to be a day when senior developer was somebody that had 10 or 15 years in, and now we're seeing it in 10 to 15 months, right?

Jim: Yeah, well, maybe not quite that but certainly 4 or 5 years we see it sometimes. So, absolutely. So, what are you doing to ensure...Are there people that can be that senior? Maybe not from an experience standpoint, but certainly from a knowledge standpoint? Yes. So, there's ways that you can validate that they've got certifications, they've got certain levels of experience. Certainly testing, it's important to have bench. Having one person that you're building everything around, that's a total rock star might work in a startup or at least temporarily, but it does not scale a business or create that redundancy and reliability. So adequate, and one of the things that we see very often is that, it's built around one person, and the rest of the team is really inadequately equipped to hold the fort should that person go down for whatever reason. So it's important for companies to have training. Ongoing training, cross training, ensuring that there's certification, ensuring that the other companies that they're working with are also doing the same thing, because ultimately, your team very often extends beyond your four walls.

Bobby: Right, right. And I think that's a good point to bring in, is that when you're outsourcing it is a way to reduce that risk right? That risk exists whether or not you are outsourcing, and outsourcing is a method to reduce it, right? So, by bringing in more skilled people, more skilled individuals, but you've got to make sure that they're there.

Jim: Absolutely. And one of the ways we like to do so is, the reality is very few markets are flush with available resource, very senior, very knowledgeable resources that check all those boxes. And one of the benefits of outsourcing is that you can identify what your needs are, or have somebody like us help you identify what those needs are, and then draw on a larger pool.

Bobby: Right. Absolutely. So, you know, I want to kind of put a pin in that one and move forward. And, you know, one of the other things that we talk about too is operations, and it's undefined or maybe lack of definition around operations. You know, does everyone understand who's going to handle the hosting? You know, is it optimized for the correct platform that it's being put on, right? Those are kind of a couple of things I see there.

Jim: Yeah. The term that you hear the most now is DevOps. And really, in the last 5 years, it's kind of come to the forefront of everything. Some people were certainly doing it a little bit before. But the reality is, there's very few organizations that I see that do DevOps really well today. And what DevOps, for those of you who are not really familiar, is, the development team essentially being part of operations. So they're coordinated together. And there's a specific process around identifying what's being developed, developing and standing it up in certain environments, testing it, releasing it and the ongoing support of that, but where development and operations are merged together. Where a lot of companies we see fail is on the ops side where they have not adequately architected, and don't I want to spend much time about, in that right now, because we're gonna come to it little bit later, but where the environment isn't correct and where they don't have the people, personnel, again, the skills, the training, certifications, whatnot to manage those operations. So, what is your process around release management? What is your process around the systems that are being supported? How are you maintaining those? How are you monitoring them? How are you scaling them? And again, do you have not only the right system, but the right people to support this?

Bobby: Right. And again, you know, it's systems and it's people and, you know, I think that's a great point about DevOps and, you know, DevOps, like any other new term out there, is defined 500 different ways, at least that I've seen, right? And so, even what do you mean by that when you say it? So, you know, I think that's some good points. And you talked a little bit about being architected and that is a part of it. Is it architected correctly for the platform? And that really kind of melds into that next category that we talked about, and it's the design effectiveness. And design effectiveness is not just from the front end standpoint, in that, do we have a good fit between what the business problem is that we're trying to solve, but also designed from the back end standpoint of, you know, is it scalable? Is it correct? Is it adequate? Right? Would you agree?

Jim: Absolutely. Design really comes in two forms. The one that most people think of is the traditional design and getting into what's the UI, what does the user interface look like? That really is a result of what the user experience is though. So that the two parts are really more architecture, and I'll come back to that in a second, and user experience. And we see so many organizations that don't take the time up front to look at what the user journey's going to be, how the user is interfacing with the system, whatever that might be, which ultimately will drive you to a specific user experience, which requires a user interface to execute well. So having poor design can result in, if it's a SaaS solution, for example, very poor adoption. If it's an internal system, enterprise system or something like that, it can result in a lot of frustration, a lot of poor adoption internally, even if people have to use it or it not being used right or people trying to find workarounds, so, design is a critical element. Now, on the flip side, I said there's two ways. The other thing is really architecture, and that plays into the environment, the servers and the systems and whatnot. How are they architected and designed to support your ultimate goal, and are they designed in a way that can grow with the business and the solution as it grows? And it could grow in two ways, one could be in scale and one could be in functionality, and is it designed to do that? And then the design of the software architecture. Is the software designed in a way that allows you to maintain it and grow it and evolve it appropriately?

Bobby: Right. And you know, as we were talking about that, I thought of two stories, you know, personally, that impacted and, you know, I think one was looking at design from the frontend. We had a project that we were working on and, you know, we really understood what we thought was the business problem, we knew what people needed to do for it. We kind of designed around it and, you know, in our talk and in everything that we were doing and running, we said, "Hey, you know, we've got this." And then when we put it out there we saw there was, you know, really low adoption and we couldn't figure out what it was, and we realized that really what it was is the one thing that almost everybody wanted to do when they were picking up that device and going into the application was buried in like two menus deep, right?

Jim: Exactly. Poor user experience.

Bobby: Right. And it was just a poor user experience. We had it there, we had solved it, but we had just put it in the wrong place. And, you know, so we ended up pulling it up, moving it to the front. It didn't make any sense, kind of logically looking, like why would it be here, right? Because it was really a subset of something else. But that's what everybody went to all the time. And, you know, once we moved that up to the front, people found out they could hop on quickly, get to that, and do it, I mean, suddenly adoption took off. And...

Jim: And that's why it's so important up front to spend time on the user journey and understanding where are they coming from? Where do we want to take them? What options are there going to be along the way? And how do we ultimately prioritize, which plays into the ultimate design, how this is going to work. So user experience is critical, and getting feedback from users, involving the people who are going to use it, not just the people who are saying "Hey, this would be great to do," but involving the end users in earlier, more often, getting that feedback, is going to save you time and money in doing this right.

Bobby: Right, right. And, you know, on the backside, so, you know, looking at the back end, you know, another story working within the mobile space, we had decided that our application was getting way too big, right? It was too thick. It was too fat on the phone, so we wanted to thin it out. And we had been working with services, right? Like everybody does these days and going through that, and we said, "Well, you know, we got a little extra logic, maybe a little stuff, what we need is an orchestration layer." And so, we decided to build this neat little orchestration layer that, you know, in about two or three iterations turned into its own monolith, right? And so, you know, I bet you know where I'm going there. It didn't scale, right? So, we kind of had to go back to the drawing board. But yeah, it's designed in those two areas and just that radical application to it. There's some quick risks they can be can be found there pretty quickly.

Jim: Yeah. And it's really critical to design again, we talked a lot here about the user interface, but it's really critical to design, and morph more architect the software and the hardware and systems behind the scenes to... Good example I have is a company wanted to use a new technology, had a new database technology because it was new and cool and the people wanted to learn the new tool.

The reality was, it was not the best tool for the way they were managing data. And so, in order for the software to scale, they needed to allocate more hardware resources, more server processing or RAM in order to make the database perform as it should. Well, there were costs to doing that. And early on, when you're developing, there's not a lot of users on it. But when you start going to scale and you start having users, all of a sudden that performance is a big deal. And they unnecessarily were driving up the cost of ongoing system maintenance because they chose the wrong database design and database architecture from the start.

Bobby: Yep. And so, you know, let's kind of move on and talk about a couple of those other risks in the interest of time. You know, obvi, I think this one really ought to be obvious, but it's QA, right? It's your quality assurance, and it's lacking or not having it well-defined, you know, procedures in place that are truly understood. You know, are they robust enough? Are the standards for the software accurately and adequately communicated and fully understood, right?

Jim: Yeah. Absolutely. I'm smiling the whole time you're talking here because your first statement is, this should be obvious. And yes, it should be obvious. Everybody will tell you they need to do it. The reality is, it's probably the most under-executed component of software development that we see. Everyone...

Bobby: I would personally rather gouge my eyes out.

Jim: Well, what happens is, we try to do too much too fast. And QA takes time. And everybody says, "Well, the developers shouldn't be writing bad code." And yeah, they shouldn't. But they're humans. And a lot of times they're not factoring in all the other external variables. And a lot of times QA points out undesired workflow. So, a scenario where the user uses the tool differently than was expected, but still possibly a way that it could be used. And so, it really, really is critical that quality assurance testing be taken very, very seriously and that the right resources can be allocated. Now, that said, without going into the tools and solutions side of this so much, there are some phenomenal tools in the area of automated QA or automated testing, has evolved radically in the last several years, and it's one of those things that takes a little more work on the front end, but once it gets done, every iteration it's easier to test, better test any legacy code's interaction with new code. So, it's something that's well underutilized, and you always want to be finding issues in your code before your users do.

Bobby: Well, and that automation too, I think it's important to say that that needs to be at both the component level, at the system integration level, not just automation up at the UI level, right? That can be very temperamental and not there. I mean, you know, it's a great example of test-driven development, right? Let's get it at the unit test, you know, let's run our unit tests, make sure they're passing, and just kind of move up, you know, each of those iterations. And what we can do today with automation, it truly, truly is amazing, and it does save a lot of time. But you still have to let it run, right? You've got to take the time. And, you know, I always love that every project I've ever done, QA seems to always prove out the law of unintended consequence, right?

Jim: Exactly.

Bobby: Invariably, there's something that you did, and somebody goes, "Oh, no, no, no. We don't need to test that. We didn't touch it." And sure enough, that's the thing broken, right?

Jim: Of course. Yep. Yeah, but you touched the one thing that cascades down to that. I'm glad you brought up test-driven development, or TDD, as well. And for any listeners that aren't familiar, what it really is, is defining not what's going to be written, from a code standpoint, by the actual requirements, but define it by how it needs to perform. So you define what is going to be tested, and then you develop the code to pass those tests. And then it's, there's little interpretation left to the developers to understand what they're actually supposed to be doing. Whereas in the other format, where you're just giving a developer a requirement, well, the developer may misinterpret that requirement and develop something that meets the requirement, but not in a way that is actually intended to be used or tested for.

Bobby: Right. Right. That is always a fun case, right? When it's working as designed, but maybe the design didn't meet your requirement.

Jim: It absolutely meets the specification. That just wasn't the specification we meant it meet, so, sure.

Bobby: And, you know, lastly, let's talk about the...I tell you, you know, this next category that we're gonna talk about, I'm sure that the minute I mention it, everybody will go, "Oh, yeah." But to me, this is another one of those that actually seems almost more terrible than QA in some circles, right. And that's technical debt.

Jim: Yes. Yes.

Bobby: Nobody likes debt. But I tell you what, I think we do the worst job of structuring those loans to pay off this debt right, than anywhere else.

Jim: Yeah. And it, just like QA, there's this belief among product people and organization leaders that the developers are just supposed to write good code. And in reality, what happens is sometimes they don't, again, because they're human. But very often, the code they wrote was totally appropriate now, but in 6 months or 6 years, some new functionality gets added in. And now that original code is operating less efficiently as part of the larger solution. And because we were trying to meet some deadline, we just kind of patched it and we didn't actually we readdress the solution as we would in a ideal situation. And so what happens is over time, you end up with a lot of inefficient code, which costs you money on two fronts. One, it is usually more difficult to develop around in the future as other areas around that code are being, evolving, I guess. And so, it takes you longer to maintain the legacy code. So there's an argument there for taking some of your time in new development to update and modernize the legacy code so that it's easier to maintain on an ongoing basis.

The other area where it costs you money is ongoing performance, and I mentioned earlier the database scenario, where it was poor architecture, but in some cases, because code is not efficient, it requires more resources to operate, which means you're paying more for server CPU cycles and for RAM and potentially bandwidth. Who knows what else? And those things can, don't to say easily, but can very reasonably be managed by allocating a portion of all of your development time to addressing technical debt. And as the solution evolves, you want to minimize the anchor that you're towing off.

Bobby: Well, and too, I think something that's very important to point out is, I, you shouldn't, and I'll say this carefully, you shouldn't try to have zero technical, debt, right? At some point, you're gonna have technical debt. And really the cost to pay off the debt may be too high. So, you need to understand what is your threshold. I mean, maybe you are an environment where, you know, you just, you have zero threshold for debt. I would guess that you're probably not at the highest margins in the world.

Jim: Yeah, there's always going to be some. Think about a house. If you build a house, you know, later on you change a fixture, you change whatever, you build an addition, you add something here and there, and there's some core underlying structural whatever that is probably overbuilt or tweaked or modified, so that it supports whatever the new thing is. If it were being built brand new from the ground up, it wouldn't be built the same way.

But we've all seen things that, yeah, whether it was a vehicle or a house or whatever, where we looked at it and we just knew it was wrong. "Yeah, it's functional, but, that's wrong." Now, that's the type of technical debt that you ought to be fixing, because it's not safe or it's whatever. So, yeah, there is a balance. It's going to be there in a mature application. But it's important to acknowledge that a portion of your development time should always be ensuring that uber-inefficient and costly technical debt doesn't remain. It gets rewritten. And if you don't, what'll end up happening is things that should have taken you, you know, much less time to add as future functionality will suddenly require a tremendous amount of time.

Bobby: Absolutely. Absolutely. So, you know, Jim looking in the interest of time and, you know, we do want to keep these kind of short and still cover the subject, but I think we need to look at probably wrapping up, and so just as a quick recap, what we said the categories of risk within technology space are inadequate skills, undefined operations, ineffective design, lack of good QA is what I'm gonna say, and technical debt, right?

Jim: Exactly. And again, Bobby, you mentioned at the beginning, there was recently an article in CIO magazine and that's gonna be linked from the show notes. So, there's more recap of this for you to consider.

Bobby: Yeah. Absolutely. We'll get that in the show notes. Along too, I'm gonna point out that we do have our 15 risk indicators PDF that has more detailed information on not only these technical risks, but also the business and management risks that we've previously spoke of. So we'll link to the article in the show notes, we'll get you the content out there so you can download those 15 risk indicators. And, you know, I want to thank everyone for listening to The Software Outsourcing Show. I want to remind you that we're out on iTunes and SoundCloud and you can also find us at softwareoutsourcingshow.com. You can always get the latest podcast episodes and show notes there. And with that, Jim, thanks again for joining me. I am sure I will see you in a future episode.

Jim: Thanks again for having me. Always good to chat.

Bobby: Sure thing. Thanks everyone for listening and we hope you have a great week.