Translating your vision and goals into a strategic, actionable roadmap: Part 1

SEAN DAWSON: Hello, 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.

I'm your host, Sean Dawson, client architect at Cask as well. And with me, I have Megan Harter, who is the director of enterprise program transformation. She has over 20 years of tech project management to strategic program transformation, is an ITIL expert, and been doing this for over 20 years.

So, thank you so much, Megan, for taking time out of your schedule and joining us here on the podcast today.

MEGAN HARTER: Thanks for having me, Sean. This is great.

What is a roadmap?

SEAN: So, what I thought would be a good place to start with this is, you know, “What is a roadmap?” I grabbed a list, and there are so many different roadmaps: There's technology life cycle roadmaps, there's project roadmaps, there's capability roadmaps, scenario roadmaps. What kind of roadmap are we talking about here?

MEGAN: So, today, we're gonna focus on something called a strategic roadmap or an outcomes-based approach roadmap.

We're really, we're taking a look at aligning to what maybe is going on in your organization that are gaps or, you know, strategic goals that you might have to align to either a corporate strategy or departmental goals, CIO strategy, HR strategy, anything like that, and really focusing on the end state first. 

We almost work backwards in terms of what you're looking to solve or where you're looking to get for a destination, and then figure out what points you need to get to, to really achieve those targets in a meaningful way and then put together a strategy around kind of that value realization in terms of, how will you know when you got there? What does that actually look like for your organization, and when can you expect to see some of those results?

Overlying technology on top of that is kind of a secondary piece, but really focusing on where your organization wants to be and, you know, kind of that thoughtful approach of how you want to get there to solve those problems.

SEAN: OK.

Perfect.

So, essentially, if you purely break it down, what you're focusing on is the business need and then mapping that to tech.

But turning that into a roadmap that goes over quarters, years - whatever it is, it doesn't matter - it goes over a timeline, really.

Am I getting that right?

MEGAN: Yeah, that's exactly right.

SEAN: Perfect.

Why have a strategic roadmap?

SEAN: Well, with that in mind, why is it important to have a strategic roadmap?

MEGAN: So, if you're thinking about technology only and you're only looking at, you know, what might be in front of you from a licensing perspective or specific components of any particular technology, you may miss pieces of that particular application or even other applications that might be a holistic and better fit for your organization to get where you really want to go.

You know, I've heard a couple of customers say that they have had implementation in spite of strategy, right, or in the place of spread strategy where they may have done many different pieces of work, but they didn't really get anywhere with it.

You know, they just kind of checked a box and said, “Well, we bought this, we should implement it.” But, they didn't really think about, you know, why they were implementing it or how they could optimize their business, or maybe streamline processes, or reduce processing time, or reduce swivel chairs, or any number of things that we see customers really striving to achieve from a business perspective and understanding why it matters to their organization.

You know, what the business case is for actually wanting to do those specific things in a holistic kind of overview-type approach rather than just, “Oh, well, today we're going to do, you know, incident management and next year we're gonna do HR.” Like, how do all those pieces fit together and why should you care about that?

And hopefully, you know, you're getting organizational buy-in around the importance of these different projects so that everyone understands why - not only why they're important, but how it could impact their work and their, kind of their day-to-day lives in a positive capacity rather than just being like, “Oh, this is another thing that we have to do,” right?

And sometimes that bogs people down from their day jobs, right? This really is their day job. Making their business excellent, and how can we help them get there. That’s really kind of the crux of it.

SEAN: Yeah.

And you, you kind of called out something in there that made me think.

I've always used this term “painting myself into a corner,” or I don't want you to paint yourself into a corner.

You talked about implementation without strategy.

And it really, to me, I've seen so many organizations start going down a path and it's almost too late and they figure out, gosh, we've locked ourselves in. Now they're looking at refactoring, or reimplementing, or didn't connect something.

So now they’ve got to go different routes.

That's a very good point.

Getting started with a strategic roadmap

SEAN: So for organizations that aren't familiar with it, how can they start the strategic roadmapping process, and maybe who needs to be involved with that?

MEGAN: Sure.

So, you know, the most successful strategic roadmaps, we've had some sort of high-level executive stakeholder sponsorship or at least interest in the final product. At times, we've worked with different customers who then take these things to their senior leadership as a business case to proceed.

But, it's always really good if you have an engaged senior stakeholder. It doesn't necessarily have to be a C-level, you know, executive, but someone who has some sway and I guess organizational backing, right, in terms of - your opinion matters within your organization.

If you can get backing by someone like that in your organization to work through something like this, it holds a little bit more. You get a little bit more traction.

It does take time and commitment in terms of, you know, being willing to dive into the different areas that might be a problem or where your organization is struggling and kind of be able to suss that out.

It takes honesty, right?

You have to be able to look at yourselves with an objective lens and be like, “Yeah, you know, we're really not great at that,” or, you know, “I'm hearing the same theme across our organization,” and being ok with the fact that your organization probably has some gaps and, you know, places where they could mature, and that's not necessarily a weakness or it means your organization is failing.

It just means that these are the opportunities in which you can latch onto and be able to make some growth as you're working towards this.

But, you know, kind of the critical factors here are, you know, time, and you know, resource commitment and capability to be able to execute on something like this as well as the organizational skill to kind of pull something like this together and be able to see and read into themes and understand kind of where you should go.

SEAN: Yeah, that's great.

Thanks for that.

Technical vs. strategic roadmaps

SEAN: And then, you know, I alluded to it earlier when we talk about there's different kinds of roadmaps.

But from what I'm seeing is that, you know, you can get, you know, a technical roadmap and a strategic roadmap and how do they differ and do they come together?

MEGAN: Yeah, they absolutely can come together. A technical road map really highlights the pieces of technology that will support a more strategic-type roadmap.

