all right everyone this is uh this is Pete spear from covestic thanks for joining the webinar today uh the topic is uh I'm implemented now what which is really focused on maintaining a healthy service now instan after after go live and some of the Staffing elements uh around uh maintaining an instance and and Staffing a team to support your service now environment my name is Pete spear I'm the uh I'll be sort of moderating the uh webinar today um my role at covestic is Director of Business Development for the West um I've been with covestic for over four years now and have been responsible for business development and account management in the itsm service nowspace uh for the west and um happy to have you all join us today thanks just just a bit about covestic for for those of you who don't know who we are we uh we're based in Kirkland Washington we've been around since 2001 uh we've been delivering Services Nationwide uh we have about 200 plus folks uh mainly senior level Consultants with an average about 14 15 years of professional Consulting experience um we have three major lines of business uh our it operations Services practice focuses on uh developing and standardizing it operations environments including cloud and uh Enterprise infrastructure environments including security operations and and other applications administrations uh our project delivery services focus on providing project leadership to uh very complex IT projects um we have a long history of project management uh that it really ensures compliance quality and timing of project delivery and then finally our service uh management uh service now practice focuses on um assessment work um implementation work and uh service network as as you as you may know and service now is the only tool that we work with so um across the the vast you know landscape of service now tools we only work with service now uh We've performed over 100 service now projects with an average seat score of over nine and we've about 90 over 90% recurrence rate with with our clients uh here's a depiction just a few few of the companies we work with uh this spands across the country of course uh we have a focus on on the west for my standpoint but also across the country with with many large Enterprise organizations uh across many Industries from manufacturing to government to Telco uh to state and local as well the agenda today will we'll cover three topics we'll focus on building a product road map and what that means uh for developing your your long-term service now objectives uh we'll discuss best practices around uh defining an stlc and discuss the Staffing considerations and a few models around how to staff a team to maintain a service now a healthy service now environment and a healthy instance um this should provide some ideas and and a few different models that may or may not fit your needs um and we can always you know work with you ongoing to tweak those items and some of these models for your particular environment please feel free to ask any questions there's there's a Q&A uh session after Michael's presentation um but we definitely want your feedback and we can answer some of those questions ongoing so just take note of some of the material as we go through this and uh feel free to ask answer any questions or ask any questions and we'll be happy to either follow up on this call or or after this call with you directly I'll turn turn it over now to Michael E he's one of our senior solution Architects for covestic uh Michael will be delivering the majority of the content today so Michael please proceed great thank you beat uh glad everyone can make it today uh again my name is Michael Y and I'm going to be the host for today's webinar as Pete said I am a Solutions architect with covestic I'm based out of Southern California I've been with covestic about five years and been working with the service now platform uh since around on 2007 time frame first as a customer and the last six years as a consultant in terms of my Consulting projects I've done over 50 service now projects providing design delivery Assurance as well as delivery so today's topics you want to get into is you've implemented service now now what so this is a great topic and really where I came up with the origin of this topic really started with a conversation I had with one of my customers several years ago it started off with a simple question where one of my customers asked me you know what siid does my team need to be and as a consultant my classic response was well it depends and his response on it depends on what that's when I came up with this particular slide you kind of see this graphic here on the right this is a this is what I developed during the conversation this concept between the prod road map the stlc and the Staffing which I want to kind of share with you today because this really talks about the different types of components that really is going to influence what type of Staffing model uh that you should adopt and we'll go through uh each Topic in detail I first had this conversation as I said it was in Vegas actually in one of the previous no knowledge conferences a few years back and I put this analogy in terms of a Vegas buffet and if anyone hasn't been to Vegas before or eaten the buffet at Vegas uh Vegas is known for their you know rather large or same number of items that you have on their Buffet if you haven't had a chance to eat one you should try and if you haven't had a chance you may have an opportunity next May when servers now has their annual knowledge 18 conference out there to try one of their uh their crazy buffets so what does this really have to do with Staffing in the product road map really when you go to a Vegas buffet or when you build your your um your Staffing model it's really about strategy you what you want to do is you want to develop a strategy because when you go to a Vegas bu they have literally hundreds of items in which you can choose to eat and there's no way which you could possibly eat all of them so the idea behind that is you really want to develop a strategy prioritize items where am I going to go to First and really kind of figure out what's important to you and what's not and that's really what we're going to be talking about today in terms of different Staffing options so the first thing which I want to talk about is you know the product road map and the product road map is really about being able to prioritize what is what it is that you want to do as an organization what do you want to focus on what are those items which that you're going to be uh implementing either in the new future or in the distance future and this is really about selecting which items on the buffet that you want to put into your road map and say you know this is what we're going to be uh to be focusing on the second thing which we're going to be focusing on is the stlc and this is really your strategy and how to execute your product road map and if we go back to our Vegas um Buffet analogy some people will have the strategy of grabbing multiple plates at a time and bring it back bringing it back to their table while other people will take one Plate at a time and the idea behind sdlc is figure out what is that Cadence in terms of what are we going to do in order to grab those road map items and Implement them are we trying to going to do a bunch of them at a time are we going to be very strategic are we going to group them together and that's what we we'll really talk about in the sdlc and the last thing which we want to talk about excuse me sorry is Staffing uh Staffing is really going to be making sure you have the correct resources in order to uh support your stlc in your road map if we go back to our to our Buffet analogy this is well am I getting food for everyone at the table or am I just getting it for myself because if you're grabbing dessert for everyone at the table you're going to be grabbing more as opposed to just kind of doing it as an individual so you really need to know what resources you have available as as well as what resources would you um are going to need the challenge which we have is that even if you do Define this your product road map and the requirements you have on there your velocity and we'll talk about what that means in terms of sdlc as well as your Staffing these will constantly change over time uh you have staff members who uh will get diverted to other projects or may leave the company you may have re priorit pre- prioritization in terms of road map items uh you may find that your sdlc Cadence needs to be adjusted upwards or downwards so it's also key to keep in mind that you need to come up with a dynamic model that will be able to adjust up as well as adjust down as the business environment changes for your service now environment so let's first talk about the product road map and how to develop a living road map that evolves over time these are some some some common questions I hear from customers after go live they are questions like uh what should I focus focus on next I have hundreds of bugs and enhancement requests on my team and I can't keep up other departments want to start using service now where do I start and service now is releasing a new version uh usually twice a year should I upgrade and when should I upgrade these are common questions and if you've asked yourself the same these same questions um or if you're asking yourself these same questions you probably first need to look at your road map and if you don't have a road map one of the things first things you need to do is either to create a red map or update your road map typically after go live and your user-based community has started using service now for some period of time they'll start to identify bugs as well as enhancements things which they you know want to see in future versions of service now the double-edged sword with service now is the more successful you are implementing uh service now at GoLive the more likely that other functionality will want to be introduced especially you know if they're aware of the service now platform capabilities you may have other organizations or other department departments who are looking to migrate their own legacy applications to service now on top of the existing footprint which you implemented during your first go live the key behind this is you can't possibly do everything all at once nor should you try I often hear customers tell me that like I said they have hundreds of requests that they can't keep up like I said this is normal and instead of tactically trying to close them like incidents one at a time the better way is to build a strategic product road map to provide some strategic direction for your organization for my customers I typically build a three-phase road map I have an example here on the right uh the phases are in this case is broke up into three phases in terms of the shortterm as well as a uh second term and a and a longer term road map the first phase is it really focus on things which you really need to do immediately and has some fairly High detail in terms of what it is and what it's going to take while the second phases are um a little bit further out and have a little bit less detail the purpose of the multiphase road map is to publish this road map to your organization and set expectations on when certain road maps will be implemented so that way if after go live for example and you have this road map and someone says okay well I see that in uh Jakarta instance service now has the automated testing framework I really want to you know to you know take advantage of that if you have that on your road map like we have here in our example saying okay well we understand we're going to start looking and considering that you know in our April 2018 uh release and that way you can do a little bit more strategic thinking and planning in terms of rolling out something like test management as opposed to trying to handle it like an incident and kind of close it out right away I like to create themes for each phase the road map so you see in this example this three-phase road map the first phase I have here is the it service management or an itm theme and the second theme which I have here is the facilities and it business management but if you look at the individual items in here just because you have a theme for a particular phase it doesn't mean that everything that in that theme uh needs to be uh inclusive uh for that topic so for example if you look at the facilities theme which I buil here as an example it has three items in here which has to do with facilities facility service management uh some geojson map integration move management I also included two topics which are traditionally with itsm which are basically bleeding over from the first phase into the facilities theme that's vendor management and Knowledge Management for the end users so the focus on this particular theme could be facilities management but that doesn't mean that you can't take on other topics that may be of a prioritization for your road map so how do you know what items to put on your road map you want to consider two different approaches the first approach here is to mature your existing applications so for example if you started off with a service now quick start where you're doing itsm incident change problem uh maybe a cmdb light and that went successful your second phase may be to build upon that existing uh scope so you may be doing you know additional cmdb you may be doing some additional things around problem management and change management maybe you're going to be looking at doing you know the standard change catalog or the cab workbench so in this particular case your road map items would be expanding existing functionality that you already have implemented and what you'll find a lot is that even after you go through go live and your users start using a particular application even as something as core as incident or change management 30 60 90 days you should have enough items in there in order to um you know create a backlog in terms of what you can do in order to improve that particular application and really bring it to the next level of maturity so it's not uncommon to see something like a service catalog or Incident Management be spanned across multiple level of phases simply because we're constantly trying to evolve these processes and make them make it a better experience for for our users the other road map consideration which you have is introd Introduction of new functionality so this is functionality which isn't previously available to your uh user community so you may be adding in new applications that were not previously available so for example if you see in our road map here uh we're adding in facilities uh Facilities Management in the second phase and we're really focusing on facilities service management move management those would be uh two brand new applications uh you could be introducing new Integrations like we have here for our geojson map integration which you know gives you the um uh the space maps that we can use with facilities the other thing which you can kind of consider is that if you have Legacy applications what you that you want to migrate to service now which requires some custom application development those Legacy applications are often really good Targets in terms of um things which you can kind of put in your road map especially if it's something which you're looking to sense that in the near future here here are some uh benefits of a product road map really without a product road map organizations will really struggle to keep up with a service now product demands they'll have problems setting uh expectations with their stakeholders and their organization and the de development teams um are a lot of times not appropriately staffed to meet demand without a road map some organizations will attempt to log service now enhancements as incidents we'll be talking about a better solution for that uh here in the next slide and what this does this creates the organizational perception that service now is broken uh because they view that oh there's all these incidents which is being logged against the service now platform and this is really subjecting service now to the incident management process and when you think of uh things like bug fixes and enhancements some of those yes may be uh actual bug uh uh bugs but a lot of those really have to be a lot of times in my experience there'll be training opportunities as well as you know enhancement request that people want to see out of the new platform it's really key that we differentiate the two with a published road map stakeholders have a less of a right now expectation on development so they basically know you know what's on the horizon what's a little bit further Beyond in the advanced phases and know really when uh when certain uh items will be implemented stakeholders will have a better understanding of the Cadence and the capability of the team we know we're doing a three-phase road map we know that we're focusing on one theme uh per phase if you have a larger development team will be talking about that maybe you're focusing on you know two themes per phase but this will set the expectations for the organization in terms of what's coming and how much is being done during each each particular release cycle uh the organization is able to align road map items with business objectives and that's really key is you want to make sure that whatever you're you're putting in your road map is really for the benefit of the organization and it really aligns to what you're trying to achieve as the business so for example a lot of organizations would come to me and say uh Michael I'm really interested in Asset Management because you know we have uh issues in terms of you know being able to reduce our cost in terms of software license and that has a very specific business objective as well um some specific goals which would really make sense to be put put on the on the road map and those are the types of things which you're kind of looking for additionally we've run into some circumstances where people will say you know what I understand what your road map is but I have this really high priority item for example they may say you know we have our our marketing teams out there and we really need to get them to go live um and they're not on your road map yet and a lot of the times if something is that high of a priority you can view this a lot of the time as being an opportunity to fund additional resources or you can say okay you're not on the road map right now because we're only building our road map based upon our current capabilities but if they're willing to fund a project we'll talk about you know some um examples in terms of how to execute that but they're willing to fund a project and to staff it you may be able to accelerate that particular topic or that particular road map item um if they have the the funding for that what the road map does it promotes some more deliberate preparation planning and design before the actual development you want to make sure that you're not doing things last minute but that you're actually collaborating with whoever is asking in terms of what needs to be fixed because a lot of the times especially after go live things which are quote unquote bugs as I said before they may just be training opportunities or things which people need to get you know adjusted or acclimated to or that may be that it does need to be something which needs to be addressed but it needs to be addressed from you know a larger macro level as opposed to you know a tactical change you know on a form and really what happens is that the more planning and design that you have before the actual development and collaborating with the people who are requesting it understanding what the platform requirements and the platform impact is the higher level quality of solutions that you're going to be able to deliver this next slide here is really about demand management and what this has to do is that if you have a lot of of uh requests and bugs and fix enhancements which are coming into your service now team demand management is actually a a perfect vehicle in order to capture and to manage those types of requests for those who are not familiar with it uh demand management is an application that is available you know within service now and the idea here is that you know through a catalog item or even through the the UI users can submit ideas and those ideas can be um grouped into demands and you can evaluate those the demands are in terms of the risk and the value into the organization so what you're seeing on the right is uh just one screenshot of the demand management with a bubble chart which you're able to really compare different ideas or demands which kind of come in and see which one really makes sense other things which you can kind of do with demand is you can do things like be able to size the um uh the effort for that particular item in terms of what it would take in terms of cost in terms of effort and really what this allows to do is it allows you to be very strategic in terms of what what you're going to be putting on your road map you have a really good understanding in terms of what it's going to take to implement that road map item as well as what the benefit will be to the organization if you were to implement it and help out with a prioritization just some key things to remember about building a successful road map the first thing about having a successful road map is really about developing a product owner and getting uh the service now stakeholders and uh leadership being able to review the pro uh the product road map uh the product roadmap should be publish it should be visible it shouldn't just be a a um document which is kind of tucked away in some some sort of shared folder we want everyone to have visibility in terms of what you're building on the service now platform get people excited about that as well as have people kind of contribute to you know you know any sort of items which need to be you know added to that road mapap this should be driven by the the product owner and we'll be talking more about you know what the product owner role is a little bit later the product road map should be a living document meaning that just because you built it once doesn't mean that it doesn't need to be updated so typically I recommend is after each major release you're going to go ahead and you're going to update that road mapap to to um check off you know the items which you've done as well as look at the items which are next on the next phase in the road map and you have to consider okay for the next phase do I need to reprioritize road map items do I need to add new items to the road map do I need to consider some new features that are available in the latest release of service now you want to review to ensure that the appropriate maintenance Staffing and budget considerations are in place in order to support that road map and we'll be talking about that for example if you're going to be introducing something like Discovery in the next phase you want to make sure that you have the appropriate Staffing Resources to support a discovery not only implementation but a maintenance ongoing maintenance uh after after the go live so the next topic which I want to talk about is the software development life cycle or stlc and really this is about creating predictable release Cycles so at this point with your product road map you know what it is that you want to do you have that published out to the organization you really need an stlc uh as a vehicle to help you to figure out well how am I going to implement this to make this a reality and the first thing you want to do is really to establish a release schedule and the release schedule which I usually recommend is basically to have at a minimum uh two uh regular release schedules you basically want to have a a maintenance release and in this example here I have a weekly maintenance release some organizations will do this on a on a a bi-weekly or a monthly basis as well as you want a major release or a road map item release and in this example did a quarter release the idea is is that you're going to have a bunch of different maintenance items and these could be things as simple as okay I need to clean up some notifications maybe there's some form views out there which need to be cleaned up maybe I need to you know create some um you know reports so those are the maintenance items things which will go on on for a weekly basis and it's really going to be focusing on uh maintaining your your current scope your second release which is your road map items which is less frequent and in this case bis quarterly this is really about pushing your road map uh forward so that uh product road map which we just discussed you're going to be taking uh one of those phases and really executing on implementing that particular phase and what you're going to need to be able to do that is to develop a Cadence or develop a a set of release activities uh for both of these relate uh uh release types so for example if you're thinking about okay well I'm going to be doing a major release how much time do I need in order to get requirements or gathering or user story development as they call it in agile how much time am I going to need for actual development and in terms of what I need to do in terms of unit testing and how much time do I need in order to do an update update set promotion in uat testing what organizations find is that a lot of the times they'll come up with an ndlc for example and they say okay well we're going to be doing uh for a maintenance release 40 you know FTE hours basically one person you know 40 hours a week fairly simple example what they find in reality is that in order to actually execute and Implement on that 40 full-time or uh 40 hours a week it really takes three calendar weeks in order to actually execute that because they need at least one week in terms of requirements and user story development and they also need another week in terms of uat testing remediation documentation and training so it's very care it's very critical to that you understand you know what your exact Cadence is and that you just don't incorporate the the development persp perspective but you also understand you know what the other aspects are for the release we'll talk about some of the major road map items a little bit later in terms of some of the roles but one of the things to consider with major road map items especially when you're looking at changes in terms of uh the UI which you know typically happens um maybe on a yearly or every other year basis with service now where people actually will see things different with the new release or maybe you're changing your process there's going to be a aspect of of organizational Chang management or ocm and you're going to see that in our slideshow where you're going to have to invest in the organization to be able to adopt the new process to adopt the new UI so there's going to be training and internal marketing campaigns and communication which also needs to be um delivered and that really needs to be built into your release activities to make sure that you're successful uh common organizations expectations um excuse me common organizational expectations with no publish sdlc what do they kind of run into um a lot of times they run into bug enhancement requests that are ignored or take too long because a lot of times people will focus on just a couple of bugs or enhancements or the other ones which are out there which they don't know um they get a little bit delayed uh without a good stlc process without a good stlc process there's no expectation in terms of the duration so when a user submits something they don't know whether it's going to get uh fixed tomorrow next week next month next year you want to make sure that uh uh that you set an expectation in terms of you know what the turnaround is for that um the other uh issue that you run into is that the management organization doesn't know what service now team is doing and when they're doing it they know that they're busy but they don't know what exactly that they're working on uh without that sdlc without that Pro product road map we can't say hey we're working on this particular phase which has these particular road map items from a development perspective uh the team will have some challenges with no publish uh sdlc the biggest challenge which I see from a lot of my customers without a mature sdlc is that the requirements which they're given uh from their users or that they get in uh they're usually incomplete or in inadequate and they spend a lot of times going around trying to collect the right requirements or in a worst case what they end up doing is they have to do multiple testing Cycles or at the absolute worst case multiple release tempts or multiple tries because they just didn't get it right the first or second time the idea is is that as I was saying before the better planning and design you have uh the better chance you have on getting a first a higher quality solution the first time around other issues that you have is that without ndlc you're going to be more susceptible to duplicate requests you're not going to have complete visibility to everything which is going on especially if you're taking a a first in first out just kind of working from the top of the list and and and moving your way down you're not sure if someone else is working on the same thing or you know maybe that's something which you guys have tried before but you just have visibility to it and this really kind of creates a reactive development um environment as opposed to a strategic one in terms of sdlc benefits here are some uh benefits you'll see with the mature sdlc process the first one is organizational visibility to the service now team velocity this is really going to tell the organization and Leadership how much work your team can do reasonably and accomplish for each maintenance and major release you know we talked about in terms of development hours maybe you only can do 40 development hours of Maintenance release a week maybe it's only 10 or 20 kind of and we'll talk about you know how you calculate that out a little bit later but the idea is that you want to make sure that the that the organization has Vis visibility to what your team is capable of you'll also have visibility in terms of do you need additional resources to meet demand especially if you know that this is the Cadence which I'm setting up for the stlc uh and this is the you know the product road map where the organization expects us to execute it do I have you know the the right number of resources or maybe on the opposite maybe you have too many resources maybe you have too many administrators and not enough developers where uh some of your administrators are are idle and your developers are being um overworked you want to make sure that you have a good ratio between uh road map items and maintenance items so as an sdlc you want to make sure that you're maintaining your current scope as well as you're focusing on your product road map items as well you want to make make sure you have a good blend of two of both of those the second benefit which we put on there is to manage product expectations you want to make sure that you understand your team's cap capability and benefit to the organization so that the or so the organization knows what you're doing and how it's benefiting the organization at a whole as a whole you want to make sure that the process encourages collaboration with the requesters and the business units When developing Solutions so you want to work with the business units and with your requesters in terms of develop in stories doing storyboarding and mockups um and working together in terms of user access acceptance testing um the last benefit uh which we talk about is that team knows what items to focus on and what items uh must be delivered but more importantly what items are on the product backlog that they don't have to worry about right now so allows them to say okay that's something which is going on in phase three we're going to worry about that when that phase comes along these are the items which I need to to focus on for right now so let's talk about some staffing models that you'll need in order to you know maintain your current instance as well as some of those uh project uh road map items first thing I want to talk about are some common Staffing roles uh these are some common Staffing roles I see for most service now organizations the one which I have on the top is a product owner and I say I say that this is essential for for all organizations this is usually one named resource one person it's usually not you know a multiple multiple people it's not a committee but really we want to Pro have a product owner who's developing the product strategy sharing that out with uh leadership and really is being the championship Champion for for the service now platform now they may work with a larger committee or a service management organization or another governing body we want to make sure that we basically have someone who is uh responsible for the service now platform as a whole to make sure that one it's aligning with the business objectives as well as as um maintains the platform Integrity second role which I have here is the system administrators and I say at a minimum organizations should have at least one certified system administrator on staff preferably two or more really kind of depends on the size of your organization talk about that in a second the role of the system and administrator is to perform platform maintenance and day-to-day activities so they're really about maintaining the current scope that you already have implemented so if you did a phase one itsm implementation the expectation is that they're going to be able to maintain as well as provide some minor enhancements to that existing scope the expectation is typically not that oh you know that we're going to be introducing them to you know things like automated testing framework or GRC or performance analytics those are roadmap items which typically um system administrators you know would need uh at least um some some some additional resources to help to plan and to implement the third role which I have here is the developer uh so this is uh for organizations that have expanding functionality in terms of road map items and really their their role is to extend the the platform functionality so it's to introduce those new applications to extend the existing functionality uh build integration that sort of thing the fourth item on here is a business analyst and the business analyst is really going to help you in a number of ways one they're going to help you with in terms of uh document requirements as well as really kind of help you lead with the uh Championship enablement or the organizational organizational change management uh requirements that you have for your organization so this is going to include things like internal marketing campaigns training documentation as well as even on a more technical side identifying whatever changes or what whatever you're implementing what is the organizational and platform impact that you need to prepare for and need to make adjustments to make sure that it has the the most minimum impact to your organization I threw this last one in only because I'm seeing it more and more and um I'm calling a configuration librarian I've seen a configuration administrator uh the idea behind this particular role is that if you have a cmdb and whether you're using uh service now Discovery or using another Discovery solution or service mapping um you're going to have to have someone who's going to be able to maintain the cmdb health and provide reconciliation and mediation of the CI objects and that's really where the configuration Library librarian comes in so for discovered objects they're going to go ahead and uh help out with um maintaining those CIS and then for the uh ones which are not discoverable maybe it's things like who owns particular services or you know who is the supporting group they'll help you to maintain those those attributes as well here are some staffing options that we see very common uh in the industry the Staffing options that we have here are in-house this is probably the most basic this is used for sustained Administration and development uh you have manage services which is more third-party so this is also used for sustained Administration development but this is you know usually a third-party um uh firm that you're using you have developer on demand some organizations will call this a virtual administrator and this is really used to augment your in-house staff uh the advantage of developer on demand at allows you to dynamically adjust your team velocity uh gives you a lot more flexibility and the last one which we have here is uh Project based Consulting and Project based Consulting is used to implement a new highly specialized functionality uh against your road map items and this is usually used for uh projects where your in-house staff may not have or they may not be up to speed on those specialized skill sets when you're considering your Staffing options things which you want to take into consideration is what your current sdlc velocity is and what you anticipate your stlc velocity is against your product road map so you want to make sure that you understand you know am I going to have um you know a maybe in the third quarter a uh increased demand for you know development and in the fourth quarter it's going to go down well how am I going to adjust to that because in-house staff is you know fairly um um uh sustained uh but I don't want them to be idle for three months so you know can I backlog that with you know developer on demand or maybe put in Project based Consulting so that's what you really want to do is in order to make sure that uh you have you understand what your sustained velocity is as well as your anticipated velocity is in terms of your road map items as well as what your cost and budget is to fund each one of these Staffing options so let's talk about creating a staffing model the first the first step we have here is identifying a product owner we talked about who a product owner uh should be and what their uh role is the second item here is to identifying the staffing needs based on the product road map in the sdlc process the idea is that you want to quantify the plan demand for each roadmap phase so agile uses a system called points you'll see that demand uses t-shirt sizing and other methods really any of those methods would work but really you want to come up to say okay you know for each um for each release I know that I'm going to need you know 300 you know points or five large t-shirts in order to kind of implement that you want to be able to make sure that you can quantify that in terms of your road map so you can start to align what your uh align what your Staffing requirements are you want to build an sdlc process to support the demand from your road map as well as a recurring maintenance release so you want to understand what is a velocity that I need in order to maintain my current instance and maybe that velocity may be oh I need you know 20 points or 40 points a week in order to maintain my my current demand and I need an additional 200 points in order to hit hit the road map those are the types of things which you're trying to trying to align in terms of of your sdlc and the last thing on or excuse me the next thing which you want to do here is you want to budget according in alignment with both of these release types uh the third item here is identify the required Staffing roles so once you have your the understanding of your pro of your product road map and your sdlc process you need to figure out how many admins do you need how many developers how many business analysts do I need other roles like a configuration librarian uh in there in order to uh to to meet those needs and the fourth and last item here is to Source your staff using the Staffing options is now you have an idea in terms of how many of each different type of role well am I going to staff them all in house am I going to use manage services am I going to use Project based Consulting and this will actually all start to kind of come together and really kind of align up in terms of you know what your actual needs are so let's start taking a look at some of the uh Staffing models which are out there this first one which you see out here is what I call a baseline model uh this is one and a half full-time employees or FTE for a quick start implementation and this is really about maintaining uh and enhancing your current scope so if you think of a quick start it's usually you know incident change problem a little bit of service catalog and we're assuming that you're going to have a fairly fixed um sdlc velocity in terms of maintaining that so the idea here is that you're going to have at least you know one um um excuse me you're going to have two system administrators and in this case you know they're in-house this is probably the most basic uh Staffing model you see the idea here is that you're going to have 1.5 FTE in total so both of these individuals are probably going to be a uh a portion of of their time the second model is basically the the same model as your Baseline but it's augmented with managed services and this allows you to give you a little little bit more flexibility because you're using a third party you'll be able to able to ratchet up or down the level of system administration you need so this is still assuming that you're going to maintain your existing deployment scope but it allows you some flexibility in terms of U being able to add or you know remove um administrators um you know through your managed service provider the one of the advantages of using this model is that with most managed service providers you already get uh trained preferably certified resources who have access also to other specialized resources so you don't have to worry about maintaining uh your own administrators keeping them up to bit date making sure that they know the latest and the greatest they should already have all of their certifications as well as also have access to a pool of resources uh that they can rely on this next Staffing example is a in-house with augmented with a developer on demand or DOD the developer on demand or DOD Staffing model contains an element of In-House administrator augmented with the dod service that is really a pay as youo model um sometimes uh by the hour or by a bucket of hours this model gives you the most flexibility where you can build Dynamic adjust or you can dynamically adjust your velocity based on demand while the previous managed service model also has flexibility managed Services uh flexibility adjust typically on a contractual or annual basis while DOD can be adjusted um almost um dynamically on a month-to-month basis as with the managed service model this model also provides you with access to specialized resources as well as developers and architects who can uh provide for product planning uh this next model is an in-house model with your in-house developer so this model is more indicative an organization that has a very heavy heavy product road map it's a very aggressive road map this model has in-house uh administrator as well as multiple in-house developers this is a fairly common approach that I see among my customers the key in order to maintaining this particular model is to ensure that you have a sustained road map that justifies the headcount I seen in a lot of organizations which they'll say okay we're going to do phase one and phase two but we're going to between phase two and phase three we're going to take three months offs to have like a burn-in period and a lot of the times those Developers get allocated to other projects or in you know Other Extreme circumstances you know they may get you know bored and move on to other organizations so the idea is is that if you have in-house developers you want to make sure that you have sustained velocity to really to kind of keep them engaged throughout the duration of the entire road map this next uh Staffing model is really about a blend of In-House and the managed service so again this is for a heavy product Road map and I see this more commonly amongst organizations that have been using service now for year for years this model has an in-house administrator and manage service provider developers it has a minimal um in-house FTE investment and the manage service providers will provide you with some flexibility in terms of the number of developers however like the previous model you'll still need to justify the managed Service uh contract duration with the relatively sustained velocity for the duration of the contract so if you have a year contract you need to make sure that you're able to keep those Developers for the uh busy for the duration of the contract this last Model I want to talk about is about Project based Consulting and this is really about uh implementing your major road map items so typical road map items usually contain brand new or complex functionality that in-house staff may only have minimal exposure to or if it's new functionality they may not have any exposure to it at all project-based Consultants bring in experienced Specialists for the project to accelerate development cycles that are typically difficult to achieve by in-house or even managed service providers the key to a successful project-based consultants and the biggest risk is to ensure that development efforts performed by the project Consultants include good documentation this includes release notes training and knowledge transfer to in-house resources so in this particular example you'll see that while there's Project based Consultants there's still an element of In-House developers to uh per form the knowledge transfer to um so this next slide really talks about how we're going to be talking about retaining service now resources uh there is a three steps which we have here and really the first thing is is creating the right Staffing model to ensure that you have one efficient use of your budget an opt optimized mix of resources between administrators developers business analysts as well as a good mix in terms of what your service options are whether they're in-house man Services DOD and Project based Consulting you want to make sure that you minimize your over and underallocation of resources and that your resources stay engaged for the duration in which they're intended to you want to make sure that they they they don't remain idle and that they have an understanding of what the product road map items are and that they're preparing uh to to execute on those product road map items the Second Step here is you want to align staff with the road items to keep the re resource resources engaged so you want to make sure that if there are upcoming topics or up upcoming training that your staff will need you want to make sure that you're preparing for them uh ahead of time so by the time that that uh phase of the road map arises that they'll be prepared to execute that you want to make sure that the sdlc process is there to ensure that the development that you have efficient development and that it's optimized for the team velocity the last step here is you want want to keep your staff engaged so some of the recommendations we have to keep your staff engaged is to have them attend a regional snugs or service now user groups uh keep them active in the service now Community uh provide them with uh training opportunities service now has a number of training opportunities and changing topics a lot of them are are virtual so they can do that from their own desk uh participate in the knowledge conference as I mentioned previously the next one it will be in May next year in Las Vegas as well as uh participate and have them um involved in developing your product road map so they basically have input and they have understanding in terms of what's what's coming up in terms of the platform so in summary and conclusion building a staffing model is really about um creating or really building these three elements of uh the pro uh these three elements that you're seeing here the product road map the sdlc and Staffing for example example you might want to establish that your product road map requires a quarter release of 300 development points and you build an aligned sdlc process to support the quarter release plus a weekly maintenance release of 75 points taking into account the complete sdlc cycle the Staffing requirement could be that you need one and a half administrators and two developers any planned or unplanned changes to any one of these elements will have the direct impact on the other two so for example if one of your if one of your developers you know moves on to another project or to another group this is going to directly affect what your velocity is as well as your ability to execute on the road map and if that's going to remain permanent you need to make sure that you re you reset adjustments as well as republish your road map and adjust your sdlc that people have an understanding in terms of uh what your current capabilities are well that's it which I had today for the product mod road map or excuse me for the the um for the staffing uh thank you for everyone for attending this webinar I hope you found this information useful and I'd like to open up the floor back up to Pete so thanks Michael for that I think we've got a bunch of questions that came through um I think at this point given the velocity of questions we will most likely answer those directly to the folks who have reached out to us um just because there's so many questions that have been posed uh if you have other questions U Michael you want to advance the slide um to the next one here uh please reach out to this email address uh we will get your questions that way uh you can also reach out to me directly ppar ces.com uh I would like to just just Shameless plug around covestic we we are involved heavily with Project work as many many of you know we also have a virtual support service called developer on demand which can help augment uh your Staffing teams uh with a virtual support Subscription Service which is really per hours uh sort of a bucket of hours per month model more than happy to discuss that with you uh if you're interested in that um but uh at this stage we'll we'll uh conclude the webinar we thanks for your your time everyone for joining and please feel free to reach out for any other uh information you need from us