[Music] hi everyone welcome to glidefast on air i'm lauren jankowski the marketing manager here at glidefest and i'll be moderating today's webinar where's my roi learning from digital transformation failure i'm excited to introduce to you your presenter for today travis tolson a senior architect here at glidefast consulting before we get started i'd like to give you some background information on glidefast glidefast consulting is a consulting firm that is dedicated exclusively to servicenow and as an elite servicenow partner our expert team of developers and architects have worked on both sides of the table on the customer side and the consulting side our company was founded by servicenow architects and we're proud to have a team of over 100 experienced consultants an average csat score of a 9.7 and more accolades as you can see here we'll be monitoring the q a throughout today's session so please send in any questions as they arise and we'll do our best to answer them for you as another perk of attending today's webinar we'll be giving away a 50 visa gift card to someone at the very end of the session so make sure you stay on for it now i'd like to hand things over to travis tolson good afternoon i'm travis tilson i'm a senior architect with glidefast consulting and i've been working on the servicenow platform for a little over uh nine years now and a uh fun fact about me is that i'm a big tampa bay buccaneers fan and oddly enough it's actually on that point that i'd like to begin the conversation you see unfortunately for bucks fans our team is perennially not very good it's uh definitely a rooting for the underdog sort of thing personally i first took an interest in the tony dungy era of the late 90s and i was sold on the team by the time ruden took them to the super bowl in 2002 but if you know anything about the bucks you know that the dungey gruden era is about the only successful time in their history and even during that time frame they only managed to win slightly more than 50 percent of their games in fact in their entire history they've only won 39 of their games which is the absolute worst in the nfl now if you look under the buccaneers wiki page you're going to find that they have oops you're going to find that there's an entire subsection under facts and records titled losing streaks really really not setting up for a great picture here now the worst time in the butt's history was during their first season or from their first season in 1976 until about 1996 and that era's dubbed the creamsicle era so not only did the team master an all-time low of 31 win but they also wore the titular creamsicle uniform an abomination of style whose tragedy was only matched by their first season record of zero in 14 and in fact it is during that 1976 winless season that when the head coach was asked about his team's execution he responded i'm in favor of it and his fans we get that but the rest you might be wondering what does any of this have to do with digital transformation the answer to that is uh sadly quite simple in fact as perennially awful as the tampa bay buccaneers may be team digital transformation wins even less according to forbes as many as 84 of companies fail at digital transformation and worse 73 fail to provide any business value whatsoever according to everest group and now it's difficult for me to say for sure whether these trends hold true within the servicenow industry but i can tell you that as incredible as the platform is technology is not a silver bullet for digital transformation anecdotally many of the customers that i've worked with over the years were rescue and restoration projects uh either from poor implementation poor adoption or failure to achieve desired results um between that number and frankly the number of folks who are interested in hearing about this topic today i can pretty confidently say that the industry surrounding our platform is at the very least not immune to digital transformation failure and that begs the question what are we doing wrong and more importantly what could we be doing better to make our roi look a little more like the 2002 buccaneers and less like well most of our illustrious history and to help answer those questions i want to tell the story of three different projects where a significant roi killing mistake was made and share with you some of the lessons i learned from them these organizational stories are every bit as real as the tampa bay buccaneers uh but i have fictionalized a few things in order to protect identities uh and so forth so with that let's move on to our first story so earlier this year i got a phone call from preston a uh recruiter who was head hunting for a very special set of skills now preston had a cio friend mr mcintosh who was looking to fundamentally transform his equipment rental company using servicenow but he needed an architect who was equally strong as a developer architect process design organizational change management and uh nothing too particularly unusual at that point but it's at that point that he tells me that this is a blank check name your price sort of opportunity you have my attention what exactly is mr mcintosh's objective at this point preston responds well he's looking to reduce loss revenue by about 1.8 million per year by better matching underutilized assets to underserved locations and my mind pretty much exploded on that moment and you might be wondering where's the mistake how could this possibly be failure it seems like such a great start well this one's a bit of a uh trick story because the failure is not the story itself but the uniqueness of it you see in nine years on this platform serving at least 100 different customers over countless more projects this is the first and only time i've had a conversation that began with a specific metric based definition of the roi a customer sought to achieve instead most projects begin with the definition of success measured in the phrase on time and on budget if we spent less money and less time than we planned to then the project was a success occasionally we'll call out some qualitative high-level objectives like implement incident management best practices and a caveat to minimize required maintenance but this is a far cry from the highly specific tied to the bottom line 1.8 million with an explicit strategy for accomplishment that preston's cio friend established now intuitively we know the solution to this every professional development course on project management tells us the solution define your success quantitatively but clearly this is easier said than done unfortunately i've got a template here that you can follow to make it easier to write goals objectives and success criteria that tie up to roi you may be familiar with smart goals and this follows in a similar pattern but is designed to coach you in writing those objectives and the template is for what by how so let's break that down so for what by how is an approach that i personally use to better structure and devise smart goals and similar objective statements it's a step-by-step process that can help guide your thinking and simplify the complexity of writing these types of statements it helps get rid of the blank canvas feeling that can be overwhelming for some and in the process each of the words for what by and how represent some part of the overall goal statement so in the first step we want to identify who this project is for in other words who is the project designed to serve now oftentimes we try to focus on the what uh or is common in a a lot of the advice given today the why understanding the why but for me who is the why it may be a team of people or a specific individual it may be multiple different people whose individual goals are in conflict honestly maybe we like them maybe we don't but all the work that we do is done in service to somebody who are they so for example in the previous story it's implied that the cio is likely serving the shareholders hence the direct focus on revenue but we can also easily see where this project may have also served the managers of the underserved locations and even those with unused assets we can likely identify a number of stakeholders who have some need and as we'll see in a moment the end of our goal statement can easily lead us to additional goals in the second part we want to transition our focus from who to what and by that i mean what does what do the stakeholders we identified need or want in what way are we serving them an easy to use structure for this part is to try to define what in two words so the first word is usually going to be something like increase or reduce and the second word the second word or phrase is going to be some measurable quality that we're trying to increase or reduce so in our story the cio was seeking to reduce lost revenue and this clearly identifies what metric we're trying to influence in essence it's our lagging indicator now there are additional possibilities other than just increasing or reducing a value as a goal you can seek to maintain for example uh but increase and reduce are the most common outcomes that we seek if your situation dictates remember that this whole thing is just a template to help you you can make changes to it as you need the important part at this point is to identify what measurable qualities you're trying to influence and this feeds quite naturally into the third step which is to identify the by statement now that we've identified what we seek to change by how much and by when is the next big question this step is all about quantifying our values this is the part that makes our goals measurable which also implies that we must have been measuring something before and some research may be needed can you pull metrics from your existing system can you estimate or approximate and if you aren't sure ask you can ask your teammates and co-workers you can seek out your organization's reporting and analytics teams if you have one you can seek out your boss or the executive teams to see what numbers they look at you can also ask your partner like glidefast shameless plug who if nothing else may be able to obtain some industry benchmarks to help concrete numbers and concrete timelines are an important part of establishing success criteria as we don't know what we don't measure and the last step is how as in how are we going to achieve this and typically this is going to be done via some action or upstream process that feeds into our objective in other words it's a leading behavior which if measured would give us a leading indicator but wait isn't a leading indicator just another measurable goal absolutely and if you remember i mentioned a moment ago that structuring a goal statement in this way can lead to more goals how statement is the way that we achieve this iterative objective design how ultimately describes a process that we can additionally measure which implies more stakeholders and more measurable qualities and you may be wondering how far should we take this well the answer to that is you should take it as far as make sense for your ability to manage the collection monitoring and responsiveness to the metrics you identify more simply stated measure only what you have to in order to succeed so now let's step back and put all this together so we can see the whole picture so on this slide you can see three different objective statements that are defining success for the project mentioned in our story and let's step through these real quick to highlight before what by how so first we have the for clause identifying who the objective is designed to serve next we have the what clause showing what measurable quality we're trying to influence then the by clause indicating by how much and by when but travis one of your by clauses is actually a two clause yes good catch as i said this this is a template and it's designed to be modified it's really more of a guideline and then lastly we've got the how clause identifying the upstream processes you can also see how i've expanded the original statement by the cio to include two upstream goal statements giving us a direct line from non-monetary operational goals up to the direct roi driving monetary goals keep in mind not all metrics and kpis will or have to tie to directly to rli for some the term roi is used interchangeably with successful outcome and not all successful outcomes drive positive bottom line the important part is that we identify what success is and how we will measure it what does roi mean to this project and personally what i love about the for what buy how technique is the way it helps identify leading and lagging indicators in a fairly plain natural language regardless of whether the objective is purely monetary or not we don't have to be data analytics or kpi experts to get started yet we can still achieve the desired result a clear measurable definition of success so now i want to jump over to a different customer that i've worked with we'll call them gringotts now gringotts is quite possibly the most mature organization i've worked with in terms of their team structure around servicenow implementation i mean these guys had processes for their processes for their processes when a development team wanted to promote changes the team had to prepare a migration plan that was then submitted to a separate team who would actually execute the migration developers simply weren't given access to make changes in intestine production systems so there was no worry about uh whether or not they were authorized it had to be a separate team and each process area had separate development teams that coordinated when when necessary across boundaries i mean there must have been dozens of teams in this organization all working on service now i mean there was so much activity so much platform development and flight it really was a sight to behold but then seemingly overnight everything came to a halt gringotts wasn't quite getting the return that they expected on the platform and some of the technical analysts believed they found the cause duplicate cmdb data now i can't say for sure whether this was or wasn't the true cause of the failure to achieve roi uh ultimately you know that was that was a separate level but what i can say is that many decisions led up to the moment that every application was directed to make data model changes and some of these applications wouldn't see the light of day for another year as changes were made let me rephrase that another way for some of these applications one year of return was transformed into one year of investment and it's that that highlights our next mistake the mistake i witnessed at gringotts was a mistake i've seen quite often which is a failure to launch digital transformation can't provide any roi if we keep the transformation locked in a vault despite this truth scope creep is alive and well we have a bit of an addiction to adding more and more and more until the project stalls under its own weight the solution is to emphasize achievement velocity over perfection after all compound interest is the eighth wonder of the world and so the earliest returns can often yield the most in the long run and this applies just as much to digital transformation in the servicenow platform but once again despite the prevalence of digital transformation failure we know this solution we use agile processes of course we all use agile processes we've all got a 99 agility in madden 21. so why are we collectively still falling short well mostly it's because we over indulge perfection technical folks often want things done and done right perfection isn't just a pursuit it's a passion but as the aphorism goes perfect is the enemy of good we have to equip ourselves to guard against scope creep so that we can win early and win often we have to learn to identify what i call stop phrases stop phrases are a magical set of words that kill projects by opening the door to scope creep in other words these are phrases that stop projects dead in their tracks and if we can learn to identify these types of phrases then we've got a shot at getting our perfection obsession under control and to that end i want to cover a few categories of stop phrases that i've personally identified so that you yourself can try to identify them when they come up in your projects so the first group of stop words is the uh to put it as gently as possible users are stupid or evil category during workshops and requirements gathering you might hear someone say something to the effect of we need to make this easy for our users or we need to dumb this down these stop phrases are based on the assumption that our users will screw things up given the opportunity and the proposed solution more often than not is a lot of rules and restrictions most often the concern is that the user will fill out a form improperly which results in bad routing or bad analytics now yes we do want to pursue good user experience and i don't want us to challenge that concept what i want us to challenge is our assumption that more is the answer more fields more choices more rules more restrictions the inevitable result of this is more development time less achievement and ultimately a failure to solve the need for simplicity in the first place let's see i can select the hardware category but only if it's the third tuesday after a blood moon when the tier 2 assignment group is selected you see this all introduces more complexity to the users that we assumed couldn't handle the system in the first place but travis if we open it up then it's just garbage in garbage out we can't get accurate metrics with that and you're absolutely right but this brings me to our next category of stop phrases which i call analysis paralysis stop phrases these phrases come up when people start talking about metrics we need to add a field so that we can track the networking team category we have to be careful about treating all metrics as equal if we've clearly defined our success criteria then we should limit the metrics we are collecting to those success criteria measure only what you can manage and collect only what you measure the alternative is that we turn our tier one teams into nothing more than metrics collection agents instead of first call resolution agents now does this mean that we must abandon categorizing altogether no not at all but keep it simple and remember you can always evolve later adding later is always easier than taking away so start simple and iterate quickly there's always another tomorrow speaking of tomorrow our next category of stop phrases are spoken by our tony stark futurists now personally i love these guys ha i'm guilty of these top phrases all the time but as willem gintariva said i'm not tony stark and we have to be careful because these phrases can sound promising but often the only thing that they promise is more investment so when you hear wouldn't it be great if or hey maybe we could stop and ask yourself if what you're discussing belongs in the parking lot rather than what we should be doing right now and the last category of stop phrases are potentially the most dangerous and frankly it's the one that gringotts was most susceptible to and that's the ones that i call the king's seal as mel brooks once said it's good to be the king a king's seal stop phrase is marked by a personal preference and the authority to mandate that preference the reason it's the most dangerous is that project team members are more reluctant to challenge these thought phrases than any other type because the person speaking it has power often the only person able to challenge this stop phrase is the person speaking but fortunately there is one tactic i've seen that works really really well and that tactic is a third party meeting facilitator third party meeting facilitators generally exist outside the normal power hierarchy and their purpose in life is to challenge the project team and eliminate anything that distracts from from the success of the meetings and ultimately the project my favorite facilitators are disarming funny and many of them throw plushies and foam toys at people which if nothing else helps keep the meetings interesting because at the end of the day if you have a king in the room you need to bring a gesture now whenever we hear a stop phrase we need to be challenging it so how can we easily identify if we are just indulging perfection or if we're dealing with a genuine requirement challenging perfection is as simple as asking a few questions about your proposed requirement does this fill a legal requirement does this fill a policy fulfill a policy requirement will we fail to achieve our des are defined objectives without this note that that requires having to find the objectives in the first place and is there a simpler way to achieve the same result and i want to highlight none of these questions are aligned in any way to do we currently do this nor are they aligned to do we like this while you can feel free to add additional questions i'd encourage you to maintain the spirit of these original questions because what they're tied to is success not preference or tradition a power saw doesn't care how you used to cut wood or how you prefer to cut it you can unplug it and try to use it like a handsaw but that technology will simply give you no benefit and all you'll have is more weight so when in doubt try turning servicenow on and using it as is you might be surprised at what the technology is capable of as is our third and final story is that of by and large by and large uh has some of the most sophisticated robotics and automation that i have ever experienced not to mention some really catchy jingles in the movie but in their manufacturing centers just about everything is automated from the top to bottom there are very few people on the manufacturing floor itself behind the scenes there's a number of technology teams that operate on different platforms each selected for specific capabilities sharepoint sap servicenow you name it these guys had it and each platform had a separate team and this is where the issues began you see by and large had an issue with poorly formatted messages being sent down from the the upper level orchestration systems down to the lower level manufacturing systems some of the systems could generate xml that was excuse me that was basically considered invalid by the manufacturing systems and it would inevitably cause the manufacturing systems to shut down when these issues were detected the operations team would begin investing investigating and fixing the messages detection investigation and remediation were all manual processes now if the operations team was unable to resolve the messaging quickly enough production would shut down costing millions per hour in true cost of downtime a rapid sequence of poorly formatted messages could cost two to four hours of downtime and in the early days of these issues it was even more than that as we were trying to identify some of the root causes now the servicenow team we were working with had a solution to automate the detection generating a critical priority ticket for the operations team with the relevant details which would buy the operations team potentially hours of lead time in order to remediate those messages and catching those and detecting those early was the critical feature that was missing unfortunately servicenow was the help desk ticketing system not the automation and detection system territorialism set in and the team was directed to stay in their lane now in the remainder of my time on that project the downtime issue was never resolved by the organization i do hear that eventually the bug itself was remediated but i can't help but wonder how much was lost before a fix was put in place or how many similar issues have occurred since with similar result and all of this could have been vastly improved if servicenow's capabilities were simply allowed to expand to a larger role the issue here is a failure to adopt by and large was built digitally from the ground up but failed to adopt a platform for continued digital transformation and so when an incredible opportunity for the digital transformation was uncovered the organization had the capability but not the culture to make it happen this for me is the most heartbreaking of the three failures typically behind this failure is an individual or a team who are passionate about digital transformation passionate about what servicenow can do for their organization but ultimately they struggle to get buy-in and struggle to sell the vision and this is a story that i hear far too often fortunately there is an answer and i could honestly probably do an entire webinar on this topic alone but in the interest of time and trying to end on a high note i want to share with you the behaviors that i have observed in individuals at the most successful organizations with regard to digital transformation adoption so the first thing that adopters do is identify their champions champions are the people who are passionate about improvement and therefore willing to see the opportunity in the first place in our story that was the servicenow team these folks have influence and are capable of results if you're in a leadership position these folks might even be a bit of a thorn in your side but you tend to keep them around anyway your champions are the key to digital transformation adoption because if you're trying to drive adoption then adoption isn't about you it's about the people around you so find the people who are most likely to be allies to your cause and keep in mind these champions may be peers in other business units or subordinates or maybe even senior to you transformation is both top down and bottom up now once the champions are identified successful adopters clearly articulate their goals and budget to their champions and this once again goes back to our first point of defining success quantitatively the absolute best organizations communicated those exact dollar budgets from top to bottom and maintained a clear set of objectives this level of transparency communicates trust and gives your champions ownership and outcomes it also leaves less room for petty politics and ultimately yields to a solution where your champions are more engaged in solving the problems that you are identifying trust yields trust in this situation now the next behavior i've observed from the most successful is that they choose from their champion solutions in fact bake offs that allow multiple champions to prototype their solutions competitively are quite common in these organizations me personally i love a good bake off of solutions it's amazing how much a one or two week commitment to giving your champions a shot at their solutions can accomplish it helps to get the buy-in you're looking for because people feel involved it encourages the sort of velocity that we mentioned before and it builds a common awareness for all involved in terms of what the different teams are capable of best of all it requires low commitment and trust me a week or two is often all it needs to prove servicenow's value to digitally transform new areas of business for your organization now the last common behavior among successful adopters is that they get out of their champions way once you've set them up for success let them be successful yes remove barriers give support stay informed but ultimately if you want successful adoption you have to adopt a mindset of serving not control for those implementing service now the most common response that i get to this is some form of i wish my leadership would listen to this advice but i do want you to understand that this is a challenge for everyone not just leadership even if you are the lowest person on the totem pole you can talk to people in your organization somewhere you're gonna find someone who just knows that there's a better way and guess what you just found your champion you have a budget too how much of your time are you willing to use to serve that person there's your budget set objectives and achieve them then support and encourage your champion to share the results now you're building momentum now admittedly this is a tough way to go and that means that leaders you're not off the hook you're in the best position to grow digital transformation adoption in your organization and this is not a buy all the servicenow licenses sales pitch i challenge you to sit down with a servicenow champion in your organization tell them the financial challenges in the organization you're looking to solve and then listen yes digital transformation is a cost but when you have the right people focused on the right problems you'll achieve the roi that you are after okay so that was a lot of information so for those of you that skipped to the last chapter of the book let's do a recap 84 percent of companies fail at digital transformation today i've shared some stories highlighting three different mistakes organizations make during their digital transformation processes with servicenow that ultimately lead organizations to ask but where's my roi these failures don't have to be the norm to overcome these mistakes we've discussed three main keys to success the first is to define your success quantitatively this sets your roadmap to success and gives you a way to evaluate every subsequent decision the second is to emphasize achievement velocity over perfection launch your transformations iteratively don't sit on them until they're perfect the goal is the return not the investment and lastly digital transformation adoption in your organization servicenow is a lot of money to spend for a ticketing solution but it's a small price to pay for fundamentally transforming your business operations increasing returns comes from increasing adoption with that i'd like to thank everybody for coming and we will move to the rarest part of any webinar i've ever given which is the q a awesome so let's look it looks like we have four um notifications in the q a first question travis when looking for stop phrases how do you know the difference between truly making things easier for your users and just adding complexity ultimately on this one i think the best solution is if you have that question start without it if you have something and you're if you have an implementation and you're thinking i don't know if i need to implement this then the answer is don't let your customers prove to you that it's needed you know we we talked about um um you know the the uh uh dumbing things down for your users let your users prove that they need certain guardrails before you put them in give them trust first fix things later awesome um it looks like jace wrote i love this content we love you jace thanks for joining in another question says how can we go about defining success if we don't have reliable metrics in the first place um don't take this one the wrong way guess [Laughter] start somewhere um i'll put it this way when you turn around and step out on basketball court and you haven't shot hoops in a while you turn around you turn to your buddy and you say i'll bet you i can make six out of ten free throws do you know absolutely not you pick the number out of the air it's a guess but from there you can iterate from there you can you can improve if you hit six this time now you can look at the next time what do i change how can i do it better and then you can evaluate whether it worked so silly as it sounds in the absolute worst case guess you lose nothing by doing so awesome great answer one more uh question what can we do to to get leadership to buy in oh gosh that's that's and that yeah that's the million dollar question isn't it um communication communication communication um i think one of the biggest issues that i see when folks are talking about getting leadership buy-in is that a lot of time they have limited communication with the leadership they're trying to get buy-in from you know if you want change you have to talk to people that can implement change you have to talk to people that uh that have the power to make that change happen um and you know philip uh sherry i hope i'm pronouncing that right is mentioning leadership tends to buy into roi and statistics and that's exactly right you know if you sit down and talk with them find out again going back to our first point find out what their definition of success is and then tell your tailor your story to show them how you can give them the success they're looking for awesome so now um i'd like to announce the winner of our 50 visa card giveaway and it looks like the winner of that is emily long congratulations emily we'll uh email that to you with the email that you signed up for this webinar on thank you to everyone for attending today's webinar and thank you travis um for giving us an hour of your time with this great information i'm sure everyone found it super informative um thank you to everyone for joining us on glidecast on air please check us out on glidefest.com for more on air sessions we're going to have a lot more coming in the fall thank you everyone and have a great day you