The best roadmaps that I've worked on, we don't even talk technology until the end, right?

We understand what problems we want to solve, what outcomes we want to achieve, and how will we know we got there?

And then we take a look at the application portfolio that a customer might have.

You know, quite often working with Cask, we are looking at the ServiceNow platform and you know, how can that solve and be kind of that underpinning technology that marries into the strategic roadmap.

But, you know, we don't go into it with our mindset that, “OK, we need ITSM and ITOM and ITM and you know, maybe a little SPM later.” We really take a look at the components of the platform and how we can execute upon that after that strategic road map is done.

But the technology piece is equally important, because if you don't have the technology, you don't have the conduit for success, right?

You have to have something that marries it all together from a technological perspective.

And there may be outside applications, you know, that need to interface in some capacity to really achieve your optimal goals.

And having that all painted out in one picture can really help you write your business case and understand kind of what the organization is going to get out of this, and often take that for buy-in or budget or something like that to be able to execute against it.

SEAN: Good, good.

Avoiding roadmap overwhelm

SEAN: So now that we're talking about, you know, a strategic technical roadmap, I imagine and, and I've personally seen this as well.

I don't need to imagine it and I've seen it - where roadmaps can get pretty big, I mean, especially when you start overlapping the technical side of it.

From your experience, how would you recommend avoiding, like, roadmap overwhelm, you know, and how to get balance and what you need out of that.

What are your thoughts on that?

MEGAN: I think you have to really understand where your organization is today and the amount of resources, whether it be financial or people resources, that you are able to kind of redirect towards a transformational effort.

Lots of people, you know that saying where your eyes are bigger than your stomach, right?

And you end up taking way more dinner than you think you can eat because it looks really good.

We see that a lot, right?

Like people dive in, “Yeah, I wanna do it all right now, this is gonna be great! We're gonna get it in by the end of the year.” And then, all of a sudden they see what that takes, and they're like, “Oh, right. That's a lot of working sessions that my three stakeholders are going to have to sit in at the same time.” You know, so really working with, that's one of the advantages of working with a partner such as Cask, is that we can help you take a look at your organization and the different pieces of work that need to go into achieving those outcomes and then put together an execution strategy that matches your organization.

You know, there are some organizations that are primed and ready to run and can take on a multi-workstream engagement and be able to allocate fulltime resources to it.

But there are many, many, many more who can't do that, right?

And where are they gonna see kind of the biggest bang and how can we make sure that every single component really reflects what they need it to at that time and that those resources are focused on the right things.

Sometimes it seems boring, you know, some of that foundational work can feel, “My gosh, why do we have to do this now?”

But when you get later and you realize that you set that really solid foundation and people understand, you know, roles and responsibilities and process and the technology components on top of that, that when you get more mature into those processes, you don't have to revisit that constantly.

And it's just kind of a new way of working.

Those are some of the things that, you know, we can really help with in terms of that execution plan and your roadmap could be six months long, it could be five years long or beyond.

Constantly reevaluating that as well and making sure that you're getting the traction you hoped to.

And if the answer is that we're not, or, you know, people are constantly being pulled away - again, kind of like the honesty thing, being able to take an objective look at yourself and understand where your deficiencies are.

And can you close them with a partner or can you close them, you know, internally but reflecting on reality and being able to work with where you are and having a partner who's willing to meet you where you are and create a plan that can get you exactly where you need to go.

SEAN: Yeah.

Managing a roadmap across workstreams

SEAN: And then when we, when I, as you were talking, I was thinking about, you know, overwhelm and I could see that happening, not only from the strategic and technical, but when we start adding workstreams because you know, the ServiceNow is a huge platform. We talked with, before on the podcast, about getting the most value out of the platform.

So you want to start those value conversations with other groups.

But from a strategic roadmap standpoint, how would you recommend managing across multiple workstreams on that?

Like, I know there's a little bit of, I keep hearing a theme of a little bit of OCM in there.

There's an organizational change management.

You gotta, I always call it, “Who, what, where and why,” so everybody knows what's going on.

But what are your thoughts on managing the strategic level across multiple workstreams in a strategic roadmap?

Any thoughts on that?

MEGAN: Yeah.

So you know, some of the things that I've seen be successful in this space are having the roadmap components not necessarily map to any one particular piece of the platform and then helping those maybe functional areas learn how their components fit the big picture from a customer perspective.

And then, kind of, the idea of a - I'm gonna call it a strategic architect for lack of a better term at the moment. Someone who really sits alongside with someone like myself and provides the layer of technical oversight and governance across the program in a technical lead capacity, right, where they understand the big picture, they're not solutioning individual components of that, but they make sure that everyone who is understands kind of how all those different pieces fit together and where those dependencies lie and oh, we're doing something in asset that's gonna impact some of the work that we're doing in ITOM, right?

Like, let's make sure that we are sequencing those things properly and that those architects or business process consultants are having conversations regularly so that they're planning out how their work goes, and understanding kind of that big picture as much as possible.

I think you can't do a multi-workstream program, you know, strategic or not, without the different components understanding how their bodies of work impact one another and kind of having these functions on the top to ensure that those conversations are happening.

So often we're only focused on, you know, the little box that I'm working on as a specialist across the platform, right?

Like, I'm just gonna do my piece of work and that's gonna be good.

But when you get into these multi-workstream programs, you're really looking at a machine and things, you know, they have to work together.

And there are components that are, you know, directly impacting one another and making sure that someone is helping to string those conversations along and paint that picture so that it's not a surprise and everybody knows what's coming.

And the customer also understands, kind of, how those pieces fit together.

So that as they operationalize these different components, they really know how their organization is architect.

Because moving on into operations, they'll have the same types of interactions between their platform components, same as we do during an implementation phase.