Subscribe
Share
Share
Embed
Let's talk IRM. The real stuff. Join Jada, a certified ServiceNow IRM practitioner, as she breaks down compliance automation, risk frameworks, and the strategies GRC professionals actually need. No fluff, no theory. Just real talk from someone who builds it. A SaaSCE Boutique Podcast.
You got the platform, you did the implementation, you trained the users and you built the guides and somehow the work is still living in spreadsheets. The risks are still being tracked in an email thread and evidence is still coming in through JIRA tickets. And now someone is asking you, why did we spend 6 figures on a tool that nobody is actually using? If you've been in that room or you're in that right now, then this episode is for you Today, we are getting into the question that nobody asks before they go live. Are we actually transforming how our team works or are we transferring the same broken process into a shinier tool?
Jada:Because those are two very different implementations and only one of them gets you out of that room. What's good army crew? I'm Jada and this is Let's Talk IRM. Okay, welcome back everyone. So today's episode is a little different.
Jada:Today, I brought in someone who has seen countless IRM implementation and brings a wealth of information to the Let's Talk IRM podcast. I want to introduce you all to Elaine. She can talk IRM forwards and backwards, but more than that, she's been in the room explaining it to people who have never even seen a control objective in their life, which in my opinion is the harder job. So, Elaine, welcome to Let's Talk IRM. Thanks for coming.
Jada:Would you like to take a moment to introduce yourself, to our audience?
Elay:Yes, definitely. So Elay here and I have spent the last few years walking organizations through IRM implementation, not just, you know, configuring the platform, but also sitting side by side them with their teams who actually have to use the tool or platform afterwards it's been implemented and kind of like keep an eye on what's the gap that has, you know, reoccurred over time. And also like the platform, what do we need to technically correct from the platform standpoint? What do we need to operationally ignore or operationally implement? So I feel like I've seen a lot from different implementations over the years that I've been implementing and, you know, I there's one or two things that I could definitely share.
Jada:Awesome. And I truly love that. So I want to start with the LinkedIn posts that actually inspired this podcast episode, right? Someone on LinkedIn said GRC platforms are the most hated tools in security, not underutilized, not overpriced, but hated. Right?
Jada:Then they explained why they said that spreadsheets serve them better than navigating six dropdown menus, being forced to navigate mandatory business justification fields, and then 47 fields after that on the platform, to show anything useful. They said that they've watched entire security teams do the same exact thing and just walk away. Being a 6 figure platform to collect dust while the rest of the work happens somewhere else. Sounds pretty drastic,
Elay:Very. Right.
Jada:Now, to be honest, I don't think they're wrong about their experience. I felt that friction too, as a practitioner. But when I read that post, Elaine, the question that kept coming back to me wasn't, is the platform bad? It was more so how much of their old process were they trying to hang on to while building something new? Makes you wonder, right?
Jada:So I want to say that that sounds like something familiar, right? Have you experienced a similar situation?
Elay:Yes, very familiar.
Jada:Okay. So let me ask you this then. When you walk into a new IRM engagement, is there a moment early on that usually tells whether a team needs to transform their process or transfer it?
Elay:So usually in the first session, not during sales, not during discovery, usually in the first working session, you can kind of tell right on the discovery call. You know, a lot of people, and when we say discovery, this is where you're just trying to understand what's their requirement. What are you looking for? You know, and during the discovery call, everyone kind of says what they want the things to do. Right?
Elay:They wanted to do the right. They want to do the right thing in summary. But when you sit down with them and start going through their process, mapping the fields, one of the things that you would want to be on the lookout for is to watch how they react when IRM doesn't have the field for something they want, right. Or a field for something they care about or a particular flow that they care about. Right.
Elay:If their instinct is, can we add this? Can we do this? Then that's more of a, you know, transformation conversation that they want to have now. Yeah. Cause usually they're like, now they're this, you would see the enthusiasm in them.
Elay:Right. But if they keep saying, well, we would just keep doing this. Right. Or we would keep using Jira or we keep using spreadsheet in that example. Right.
Elay:Or we can keep this part in the spreadsheet and then use the system for this. You can tell that maybe this is just a situation where they just need to transfer. Okay. Maybe we need to really, really, you know, how it's like crawl, walk approach. No, maybe they're more than crawling.
Elay:Right. Cause you can tell that they're not ready, even though they say they're ready, the actions speak otherwise. Right. And usually then we start asking like the internal implementation team. We start asking questions to ourselves.
Elay:So even sometimes we would involve the client and be like, Hey, does your current process work? Based on the current person, just process, they just explained to us. Do we think it even works? Right. Or does it just exist so that they can say they have a process because those two things are different.
Elay:Does your process work? What you're currently doing? Is it working or is just existing and you're just going through the motion? Cause you would see if audit fails, you know, things like that, or they're not passing or maybe, you know, there's always an underlying reason why they purchased a new platform or a new tool. So usually earlier on, you can tell.
Jada:Yeah, I can actually agree with that. I've even heard the sentence. Well, the demo showed me that I could do that. And that's usually during the sales call when they see like the fully vamped out IRM and then you realize, well, there's a difference between the demoing the product versus the actual product that you purchase.
Elay:You know, one thing though, I would like to ask you something because I've actually been in an implementation where, because they saw something in during sale and the sales team told them something specific. As soon as we said, we don't advise you to do that because of X, Y, and Z. They're like, we're not going live. We're not implementing this until you give us this, give us what we're asking for.
Jada:Gosh.
Elay:Yeah. So that's why I said that approach where it's like, we're not doing this. It's not going to work because we need to go a lot. We need to end this project. We need to deliver something to you.
Elay:Right? So that's why we always try to meet them somewhere. Now, let me ask you though, to that question. You've been on the implementation side and the compliance side, right? Cause I know we met during the, when you were in the compliance side, but does your answer to transform or transfer change depending on which seat you're sitting on, does it matter?
Jada:Well, if I'm gonna be frank, I will say, course. I mean, if I'm on the compliance side, I mean, I don't want to recreate my process. Right? No, I'm just kidding. No, that's usually the response I get when I hear that.
Jada:So no, I definitely don't agree with that. To me being on both sides, even at one point I was wearing dual hats and I do not recommend that by the way, it was very stressful and rough. What I know now and how the GRC field is going, I will say it really depends more on the organization and how they're doing something than the position I sit in. And so for example, say I'm at an org that is used to showing dashboards in Microsoft three sixty five or Tableau, right? And they brought in ServiceNow IRM to help them improve their risk management process.
Elay:But we
Jada:both know platform does dashboarding as well. Right? So the question comes, do we transform how we do dashboarding into ServiceNow, or are we going to transfer the data to our preexisting dashboards and do that? Right. In that situation, I will definitely transfer that data in a heartbeat to the existing dashboard and keep it moving.
Jada:Because to me, trying to change that way of the organization showing dashboards, I feel like is working harder, not smarter. And I definitely want to work smarter regardless of any situation. Right? But it's working for the org. They're not having pain points with it.
Jada:Let's not try to change it. Let's try to adapt to it and have that data from the, go from the Now Platform to the dashboard of choice and have it work. But in a different situation though, if the org is using say offline copies and are manually updating quote unquote their dashboard every month manually, that's a different situation. At that point, I think it's time to transform that process and have the ServiceNow platform do the work for them. Again, that is working smarter, not harder in my opinion.
Jada:Why manually do something when you now have adopted a solution that can automate it for you? I mean, at that point, doesn't it sound like a easy decision to make? Does that just mean? No,
Elay:it definitely is. And we see a lot of customers, sometimes they are already matured customers where they have their own reporting tool like Tableau or EREP and they would actually take the data from ServiceNow, transfer it to their own, it's a third party tool and do the reporting from them rather than trying to use ServiceNow as the NOBL reporting.
Jada:I love that. I love that. Very different. So yeah, I can totally understand that. Okay.
Jada:Elay. So I have another question for you. Have you ever had a client that you knew needed to transform, but they were dead set on recreating what they had. And how did you handle that conversation? I hear you laughing.
Elay:That's a good question. And it's a good question because I want to say sometimes not every time, right? I have lost the argument with the client. Yes. And sometimes you just have to let them do it their way and then let them realize, because imagine being on an implementation and you're arguing with the customer, they purchased it.
Elay:Think about it.
Jada:They spent the money.
Elay:They spent the money. But one of the things that I always try to make sure before I give up is help them understand the platform needs to be configured correctly because if they let us, if they say, Hey, if we lose, let's say we lost the argument, right? Which I'm not even gonna lie, it happened. Right. The platform would be configured exactly like their, in that example, old spreadsheet.
Elay:Nobody's going to end up using it because you just literally copied and pasted.
Jada:So what are you improving? Right?
Elay:Exactly. You're not improving anything, right? The fields are there. The 101 fields, 47 fields, and number of fields are there. The workflow is there.
Elay:Sometimes the workflow that is in the platform does not match the workflow that you have, but you're like, Hey, we just still want all of these copy and paste the spreadsheet. The system doesn't see those new fields on the spreadsheet. The system doesn't know what your spreadsheet does. Right. But one thing that I've learned though is I can't win every battle in every implementation.
Elay:Right. Are some battles that you will win and the customer can see that. They're like, oh yeah, we're happy you did this. Or you said this, or you made us do this. Right.
Elay:But the battles that I can now win, I try to have as much logical compensations about it. Right. Cause that's what I've learned. You have to show them that, Hey, these are the features. Functionalities.
Elay:These are the things that you're going to give up. If we go your way, sometimes I would literally pull up. I'm just going to give an example, like a risk framework, right? That actually shows them, you know, what exactly would, how the system would work natively without your 47 fields or copy and paste it from your spreadsheet, how our control visibility happens for them, how the relationships will work in your spreadsheet. You technically don't have relationship except the formulas that you've built or the VLOOKUPs that you've built.
Elay:Right. But how the native system just naturally has relationship based on the information or data model that you've created. And sometimes I would even ask them like, Hey, can your spreadsheet do this? Can you point to this? Right.
Elay:Can it natively see their three sixty relationship? Right. And most times it cannot, but when I lose the battle, I just let them have it. Right. Sometimes it would create a phased approach like, Hey, we're doing your way right now.
Elay:Keeping in mind, you might have to do a reimplementation depending on what you decide.
Jada:That's big on what you just said, Two things based off what you said though. I love that you put care into the work that you do. It's very clear because even though you lost the battle, you still care enough to tell them, we can do it that way, but this is what we're missing out on, or this is what we may lead into. I don't think there's a lot of consultants that do that. They kind of just accept and just move on without saying, Hey, just in case you didn't know that this is going to happen.
Jada:And then my second point is that I feel like you've taught me that. You've taught to me that it's okay to lose the battle because there are just some things that I can't control. And I'm totally fine with that now. And I think that's what makes you better implementer and practitioner when it comes to the tool is knowing the things that you can control and the things you cannot. Yeah.
Jada:I agree. I know it was
Elay:based on that practitioner side, so I know you'd be stupid. But so you said something, right. And it got me thinking, right. Based on this transfer or transform conversation that we're having. Right.
Elay:So if a team has been lifting and shifting, you know, their processes for the past few years. Okay. Let's say two years. The platform is already configured that way. Is it worth going back and ripping out what has been configured before, or would you say it's better to work around?
Jada:That is a good question. And again, you said it gracefully. Usually I would use the term blow up, blow up what they've implemented and start fresh. Right. In our honesty though, I think it depends on which part of lifting and shifting are actually working versus which ones are not.
Jada:For things that are not working, that I do know that I don't want to stay in that state for too long. And we'll say what I need to say to let them know that, Hey, we didn't get this right. We need to redo because I feel like it's going to cause more friction. So like in my experience, I've seen that the more we try to change how IRM works, the problems we run into causes more frustration. If what's working though, is also considered a dependency on what's not working or vice versa.
Jada:Well, then that has to go too irregardless. I mean, I know it's working, but at the same time it's causing something that's not. So, and we need to start fresh. We want an integrated risk management program that is solving our issues, not making new ones and then just accepting them as is because well, there's nothing we can do. Don't agree with that.
Jada:You know, having to rebuild is already frustrating enough. I get it. No one wants to do that, but I feel like always running into problems is far more frustrating, especially when we can overcome it by just rebuilding and going forward after that. But I do know, and I want to acknowledge that navigating that conversation around rebuilding and when is always tricky too, because it's almost like a catch 22 in my opinion. Users may already think they're doing something right because they've adopted this new platform.
Jada:They have accepted it and say, okay, this is how we're doing it. But then at the same time, you're telling them yes, but there's a better way. I can tell from the moment, depending on how that conversation lands, you're going to have far more frustrated users than if the implementation went well the first time. That's my perspective on it. I will live on that hill, but long story short, there will always need to be time for a rebill if you want to get the fullest out of what you purchase.
Jada:If you don't, that's a different story. If you've paid for it, just like we mentioned before, then you want to get the most value out of what you paid for. So the answer is obvious at that point, or I don't know, maybe it's just me, but like I said, I'll stay on that hill if I need to.
Elay:No, but I do agree with you though. It depends. Like I always say to the mind sometimes where's your pain loudest the most, right? Because that's how it's going to be the easiest for you to figure out what you want to do. Because sometimes you're still limping, you know, you're still like, oh, okay, we're still trying, but leadership hasn't felt it.
Elay:Findings haven't caught up to it. Maybe this is not the time then we rip it off. Like you said, maybe we can do some work around around it. Right. Yeah.
Elay:That we
Jada:can make sure. Yeah. There are situations where people see
Elay:it, but
Jada:it takes the right person to come in and say it.
Elay:Right. Exactly. So it just depends honestly, but I agree with you.
Jada:So last question I have for you is where do you draw the line, if any, between meeting users where they are and enabling a process that's going to hurt the implementation long term. So kind of similar of what we discussed before, but more so thinking about the level of effort it's going to take to implement something they requested versus going in a different direction. Like what would you say to that?
Elay:You know, sometimes this one, I wrestle with it because you're asking them to change. You're asking users real life, right? They need to have pretty much have change management, which is real, right? Because you're telling them, Hey, you need to change the way you do something. Right?
Jada:Exactly. Yeah.
Elay:You're also telling them pretty much you need to adopt something new, which is real. Some people don't like change and then plus adoption. Right. But most of the time, the difference that I've seen between users meeting users where they are and enabling the process is kind of like, I can meet you on a front end standpoint, because I know that that's where the change would happen the most for you. But when it comes to the backend, meaning the data model, the process, sometimes meeting you where you are is not gonna work.
Elay:It's just not going to work. How you use the system from a front end standpoint, you know, we can make it a UX, right? We can make it look and feel certain way, you know, make change some languages on the UI. So you're more comfortable and it's easy for you to adopt. But one thing we would want to make sure we protect when we're implementing is the flow, meaning the workflow or the life cycle, the configuration of the data model itself, because one thing I wouldn't want, or as an implementer, you do not want is to configure the wrong thing, right around a or configure a data model around a broken process.
Elay:Right. Because you won't be able to undo it quietly. Honestly, you will not. It does take effort to undo it. A bad data model, a bad implementing a data model on a broken process is just to me, a recipe for disaster in a few months.
Elay:So most of the time we just always have to think about where would we want to meet the end user for us? It would always be on the UI, front end, the front facing, like if there's a form or a website or, you know, that's where we would want to make, make it easier for now. And like, okay, we don't want to change too much. Now maybe we have a phased approach. In phase two, we might tell you, okay, now that you've been using this, you're a little more familiar and comfortable with the system.
Elay:Now these are some of the things that we recommend that you start changing or looking into changing or even updating. Then at that point, you know, from a front end user, they're already comfortable with the navigation, with the forms and you know, how to submit something or request something or provide evidence. Right. They're a lot more familiar with it Because what I've seen in most of the time, if we're not careful, right. They will in few months when they realize, Hey, we've actually done the wrong thing, which most of them they will find out when they start doing reports, right.
Elay:When they see that, Hey, their risk scores don't reflect what the reality is for them, or maybe the process that they were supposed to fix. Right. It's not working anymore for them because now they're in the system rather than the spreadsheet. Right. I have had to take people back to out of the box, even though we're like we told you in the beginning, which everything is always documented.
Elay:Right. So short term, we can, from a front end standpoint, assist you or meet you there. But from a long term, we try to protect the integrity of the system as much as possible while ensuring that they find a way to help them improve their process. 99.9% of the time, 47 fields are not needed.
Jada:See, you answered that so gracefully. So kind, Elay. I feel like maybe I'm a little bit rough around the edges a bit when it comes to that approach, but that could be because I come from the compliance side, right? I was not originally an implementer. So for me, and that, in that perspective, you know, I would tell, I would tell whoever's asking for something that's either going to affect upgradability.
Jada:And like you said, the integrity, I tell them we can't do that. And if someone says, but no, we can't do that. This is the alternative that we need to do. So I'm a bit more direct about it because the one thing that draws the line for me is getting into a situation where the now ServiceNow is telling me that, Oh, we can't upgrade your instance. You've made too many customizations.
Jada:So instead of letting them down gently, we're just going to turn that page, say, Nope, can't do it. Move on. So thank you for showing the graceful side of that response, but we both agree that, you know, there is a line and it must be followed.
Elay:Okay. So now we've talked about that. It depends, right? The scenario is dependent on what the customer is facing. Right?
Elay:So last question for me, Is there a scenario okay where the lift and shift is actually the right call or is it always a red flag?
Jada:Well, if I'm going to be upfront, I'm going to say definitely a red flag, hands down a red flag and probably the biggest red flag I've ever had to deal with personally. Cause I've been there. I lived through that. I don't want to do it again, but it has happened. So to be clear, I was in a situation where there was no support from leadership on transforming the organization's culture around IRM.
Jada:So we know IRM is not just a ServiceNow application, but it's also a strategy that changes how orgs see and respond to risk. Right? So what happens when you have that lack of support? Well, it basically means that work around IRM is never prioritized. It's neglected.
Jada:Important key questions about processes go unanswered. And to me, I started to think, well, what's the point of all this? At the end of the day, I didn't purchase the tool. So if you're going to not care about your investment, why should I? At that point, to me, it's easier just to get the existing process into the system and wait for leadership to pay attention and start asking the right questions.
Jada:Because in my experience, and like I said before, you taught me that I really could only focus on the things that I can control, but there's only so much that you can control, especially when you have leaderships that need to make direction, they need to make, they need to define different portions of what an integrated risk management strategy looks like for the org. And you can't do that alone. You have to depend on leadership to get your implementation right. I feel like that's the difference when you're in a situation where an org has fully supported not only the tool implementation, but the process improvements that it's going to create versus an org that just sees it as a tool they've purchased. That's just going to work at the end of the project.
Jada:And that's the end of it. So that's my perspective to the answer. What are your thoughts? Like, do you agree or would you say I it'd be different for you and your experience as an implementer?
Elay:For me, it's not a red flag right now. It's not a green flag either. Okay. But I do a 100% agree with you. The direction always has to come from leadership.
Elay:There has to be an organizational agreement, which that only comes from leadership. Okay. As a compliance practitioner, sometimes yes, they will ask for your feedback, but if leadership doesn't have the buying or the agreement across the board so that they can trickle down that information down to everyone, it's not going to work. It's not. I worked my day in shifts.
Elay:I will be honest with you. Right. But there's scenarios where you're stuck at as an implementer, where sometimes you don't have a choice because you don't work for the company. Technically you work for them.
Jada:And is the perspective of the consultant and which is why it's so valuable because I never saw it like that. So thank you for sharing that, Eli. Definitely. All right. So we've had a pretty in-depth discussion around the transforming and transferring discussion.
Jada:I again commend you and appreciate your time, Hille, on sharing your knowledge with us here. I definitely hope that we can do this again in the future because honestly, doing a podcast with someone else versus yourself alone is so much better. So until next time, I'm Jada.
Elay:And I'm Eli.
Jada:And let's keep making sense of IRM.
Elay:One conversation at a time.
Jada:Let's Talk IRM is a Sassy Boutique podcast. If you're looking to go deeper on how to implement IRM as a strategy and as a ServiceNow application, we're building something for you. Head to the sassyboutique.com to join the wait list and be the first to know when it drops. Connect with me on LinkedIn to keep the conversation going, and follow the show so you don't miss what's next. Links are in the show notes.
Jada:But until then, my friends, let's keep making sense of IRM one conversation at a time.