Subscribe
Share
Share
Embed
Authentic, Authoritative, Unapologetic ServiceNow commentary by Cory "CJ" Wesley and Robert "The Duke" Fedoruk
CJ: We're live,
Duke: Okay.
CJ: not live currently,
just, you know, recording.
Duke: Oh, Someday we'll get this smooth.
Someday after we're past our
hundredth episode, hopefully.
Carleen: This is where we start to
hear Robert talking about, um, who,
who has access to what, and who
Duke: Oh,
Carleen: Woohoo.
Duke: 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?
. CJ: All right, Duke.
Today, we're going to talk about
managing customer expectations.
Duke: It sounds like a lot of fun.
Sounds also very handy.
CJ: 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.
Duke: 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
CJ: Oh yeah!
Oh yeah!
Who we got, dude?
Duke: We got Carleen Carter.
It's still Carter, right?
I was like, which last name do I use?
Carleen: 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.
Duke: car.
Carleen: Yeah,
CJ: Nice.
Duke: That's funny.
Carleen: work with that.
CJ: So Carleen is, , very special,
, because she is our first CMA that
we've had , , on the pod, I do believe.
Carleen: I'm the only one.
CJ: I
Carleen: Or so far, I guess I'm
Duke: Yeah, so far.
, but also, , one of the
first CMAs ever, right?
CJ: absolutely.
Carleen: Yes, I was in the pilot
cohort in 2019 with 24 other folks.
Duke: been like a CMA for longer than
some people have been in the game.
Carleen: Oh, a little bit , I guess so.
CJ: 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.
Carleen: Well, actually that
is kind of about managing
customer expectations, so in this
CJ: Oh yeah.
Carleen: 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
Duke: we know.
Yeah.
CJ: Absolutely.
Carleen: 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.
CJ: No, that's awesome.
So now that you've been a
CMA for, did I hear it right?
Five years?
Was it?
Carleen: Yeah.
2019.
CJ: 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.
Carleen: 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.
CJ: 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.
Carleen: 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
CJ: Hey.
Carleen: 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,
Duke: 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.
Carleen: 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?
Duke: Yeah fixed dates
versus variable dates right.
Carleen: hmm.
CJ: 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.
Carleen: The old can does not equal should
CJ: 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,
Carleen: 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.
CJ: Yeah.
Duke: 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
Carleen: Yeah.
Duke: and then add conditions to them.
very quickly.
yes, under these
conditions, we can do that.
CJ: 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?
Duke: Yeah.
CJ: 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,
Duke: 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.
Carleen: 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,
Duke: 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?
Carleen: yes,
Duke: does that, how does that
Carleen: 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.
Duke: Yeah.
Yeah.
Carleen: 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,
Duke: Yeah,
Carleen: customer as a partner.
Duke: 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.
Carleen: 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
Duke: Uh
CJ: Heh,
Carleen: 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.
CJ: 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?
Carleen: 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.
CJ: 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?
Carleen: Yeah,
the
CJ: sometimes,
Duke: the right ones too.
Right?
Yeah.
Carleen: 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.
CJ: Yeah.
Duke: 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,
Carleen: 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
Duke: Ah,
Carleen: 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,
CJ: Okay.
Carleen: 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,
Duke: 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.
Carleen: 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.
Duke: 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.
Carleen: 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
CJ: Yeah.
Yeah.
Carleen: 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.
Duke: Sometimes you want.
CJ: 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.
Carleen: 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.
Duke: All right, wow, uh,
just like that we are at time,
Carleen: Let's end it
on a contractual note.
Duke: if you want to reach Carleen,
we're going to have a link to her
LinkedIn, , in our description
and, , Carleen, any last words?
CJ: lot.
Duke: Thank you for joining us last
minute, Carleen, really appreciate it.
CJ: Currently.
Carleen: Thanks