Hello once again, and welcome 
to the Cask Distillery Podcast,   where we unlock the full potential of ServiceNow 
with expert insights and practical strategies,   only here on the Cask Distillery Podcast. 
With me today is Felix Ortiz, who is our   principal program manager and director 
of operational program transformation. I have that right. Right, Felix? Yep. Operational program is the easiest way 
to say it: director of operational programs. Awesome. And we don’t normally do this,   but I would love for you to give a little 
quick intro of yourself and background. Sure. So, I’ve been around the ServiceNow 
ecosystem for well over 17 years. I started   off as an early adopter, as a director for a 
biopharma where we implemented it at house.   ServiceNow didn’t even have letters to 
their names when I started with that   product. Switched over to consulting; did 
that for several years—solution architects   from master presale support-type stuff. 
Switched over to sales for three years. So you could see I’ve hopped around a 
lot in my career, all revolving around   ServiceNow. And then for the last six, 
roughly, I’ve been in shared services,   managed services, operational services in 
one manner or another in a director role. Yeah. Yeah. I jumped around as well. 
I was in actually doing work and then   in sales and marketing. I jumped 
around. So I can totally appreciate   your background. But thanks for 
jumping on and taking the time. And we want to talk about operational services 
today and dig into that a little bit. So, what do   most platform owners struggle with in relation 
to managing the actual platform in your eyes? The irony of ironies is that when 
people or organizations establish a   decision or make a decision to implement 
ServiceNow, they tend to neglect that,   once ServiceNow is done, that 
they have a lot of work to do. That’s just the beginning of the journey. 
So many organizations get to that point   in their journey and say, “Well, what am 
I going to do to support it? And how am   I going to support that?” And it encompasses 
everything, right? It revolves around taking   the demand from their customer base. 
It’s stabilizing the environment. They   get demands from ServiceNow themselves in 
terms of upgrades and patches. And not to   mention the churn of the in and out of just 
needing to do reports forms and otherwise. That tends to be—as simple as that 
seems—it’s a task in and of itself,   and it just grows exponentially once 
you implement the solution. And most   organizations don’t stay with just one portion 
of ServiceNow. You don’t do that. So as they   grow with ServiceNow, all of a sudden, they 
realize that they have a lot to take care   of from an operational perspective. They 
just underestimate that too many times. Where do you see the talent shortage 
creating issues for clients right now? Around a lot of the specialized areas—CSM, 
HR, security operations—ITSM has become a   common name for most organizations. And 
that’s where a lot of the strengths are   from a talent-pool perspective. But even that 
has become difficult. Because as ServiceNow   evolved and things have become more complex, a 
lot of the specializations around integrations,   self-service capabilities, the thought 
leadership around how to leverage ServiceNow   from an automation perspective, it’s that type 
of talent that’s really difficult to find. Yep. And then when you think about it,   you’re either bringing people in, or you’re 
trying to bring talent in. Do you see any   issues with the traditional outsourcing 
options where they’re falling short at all? Yeah. The most common one is staff aug. 
When you think of that scenario and you   think of how dynamic ServiceNow is, 
the simplest way to say it is that   you bring someone in for one problem, 
but then as you evolve in ServiceNow,   that person becomes not able to provide 
you the value you’re expecting right away,   or it results in you having to switch people, 
which in and of itself is a challenge. So,   from a consulting perspective, that used to 
work when you weren’t dealing with something   as dynamic or as evolutionary as ServiceNow 
is in the way that they mature their platform. Yeah, that’s the biggest problem in my opinion. Yep. And then, because we’re talking about 
staffing and kind of keeping the platform   going and getting help, it’s often that we 
want to—we usually recommend that people   have a 90-day-deep backlog. But why is it 
important to have a 90-day-deep backlog? So, the 90-day lens, as I like to refer to it, 
is really one of those scenarios that really help   organizations set a target for what they want 
to try to accomplish in those windows. A lot of   talk revolves around road-mapping and strategic 
planning that goes two, three, and five years. Well, things change way too much and way too rapid 
in that world of things to try to evolve a journey   around ServiceNow that’s that far along. Now, 
you can do it at a very macro level, sure. But   the reality is that the most important thing is 
taking it into a reasonable, digestible chunk,   like 90 days. Trying to set a target for having a 
groomed backlog of 90 days of work. So that means   requirements that are really vetted and ready to 
be consumed by the customers, and establishing   that over a 90-day window. That provides a lot 
of value for an organization in terms of being   able to do planning and organizing what type 
of talent they need and when they need it. It also helps align the business who, usually, 
we end up having them join us when they have   their “day jobs” too, right? So this helps 
in planning and organizing that as well. You know, on the converse side of 
that, and an organization like ours,   this helps us help them because when they have 
talent that they don’t have the specialized   skills for, or they have a need that just happens 
to be outside of their wheelhouse, we can work   with them proactively as opposed to reactively in 
staffing and supporting them against that lens. Yeah. That really strikes a chord with 
me, when you think about what kind of   talent and where to use. Because there’s 
a lot of times—I’m sure you’ve had these   conversations—where they know they need 
help, but they don’t know who to bring in.   They were able to help answer that, but 
it’s great for them to have that 90-day   lens and know where and what to do and who 
to bring in. It’s a great way to do that. So how can somebody proactively 
manage the demand incoming? So, there’s a lot of ways to do it. One of my 
backgrounds is in Agile. I’m a Disciplined Agile   senior scrum master. And through that expertise, 
it allows me to be able to adapt Agile to align   to a customer’s needs. What that translates to 
is that there’s a multitude of ways to actually   gather the demand. And the way you manage that 
demand is ultimately the way you manage the   growth of your backlog. Because that’s really 
where the rubber meets the road in terms of   the 90-day lens. I think a lot of organizations 
know how to take a requirement that’s defined   and get it through to production. And there’s 
a multitude of ways of doing that as well. But the biggest exercise has to do with 
bringing the right type of consulting and   conversations to the table around what type 
of demand there is, how to prioritize it,   whether it’s something you should do or not—just 
because you can do something in ServiceNow doesn’t   mean you should—and then ultimately get 
that into a backlog that’s 90-days deep. The irony of all ironies is that in one 
specific requirement and one linear flow,   that’s really easy to do. The challenge is 
that when you accumulate them over the 90-day   window of planning, it becomes a really serious 
problem of prioritization and organizing, and it   also becomes a problem of taking new demand that 
comes in and trying to feed it into that window. Trying to keep that 90 days as 90ish as 
possible, if that makes sense, is the challenge. All right. You had mentioned something 
you should or should not do within the   platform. And that leads me to start 
thinking about platform governance   and setting priorities. But how would 
you establish that in your platform? So, ironically enough, it has nothing to do 
with the platform and everything to do with   the way you manage people. Because when you think 
of governance and you think of the requirements,   the demands can come from anywhere. 
But having the right structure,   having the right leadership over the right 
areas—so, give the example of incident,   problem, and change manager, going 
back to old-school ITIL nomenclature,   and of the process owners—having them know what 
the processes need to be and what they want those   processes to be within an organization and then 
acting as that filter to say, “My customer wants   X. That doesn’t meet my needs. So say no.” For 
some reason, saying no is a problem sometimes too. So you need to go through the funneling process 
of taking all that demand, vetting it through the   right process, through process, governance, 
and reviews. And then ultimately you get   into the scenario where you have all of these 
requirements, all from competing areas of the   business, and needing to come to consensus as 
to which one takes precedence over the other. And you had mentioned something earlier, but I 
wanted to ask for the audience so they understand,   is what is Disciplined Agile, and how 
does it support continuous improvement? So, Disciplined Agile is an Agile methodology that 
was established by the PMI (Project Management   Institute), which basically takes all of the 
best of all the different types of Agile—so,   Kanban, Agile Scrum, SAFe—and puts it into 
essentially one magic bag of tricks. (And I   don’t want to hear any Felix the Cat jokes.) 
But the key there is that it allows you to   kind of understand the best tools that 
are available from an Agile perspective   and leverage them for the various 
types of work efforts that you do. So Disciplined Agile has a structure around 
projects. Disciplined Agile has a recommendation   around operational programs. And they have about 
seven or eight frameworks that all use Disciplined   Agile tools as a basis to start from. When you 
join an organization, start a project of any type,   start an operational program of any type, one of 
the first things you do is align the Disciplined   Agile framework to what the business needs 
are. Get something in terms of consensus as   to what you want to do and how you want 
to do it and you run with it from there. Awesome. So to kind of wrap 
this up, I always like to ask,   is there one thing that we didn’t 
cover that you’d like to share for   those that are looking for operational 
services or want to know more about it? So, I think the most important thing to realize is 
that there’s a couple of ways to really support a   customer. And Cask is very much about meeting you 
where you are. So, you know, whether you need an   organization that really manages the entire 
demand to delivery lifecycle and deals with   things from a level-one, level-two, level-three 
perspective and VAU enhancement plus governance,   or if you just need to supplement a team with 
firepower that supports an existing team,   whether it be a pod or individuals, 
we can do that. But ultimately,   everything that we do within our services 
revolves around the Disciplined Agile   framework and aligning that to your business 
needs to then deliver on operational services. Awesome. Well, thanks again, Felix, for the 
time—I know how busy you are—and taking out   time for the listeners. And speaking of listeners,   I do want to ask you to like and subscribe 
and please provide us any suggestions—anything   that you want to see. And we’ll see you 
again on the next Cask Distillery Podcast. Take care. Bye bye.