welcome everybody to the Digital Services Forum weekly or weekly meeting today we're going to have it Brad come in and talk to us about a perspective on the need for a service now operating model I think he's still struggling to get in but he should be here in a minute apologies John I uh I was forced to to register okay s good deal I just get it kicked off and then hand it off to you sounds good we start off we have a very active chat and we go back and look at the chat and make sure that we get all the messages in and a lot of the way that we developed the content for future meetings is we go ahead and look at the chat and see what everybody's talking about or where we might be missing content so if you have any ideas along the way go ahead and drop them in there and if today's your first time especially make sure let everybody know who you are and where you're from and what you're coming from so that we can uh we can get you involved in the conversation so today our speaker is going to be Brad he's gonna he's our senior executive Enterprise architect we work together uh pretty frequently so it's great to have Brad speaking for his first time and he's going to go through a couple different topics on governance and then at the end I think you're gonna hand it to me for the last few minutes and we'll just touch on some future sessions without further Ado hand it right off to you and you can get uh get us kicked off on governance all right sounds good thank you John and good morning everybody okay so uh popular topic these days is the operating model uh recommended operating models for service now and governance in the platform um you know for those who have been around as long as as John and I have in the platform you know this is a a topic that didn't exist you know 10 plus years ago um but really over the past few years this is a something we've we've really put a lot of energy into and and refine the message um it's really important in how we manage the platform so I'm going to go through this and I do want to keep this as an open Forum um if anybody does have questions as we're going through um please feel free um either uh John what's the the best format is uh to put them in the chat and then uh and then you can you can help call them out or do we want people raising their hands or just being interactive how do we how do you typically run them yeah just go ahead and drop them in the chat and then if uh if there is something more complex I'll ask them to come off mute and and jump in as well terrific so feel free guys add them in the chat uh John's able to keep an eye on that as I'm going through this and we can we can pause and pivot and and have all sorts of conversations because I I do enjoy this to be a lively conversation I know it's governance how Lively can it be but I'm going to present a lot of of information and and I do want to get some thoughts and feedback from you if you have questions on on any of things the things that I'm going to be talking about today so um let's have some fun with this so I want to start with uh a bit of an analogy um and my analogy that I love to talk to is is NASA so if we look at you know the late 1950s to the say early 2000s if you wanted to get a payload into space there was one game in town it was it was NASA that was the way to do it um but as we look to you know the year 2000 and Beyond new entrance enter the field right SpaceX blue origin Virgin uh these were all new companies that developed their own shuttle Tech or spacecraft Technologies to deliver payloads into space but the one thing they had in common was they still relied on NASA to be the enabler to help them get what they needed to do in orbit so this is the analogy that I really want us to think about as we go through all this material you know our platform support team is the NASA right they may have been the original uh the original team managing our service now environment but as our needs for the platform grow their role changes to be this enabler uh for more like a modern-day NASA as opposed to a legacy NASA so keep that in mind as we go through the rest of the material okay so I want to talk about um eight reasons why some customers aren't as successful as others so you know our team here at service now we've we've worked with hundreds if not thousands of customers over the years and we've seen the good we've seen the bad we've seen the ugly and that's really where a lot of this input comes from uh but it's important to highlight you know where customers fall down so that we understand what do we need to to do in order to be successful so the first thing is you know missing any defining kpis or measuring outcomes with the work that we're putting into the platform right if we're moving workload into the platform let's make sure that we are doing something to measure it how do we know we were successful if we don't know what good looks like and how do we make sure that we're improving if we're not measuring in the first place so anytime we're moving workload into the platform let's make sure we're doing something to measure it uh preferably also make sure we're measuring the value that we're bringing um but as long as we're measuring outcomes we can always derive value as well missing platform governance or missing Federated development so this is relying solely on that platform team for everything right a lot of our customers you know they started off um using itsm in the platform and so what did they do well they had their remedy team their BMC team and they said hey you know what you're now going to manage this service now thing and so basically what you did is you took an application support team and you gave them a platform to manage probably with that is we're not an application we are a platform and so as the scope in your organization starts to grow Beyond itsm you're now asking a singular application support team to start to manage more than they're capable of they can't scale so we cannot have the platform team accountable for everything and we're going to talk more about the concepts of behind how we make Federated development happen that's going to be a big thing for us to key in okay no documented Vision or strategic road mapap for the platform um you know again this is a byproduct of you know coming in as an itsm tool in a lot of organizations we become a a tactical ticketing system in the view in the vision of a lot of senior people within an organization and these are some of the things that we need to change and one is what is the North Star for the platform what is service now's purpose in your organization let's document that let's make sure that everybody understands you know where does service like what what is the purpose for the platform and make sure we have a bit of a road map to help align the capabilities of the platform to how we are enabling strategic outcomes within your organization now one of the things that's going to help us do that is engaging senior leadership so again this is another thing where we see organizations struggle is when they don't have senior leadership involved as part of the governance process and that also plays a role in they're not going to have that vision and they're not going to have that road map because these are things where we do need that senior leader to be involved to help us create in the first place trying to go it alone uh without a partner or internal experience so uh I often talk about uh you know internal experience and I love to differentiate between experience and tenure um in my mind two very different things I I've worked with one customer they've been on the platform for a good decade or so um but because they've been on the platform for so long there's a ton of technical debt it doesn't even look like what service now is supposed to look like anymore they've customized it so much so when you get people in that organization that say yeah I've I've worked with service now for six years it's six years on a highly customized environment doesn't resemble a platform so that's not really valid experience that's just six years of tenure uh and that's not the same value so if you're when you're bringing in people to grow your team make sure that the experience is um valuable but when I talk when I talk about trying to go all alone uh we want to make sure that as you're looking to turn on new capabilities in the platform right especially when you're looking for you know standing up new products so let's say you're turning on risk for the first time or SE Ops make sure that you've leveraged preferably a partner they've done this hundreds and hundreds of times it's so much easier for them to do this effectively and efficiently they'll get you done in you know potentially 2 three months whereas you're in internal team would take 10 or 11 months uh there's massive cost savings even if you you know a lot of organizations get hung up on well you know the partners their hourly rates are high and this that and the other but the reality is is that you're going to take so much longer to do it internally it's going to cost you four times as much anyway so leverage those Partners leverage people with experience get you up and running you can always do the knowledge transfer to to your internal team if you're going to sustain the platform internally no problem with that at all um it's just the getting up and running leverage some experience to help with that platform team not staffed correctly according to best practices so um hopefully everyone on this call knows and if you don't I'm going to tell you right now uh we do have a what we call our our platform team size estimator um it's available on our public facing website go It'll ask you a bunch of questions some variables that are unique to your organization you can sort of enter in those parameters uh and it'll spit out a report telling you based on the data that you gave us here are the roles that you here are the number of FTE you should have in which particular roles um there is going to be a bit of a range because it's not a perfect science but at least it's going to give you a guideline on what is the ideal team size for your organization based on the information you shared with us okay um more often than not when people go to that team siiz estimator their their eyes pop out of their heads because the number they see is so big but the reality is is that we are a strategic IC platform for the majority of our customers um and we do need to make sure that we're Staffing ourselves accordingly if we want to get the maximum value uh out of the platform for your business uh not staying out of the box and incurring Technical debt through too many customizations this is a big challenge for I know for older customers I I think it's you know newer customers have a uh an easier time grasping this concept um but you know the Wonder thing about this platform is we can do so much with it um that can sometimes also be a bit of a curse if we're if we're not doing it properly right so you know sorry was there a question no we're good okay uh you know to quote Spider-Man right with great power comes great responsibility right so we need to you know yes we need to understand that there's a lot we can do with the platform but we need to know the wherewithal to understand where it's appropriate to do certain things um and one thing that I I will throw out there is a lot of organizations tend to um when they engage their business their business is yeah I want to I want to do this in the platform and I'm going to operate it the way I operated it before just move it into service now and you know what that's that's not really digital transformation that's just digital migration right so the whole point of our platform is we are going to transform the how the outcomes your business will will dictate those outcomes don't change how we get to those outcomes will change that's part of the transformation journey and and we're going to do that by staying out of the box as much as we can uh we pour a lot of money in research and development in our platform every year this is to make sure that we are doing the best way to accomplish these goals for the products that we've got uh in in the market okay and lastly assuming you can have a worldclass cdb without using Discovery and service mapping um the big piece here is I want to focus on it's all about automation right we talk about uh our agent list Discovery and service mapping these are just automated ways to get data into the CNB and understand the relationships uh between the CIS and your services automation automation automation let's make sure that we do not have any manual loads into our cmdb they're going to be fraught with errors uh or or challenges making sure that we're able to maintain this accurately over time so why is this important governance will ensure we have alignment and focus to ensure we are working on the right things that matter we're going to end up with standards that are going to be backed by policies on how we are using the technology we're going to have clearly defined roles and responsibilities for all the stakeholders involved in the platform this is also going to include standards regarding our data and lastly we'll have an understanding of the value we are getting for the platform and understand are we aligned to our goals so how do I tell if I'm set up for Success right we got to ask ourselves are these things in place right capability road map are we continually increasing the value of the platform and our operating model is it working engaged leadership do we have an executive or a c-level champion are they setting our direction right have we defined all of our services that we're going to be managing in the platform certified resources uh I'm going to drill into this one for a little bit because this is a massive opportunity that I find a lot of customers tend to overlook um it's not enough to just train your teams uh but we do need to make sure you certify them as well the results are going to be astonishing and here's my story on this you train your staff they're going to be trained and they'll go on their merry way and there's no incentive to continue with education on that subject matter getting a certification in a certain part of the platform requires you to maintain that certification um and hopefully you know there's a good number of folks on the call that that understand what I'm talking about you've been certified at something in the platform right but for those who aren't right the certification process you have to write a Delta exam every other release to maintain your certifications and here's why it's important if this maintenance did not exist then I would be a certified implementation specialist on the Berlin release of service now I think we can all agree that between Berlin and Washington there have been a lot of Innovations um that have come out in those 20 odd releases right keeping the certifications and maintaining the certifications mean I have to review the release notes for every one of the every one of those Delta exams I have to write forcing me to be familiar with all the cap new capabilities that come out and this is going to be massively beneficial to your organization especially when I get start talking about some of the roles and responsibilities uh and we talk about the concept of the solution specific Architects that we want to have within uh within your teams okay and lastly distributed development this is really the the only way to scale the platform right we want to make sure that we've got teams that understand the business requirements front-facing to those parts of the business speaking their language and understanding the requirements and then translating them into out of the box capabilities on the platform so if we do this right what's the end result we're going to have better visibility on what's happening in the environment all of it even if you've grown five times as large there will be no more finger pointing or gray areas in your process you'll have improved funding models you'll get better leverage of the technology and capabilities that you have and you're going to have overarching service improvement capabilities that are going to work okay so that's just sort of the the backdrop of why is this important so hopefully you know some of those some of the things I talked about have resonated on yeah you know what that makes sense this is important now I'm going to start going into um the three main areas that we need to focus on as we look to stand up governance uh within our organization so the first thing we need to talk about are roles and responsibilities okay so we have 15 critical roles on the service now platform support team now a lot of people see this and they kind of gag they're like that's a lot of people I don't have that many people what are you talking about so consider the roles like hats okay somebody can wear more than one hat that's okay um I I'm not going to go through all 15 of these roles but I am going to talk a little bit about the ones I've highlighted in green because these ones in my opinion are some of the most critical roles uh as we talk about governance okay so our executive sponsor that's obviously a very critical role we do need an executive champion this is a person who is helping to set the vision for the platform setting our North Star um working with our team to understand what is the road map for the platform right what do we want to accomplish over the next 12 to 18 months and how do those things align with our corporate strategy right at the end of the day we are a platform that enables us to deliver on our strategy let's make sure we have that alignment uh at an executive level they are also going to be the chair of our uh strategic governance board which I'll get into in the next section more uh but that's a key role dealing with executive peers in the organization as well okay the platform administrator is another very important role this is going to be a person who is going to be setting some of the overall technical direction for the platform um working to understand what are the standards that we need to have in place platform wide uh and working with our other um teams that are going to be working in the platform and building in the platform to ensure they're adhering with those standards right and they're going to play a key role to making sure that it all ties together and working with our Enterprise architecture team uh oh sorry I just realized I highlighted the wrong one I apologize I'm talking about platform architect not platform administrator um but I realized when I highlighted these the other day I highlighted the wrong one I apologize for that so it is the platform architect that I'm talking about here that's the um the key person I just saw the a I must have just my brain filled in the um but there're because they're our platform architect they're also going to Lia with our Enterprise architecture team if we have one to make sure that we're anything we're doing in the platform from a standards perspective aligns with the rest of the organization's uh Enterprise architecture standards okay number 11 on this slide it says data manager uh when I go through my my full set of materials I sometimes call this the data Steward or the cmdb manager right at the end of the day this is the person accountable for the data that is in the cmdb and making sure that it's up todate it's being handled correctly setting helping set some of the standards around the the data as well um and this is a person where you know I talked about the concept of hats before this is a solo hat um this is a very critical role it needs to be one person wearing this hat uh or at least one person maybe they're leading a team but it rolls up to one person this is not something that someone does on the side of their desk this is not a shared uh job that they can share with you can share with other responsibilities the cmdb is going to be the lifeblood of your environment we need somebody making sure that all the data coming in is coming in cleanly if I have issues with my Discovery schedules uh then this person will delegate the work to the appropriate owner of the source data to figure out what's going on right it is not incumbent upon them to solve all the problems it is incumbent on them to identify the problems and farm them out to the relevant people in around the organization to do the work right so if the distrib the distribution of work is what is really critical here so it's not on this person but they're going to be checking things like your cmdb health dashboard make sure that you know my stale CIS are taking care of my orphan CIS and my duplicate CIS are are all at a reasonable level uh and continue to Monitor and manage those going forward Brad yeah the um there's a question on here do you see the platform AR protect an Enterprise architect the same role or separate um it's a great question I think I see them as separate um because the platform architect is going to have a lot to cover within the platform uh I know I was talking with a platform architect the other day and I was having you know I was talking governance with with their team and right now that platform architect is actually involved with all the different delivery pods uh within this organization reviewing all of their requirements and he's actually a bottleneck to their process today right so if he was doing an Enterprise architecture function as well that would only make that worse so the platform architect is going to be busy enough just dealing with the platform I don't think it should be a shared function with the Enterprise architecture okay great question usually the Enterprise architect has a brad scope too like they might be looking at several platforms right instead of one I think that's absolutely absolutely great Point John yeah thanks br all right um the next role I want to talk about is the and I did it again I highlighted the wrong one wow I must have been in a rush um number 14 the solution specific architect that's the the role that I'm that I wanted to talk about here and guys we'll we'll clean this up before we uh we share this out with everybody else so John don't don't share this until I update this for you um so the solution specific architect is the is the fourth key role that I I want to talk about and this is going back to my conversation around the certifications the solution specific architect is ideally what you're going to have as you start branching out and the scope for the of what you're doing in the platform increases you know you so you've moved Beyond itsm you're now dealing with you know customer service management HR Service delivery integrated risk management well you're now going to start to work on some product teams that are going to help manage those products but you also want to have a solution specific architect front-facing each of the business units that um is interacting with those products and here's what they're going to do the solution specific architect is going to be trained and certified on the particular products that they are responsible for so if it's hrsd they will preferably be an implementation specialist for hrsd and what this is going to give you is it's going to make sure that that role has intimate knowledge of that product hrsd and what all the outof thebox capabilities are so that when HR comes to you with their requirement ments you now have somebody who says okay yeah I understand your business here's your requirements here's the out of thebox capabilities that are going to give you the outcomes that you're looking for when you don't have this rule in place here's what happens we all have a lot of smart developers in our organizations I'm not going to question that for a minute but what the smart developers don't have is the Insight on how we leverage some of the out-of the boox capability if they don't know it's there and they're not not aware of it what are they going to do they're going to script a way to make the requirement happen in the platform and guess what now youve built technical debt and you built some customized capability you have to maintain that guess what it's also not going to talk with all the other parts of the platform that it was originally designed for so this is the value the solution specific architect is going to really bring to the team is ensuring that we're staying as out of the box as possible minimizing our technical debt and giving the capabilities that align with the business requirements of our business stakeholders okay so that's quickly a little bit about the some of the key roles there are some extended roles as well um which I I I don't know that I have time to cover today uh but we also talk about 10 roles outside of the core platform support team and again these are just from people from Enterprise architecture to information security um they're not part of our our base umbrella team but they are part of the Greater Community and we need to involve them in our process right they're going to be stakeholders especially when we talk about security right we don't want to bring Security in at the uh the 11th hour to a conversation about Discovery right I've seen this so many times where nobody talks to security we're about to implement Discovery and then all of a sudden security gets wind of it and they're like oh hold on a second you're asking for a lot of access on these servers um but we we bring them in at the very beginning of the conversation you know make it clear so they understand what we're actually doing with agentless Discovery what what processes are running what are we doing with those IDs it's read only like all these things helps the way so that we can get things done faster okay all right so when we look at operating models on the platform right we've got basically three different uh options available right then this is stra self-explanatory we could you do a distributed model which would be great because we're going to have you know a team aligned with you know each of the products that we have we'll have our own backlogs our own prioritization great no problem the problem's going to be is how do we ensure that they're consistent in how they're dealing with things like data with things like Integrations that's a challenge on the flip side a centralized model that's no problem it's one team we know they're going to follow the same standards they're going to deal with h Integrations and data the same way problem is there's no way that this centralized team can scale to meet the needs of our organization as we expand Beyond one or two products so the whole concept between our recommendations is really talking about a hybrid model and how do we get the best of both the distributed and the centralized model in this hybrid mode that's the magic behind uh what we put together as part of this talk track okay I do want to highlight that this is a bit of a maturity model right this is not a yeah there's one model implement this and you're done no this is all going to going to depend on your maturity in the platform how many products are you leveraging um and also just you're the type of organization that you are are you a local organization a National Organization or an international Global organization right so we do have a bit of a a a maturity um model that we can go through uh as we work through this material um I believe for today the purpose of today's conversation I'm going to focus on um you know initial governance and the maturing governance uh I find the getting into the complex organizations is truly for a very small subset of organizations that I often don't don't interact with uh as part of the customers that I engage with uh but we can always have conversations if you are one of those um we can talk about that separately but I feel feel that the majority of customers can make do just fine with you know the the first two options here okay so as we're just starting out with governance what do we want to look at and we really just want to set up our three initial governance boards right we want the clar again going back to some of those initial slides I showed you clarification on the decision-making processes understanding who's responsible for what and giving some roles and accountability to those roles so people understand what is required of them so when we look our strategy governance board right this is going to make sure that we understand what are all the corporate initiatives happening in our organization how does service now fit into that picture right they're going to create the road map the funding model and keyy measures of value that are going to be important to us as we Implement work into the platform right we're going to have business unit leadership from all of our business units as part of this governance board so again everybody in the organization is going to understand what's the relevance of service now and how is it helping us as an organization not just helping us as it okay because this is going to help as well with enabler for Enterprise service management again across all of our businesses our technical governance board you know ultimately they are going to morph into really focused on the stability of the platform for but when we're starting out their mandate's going to be a little bigger um they are going to do some development as a starting point but again you're going to see how this changes as we start to scale uh and mature on the platform but for now the initial stage yes it is going to be somewhat a singular team um they ALS going to make sure that we're going to put in policies to handle things like how we manage our instances how do we promote our update sets how do we handle data how do we um manage patches and City releases and then lastly is the concept of our portfolio governance board and this is going to be the area where we are going to manage demand and intake to the any requirements or requests for work to be done in the platform right we're going to put together some formal on assessing business value um so that we can properly prioritize based on quantifiable data as best as we can right cost effort value risk those sorts of things uh and giving us you know a bit of an overall perspective for prioritization uh at an Enterprise level when we talk about the these governance boards right um just to give you an idea of who the roles are that should be part of each of the governance boards so really important to note our strategy governance board you know our executive sponsor they are the chair our CIO or CTO should be part of this board as well when I say business partners these are are Business Leaders from around the organization so potentially other Executives as well so again we're going to understand from an executive perspective how is service now helping your part of the organization our platform owner platform architect are part of this board Enterprise architecture she'll be sitting in here as well and then ser owners again um we've got we've got business partners but also service owners because we may have another dimension in the organization where we need to bring in some leadership from uh from service ownership side of things okay the technical governance board this is this should be pretty straightforward everybody understands you know what roles are part of our core platform team they're all in here um our PL portfolio governance demand board again we are going to put a demand manager in place to chair this board uh with the help from our our platform team the platform owner platform architect and our solution specific architect is part of this as well because they're going to play a big role as requirements come in how are we aligning that to outof thebox capability right big piece to that puzzle right our it process owners our service owners program managers they're all part in here as well because they're going to understand what work needs to be done this year for different parts of the organization I talked about setting up some policies these are uh eight that you can start with right and you can see which policies are going to align with which governance board uh and they all sort of have their their importance right so you know when we talk about strategy governance right let's talk about a customer Journey road map policy like this it's it's so important to create and maintain this road map that it is recommended to create a policy on this right uh I'm sure everybody can appreciate every year your strategic uh imperatives for the organization change right our SE Suite is always every year they've got new Direction new strategies let's make sure that our road map aligns with that year after year as those priorities change right technical governance right some of the big key things here is the platform data governance policy right understanding how are we going to manage and and standardize the data how are we synchronizing data right how are we using the identification and Reconciliation engine if we have multiple sources for duplicate data who's going to win how do we set that up um and the the development policy this is an important one too right configuration versus customization policies right we we talk about technical debt and the need to minimize technical debt let's make sure we have a policy in place because there's going to be the time where someone's going to say you know what if we we need to make this customization we have no alternative that's fine that's okay but let's have a policy on how we're going to manage that how we're going to maintain visibility for that so that way we can see okay you know what we went and we we updated to Zan uh now I see this in my skip log can I can I pull it out can I get the that that Tech debt out of here because zand do had that capability that I had to customize for right so making sure that we have a way to manage that and not just lose sight of these customizations hey Brad when you talked about service owners there's some confusion so you wouldn't invite every service owner to the demand board only the service owners that own the service now services that are being delivered right is that what you're this yeah so service owners that are requesting and requiring um capability to be turned on and enabled in service now so it's not I'm not just inviting every service owner in the organization no no no no it's a service owner who has a requirement for service now work is that also the strategy strategy governance board that was the one I was asking about having service owners in the strategy governance board that could end up being a very large number making that strategy discussion unwieldy yeah you know what great great question Jee and I think at some point you know when we look at the the audience in the strategy governance board right it's our executive sponsor it's our CIO and CTO when I say business partners these are Executives within our business units same from a service owner perspective we'll bubble that up to a certain executive level where we're not going to have as many and then it becomes more appropriate for their participation in the governance board so you're looking for representation appropriate representation for the area not okay got it correct correct okay but great question and uh and I'm glad glad you asked that because it's a good thing for us to clarify okay so that was sort of you know level one as you're getting started now I'm going to talk about what do we how where do we go from here and take it to the next level right so when we start to mature we start to get more products into the platform um we start to expand outside of it we need to expand that original governance model and so we're going to start to talk about the five COI pillars so center of excellence and Innovation pillars that we're going to move into and you're going to see the some of the changes that we're going to make uh it's important as we do all of these exercises and the same for the initial governance right let's make sure that we are tying names to each of the roles that we've identified that are going to be participating in these governance boards that way people understand what is expected of them and this is the whole clarification of roles and responsibilities and make sure they understand what are the activities that are required of them okay hey Brad I want to interrupt you here one minute hey Alan would you mind coming off um coming off mute and asking your question hey John um thanks um technical debt is uh is really important and we've all become aware of it but as far as I can tell there there really hasn't I haven't seen anything yet about defining and managing it quantitatively we say oh you know that's going to incur technical debt or that's too much technical debt or that's a little customization or or a lot of customization um is there any work to to take that forward so that we actually have something some harder numbers that we could manage in the in pure you know financial debt you um you know those numbers are are very well known and you you work on debt you you retire debt there's the cost of maintaining the debt um it'd be really helpful if we could could move forward from qualitatively working with technical debt is there any work around there that's a great question Alan um I am not I have not seen anything um I know we often talk about it as you know what you're going to have to live with it uh and there's there's going to be a cost to it and I think it can vary so much from organization to organization depending on what does that technical debt actually look like um so to quantify um an average might be challenging I mean it's a it's an intriguing proposition because yes I mean if if we could present some data say on average this is how much technical debt is costing you and this is what you know help to justify avoiding it um it's a great conversation to have um I'm just not sure if anybody has uh really done that level of analysis on it we can look into it and see if there is anything out there and share it with the group there's there's a lot in the product management area that comes with that because the product manager is first and foremost made financially responsible for their areas um so that I think that specifically gets more into that if you're managing five different solutions that do address normalization you're probably going to be looking to get that down to one because you're responsible for the cost of it all right right yeah for better for worse we know that um once you can express things in two decimal points you you get more attention from Executives um as opposed to just just you know principles no for sure thanks John okay so the top row you'll see our original Three governance boards right you'll notice the some of the changes that we've made as we start to mature the platform right is you start to get more products in the platform that technical governance board cannot exist as a singular team anymore and this happens very quickly in a lot of organizations where we need to split out our platform team from our delivery team and this becomes a change that will help you to scale um infinitely so we want to make sure that we just understand platform team think of them like a any of your Cloud teams right you've Azure AWS right what what's their sole purpose make sure the cloud environment is stable patched and available to be developed on and then that's where our delivery teams come in they're going to come and do the development work on the platform following the standards that have been set by the platform team okay on our portfolio governance side right this is where the portfolio demand management that stays the same the difference here is we've created this Innovation board uh which is really looking at how do we leverage the latest and greatest Technologies and capabilities which are the things that we should invest our time and dollars into that are going to receive uh a positive Roi in the organization and really show us value and when I show you you know the roles and who is involved um The Innovation one is is different than you know our platform and delivery teams you know there's there's some significant overlap with some of the key platform team roles uh difference being more the developers obviously sitting only in the delivery team side but the Innovation board um you'll notice it looks a lot like our strategy governance board right our executive sponsored chairs that our CIO and CTO are there the reason why is because we need them to be the ones making the decision on where do we want to invest our Innovation dollars our R&D dollars uh on really pushing the the edge of of the capability and the newest capability in the platform okay so when we put it all together right we do have our dedicated service now team rolling up to our executive sponsor and platform owner uh our center of excellence and innovation has the platform team and the delivery team now I will I will throw this caveat out there um the delivery team well yes it could be part of the broader coei they can also exist as a as a team that is not rolling up to the that executive sponsor and operate in a matrix environment uh that is that is ultimately going to be up to your organization but they do have a very tight coupled relationship with the platform team because they do form the center of excellence and Innovation okay and then our cross functional governance boards pulling in people from all different parts of the organization to participate uh in these various boards where they're where they are required okay I'm going to move quickly into demand management um obviously this is an important concept and just trying to where my mouse go I want to move this bar so I can see my slides again and I'm just realizing that there's one slide I didn't include in here so I'll talk to it instead so we want want to make sure demand management is going to be very important we want to make sure that any request for work in the platform we want visibility into it that is going to be critical um with the visibility is going to allow us to be able to plan and allocate resources it's going to make sure that we're able to maintain the velocity that we need uh to meet up with our commitments uh but also again if we need to staff up or staff down because we know there's three major projects that are happening 4 months from now okay well let's take some measures to leverage a partner to extend my delivery capability or something to deal with that anomaly in my my future workload as far as putting a intake practice into place right let's keep it simple uh we do want to make sure that people are leveraging um the process that we are using so if we're going to create a demand intake form um let's keep it to a minimum number of fields to start the process um I was I presented uh this topic with a with a customer last week um and when they did this you know they had some underlying processes that were a little more detailed that they got into with the with the stakeholder after the initial demand request had been submitted so keep it simple so that we can promote adoption let's make sure value is always part of the conversation right what is the value that this change is going to bring to the organization uh so that we can justify doing the work and then we can also measure the value that this brings to the organization after it's been implemented okay um important piece about demand management and again one of the benefits of doing this on platform um is the ability to visualize with three dimensions so you know in our demand workspace uh we can take our three different dimensions at work recording I think you know size value and risk are the the three that we key in on you can change those you can measure what you want uh but those are the ones we're looking at and ultimately what it comes down to is you know you're going to have limited number of people submitting your demand um this is a key concept we want to also enforce is um the demands can only be submitted by certain people these are going to be representatives from um your your your stakeholders the platform team um those are some of the key areas that we want to restrict submitting demands to if we want to open this concept up to the broader organization that's fine um we can do that as part of ideation and we can stand up an idea portal where every employee in the organization can submit an idea they can get upvoted down voted and then the most popular ideas can then be converted into a demand as part of our demand process okay our demand manager is going to make sure you know I'm going to go back here for our demand manager is going to make sure that the demand has been filled in correctly and then once they're satisfied then we can actually set the demand to screening for our stakeholders who we will identify based on the demand to assess the demand so this is going to be a combination of platform people uh and stakeholders who are going to assess the value of the demand which we will then use for the ultimate prioritization within the backlog that we are working with and so again as as we start to build out more uh more product teams we we'll potentially have a demand board for each of those products so that we can prioritize independently of each other so we don't have Financial Services operations competing with it service Management on when they get to go and I I say that because that's a real conversation I had a couple weeks ago I had the business user saying I don't want to wait for itsm to be deployed in 6 months before I can get my financial services disputes Management in place I need need it next month so let's separate the the backlogs between these teams between these products so that we can ensure the prioritization is relevant for the business okay so I'm just going to take a minute now to to wrap this all back up um this is sort of where we we ultimately sit right the hybrid delivery model we have a a dedicated delivery team for each of the products that we are working with you know in this case we we've sort of bundled it operations together with it TSM and itom uh again once your itom deployment gets certain size maybe you want to separate that so you can have uh event management separate from itsm but again our coei is interacting with our all of our development teams uh as they are working on their own backlogs for their own products as a one pager another way to sort of summarize this again you see our product teams and we have the various roles within those product teams right they're all going to be interacting with the demand board they're going to be interacting with the technical governance board you right understanding what kind of uh in what kind of solution is is being proposed and then our Center of Excellence our platform support team up at the top um understanding how do we interact with the executive steering board as well right so this gives us sort of an overview of how it all ultimately fits together and the last thing I just want to say you know we talked about our NASA analogy at the beginning I'm going to throw in another analogy at the end here right so we have a carpenter who's building a shed they're going to build it Soup To Nuts right one man one person job um now we're starting to build or remodel a house while the carpenter is still going to do the carpentry but they're going to be managing some people right they're they're going to bring in a Mason to pour the concrete foundation they're going to bring in electrician plumbers right figuring out scheduling when do everybody need to come in so there's a little bit of a hybrid role here but you know when we sort of take that to the next step and now we're being asked to build an office building well that Carpenter is not doing any of the work anymore they are now you know acting as a contractor and coordinating all the work efforts for all of the different trades that are are part of the process so this is ultimately where we need to get to right much like NASA is the coordinator right now you are that that that um mature Carpenter who is acting as the contractor we're playing traffic Cup right we are making sure that people are following standards they're building to code uh they're not violating any uh any laws right and everything gets built within uh with synergies with each other so that's the ultimate goal and when we do this and we do this right um this is how we can scale that's what it all comes down to at the end of the day is how do we have the right um processes in place the right controls in place that are going to allow us to get work done but also allow us to scale as demands for workload in the platform continue to increase so this was just a short version of what's normally a much bigger deck a lot more content um but happy to share all of that with you uh another time if if needed but hopefully this was uh of value to to everybody on the call today so thank you for giving me the time thanks Brad yeah we we offer this as part of the EA engage ments that we do too to come in and make this more yours any other questions before all right I'm going to grab and share a few slides just to uh wrap us up here there was a question on the on the Forum about the um about the let me go back to this one where all this content is at the end and I'm just going to flash that up real quick so that I can give everybody a reminder so with the stuff that Brad just presented if you go on Monday or usually I have it up within the next day or so but if you go on to the Forum and you go under blog all of the meetings are on the blog two days afterwards so if you go on the foundational data one we did back on June 6th and you click on that you'll have access to the recording um on that link and then you'll also have access to any of the content that was shared so the content is either up here in a link if it's big and down here has attachments if it's small enough to where I can attach it um in in the um in the community blog so just if you wanted to link that that blog link that's a good one to have I'm going to share a couple slides with you just uh in closing here that I use and this will be in the deck that I share on that blog so a lot of you are working off these now we shared these a couple times the different content but basically the capabilities map of service now and if you come at this from a governance perspective all the stuff circled in number one is owned by the platform team so we try to really assign the ownership as part of the model so number two could be an IT service management area we might group itom together with itam to make um all of that area as one pro program app portfolio management is its own right app engine might have its own area so this is depending on what you own you're going to have different areas of ownership and this is what I've been really driving a lot with product management is how are we grouping these things together so that we can say Jill owns that Jenny owns this so if you take all that and you draw it on the map um on on the capability map then you go down and now you can start to say what is the team that takes takes care of this so this is u a lot of what Brad talked about earlier the structure of the team there's an executive sponsor and if you drill down in the deck there's a ro responsibility definition for that executive sponsor so everybody has their own Parts this middle layer to me is the most important what I've been driving a lot some of you called them solution area owners some of you call them service owners um I call them product managers so there's actually Jill Smith owns the IT service management product and here if you go down it'll be the whole road map so there's all different types of things that can go on here like in some states I have where Jill would actually be providing it service management as a service to other agencies and so that could be all different types of things and and the role could be all different types of sizes depending on what Jill is actually doing down the bottom we have the role descriptions for the platform team right but the idea here is that you really want to set this up so that that platform product manager I got Bingo here right that platform product manager serves all of the tenants on the platform so these are all tenants on the platform to the left are it tenants to the right are non-it tenants and then those tenants are who the plat so the platform product manager product owner whoever you're calling them they should never be making a case for procurement there should be somebody else making that case for the procurement product and somebody else asking to host it on the platform and bingo should be helping that person do that but they should not be the one that gets all the demand for all of the new things that run on the platform one other thing here is that if you're working on this and you're the it asset manager Mike Lee you're not the product manager for service now you're product manager for the entire asset program right so service now's part of it but you're not doing Asset Management with just service now you're using secm you're using Jam you're using all this data all these other connectors so Mike Lee is responsible for the whole Asset Management program not just to say that hey I got the service now Parts done now the middle layer is really where you want to have that strategy decided with the top layer so that that and this is aligning the products on on the the capability map to the people and then what we have here is the same thing Brad mentioned earlier right the executive steering board right which is largely those top two lines and then you have the demand board which is mostly going to be the middle line right all the people that own the different service now product areas are on this demand board and then you have the technical governance board which are usually going to be the bottom two lines right the people that are have active things going on and are meeting regularly to talk about those things so this is a way this is a framework we're giving you right so Nobody Does it exactly the same pretty evident on on the chat that we had earlier right everybody's doing this a little different so these are guidelines we come in as architect we help you shape this for your organization so the last thing besides saying hey these are all the things you own service now capability wise and that's area one versus area two there's also going to be the different ways that we can stage the road maps so that app engine product owner or product manager whatever you're calling them they would be able to now look at the service now capabilities and Stage those in depending on how they would need them so this again this should not be the service now platform owner who does these road maps road maps at this level should be done by those solution area product owners it may be the same person but make sure as Brad said before you're changing that hat when you start talking about an app engine specific road map you're no longer the service now platform owner but you're now the product owner of the app engine product okay so those slides will be in there that's the way for those of you that work with me on engagements this is the way that I go about it and we we tweak this for everybody right it never works the same way but you know that's basically the slides that I use for that governance section and we always make sure because it's really more important than than the products right the the service now products can get you part of the way there but if you don't have the right butts and seats as I call it right you're not going to be able to get the work you need done in these areas to maximize your value so I I dropped these links in there too so that the Brad was showing these are links on Our Success Center the team estimator and also the um the document that explains the role all right a lot of words real quick so Brad thank you very much for coming on and going through that very thorough I picked up a lot of things myself that I'm gonna steal from you appreciate it my pleasure my pleasure I'm passionate about this stuff good deal thank you everybody we'll talk to you in a few weeks you