We're live,
Okay.
not live currently, just, you know, recording.
Oh, Someday we'll get this smooth. Someday after we're past our hundredth episode, hopefully.
This is where we start to hear Robert talking about, um, who, who has access to what, and who
Oh,
Woohoo.
no. That was, that was then we put, we put after, after we put the before, after like that scene from space balls, you're looking at now, but what about then? We missed it just now. Ah, okay. Well, we're live. And what are we talking about today?
All right, Duke. Today, we're going to talk about managing customer expectations.
It sounds like a lot of fun. Sounds also very handy.
Oh, let me tell you, I think it's something that we all need to know. and I think, you get better at it, the more experience you have in the ecosystem. But even if you have a lot of experience in the ecosystem, there can still be some instances where things don't go your way.
Oh, for sure. and since I don't want people to just take advice from me, a dummy, we brought in some hired guns for this episode, didn't
Oh yeah! Oh yeah! Who we got, dude?
We got Carleen Carter. It's still Carter, right? I was like, which last name do I use?
Well, formerly Carleen Greenlee. I made a name and now I am, Carleen Carter. That's my married name. So I always thought I did not want to change my name from Carleen Greenlee because I felt like the double E's everywhere just kind of flowed so well. But then I met my future husband and Car Car sounds pretty nice.
car.
Yeah,
Nice.
That's funny.
work with that.
So Carleen is, very special, because she is our first CMA that we've had on the pod, I do believe.
I'm the only one.
I
Or so far, I guess I'm
Yeah, so far. but also, one of the first CMAs ever, right?
absolutely.
Yes, I was in the pilot cohort in 2019 with 24 other folks.
been like a CMA for longer than some people have been in the game.
Oh, a little bit I guess so.
that sounds groundbreaking. So tell us a little bit about the pilot actually, before we get into the meat of talking about customer expectations. I think tell us a little bit about the CMA pilot. That's kind of unique.
Well, actually that is kind of about managing customer expectations, so in this
Oh yeah.
the cohort, all of the attendees, were the customers. ServiceNow was the, service deliverer, and they were just starting to figure out that they wanted to have these elite certifications that are different than just, something like a, CSA system administrator or. A CAD application developer that are, exams that you go and you take somewhere or you do with all the cameras facing you at your home. both the certified master architect and certified technical architect, our cohort based programs.
So you meet with your cohort every week and you get a presentation from one of your other cohort members or from ServiceNow and, I think CTA is 3 months long and CMA is 6 months long. And at the end of both of them, you do a present one or more presentations to a board of your peers that have already graduated from the program. and so it's, it's definitely different than, just taking a multiple choice test by which. there's nothing to snuff about there
we know. Yeah.
Absolutely.
but since I was in the pilot cohort and as you can imagine for the, top CMA that they invited several people who have been in the ecosystem for a while and probably had pretty high expectations. And they're also trying to develop the program at the same time. We were all very, very opinionated and not afraid to share our opinions in that and Julian Mills was running it at that point. And God bless him.
I think he rolled his eyes at us so many times, but it's really, really awesome to see where those two programs have, what they've evolved into. they're not that different from before, but they've, they're learning things, every new cohort and making changes along the way. So that's great.
No, that's awesome. So now that you've been a CMA for, did I hear it right? Five years? Was it?
Yeah. 2019.
Yeah. So now that you've been a CMA for about five years, tell us how that skillset helps, when you're dealing with your customers.
Yeah. So the CMA is really. Meant take a much higher level outlook on an entire project. They really are responsible for the success of. Everything from end to end, and that includes things like governance and, organizational change management. and they may lean on additional resources for some of that really deep. Technical expertise, but a lot of the also have deep technical expertise in certain domains as well. but they're really.
Responsible for making sure that all of the elements work together. and that we're doing the right thing for the customer, not just to get to that go live day, but also that the customer is still going to be happy with what they have in 3 months, 6 months. In 3 years now, there may be some additional projects in between now, and the end of 3 years, but, the customer's not doing anything. That's going to trip them up and not be able to be happy at the end of those 3 years or even beyond that.
That's a good segue for actually, getting to the meat of this episode, which is managing customer expectations. Right? And so one of the things that you just said that really took me back, right? Is that, doing the right thing for the long term health of the customer. And how that can sometimes put you At opposite ends with the customer when they're focusing, maybe something short term or focusing on a thing that might necessarily be best, practice.
And that, you know, 6 months a year down the line is just going to create a whole lot of tech debt for them that they won't be able to necessarily build their way out of.
company, we are a product company that has apps in the store. So our scope is much smaller, but. The overall outlook is the same. not only do we want to make sure that we're doing things that are best practice from a ServiceNow platform perspective, we also need to, have an eye on our own roadmap and making sure that we're not doing something that the, customer, Is not going to be happy with, when our next store app release comes out and we've got a bunch of new features.
and so I think that understanding where they're coming from, because they don't understand any of that. Anything that I just said, they understand where they're doing this today, whatever this, the scope is of, the, the project where they're doing this today and the capabilities of that thing. And I'm specifically not saying that application because sometimes it's Excel or
Hey.
paper or, some other. thing that's not, we're not like taking it from one piece of software and putting it into another piece of software. And that's really, that's what they know. That's what their context is. That's where their requirements are coming from. That's where their pain points are. And so they don't necessarily know that's something that they're asking for. could potentially hurt them in the long term.
And so you have to, to navigate that and try to help them understand, because,, a lot of times the people that you're working with that these requirements for, are not, developers. They're not. a little bit different than within ITSM, but sometimes, if you're working in HRSD or in customer support, they're not even necessarily people that work on systems and configuring systems all the time. Yeah,
of harm, like this could be harmful for you. I'm finding that the new people that I'm mentoring. need to understand that they're not even going to give you exact requirements. Right? So I'm teaching, I'm teaching classes on queries right now and, you teaching them to recognize the difference and opportunities in terms of like using, say relative. When you're making a query for dates, most of them want to put in hard code dates and I'm like, you got to use this relative operator.
but the client won't tell you that that's the way it should be built because they're not service now people a lot of the times. And so you've got to role play it in your head. Right. But long before they ask you for something that will damage them, they will ask for something that is just not expressed in a service now way. And it's, that's on you. Like you've got to bridge that gap for them. That's not a them problem.
Exactly. I won't say they're never, never say never, but at this point in the project, they are likely not speaking in ServiceNow terms. Even if they have maybe used other pieces of ServiceNow, especially as a requester side, they're still not going to likely be speaking in ServiceNow terms. When I do my like introductions at the very, very beginning of the project.
for years I've been saying, I'm in charge of ensuring that what we're delivering to you is scalable, maintainable, upgradable, all the ables. We want, we want this to be a long term success for you. And so like, I like planting those seeds very, very early. Cause that means like, they don't know it, but they, that means sometimes that I'm going to be pushing back on something that you're asking for.
Not because I don't want to do it, but because there might actually be a more efficient technical way to do it or something that is, just better for the long term success. Cause I think you're right. Robert is, they're going to say, well, I need a report that goes from, October 1st to October 31st. And you kind of have to turn around and go, okay, so are you actually asking for a report for the last month and that whatever month I'm in, which currently we're in November.
When I flip over to December, are you expecting that report to then reflect November or still stay stuck on October 1st through October 31st, 2023, for in perpetuity?
Yeah fixed dates versus variable dates right.
hmm.
ensuring the long term, health of the platform, right? And sometimes that means saving the customer for themselves, either because They have enough knowledge or because the knowledge that they have is knowledge that would get them in trouble. And I think ultimately, like when you're an architect, you look at the project from that level, right? It's like, what's going to be the sustainable and successful way for us to manage instance going into the future versus. Here's six stories.
Let me just go ahead and build them out.
The old can does not equal should
Yes. Yes, absolutely. And that's so relevant in service too. Right? Because how often can you actually say no, the platform cannot do this,
Not very often, although I do try to craft certain things like, well, the platform doesn't really support that interface right now, or, that's even a little bit like more on the no side or, the cannot side, but, that feature that you're asking for is we've heard that it's coming in the next release. And is it critical that you have that now?
Or could we wait until the next release and then you get a non custom version of it so that it's not something that you own forever um, and have to maintain forever because you don't want to add things to your plate.
Yeah.
your money kid? I mean, have you guys ever been on a project where you got like, how should we say a very enthusiastic VA and the customer will be well, we're wondering if the, if the application could do this and they're so stoked to be on service now, they're like, yeah, of course it can, yeah, yeah. But then they don't counterbalance with the, if we stop right here with what you're previously told us to do and spend a month on this. Yes, we can get that result for you.
and so I guess just going back to the theme of managing expectations is real clear with your yeses
Yeah.
and then add conditions to them. very quickly. yes, under these conditions, we can do that.
yeah, I actually know what you mean. I've been guilty of this, right? Like when I first started in the service now ecosystem, right, I was a customer and just getting used to the platform and using the platform coming from, the previous platform Which is, BMC, magic, and going out and talking to everyone else in the company about it, right? Once ServiceNow enters your enterprise, you kind of become the chief, ServiceNow evangelist, right?
Yeah.
I'm going around like group to group, right? Like in, in selling and showing people the thing and they're throwing out all these use cases. I'm like, yeah, we could do that. Of course we can do that. Yeah. Yeah. You know,
Oh, I heard this one is a feature that you think is cool, too. Like, not just them, but you think it's like, oh, yeah, we totally can do that. It would be so awesome.
Or something that you've had a recent success in. Like, you know, me right now, 15 plus years into my ServiceNow career, I'm just getting into UI Builder. And it is, like a completely different language. But every time I get one component to work, I start telling everybody about it. Because I'm so excited that I was able to achieve a little bit of success.
And then of course, building a new interface, a new workspace or portal evens, because you can do that in UIB, is not a small amount of effort. And you really have to approach it. With more vigor than just, right click, personalize, or not even personalize, configure form layout. Personalize was what it was like back in 2009. Right, right click, configure form layout or form design, and then you're like, oh, I need a new field.
Let me just throw it on there, and then it, boop, it's already on your form. And doing things like that in UI Builder take a little bit more A not just a little bit, some definitely more effort to achieve than just right click configure. Mm hmm,
was kind of wondering if we could maybe talk about, like, how do expectations get out of whack? there's at the start when it's like, okay, I'm not a service now person. So I'm clearly not going to explain this to you in a service now way and therefore get into my head and role play. Me, but even the best of us have been on, which would be YouTube.
Uh, even the best of us have been on projects where it's like, everything's going well, we have a clear understanding that we're doing X, Y, and Z. And then you show up to the meeting to show it off. And I was like, where's ABC?
yes,
does that, how does that
really, really important to document the decisions that are made, especially when there's a fork in the road. or you're trying to guide them towards a best practice towards whatever. and certainly the level of. Documentation of those decisions, that the more detail that you have around them, the more they will help you in case you have to refer back to them. but also there's resource requirements to be able to make sure that you're documenting all of those things and staying on your. timeline.
we have Projects with our customers that start out with a statement of work. And, it doesn't really matter. I think sometimes customers misunderstand, like it's not that anybody's trying to, sell you one thing and then, switch bait you to another thing, but there's only so much information that can be shared during a sales cycle.
And. Immediately, the people that are on the project and the that is on the vendor side and the customer side, are now like, they're going to kick off their project and then they're going to start workshops or meetings or whatever to review, what the customer has today or their requirements. There is going to be infinitely more information. shared during those sessions and to the people who actually are going to be responsible for shaping how the whole project goes.
Yeah. Yeah.
details of what you thought you were going to do in the statement of work, which is why it's really, really important to think of your vendor as a partner,
Yeah,
customer as a partner.
like, when I write scopes, I tell people right up front that scopes are, like, hardness is brittleness. Right? So we can make the parameters of this very hard, but what we have inside has to be very well known. If there's any of these things in here that we just kind of think we know. Thank you. Or we haven't done before, we have to flag those as risks to, to the scope right out the gate. It's like, we are going to build a feature that does X, Y, Z. Have we even done that before? No, we haven't.
Well, therefore it's risky. and I only did this once, so I don't want to make it sound like I do this thing and I'm like, but my dad did love it is that I annotated in the scopes, the components of the scope that were most at risk. So I had like training. It's like, I think training is going to take us two weeks, but we could end up going deeper on stuff. Could be the people just don't get it. so, this has caused to possibly inflate.
And then it was just, they knew the magnitude of cost on the scope, but they also knew where it was most likely to expand.
Yeah, I think that kind of goes back to what you were talking about. the person who's really, really excited about the new feature or the customer who's like, I just saw ServiceNow webinar and they said that we can do all these things and can we do all of these things you, kind of have to come back and say, yes, ServiceNow can do all of those things. yes, we could. Add all of those things to our project. in order to stick with the timeline that we projected, we did not have.
maybe two or three of those things that they're talking about in our plan, and we could include them, but it would require some horse trading, of, okay, well, we're either going to maybe push out the timeline because we decided that these new features are really critical to the success and adoption of our go live, or maybe we plan to do 10 catalog items and these 2 features are going to be equivalent to the level of effort to build for those.
So we're gonna go live with a set of six in these new features, but then there's four catalog items that are not gonna be built as part of this project. And we, we can put them in as, a fast follower, SOW to release quickly after go live, or, we'll put them in phase two. If you already have a phase two planned, there's always things that can be.
traded in and out and things that can adjust, but where you get into trouble, and I think this is the overall theme is when the expectations are that you said, yes, ServiceNow could do that. And all of the sudden now, those things are immediately included and nothing else changes. And so it's really, really important to address those early on. very important person to me told me at one point that bad news does not get better with age. It's like stinky cheese
Uh
Heh,
here and stinkier, and it's not going to get easier to deliver bad news. It's only going to get worse because likely that news is going to get stinkier and stinkier. So if you are honest and. you have a good partnership with your customer, or your customer has a good partnership with the vendor and, then having those conversations, even if they are not good news, becomes easier. It's not that 1 side or another is all of a sudden trying to tank the project.
It's that what do we need to agree on here in order to be successful? Yeah.
Yeah, I like that. What, what do we need to agree on here in order to be successful? Uh, one of the things that I try to agree on with my clients before we start the project is that scope creep kills projects. Right. Um, We don't want to add anything additional to this project. before we can release the things that you actually want. And like you said, if it's a heart necessity, then we do have to do that horse trading.
Well, I dropped this out and we're going to add this, but then I also let them know that, Hey, then there's a little bit of buffer here too, that needs to go in. Because now you're asking for a different project than we prepared for, right?
Yeah, and that's a really good, point to pause, as You know, I mean, you guys essentially serve as your own PMs, your own project managers. I fortunately do not have to do that job. Not one of my fortes. Um, and I do love my engagement managers to death. but that's a really important moment to pause and review the original scope of work.
And if the, now the new plan is materially, materially changing from that point, even if you plan to do nothing about the overall price of the project, that's when I kind of like, raise up my hand to my engagement manager and my management of like, hey, we need to try to get a 0 change order here, which maybe is part of the project manager mind in, in my head, And 0 dollar change order for those who may not understand that means you're amending the contract and it is a new, basically a new legal
binding contract with the changes that you have and the 0 dollar part means that the overall cost.
Yeah, and that 0 change request, right? Just really resets everyone's mentality around the project, right? so everyone is, we went into this thing started like three, three months. going to deliver X, and three months in, we're changing, right? We're changing X minus Q plus V. Right? and everyone needs to really sit down and recontextualize the project from that perspective, right? This might have been previously integration heavy project. Now it's a lot more process heavy, right?
Because we changed some things. So we got one of the things too, that you have to make sure in that situation is that you still got The resources assigned to the project, right?
Yeah, the
sometimes,
the right ones too. Right? Yeah.
resources that build catalog items may not be the same resources that are doing that flashy new gen AI integration. That the customer is so excited about.
Yeah.
the 1 thing I want people to understand about this is that it's not like a service now project is not 1 person sitting with 1 person. Like, it's not me with the customer frequently. There's like, teams of people involved and all kinds of possible interpretations of stuff. And so by putting all of this in. a document, whether or not there's more money involved, that's somebody else's decision, frankly. But we all have to come to a new understanding about how this is going to go,
yeah, 0 change order, but certainly change orders can actually represent a change in the overall cost. and I think it's also important to say, so I'm just kind of sticking on because you guys are. more independent, and it's easier to refer to you. The change is not because Corey or Robert lied to you in the 1st place. It's because everybody, all of us, the entire team have learned a lot. I learned a lot and we've made decisions based on that learning. And goodness.
Isn't that life like I'm not, to put a, poke at myself here, there were probably so many things that I said before I had kids, and I'm not gonna let my kid look at an iPad in
Ah,
I'm not gonna do this. I'm not gonna do that. Well. I've got two little girls and sometimes I need them to just look at the iPad in the restaurant and so I learned a lot that, after actually having the kids, that now the shape of my decisions and the things that I was vehement about earlier are different. And it's kind of the same thing when you get into a project that.
Again, there's only so much information that can be shared and agreed upon and reviewed during a sales cycle and that you're going to learn a bunch during the project. Um,
Okay.
and because the customer, especially during the sales cycle, they're telling you what they know, again, from their context, they're going to learn a whole bunch about what ServiceNow can do. Oh, I didn't realize, even something as simple as it could send out a notification when the state of this. Task changes, what like, those are the kinds of things that my customers are, you know, are, are realizing and, they had no idea.
and so that's a really small thing, in theory, creating a new notification is, is really, really small. But if those are the kinds of things that they're discovering, There's going to be revelations all over the place and,
got a customer I'm helping do resource management right now. And it's at the start. It was they swore up and down. It's only capacity. We're only doing this for capacity, right? Until their boss found out, like, whoa, we can do cost modeling with this. Like, no, let's just ask them if they can just throw that in.
I'm like, okay, well, listen, You can't go from just resource capacity modeling to capacity and cost modeling with the understanding that we're working on this like five hours a week, right? we've got to fundamentally change the nature of this thing.
and ultimately those decisions and those changes are for the success of that customer because. That is a pain point clearly for that manager, is the cost modeling. He's not able to answer. Well, I assume that he was a he, but he's not able to answer questions to his management that maybe his management is asking that feature would help him manage or would help him answer.
That's one trick I have up my sleeve. If I feel like it's getting hostile, but uncomfortable is always reframe the conversation so that it's not. you versus me. When there's contention, it's you versus you. It's customer versus customer. It's not customer versus consultant.
Yeah. and it's also, it could be a good time to bring in the, Iron Triangle because I think people can have something fast and cheap, but not good. You can have something
Yeah. Yeah.
good and cheap, but not fast. you know, the three things there. And I think when you, hopefully. You know, when you start bringing some of those things into the conversation that the customer realizes, yeah, okay. the people that I'm working with are human too. And if my management asked for me to come up with something good, cheap, and fast at the same time, I would say, whoa, whoa, whoa, let's make, let's be reasonable. We got to pick two.
Sometimes you want.
the only thing that matters to them. Right. And figuring out how to use the product to deliver that inside of their context, is the thing that, there makes or breaks whether or not the implementation lives up to their expectations and, um, I just think sometimes it's just hard if there's an inability to get both to everyone get in the same dictionary when we're talking about, you know, communication, right? Like, when I'm trying to tell them, this is what we're going to do.
And they're telling me again, back in their words, maybe coming from Excel spreadsheet or something that's just Now, right. And they're trying to tell me how this works. And I'm trying to tell them how service now works. And sometimes we can end up talking past each other, right? Because they're talking to me about their business need, and I'm talking to them about their technology. So I think it's sometimes important too, to make sure we're all talking in the same context at the same time.
It's a long way to get to that point. Um, but I just think it's important, right. To make sure that we're all having the same conversation. And, and so we can all get to the solution together.
So at the very, very beginning of the project, a lot of times. There will be documented business goals and objectives. And what are we trying to do with this project? forget about the technology that we're doing it with. what are we trying to do with this project? Are we trying to bring more visibility to our leadership of our overall operations? Are we trying to make something that is better for end users, uh, requesters than a PDF form that they have to fill out?
we can go back to that, which sometimes these things. are in the statement of work, right? You can go back to that, usually less than five bullet point list, and say, okay, is this something that is going to make a significant difference in, achieving our project objectives? And sometimes the answer is yes, and sometimes the answer is, well, maybe not, but we'd really like to have it. And then we say, okay, well, that's, that's, it's an okay answer to say that.
But if we focus on what your original objectives are, then maybe if it's not helping us meet one of those, why don't we push that into a phase 2 rather than horse trading for something we already, had. I think also ServiceNow has, it's changed names over time. It was called Innovate at Scale.
it was called customization best practices and I think now it's called business smart customization or something like that, but they, in their customer success center, they have a whole page dedicated to, business smart customization and there's like an executive deck. There's a, white paper. there's a 7 minute video that is totally watchable.
It's 7 minutes, but you can also watch it on 1. 5 X or 2 X. And, and it walks through how to set up the groundwork for your governance of when a requirement comes out that is either going to, of throw off maybe the project timeline or the resources that you have, or the scope that you have and also all the way down to, I've got are now a requirement. That's a pretty big high level of customization.
That's going to cause us a lot of tech debt and we measure it against this matrix of is this new requirement that's come up or any doesn't have to be new. Is it, is it required because of some sort of law? or, you know, regulatory body and well, if that's the case, then there might not be much that we can do about achieving that. but in, in a lot of cases, those don't work. Those are not very specific about the technical solution.
So you might be able to creatively figure it out without doing the tech debt, all the way down to, a level 1 or 0 that's like, this doesn't help any objective. It's just something that somebody brought up as. As something that they, you know, they saw something, they saw a feature that they wanted, but it's not helping our overall goals. it's going to require a lot of customization, but it's not actually, helping us in any way.
and that way you can, it makes it way less subjective and it makes it seem a lot, less like Carleen, the architect is really, peeing in my materials today. She doesn't want me to have anything. and it also helps. the customer to realize their context, I think, because, I used to work for a desktop outsourcing company. and. A lot of people would refer, well, the contract says this and the contract says that as a consultant.
I have now learned to say, can you show me the specific contract language because it through the game of telephone and interpretation and all of these kinds of things, it might not be as you say. So we want to make sure that we are actually following the contract because a lot of people will throw that around as well. I want this requirement because the contract says this, is that what the actual contract says? Yes. let's make sure that we read it and understand it and follow that to the T.
All right, wow, uh, just like that we are at time,
Let's end it on a contractual note.
if you want to reach Carleen, we're going to have a link to her LinkedIn, in our description and, Carleen, any last words?
lot.
Thank you for joining us last minute, Carleen, really appreciate it.
Currently.
Thanks