all right so i guess we'll go ahead and get started here welcome everyone and thank you for joining us today my name is jake ellsworth and i'm joined here by sean riley and carl hernandez who will be covering it consulting project pitfalls and how to ensure the perfect project so before i hand things over to shawn and carlo i just wanted to give a quick intro to covestick for those of you who may be new here clastic is a one-stop shop across the ite ecosystem from projects to development to operations and staffing since our founding in 2001 we have completed over 300 successful servicenow projects with 90 percent of our customers coming back for additional engagements as practitioners we implement run and offer a broad range of capabilities across it with our experience rooted in solving real world challenges and helping you perform at the speed of business all right so now that you know a little bit about kovestic i'll go ahead and hand things over to sean and carlo to introduce themselves and get into the good stuff well thank you very much jake hello everyone uh and welcome my name is sean riley i'm one of the senior engagement managers at colvestic i have been in it consulting for a little over 26 years i've spent the last two and a half years with covestick prior to that i've worked in large enterprise organizations doing everything from identity management i've got some experience with remedy and then early in my career i was focused on network operations centers network operating center and served in the united states military so with that said i'll hand the floor over to carlo hey thanks sean so hey everyone uh carlo hernandez is one of the engagement managers with classic i've been with povestic for about four years now but have been hemming servicenow projects for uh the better part of these i want to say eight to ten years um emming projects smaller projects from health assessments to integrations to larger scale multi-year program implementation so hopefully i can provide some insight into avoiding project pitfalls uh for you thank you carlo all right everyone so what we're going to do today for our agendas we're going to focus in on four key stages of a project writer or engaging in a project and we're going to start off talking about engaging a vendor all right so this is going to be all of those prerequisite things that you'll want to consider then we'll talk about the discovery and project scoping uh take a little bit of a dive into uh you know pre-sales how to best prepare how to set expectations and then we'll jump into project delivery um talk about some of those critical activities that take place then and then as with all prop projects we'll talk a little bit about change so let's jump into talking about engaging the vendors so this is how again how to best prepare prior to engaging your vendor first thing we always recommend is that you sit down as a business and you document your business case and what your expected outcomes are while doing this we just keep referring to this as your vision so really identify your goals and objectives define what deems the project of success socialize this with your various subject matter experts and key stakeholders and then put together a core team that will sit down and document your use cases one of the big value points of putting together those use cases is that they can be leveraged as part of your pre-sales cycle when you select your vendor as well as during the actual project delivery stage to help guide the team as to what it is you're doing how it needs to be done to actually be successful in your environment you'll want to take some time to research your vendor all right do they have recent experience in delivering uh the desired solution that you're seeking if they've previously been contracted by the organization find out what the experience was like you know were they a true partner or were they more of just a simple technical provider who provides folks that will take your direction and simply just develop based on what it is that you ask them to right are they thought leaders those are the types of things that you would want to be looking for make sure you understand your budget all right this is going to really drive what any vendor can truly deliver to you right and that will set expectations as far as overall scope one of the other things that we always want you to pay you know key attention to is committing staff to the project the organization must be committed to providing the resources needed to complete the overall engagement failure to do so will understaff the project it will certainly hurt you financially as well as your timeline and then finally one of the things that we talk about and recommend is considering training so regardless of what you're implementing within the servicenow ecosystem if there is foundational training available for it we always recommend that you take that this is going to serve you when you get into the workshops it can even assist you with finalizing your use cases all right these are the things that you'll want to do in preparation carla was there anything that you'd like to add in that or something that you've seen that you really want to call out yeah thanks sean uh so you know obviously everything that you've identified is is critical to the successful delivery of any project i think you kind of alluded to this a little bit uh but from my perspective i can tell you that's what's caused me the greatest number of headaches is the commitment to staffing the project as needed to achieve desired results um now obviously i realize we're all busy and as needed it's a relative term uh but once we have the project plan laid out and we know who we need to do what when it's important to have those resources available at those times i can't tell you how many times we've come to a particular phase in a project or sprint and we need to have a specific resource like a security admin or a network engineer and they're unavailable due to either conflicting projects or whatever other constraints but not having those resources when needed can bring a project to a screeching halt right obviously impacting your schedule and budget etc so ensuring that we have that commitment of those resources those teams those team members uh it's imperative to a successful project great call out sir all right so let's jump into discovery and project scoping so so far we've gone through we've put together what our vision is we've documented you know our business cases our outcomes we've worked with the various folks in the organization to make sure that we have a full understanding of what it is that needs to be delivered so now it's time to sit down uh with the vendor that you have selected and or if you're looking to do an rfp sitting down with several vendors so this is where all of that hard work is going to pay off so you're going to want to sit down with those folks and you're going to want to review that vision walk them through your use cases identify any challenges or constraints that you have so those types of items could be anything from key dates that you can't afford to miss uh there could be blackout periods there could be licensing impacts there could be several reasons as to why the timeline needs to be condensed or at some stage during the project there will be planned gaps these are things that you're going to want to share with the vendors so that they understand how the project will need to be resourced it will also help identify any particular risks early in the project phase to allow a proper mitigation strategy to be put in place you're also going to want to describe to those vendors what is the business trying to solve and why again tying that back to the vision this just allows us to go a level deeper and be open on the time and effort that your people can dedicate to the project as carlo just mentioned you know this is one of the huge pitfalls if you don't have the right players in place you end up repeating workshops having critical folks miss workshops therefore we have gaps in requirements and or folks that aren't fully familiar with what needs to be achieved or missing and now we're working and going down a path that really doesn't achieve the desired results now as you go through this process and you're conducting all of these discovery sessions with that vendor as they're trying to capture a statement of work one thing that i encourage you to do is don't assume that just because it was discussed that it's going to be included in the overall project all right as mentioned before budget is also one of those key items your budget may not allow for everything that's been discussed in that pre-sale cycle to be included within your statement of work and or there's the potential that it simply got missed all right so you're going to want to make sure review your statement of work closely and or proposal if you have any questions make sure that you reach back out to that vendor and say hey you know i don't see this particular item that we talked about is it covered is it included and have them show you where if for any reason you're not comfortable that the statement isn't clear then simply ask that vendor to place it in there and lastly at the end if it's a proposal and or that the sow comes into play and budget becomes an issue we highly recommend that you use a phased approach versus scaling back on required functionality and what we're talking about here is uh in some cases we'll go into an organization where they have purchased multiple modules process areas whatever terminology you would like to use to leverage within servicenow it is better to go ahead and focus on one or two of those areas and get them to a level of maturity that actually benefits the organization rather than trying to implement a little bit of everything across the board where it becomes a challenge for the organization so yes they can get some things done but it's painful right but they can do painful exercises across five process areas versus smooth efficient everyone loves it two process process areas go seamless the latter is where you want to go all right make sure that you focus in on required functionality and not necessarily just a breadth of development work all right so we've gone through our pre-sales cycle we've got our statement of work in place and now it's time for the where the rubber meets the road right this is the stage where it's time for us all to stay focused be open to new ideas and of course be transparent with everyone when we begin a new project uh at the beginning what we'd like to do is make sure that we get the project sponsor uh involved as they are the ones that set the tone all right we ask that that as they stay engaged that they revisit that vision often and one of the key reasons for that and areas that we can do this is right at the front end when we do the kickoff we have them go through and review what their vision is what the goals and objectives are and why we're doing that and most important what do they deem as a successful project you know those five to eight bullets that dictate hey if you achieve these things this project or program will be deemed a success that is what's most important to us as we go through the life cycle of development we'll have opportunities during sprints retrospectives and that type of thing for the the sponsor to come in and maybe reiterate and revisit uh that vision um and then there's there would be additional opportunities carl i know that when you and i spoke there's also some other areas in which you try to get the sponsor in fact and or other folks yeah yeah exactly exactly and i really like that you know revisiting the division often is listed so prominently here because i feel like it's an important component you know of any project that's often overlooked right and overlooked by way of either you know revisiting them infrequently you know to your point we mentioned it in the front end of the project at the kickoff but uh oftentimes i've seen it to kind of teeter out or or not revisit again until the end of the project before doing so in a silo right you mentioned that the project sponsor sets its own but i like to make sure that we have the full project team um involved in those views whatever we want to call revisiting uh meetings to make sure that we're all in agreement and hearing the same message at the same time good deal all right so moving on and another key aspect is failure to plan properly is a plan sorry excuse me failure to properly plan is a recipe for project failure so one of the first stages of planning is really to set up a solid rule rules uh for engagement you can think racy here really ultimately what we're looking for is who are those decision makers going to be all right who are the the folks that need to be consulted so those are going to be your subject matter experts and those people that need to be informed of what's going on all right so those are just some key aspects that we're looking for ensure that those people are made available again we get back to making sure uh that the appropriate people are assigned to the project and most importantly that their time has been committed when you're going through and and putting together your timeline we've got to make sure that it's realistic all right i can't tell you how many times we get into a situation where it could be the final quarter of the year so you know it's october is hit and a client may need to have the new solution put in place and operational by january 1. all right it was scoped from day one to be a 12-week project uh initially the plan was to maybe get that project started uh you know in september but for whatever reason some delays occurred it could be just getting contracts signed getting resources locked in whatever the case may be however if we start a project off in october we've already we've only got a limit of 12 weeks to get everything completed but as we all know when we talk about that time of year you've got thanksgiving you've got christmas you've got people both on the vendor side as well as on the client side that are taking pto this is going to include several key folks that must be present for us to be successful so you're going to lose anywhere from three to four weeks given that time of year which means now you're trying to condense 12 weeks worth of work down to eight weeks it's a recipe for disaster so what needs to happen is that a mitigation plan would need to be put in place and there's certain risks that would have to be accepted and or scale back again the scope of what's going to be done what gets you operational by january 1 or off that other software package as an example so that you don't incur additional fees uh and that way you can do all of the other additional enhancements into the new year so again it's just all about putting the strategy into place make sure that you understand and communicate other projects that may impact and or compete for resource time all right so i can't tell you how often you know we run into situations where we're just getting into a project maybe we're in our just starting our first or second sprint and then we receive a notification that hey by the way we're getting ready to do our upgrade next week you know this should have a been identified probably during the project or even during initial planning before we even kicked off the project the last thing that you want to do is do some type of major operation with servicenow or in the event that you have a competing project all right so you know maybe you're implementing some new platform that's going to leverage some of those same resources the determination needs to be made up front you know what are the priorities and or except the risk that the timeline of the of your servicenow implementation could be extended again i keep referring back to servicenow but this really applies to any project uh and lastly and i've alluded to this uh make sure that you have an agreed to mitigation strategy for all known project risks all right stick to the plan make sure that those are identified as early as possible so that there's just no surprises so we've gone through our initial planning and now we're ready to get into the true delivery phase where we're going to get into doing workshops and that type of thing so as we jump into this phase of the project the first thing that we're going to look for is to have process owners identified so these are the folks and or individual that will make key decisions each process each process should have its own owner the last thing that we like to see and it tends to cause confusion is when you're trying to make decisions by committee ultimately there should be one person that is responsible to make those decisions and sign off on those requirements key stakeholders and subject matter experts should participate as needed at the front end when we do our planning one of the things that we'll do is provide you a full agenda of the various workshops that will take place and who should be involved and we try to give you you know reasonable guidance as to when certain individuals will be needed all right to do our best so that again you're efficient uh with the use of the resources time as we're in these workshops we want you to ask questions all right two key reasons for projects to fail early on as you're in those workshops is if you simply allow your vendor to drive the conversation i.e they're just telling you what you need to build and you're just going along for the ride right in this case you're liable to have a solution that really doesn't meet your business needs because you've just trusted that whatever the vendor tells you uh is exactly what you need ask questions make sure that you understand what it is that they're proposing conversely if you have a vendor that allows you as the client to simply provide all of the requirements tell them how they want it done and they're not pushing back on certain things right throughout this this process there should be some give and take there should be you know i always say when i'm doing my kickoffs at some point we're going to bump heads right we're here and and what the value of a good vendor is is to provide that thought leadership they're there to tell you hey look that's a good idea it's a bad idea here's the reason why and then help align the implementation towards best practices right keep you away from those pitfalls if they simply do everything that you tell them to do i guarantee you that's a recipe for disaster as we capture these requirements we're going to want to make sure that they get prioritized all right so here at covestick we kind of like to put things in a few buckets and i'll give some definitions behind them so mvp this is what we call the minimal viable product not maximum but minimum all right these are the items that we're going to want to focus on that keeps the business running so you can think of this as a replacement for your as is state i.e how you do business today right we don't want to set you back next we have those critical items so these are the items that we need to focus on and that must be implemented in order to achieve our goals and objectives ie what is what deems the project a success all right now i've seen in so many cases that we gather requirements and they say well all of it's important all right well it all may be important but it's not all critical all right and if every requirement is critical then nothing is critical right there's got to be some type of priorities then beyond that we're going to get into items that are say a high priority these are things that you would really like to have and then moderate and low right low being those items that hey if we can get them done great the world's not going to come crashing down on us if it doesn't get done right when these requirements are captured and you're going to be expected to understand them as well as sign off on them uh the requirements that do get documented and shared with the team they should be well defined there should be a clear definition of what done is and what we mean here is the acceptance criteria that the work that has been delivered meets the business need requirements and proposed solutions should be based on required functionality and not the way it's currently done this is where we're asking you to be open to new ideas all right there's there's a bunch of different ways to skin the cat right but at the end of the day we've got the requirement and our goal is to meet that requirement in some cases it may in fact need to be done a certain way however what we ask is that you be open as to how we get there as long as we get there again what we're trying to do is make sure that we're keeping in mind best practices things that we've seen successful with other businesses requirements should focus on solving problems and improving efficiencies and not what ifs all right um recently had a situation in which we did a bunch of work um delivered it was sitting in production actually for a little over a month we were still engaged with the client we're still doing some work for them uh things are going great and then we got a phone call that said hey we've got a situation now where we've had one person submit something that caused a bit of a hiccup and so our you know our response was okay well let's take a look at it and as we started getting into the conversation the the stakeholder that was involved started spiraling and saying you know i can see this happening in the future and then i asked the question i said well how often is this has this happened in the past well this is the first time it happened but now that it's happened i can see that this could be reoccurring and we ended up spending several days going back and forth and then about a week later we all came to the conclusion that this really wasn't an issue all right so don't start circling the drain over what is focus in on that 80 20 rule all right so you know let's make sure that the 20 percent of our effort is or 20 of our effort really focuses in on 80 of what the business needs all of the rest of our efforts should be focused in on improving efficiency enhancements things of that nature not focused in on what ifs you know these things that happen once a month once a quarter biannually or annually right can we provide a workaround these are all the types of things that you should be considering before approving heavy development work for something that just may or may not happen so we've gotten into our project uh we're delivering against it we're going through our sprint cycles uh and as always change is inevitable all right this is where more than ever we need to make sure that we stay focused on what our end goals are that we don't start circling that drain so all requests for changes as they come in they should be evaluated by the core project team all right and simply just because we can do something doesn't mean that we should all right the first things that we should be asking ourselves or some of those key questions is you know does it align with our overall vision right and if the answer is no it should probably simply just go into our backlog does it provide benefit to the organization now the answer is in many cases some of these changes indeed add benefits that's why they were brought up to the team however is is the cost of adding this new functionality or making this change um does that level of work and financial cost outweigh or does the benefit outweigh those costs i should say excuse me so those are questions that we'll be asking ourselves uh and then is the change based on me or simply a cool feature or discovered capability we see this all the time they've gone through into you know some user group or something like that uh they see a new capability or maybe even as part of what our one of our reviews a developer said hey you know by the way one of the things you may want to consider in the future is to do x and someone says that's a great idea i've got to have it no you don't right it's one of those things it's cool to have it wasn't part of our original set of requirements so the reality is in most cases it should probably go to the backlog but again that's why we have that core team together to evaluate determine level of effort and see how it fits into the overall picture so with that said uh not all changes are necessarily bad right but we want to make sure that we do avoid a few core things one seeking perfection right as you go through into it in a project projects are designed to package a release that can be delivered to the organization that they can use operationally right i would like to think and i know everyone wants an end solution that absolutely runs with perfection there's no problems there's no issues and it solves world hunger right and no one's going to need any other changes to it you know that's nirvana never going to happen so we like to save those components for continuous improvement right so sit down think about what those items are but again stay focused on what was our goals at the beginning of the project if we've addressed them everything else goes to the backlog until after we get operational getting back to those new must-haves right a lot of these tend to be because they found out some new capability right just because i can lock down a field or just because i can automate something or what have you right it doesn't matter does it mean it needs to be done today it didn't need to be done six months ago it does not need to be done today that should go to your backlogs lastly and this is probably the biggest one that affects all projects and it just tends to creep its way in all right and this is those those minor enhancements that are very small in nature uh you'll hear people talk about low-hanging fruit and terms like that these are easy right they're they're the type of requirements and enhancements that people present that a developer will say it'll take me longer to document it than it will to develop right that's it at face value the reality is most requirements regardless of how simple they are a can never be implemented in production and or should not be implemented in production that means it has to go through the full life cycle right we want to have it validated that yes this is indeed supposed to be implemented number one two we want to make sure that it's signed off and agreed to we need to make sure that it doesn't impact anything else and then it's got to go through testing and then it's got to be moved to prod documentation could potentially need to be updated so all of this does indeed take more time but more importantly as you start to get several of these all right i refer to this as a death by a thousand cuts individually no harm no foul but once you start to bring them all together there is a huge impact to the timeline there could be impacts to resources who now have to be made available to return back to the project whether it be for testing evacuation what have you and then there's just the timeline that could be impacted or the overall cost because the project now has run over because of these small items and then because they weren't considered as a release two where we're you know considering how all of these various fixes can impact the work that's already done in some cases there is the ability to break things carlo i'm gonna ask you sir to jump in because i know that you've had you know you you've probably encountered several things within this area that you've seen cause just you know having as you get into a project yeah absolutely thanks sean so i mean just quickly i mean you know i really want to emphasize the seeking perfection piece right i mean you mentioned in your other slide about mvp and it's not uncommon that as we go through the project and the day-to-day activities to deliver a project we may lose sight of what the m stands for right it's not maximum right to sean's point earlier you know what can we deliver for this initial release so that we can get it out to our users uh to begin using uh you know finally once this releases in a while and we can begin tackling some of those enhancements but if we you know try to bait every single requirement in you know death by a thousand cuts and as they come up that finish line gets further and further away and then you know we run the risk and it's an extreme risk of that but you know we do run the risk of it potentially never getting released so something to be mindful of thank you sir great input all right folks so look this is really you know again at a high level those items that we wanted to cover with you uh we would love the opportunity to work with you so if you're interested make sure that you reach out to kovestic we've got our contact information here and jake