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.
An org once asked me to come in and customize their audit module to fit how their team works. At first, it sounded reasonable. But the more I dug into this request, the clearer it got for me. They weren't actually using the module yet. Their request was based on a high level demo they've seen and not actually on the work that they were completing in IRM.
Jada:So the real question wasn't, can we build this? It was, do they even understand what they're asking to change? That's what we're getting into today. What's good, Army's crew? I'm Jada, and this is Let's Talk IRM.
Jada:Welcome back, everyone. My cohost, Ele, is here to push on the topic from the consulting side, and keeping us honest is our facilitator, Mish. Thank you, ladies, for being here. Alright, Mish. Take it away.
Meesh:Alright, ladies. Here's a question I want both of you to sit with. Is every customization request actually solving a problem within the IRM application, or is it a knowledge gap wearing a customization costume? Jada, I want to start with you. What was the moment you knew your change request for the audit module wasn't a build problem?
Jada:So good question, Mish. So the group I was working with was one of the many groups that were working in the IRM application at the time, which is normal. You'll have different groups with different regulatory requirements all doing their thing in IRM. The initial request kind of arrived as, let's add x y z fields to our test templates within the audit module module to account for how we do our process today. Now, when this was first presented to me, I wanted to know the reasoning that was behind this request.
Jada:So in my usual response to a request, right, I essentially ask why and pretty much what was their current process today that wasn't mapping correctly to IRM. And during that call, I realized that their request stemmed from a high level demo that they had already seen and had nothing to do with any work that they were currently doing in IRM at all. So Wow. Instead of actually having a gap that they identified and wanted to remediate, they were actually going off of perception based. They hadn't actually utilized the audit module for anything.
Jada:From my perspective, it seemed like they didn't truly understand how the audit module function, the different features within it, and how the policy and compliance module or the risk module both feed into the audit module. So Right. It was my understanding that we need to do some knowledge training, understand how the different modules flow into the audit module, and then kind of understand what is your today process and does that work in an integrated risk management strategy.
Meesh:So what did that request tell you about what the client did not understand yet?
Jada:So if I think about it clearly, I I really think they didn't understand what a test template is used for. So I received kind of some feedback that, oh, this is not what we, you know, send to our users when we're requesting more information. And from there, I knew, okay, well, that's what an evidence request is for. Test template isn't something that we send to our users, it's more of modeling how we wanna conduct a test on a control. Like, what is the the x y z steps needed, and what is the expectation for passing a control test, right, when you're looking at design test of design and test of effectiveness.
Jada:So, I mean, that one detail that they provided, I knew, okay. Let's let's look at this at a different perspective because I don't think you realize that test templates are never gonna send any detail to your users. It's the evidence request that you're gonna need if you're requesting a specific evidence. So the basic component of a test template wasn't clearly understood.
Meesh:So then, Elaine, what are the signals that tell you this is really a knowledge gap request rather than a build request?
Elay:Most of the time, the signal always shows when depending on what the requirements the business is asking. Right? Mhmm. Because if they've seen during discovery or workshops, usually, they would have seen how does the process work. Right?
Elay:What's the application we're implementing, and how does this application work? And, also, during that process is when we're learning, what is your process today? If you threw ServiceNow out of the window, right, what do you do today? How do you do it today? And one of the jobs of the implementer or the consultants on that implementation is to understand the customer's ask and understand how the system works and help them bridge that gap.
Elay:So most of the time, it's always the customer not understanding how different functionality works. Based on the example that Jada was given was providing some minutes ago Yeah. It's always more of like, hey. And it's a good thing that they asked, what's the why? Why do you need this new attribute?
Elay:Right? Adding a field on a form is not it's technically a custom field. It's not a customization because ServiceNow gives you a template. Right? And it's like, hey.
Elay:Yeah. We can add more attributes, but does not mean adding a 100 attributes. You might add one or two attributes, which if it's justified Right. Case to it. Where it's like, hey.
Elay:We need to be able to break down to another level of implementation requirements, right, during
Meesh:Right.
Elay:In the control time. It just depends on the ask. The business doesn't know how the functionality works. They will ask for heaven on earth without even thinking is this is either other ways. Right?
Elay:So as a consultant, that way you're there to guide them, to help.
Jada:That is true. I do have a question for you, Ele. So that discovery that you're talking about, does this happen before the statement of work is being dealt with, or does it happen during the build of the statement of work? Just kind of understanding at what part of the process do you engage with your customers about this discovery?
Elay:So before statement of work, usually, there is a high level discovery to understand what are you looking for ServiceNow to do for you. Mhmm. Not even what's the process or what's your process. So that's where and usually, that's where, like, the sales or the architects come into the picture and try to understand the customer and then show them the art of the possible. Mhmm.
Elay:Now them showing the art of the possible does not mean that's what you're gonna get during the build because there's no way before the sow, the sales and architects can understand or solution consultants can understand all your process. It's not possible. So that's why this then they draft the sow. But there's always always a we call it prescoping or prediscovery, whichever one you wanna call it, right, but it's usually like a scoping to understand what are you looking for in general. Can I ask you a
Meesh:question on that one then?
Elay:Yes, please.
Meesh:Is there a phrase clients use that immediately makes you pause?
Elay:There's a lot of phrases that they use. Okay? It
Jada:just depends on
Elay:what kind of phrase. Like, sometimes I had a customer recently who was like, I want the system to do I want the system to tell the employee the true or false like, not true or false, like a correct or wrong answer. And then we wanted to record every single ad, every single retries that they do. We want them to store every score of every retry, and I'm like, hold on. It's not as on an LMS system.
Elay:Mhmm. Yeah. That's not what ServiceNow does.
Jada:That's a giveaway.
Elay:Right. Yeah. So for me, that's why I thought, no. No. No.
Elay:No. No. Let's come back to reality. There's a reason why LMS systems exist. Now can you integrate ServiceNow with it?
Elay:Oh, 100%. Right? We can push the answers somewhere else. But ServiceNow, it's not like you you're not building a staging environment. Right?
Elay:Because you need a staging in between those multiple retries for me to be able to know how many times you tried taking the questionnaire. Right? So that for me, that was a dead giveaway that, okay, you don't understand how ServiceNow works.
Jada:Yeah. Yeah. I can concur on that. Like, from my perspective, what I've also noticed is that a user can't really articulate what they want. It's it's really vague.
Jada:And so versus a user that's, you know, kind of like, yeah, when I'm going through my attestation phase and I do this, like, they can kind of pinpoint where their issue is. But if they completely are vague about it and cannot pinpoint where they're going, I kinda realized, yeah, you probably haven't used the tool yet, have you? So Yeah. For me, that's what I've noticed.
Meesh:So, Eli, tell me about a customization you ended up building even though you would have preferred not to.
Elay:I would say these were just, like, in the past, though. When we had you know, we were not in Yokohama or Australia back then then or even in Zurich. We were, like, in, you know, the Calgary days, the, you know, the Eureka days. So this was, like, back in the day. Okay?
Elay:It's true.
Meesh:Many months ago. Many, many, many, many, many months ago.
Elay:Because now, you know, there's a lot of features where it's, like, even if the customer wanna customize, there's it's likely on the road map somewhere with ServiceNow. Now you might not get it today. You might get it months from now, but it's likely on the road map. I've had a few customizations that we've had to perform for customers in the IRM world where it it doesn't happen out of the box. So some of them could be like a a brand new, like, one of the example, the attestation, right, for a policy, being able to attest that you've read and you understand the policy.
Elay:And it's not just saying, yes. I acknowledge. They wanted you to in order for them to validate, which was one of their regulatory requirement, was to answer a few questions to truly justify that you understood what policy the policy you just read. Because I can easily just scroll through, click acknowledge, and move on. Mhmm.
Elay:But I didn't read nothing. But in order for them to justify it was those four they had four questions, and those questions change every quarter when they do their annual policy review. So That's why we had to explain to them, like, hey. ServiceNow is not an LMS, but we can do some things. Right?
Elay:Records together for an end user because another thing was like, hey. We need to we want them to see it in one view. And it's like, you're not gonna see all this in one view. But guess what? We can do it, but it was gonna be a customization because ServiceNow doesn't have it out of the box.
Elay:They still don't have it out of the box. Mhmm. That's one of those customizations where, yes, it's justifiable as long as there is no technical debt to the customer. Meaning, we didn't update any out of the box feature, meaning the baseline functionality. You didn't touch it.
Elay:We used it, but we never wrote overrode it.
Jada:I have a curious question. Right? So out of the customizations that you've done, have there been any that kinda still haunt you today? Like, for example, the risk intake form that you and I worked on together. I know for that project, I know you know what I'm talking about.
Elay:Yes.
Jada:With what I know now, I feel like that still haunts me today because I feel like my biggest mistake was not teaching the business more about how the risk module functions, especially the level of risk module or license that they had purchased, and how their existing risk management process did not align with the integrated risk management strategy. Yeah. So it was the risk intake form that we created as a record producer. When a user submits it, then it turns into a risk item on the the risk list or the risk table. So it wasn't using risk statements.
Jada:It wasn't tying to controls. It wasn't tying to risk register? So essentially, yeah, it was on the the risk table. So it wasn't advanced risk or anything like that. It was just classic risk, and the risk, as soon as you submitted it from the record producer, just went on to the risk table.
Elay:Okay. I think I vaguely remember it, but that was how they were capturing their risk today, though. That's the only way they could get in get their risk into their risk register. And then they still need to redo a risk assessment on it.
Jada:Right. Well, I guess I guess I got my answer from you because you vaguely remember. I still remember it in detail because I feel like that was probably my first mistake that I made. And so I don't know. It just kinda sits with me, but that was all.
Jada:It was just a curious question.
Meesh:Well, Jada, do you feel as a practitioner today that you have more freedom to decide what to customize versus when you first started out as an IRM practitioner.
Jada:Yes, I would say so. So I understand that Elaine comes in from the consulting perspective, and so my perspective is a little different because when I start my interviews or my meetings with the org leaders that I'm interested in, they kinda bring my own set of questions of kind of understanding that org's culture, that org's way of thinking or their approach to implementing IRM if they have done so or not. For me, it starts at the beginning before agreeing to anything with an org is understanding what their culture is. Because if they don't fit, if they're rigid and they feel like they're set in their ways and they're not willing transform any of their processes into the IRM application, and that's a hard stop for me. I'm not willing to spend my time with an org that doesn't want to change because they see IRM as only a tool upgrade and not an upgrade to their culture on how they handle risk management.
Jada:So with that said, when I do work for an org on either their implementation or helping operationalize their IRM application, we have a unique understanding that they trust me to come in to give them a a road map essentially of what are we going to accomplish that's going to still meet our short term and long term goals, but also allow us to maximize the value of our IRM application. So I don't really operate from a statement of work that's defined, you know, by implementing x, y, and z. I kinda operate from the perspective that I'm gonna be spending some time with this organization, and there's really not necessarily end time on what I'm gonna spend with this organization, so that gives me more freedom to say, okay. Hey. Let's spend time learning first, then decide, okay.
Jada:What we wanna do, get into the IRM application, identify our personas, and start utilizing it that way. So I would say I have more freedom as a practitioner, but completely understand that not everyone operates like that, especially if you're just coming in for a project to implement. Then you have, of course, the statement of works that you have to abide by, but that's just from my perspective.
Meesh:Are we being unfair to clients? When is the client actually right and the platform genuinely wrong?
Jada:That's really hard, and I will admit that I have a bias, and my biasm is that the platform is not always wrong. In my experience, and I wanna make it clear, this is my experience and my opinion, that any org that is pushing for a customization, it has not been because the platform lacked in something. It's because of a lack of understanding. So an example would be the evidence change request for the audit module. They thought they needed to add more fields to their test template in order to make it clear to their end users what evidence they were trying to request or test upon.
Jada:That's not a gap in the platform. That's a lack of understanding of what a test template is truly for versus what an evidence request is truly for. So in other conversations that I've had, now I make it very clear that, hey. What is it that you're asking for and why? Walk me through your why.
Jada:Put me in your shoes so I can understand what problem it is that we're trying to solve. And usually, from that conversation, I can tell, okay. Let's take it back a step, and let's see if we actually understand the terminology that we're using or the action that IRM is doing that we understand what its purpose is for. So to be fair, I think it's a knowledge gap, but there are times where you could have a problem, a gap in the system.
Meesh:No problem, Hille. Is customization sometimes the right answer? A consultant just hide behind best practices.
Elay:I think customization is the always the right answer. Sometimes it's needed if the functionality is not within platform, meaning if the functionality is not baseline. Yeah. ServiceNow is a platform. It is not going to give you every single thing you need.
Elay:Keep that in mind. Every organization has a process, and every organization has something unique to them regardless of what that process is. This is also why ServiceNow has ability to integrate with other platforms.
Jada:True. Can
Elay:integrate with, you know, UCF, ARMIS, know, some of your security operations integration. We can integrate with Snowflake. We could like, this is that's the pure reason why ServiceNow integrates. We we're not a ServiceNow doesn't do everything. They're not a jack of all trades.
Elay:Now no. It's true. Now that's why I said sometimes customization is needed. Yeah. But it is the job of the consultant to do their due diligence first before agreeing to a customization.
Elay:Doesn't matter what the sow says. Right? Yes. We still wanna speak to the SAL. Okay?
Elay:We still wanna deliver against the SAL, but this is also why the customer is coming to the consultation team or the consulting team to say, hey. We need your help. We need your assistance to help us with this. So that's why I'm like, yes. There are sometimes customization is the answer.
Elay:It just depends.
Meesh:But is the real difference expertise or willingness to risk upsetting the client, though?
Elay:It's the willingness to upset the client. Because even if you do everything the client wants, it's still possible to upset them, unfortunately. If you're going into an implementation and putting feelings behind it, you that's already a problem. Going into an implementation and saying, oh, I don't wanna upset this customer, that means you're gonna do everything they ask for even if it's something that is wrong for them or even if it's something that is gonna give cause a technical debt. Now there are some times where you have to agree to them where it's like, well, if it's adding a field, just one field, two field that it's just maybe for reporting purposes, the ServiceNow doesn't have out of the box, go ahead and add it.
Elay:There's a reason why maybe they need it for reporting and they can justify the reason. Fine. Now if they're saying had add a 100 fields, now you need to step back and be like, okay. Why do we need to add all these fields?
Jada:When I'm considering customizations, right, my biggest concern is level of effort when it comes to upgradability and will the company be able to manage the upgrade on their own without having to reach out to the consulting agency that created the customization for help. So in those situations, if there's a customization, I always pressure test, well, what could happen? What could go wrong during upgrade that could block the business? And if there's minimum impact, then I'm okay. But if it's a change that's really gonna take a certain level of expertise, such as a developer specifically to fix the issue and the company does not have a developer on team, like, do you handle those type of conversations?
Jada:Do you recommend the company has, like, a standing agreement with the consulting agency for those type of issues, or do you kind of tell them they're left to their own devices if something happens?
Elay:I don't think any customer is left to their own devices when something happens. Usually, if we have to do the customization in an unfortunate situation where you don't have a choice, right, evaluating what the solution is first. What is that customization solution? There is always three, four, 10 different ways of doing one thing. Now the different ways might require different complexity.
Elay:We might achieve the same goal, but it might be different complexities. And evaluating what is the design strategy for this customization. What are you planning on using? And not just that, also identify what are some of the challenges and maintenance of each of these solutions. 90% of the time, you will be able to identify which is the best option.
Elay:But let's assume the customer did not buy a support contract. Let's assume it's just the implementation in your app. No matter the scenario, you should be working hand in hand with the platform team when you're doing any customization because they are the ones eventually that will maintain it. And also ensuring as a good consulting team not to make any change that will cause a technical debt to the customer, which means you're not touching any baseline code. Right.
Elay:You can call a baseline code in your code. Right? But as long as you're not changing ServiceNow has a business rule that does x. Don't change that business rule.
Jada:Yeah.
Elay:If you can if you need to touch it, have a reason for it.
Jada:Document the heck out of it. Right?
Elay:Document the life out
Meesh:of it.
Elay:Okay? Yes. Do the knowledge transfers to the technical team, the platform team.
Jada:Let's just let those two thing emphasize this this podcast episode for a second, Elaine. Don't touch the original code. Point blank. And if you if you have to, use the override script that call to the the baseline scripts or clone. Putting it out there.
Jada:If if we leave this talk, let everyone know that those are the two main things. I've seen it done, and honestly, the biggest headache was trying to understand why did we touch the baseline code. Yes. Point blank. Point blank.
Meesh:Alright then. So okay. So what if a customer doesn't know what they want? They think they know what they want. Like, we've seen this.
Meesh:I want this, this, this, this, this, this, because they don't really know what they want. What would you say to them?
Jada:Yeah. So they're excited. They want us they want all the thing because sometimes
Elay:It's the thing.
Jada:When they see the demo, they see the pretty sparkly, fully complete demo that has all the bells and whistles. Yep. Well Yep. For me, my perspective is, okay. Let's level set.
Jada:What did you buy? That's the first thing. I I need to know what you bought because what you saw could have been the full bells and whistles package, but it turns out you only bought the standard license, which doesn't come with none of the bells and whistles. So we need to level set and understand what you have in place. Then I can tell you what the art of the possible is as long as your internal processes that we're transforming into IRM align with that?
Jada:That would be my perspective to that question.
Elay:I agree with you. The main thing is keeping in mind and sometimes I don't blame these customers, and I'm saying this, like, honestly. K? I'm doing sales. Sales will show you everything, like we say, the art of the possible.
Elay:You can do so many things in ServiceNow. That's the craziest thing. And I've seen crazy demos. It looks good. It looks fancy.
Elay:Right? Mhmm. But I want that. You know? When you see flashy things, that's what you want.
Elay:Yeah. And one of the things that customers don't understand is the amount of work that goes into it. Okay?
Jada:A lot of work.
Elay:A lot of work. They don't understand that because you see it does not mean you need it. Because you see it does not mean your team has the capacity to be able to handle this. Yeah. Because you see it does not mean you can afford it.
Elay:Yeah. Okay? No. It's the truth because the whole purpose of sales is to be able to show you the potential of everything you can do on the platform, which is possible, including the custom stuff. Sometimes I watch some sales.
Elay:I'm sitting in the sales call, and I'm a thousand percent sure that that was a custom work. There's nothing wrong with that. But the customer doesn't understand that. And that goes back to what Jada was saying what's what what's in the South? What did you purchase?
Elay:Okay? Because the implementation team is coming in based on what you purchased, not based on what you saw from sales.
Jada:And that that part right there is unfortunately where some disconnects can happen too. Your sales team, they sold you everything that you thought was possible. Mhmm. Then the procurement team went and purchased what was actually reality. Yep.
Jada:And then the implementation team comes in, and they're like, wait. You didn't purchase that. And now you have leadership that's angry, and they're like, what? And they think the implementation team is at fault. And, actually, it's your procurement team who were like, nope.
Jada:We don't have the funds for that. So Yes. It's very important to understand what you're purchasing and make sure that whoever is showing you that demo is showing exactly what you plan to pay for. Because Yeah. Yeah.
Jada:When it doesn't line up, it it gets ugly, and I've seen it. It's not pretty.
Elay:Yes. Yeah. And that's not why most times, even when we do our own sales, we try to make sure that the customer understands what reality is gonna look like when you're implement. Right? Mhmm.
Elay:Because you never wanna put the implementation team in a bad spot.
Meesh:I was just gonna say, what's one of your phrases?
Elay:Nice to have. Not a must have. Mhmm. What and and that's also one of the reasons why sometimes, let's say, the customer already purchased it based on what they saw. Right?
Elay:Even when you're implementing, you have to remember you have to implement in phases. There are some foundational things that you have implement in IRM before you can even start running, unfortunately. Right?
Jada:Mhmm.
Elay:You need the data. You need the the roles, the groups. Who are the users? What's the plan for the users? What are the notification?
Elay:You're not gonna use out of black notification, unfortunately. It's it has nothing in it. You know, like, there are some baseline things that you will do regardless of any of those fancy thing that you've seen. And helping the customer to understand, like, hey. Let's walk before we start running is very important.
Elay:So most of the time, even when we're implementing, you're like, okay. Let's have a a road map. Let's have a a phased approach to what we're doing. It's it's not a must have. The nice to have is what are the key things that you need for your business to run Yeah.
Elay:Especially for people who are just growing.
Jada:To me, that that shows the importance of staying as realistic as possible when it comes to building your your foundation because, like, for example, the advanced risk module, Eli. I've seen an organization where their procurement team purchased advanced risk cause it had all the things, but the maturity level of their risk program was still in spreadsheet, not even considering risk at an entity level. Now advanced risk is very powerful, but if your maturity is not even at that level, there's nothing wrong with starting out with classic risk. Yes. You can start your process, build your foundations up, and then improve your processes so that when you do get to advanced risk, it's not like trying to go up a huge hill of I need to understand how to track risk quantitatively and also learn how to use advanced risk.
Jada:So it definitely is important to stay realistic when it comes to your limitation. And like you said, Elay, stick to your foundation. Stick to the things that you must have so that you can get your processes going in IRM.
Meesh:So say you've done customization. You did the customization request. It wasn't a full one because you said, you don't get your phrase. Your must haves is not a must haves. So it sounded reasonable at the time, but then became a disaster.
Meesh:So how would you feel about that?
Elay:Oh, I would feel devastated. I'm I'm having to experience it. I'll knock on wood. I hope I don't, but I'll be devastated.
Jada:You know, that kinda actually tracks back to that that risk intake form that I was talking about. That I feel like if I could do it all over again because I learned that, oh, they actually don't understand how to use classic risk. Would I wanna go back and teach them first before considering any kind of changes because we need to understand how classic risk work before saying, hey. We need to make x y z changes to it.
Elay:Yeah. But, Jada, in talking about that, I don't think the issue was they didn't understand how classic risk works. Okay? I think it was more of how they wanted the process to be. Yeah.
Elay:Not what out of the box ServiceNow baseline because with classic risk, regardless of which risk you're doing, you will be logging in that risk register wherever you come from. If your risk was created from issue management, it goes into that risk register.
Jada:Yes. Right? It does.
Elay:What's coming from security, it comes into that risk register. It doesn't matter where it's coming from. Right? You will end up in the risk register. Now how they gathered it in their or how they wanted in folks to gather it was to have an intake because they didn't want someone to come and create it, you know, click the new button in the risk register.
Elay:Mhmm. So even with that intake, right, as they mature, all they need to do is turn off the intake. Like, inactivate that intake, that record producer. Turn it off once you mature and let everyone start coming creating the risks based on the risk register. Right?
Elay:Using the risk statement, applying any entity type to it or any specific entity, let it generate your risk for you. Right? Or maybe now the risk comes from an issue. Right? An issue got created from compliance, and they realized this issue could also apply to x y z entities.
Elay:Right? Maybe all the other business applications in our library that is in production. Right? Mhmm. CMDB.
Elay:Now that becomes a risk to not just the entity that was that created that noncompliance issue, right, but to every other potential applications that are out there in production.
Jada:Right. I would agree with that. I would agree with that, that that is how it's supposed to work. But in their case, though, none of that stuff was in place. There was no way of showing how many controls or how their controls were implemented.
Jada:The entity hierarchy entity structure was nonexistent. So whenever a risk came in from the risk intake form, it was more so what do we do now? They didn't know what to do next. So that's why I say it was a lack of understanding because each of those pieces that you you described that helps build your risk program, I agree a 100%. But if they don't understand how those pieces come together and how they are a part of your risk management strategy, then you can have the intake form, but it's never gonna go anywhere if your users don't know what to do.
Elay:I agree. But I think you're also missing the point of I think this team, if I remember correctly, was the compliance team, not even a risk team. And I'm thinking of two particular people.
Jada:You are. They didn't have two separate teams. It was all one.
Elay:Exactly. They did everything.
Jada:And they
Elay:were so focused on so and that's why I'm is more this team was now mature. Right. Are and and I feel like for maturity to and I think you might agree to this. For maturity to come to start, it needs to be some trickle down from leadership as well. Mhmm.
Elay:Because I remember this team being so focused on how they do things today and not wanting to leave how they currently do things.
Jada:Mhmm. Yeah.
Elay:Right? Or They were rigid. They were so rigid. So that's why I'm like, I understand I I understand what you're saying, but I don't think it's a and I say that because just the same way, I think you went on, and I know this was, a discussion. We talked about, like, taking the SNAP and taking the IRM fundamentals and implementation in ServiceNow.
Elay:Right?
Jada:Mhmm.
Elay:You had the luxury of doing the same thing, my friend. And I remember this because just the same way you were so proactive, it was the same and I think you even came, like, after. Right? And I don't correct me. Right?
Elay:But you understood the process. Same way some of them understood the process. But because they were so rigid in what they were doing and not open to evolving, think that again, this is me looking back, keeping in mind I don't remember every single thing. Right? But I think that's where the issue was.
Elay:Right?
Jada:And
Elay:then because if it's understanding how the system work, you know for a fact how many times demo was done. Okay? You you know how many time, you know, like, the system was demoed several times. Okay, guys. Go in and test it.
Elay:Let's be honest. How many times did they go into
Jada:the system? Oh my gosh. Okay. It's So not that often. Not that often.
Jada:I can tell you.
Elay:Okay. Not often. Okay. Because I know for a fact you were in there way more than everybody, and you know the system logs everybody that comes in. How many times have
Jada:you lies. Never lies.
Elay:Never never lies. Never lies. So let's really that's why I'm more of like, hey. Is it that you didn't understand? And if you didn't understand, then you should have asked, hey, guys.
Elay:I still don't understand. I still don't understand. After how many months of same Did you think
Meesh:that you just needed training then? No. No. Customization. Do
Jada:and see, that's that's that part. That's hard to say because you can present as much of information you can, and you can do as many demos as you can, but it's also effort on their part.
Elay:Exactly.
Jada:There's not enough training that can overcome them not putting effort in just going in in the lower environment and just do something. If you make a mistake, it's the lower environment. It it doesn't matter. But if they don't try and then try to overcome their mistake, I mean, Eli could turn purple on the head and they still wouldn't get it. So that's that actually intrigues me a bit.
Jada:Say there's a customization that needs to happen. The individuals that are requesting it, they have a good they have a good head on their shoulders. They've been using the product. They understand the product, but they're like, this this is still a major gap to us. Mhmm.
Jada:You as an, you know, an experienced implementer know that it's not a 100% really a big deal because if you just went through x y z out of the box functionality, it'll solve their problem. But the company is still adamant that, yes, we still want this configuration. From your perspective, not really. Like, how do you navigate that?
Elay:So for me, I still do a lot of pushback. Right? Because if it's and I know you mentioned some minutes ago, like, customization in in the mix of configuration. Right? If it's a configuration where it's something simple, like, added a field to the form, add in another notification.
Elay:Right? Yeah. Sure. Let's just let Bikers be back and please add it for you. Okay?
Elay:Like I said, maybe they need it even though you can still report off of them. They're like, no. But we need to physically see it. Okay, my friend. Right?
Elay:It's just one field, two field. Max, let's put it. Okay? It's if it's gonna solve our problem because it's not damaging anything. Okay?
Elay:But if it's a customization where it's like, okay. You truly don't need it. Like that example where I was saying where earlier, I was saying a customer was asking to bring all the questions out of the questionnaire into the form. I'm sorry. I will not be doing that.
Meesh:Mhmm. They say no with the solution.
Elay:Customize bringing all that out of there into the form. In that case, I'm not again, I keep saying I'm not, meaning the implementation team is not doing that. Okay? We will not be doing that because you don't need it.
Jada:Oh, and to me, that's that's like, what is the org impact? If a customization is only gonna help a small group versus the better good of the whole org, then it may not be something that you need. And so I really try to focus on how are we positively impacting the whole org that's in the application versus, appeasing to the needs of a small group. Like, that that, I think, weighs the odds too of is this worth doing, or is this worth putting off until later? Yeah.
Elay:And most of the time, once you put it off to later, you realize you really don't need it.
Meesh:So episode four taught us that planning is part of the implementation, and episode five reminds us that even with great planning, the real test comes when someone asks for a customization. So the question isn't always, can we build it? Sometimes it's what is this request telling us? So what's one thing, one sentence that you ladies want to leave for the listeners?
Elay:Maybe understanding the why behind everything you do before doing before any customization, understand why.
Jada:Mm-mm.
Elay:Before even the configuration because there's some complex configuration. Understand why and understand the impact.
Jada:Yeah. That's a good one. I think for me, you are a consultant, practitioner, or a customer, do not, and I emphasize, do not touch the baseline code. Yeah. It's my one sentence.
Meesh:Thank you, ladies. Thank you for a lovely chat today. The debate was brilliant.
Jada:Thank you, Mish. I really appreciate your facilitation. And, Eli, as always, I always appreciate your cohosting and giving us the consulting angle. So thank you, guys.
Elay:No. Thank you, guys. This was fun.
Jada:Yeah. Next time on Let's Talk IRM, we're getting into risk ownership and entity ownerships. What happens when nobody wants to own the risk and everybody points at the CISO? You won't wanna miss this. Until next time.
Jada: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.