Share this webinar
Have you been told by your ITSM tool vendor “Don’t worry, it works out of the box.” or “No problem, we can stand it up in a week.” Has your boss said to you “Why do you need so much time to develop a process, it’s SaaS – just turn it on!” I can’t tell you how many times I’ve talked to people who were disappointed with a tool implementation project. Over the years, and with every generation of ITSM tools, I’ve heard the same thing. “It works out of the box on day 1!” When it doesn’t work, it’s the tool that gets the blame – and people switch to a new one – costing time and money.
Giovanni: Hello, everyone and welcome to today’s webinar, part of the 2012 webinar series. Today we’ll be focusing on the seven steps to a successful ITSM tool implementation. This presentation will be up on SlideShare so just go there and search for ‘go Navvia.
Today’s hosts are David Mainville; he is the CEO and cofounder of Navvia, and myself, Giovanni Flores, the marketing coordinator. Before we get into the presentation itself, I just want to make sure that we all have an understanding of how you can interact with David and myself. When you logged in, you noticed that a pop up control panel showed up on your screen. At the very bottom, there’s a chat panel and that’s the way that we encourage all of our attendees to the webinars to interact with us, so if at any point in time you have a question or a comment or concern, please feel free to type it in. I will make sure to keep an eye open and when your questions or comment pops up, I will make sure David addresses it live on the air.
Just to make sure that everybody has an understanding of how to use the control panel, if you can type in your name and the city that you’re dialing from; this way I’ll know that you can hear me clearly and everyone has an understanding of how to use the chat panel. If you can do that now, please.
I see Van from Dallas, I see Bob from Georgia, Diane from Calgary, Brent from Indi, Tony from Toronto, Andre from waterloo, Pam from Ohio, Becca from Utah, David from Pennsylvania, Washington. Great. Looks like everybody has an understanding how to use the chat panel. If at any point in time you have a question or comment, please feel free to type it in. I’ll be monitoring for your questions and comments and David will address them live on the air.
Without further ado, I’m going to pass it on over to David Mainville. David, if you could please take it away?
David: Thank you Giovanni and welcome everyone to today’s webinar. I’m just going to go through a couple of introductory slides for those of you who are not quite familiar with our company.
We’re Navvia and we’ve been in business for 14 years now. Navvia is a division of consulting-portal. For those of you who have known us as consulting-portal, some of you might be asking ‘why did we change our name?’ There are a couple of reasons why we decided to do that. Over the years, we were originally known as consulting-portal and we bought a product to the market called IT Optimizer. We believed it created some brand confusion in the marketplace. In addition we were looking to take our business process management tool kit and roll it out into more of a business environment in addition to the IT service management space, and we didn’t think that a name like IT Optimizer was really applicable for that. We scratched our heads and we worked with some very creative folks and we came up with a name Navvia. We really think it communicates who we are and what we’re trying to do.
Navvia is about helping organizations navigate through IT and business process complexity via our tools and our services. That’s why we changed the name. We’re the same old company, we’re been here for 14 years providing work in the IT service management space but we’re looking to branch out and to reach into new areas, still working heavily in IT service management but also helping to help the business said of the organization with their process requirements.
Just to talk a little bit about the Navvia platform, the Navvia platform is a business process management tool kit and it has four modules in it. It has a module that allows you to survey the maturity of your processes. That’s a great way of getting a good understanding of your current baseline maturity because if you’re going to make improvements to a process, it’s really important to understand where you are today. Then we have a design module, and the benefit of the design module is through a really simple lightweight interface; you can define and document your process either based on the templates that we provided, or by creating one from scratch. Then at the push of a button, you can create all of your Word documentation, your RACI charts, your Visio swim lane diagrams, all interconnected and all supported from our data model within the design tool. It makes the maintenance of your processes that much easier.
We also have a verify tool, which really takes the complexity out of governing your processes. With the verify tool, you can assign tasks to people within your organization and these tasks are typically compliance tasks; show me evidence of a procedure, show me evidence that certain activity in the process is taking place. These can be bought back and mapped on a dashboard so people can be held accountable for the operation of the process. We use templates based on Cobit so if you’re an organization who goes through audits, this really automates the whole audit process, the collection of information, the remediation of any defects that you found doing the audit. The verify tool is very powerful and comprehensive in that regard.
We also have something the learn module, and in the learn module, you get access to a whole curriculum of IT service management training. This training is provided at no additional charge on top of the other modules, on top of the product subscription price and you can get access to ITIL foundation’s training, training on how to design processes, training on how to implement governance in your organization and much more. There’s no limit to the amount of training or the number of people who can take these courses within the tool. If any was interested in getting a test drive of the Navvia product, go to Navvia.com/tools/test-drive and sign up. We’d be happy to provision it for you.
We’re going to get into today’s presentation, and today’s presentation is really something that I’ve been passionate about for many years; it’s about implementation of IT service management tools. For those of you who don’t know me, I’ve been in the service management space for 32 years now, and I’ve gone through many process and tool implementations; as a matter of fact, I’ve been in companies who have gone through three or four tools because they always seem to blame the tool when the implementation doesn’t go well. You know what I’ve learned from my years in the industry? It’s seldom the tool that’s the problem.
People often do not take the time to sit down and understand what it is they’re trying to accomplish and set out a plan to do that in a very reasonable and systematic way and instead they try to slam the tool in and it never really works that way.
I want to try and keep this presentation as interact as we can. It’s difficult to do in a webinar type format, but I’m going to ask you folks why do you think ITSM tool projects fail? First of all, if you don’t think they do, I’d be happy to hear that as well, but for those of you out there who have been involved in ITSM tool projects, what do you think some of the key reasons are for these projects failing? If you have a moment, just type in a couple of those reasons into the chat pane and I’ll repeat them out on the air.
Here’s one from Elaine, ‘it’s difficult to get consensus across the organization.’ That’s a great one and that’s something that we see a lot. Lack of management support, that is something that even recently we’re seeing more off, where management has a perspective of how these tool implementations should go and are basically dictating how the implementation should go as opposed to listening to their people and understanding what the stakeholders really require. Speaking of stakeholders, Scott says ‘wrong stakeholders involved,’ and we’re going to talk a little bit about that in today’s presentation. The lack of a definition of a service, says Pamela. Lack of process compliance, says John. Lack of definition of rules. Deadlines. Jeanette is saying ‘the old tool has to get out, maybe it’s coming to end of life, maybe the maintenance agreement is coming to the end, and it has to get out the door so the new tool is rushed in.’ Lack of executive buy ins, says Becca. I like this one, Patrick; ‘stupid people.’ You can look at it that way, sometimes it’s just a lack of education or a lack of knowledge on how to do it right. Requirements not finalized before the tool selection, there’s a great one from Jennifer. Because the process as an organization are designed around the tool. Bob, that is something that I am really passionate about myself. There’s no such thing as an out of the box tool and you cannot just put a tool in and expect the organization to follow what’s in the tool. That’s a great one. Cathy says ‘if not planned well, it drags out, people loses interest.’ Slobodan says ‘no connection among the three key components, people, process and technology.’ Not enough staff to properly implement the tools says Becca. Lack of training in executive sports says Patrick. William says ‘companies put tool selection before they know what they want to do, and they get caught up in the bells and whistles of the technology.’ Users not included in the definition and selection; Bob, that was an excellent one. Fear of change says Loretta. Don’t allow the appropriate time to implement says Brian, and Chris says ‘organizations try to make the tool fit their process.’
I think we can call this webinar a wrap here today because I think everybody does get a good anvil on it, but we’re going to push through and I’m going to talk about some of the ones I think are key, that I’m seeing, and I have an interesting vantage point. Because of our organization, we are a software and services company, I do get to go into a lot of different companies and because of that, I get to see what’s happening across a board of landscape.
One of the biggest things that we’re fighting these days as an organization passionate about process is vendors. They say there’s no need for it. It’s out of the box. Implement out of the box. As a matter of fact, I’ll tell you a little story. In a very large global organization, we had a vendor, you’d all know who it was if I were to mention the name. Basically going in and saying ‘you don’t need to implement a global instance of the tool, just put it in this silo and then we’ll deal with that, then we’ll go work with the other people separately.’ What they were actually proposing was something that probably made a lot of sense for the vendor; they were going to get something installed fast and they were going to get a foothold and some could argue a quick win, but on the other hand, this organization was global and had required global visibility in the changes. They required global visibility into incidents and if they were to follow that advice, would have ended up with a big mess to clean up after the fact.
The next one here is something that was mentioned; consensus. It takes too long. It’s hard work. It does require a certain amount of consensus and it is hard work, but nothing worth doing isn’t often hard. I think there are ways to mitigate the amount of time it takes and the ways to build consensus. We’re going to talk a little bit later in the presentation about how you balance consensus with getting things done.
One of the other big reasons we see tools fail is because of the lift and shift approach. This often happens, and I think someone mentioned in the introductory session here, about we got to get it in because the old tool’s getting retired. They do a lift and shift and we hear comments coming back when that occurs, like ‘what value are we getting out of this new tool’; it’s just the same as the old one. We still got the same problems and the folks who spent time and energy getting involved with this new implementation see absolutely no benefit from the implementation of the new tool and they blame the tool for that; they don’t blame the project, they don’t blame the lack of planning, they don’t look at why they’re not seeing a benefit. All they can see is ‘we’re not seeing a benefit.’
There’s a lot of talk in the industry today about processes and why projects that focus on process has failed; I’m always dismayed by that because we in IT are here to support the automation of processes for the business. If we’re in a bank, you better believe there are processes where applying for a mortgage or different loan processes, organizations are very process eccentric and we use IT to support it, but why is it that we in IT can’t seem to get our act together around putting our own processes in place?
The other two points relate to management and I’ll tell an interesting story about that last bullet. Sometimes management will say ‘six months? No, just get that thing in, we need to see immediately benefit from it.’ You can’t see benefit from something if you don’t plan for it properly.
The last one, there was interesting feedback from a very senior individual in an organization, an executive level, when their staff went to them and said ‘we need to define our service request flows,’ they said ‘why do you need to define it? Didn’t we buy a SasS product to eliminate that? It’s SasS; just turn it on,’ not realizing that one person’s approval flow is different than another company’s approval flow. There are a lot of different reasons why these process initiatives or tool implementation initiatives fail. I think there’s really seven things you got to do to get your tool implementation right, and no surprise here, most of it has nothing to do with the technology.
The first thing you really want to do is identify the gaps because you’re there to improve something. There could be some situations where it’s a purely financial move but for the most part, what I’ve seen in my experience is most people are moving to a new tool because they want to make things better. The first thing you have to do is figure out what’s wrong with the situation today.
The other thing is people often, especially in those initiatives, get bogged down in process. They try to start from scratch and get consensus from everybody. What that really does is it slows things down and that’s one of the main reasons there’s a push against doing a lot of process work. I say don’t start from scratch. There are great templates out there, there’s a great starting point and why don’t you start from that perspective.
This came up a number of times during our little introduction. Another thing is don’t try this on your own. This is all about understanding people’s requirements. Understanding the stakeholders; getting the right stakeholders involved. Trying to do process on your own; that’ll just kill the adoption. As a matter of fact, I did a presentation at an ITSM event a couple years ago and a person came up to me afterwards said ‘thanks for the presentation, I just want to pick your brain about some things, and I’m really struggling with getting folks to adopt the process I’ve built.’ I said ‘tell me more.’ He says ‘I got the mandate to build the incident management process, I work from home four days a week and I build the process, I got it all nicely documented, I got it all packaged up and I emailed it out to everybody and I said this is the project so you got to follow it.’
First mistake is not a single person had an input to that process. You can’t just drop a process via email onto somebody and have it done. I was actually at the Pink Executive seminar in June or July of this year in Scottsdale, AZ, and I was a part of a panel where we were talking about a similar concept, and one of the panelists actually admitted to the fact that their first process initiative, their first tool initiative was all done in isolation. They did a great job from their perspective, had great documentation, they had a great plan, and not a single person in the organization was involved, and the thing feel flat on its face.
The fourth requirement is really the one that for the most part ties back to the technology, and that’s ‘don’t be a technophobe.’ Make sure you capture the right requirements. You can’t implement this stuff out of the box. What do I mean by technophobe? There is a certain group of people that stay too focused on the process side without extending out to how does this abstract concept called a process need to be implemented in a piece of technology? You need to get down to the tool and the data requirements to automate that process, and if you don’t go that far, what’s going to end up happening is whoever’s implementing your tool for you is going to make those decisions. If it’s the vendor that’s helping you or a third party or a consulting company, if you don’t give them good technical requirements, don’t be surprised that the implementation you get back is not the one you want.
Validation. Point number 5; don’t forget to validate. This really helps with buy in. Validation is really important to make sure you’re on the right path and also make sure you’ve got people’s support along the way.
Education is point six. Education is critical because I think if people are not trained in how to do something, how can you expect them to do it? With training comes knowledge and in comes the capability from them to make the best use of the technology.
Another story I heard, I actually had someone say to us when we scoped in some education as part of a tool implementation and I was told ‘we don’t need education, we got real smart people here, and they’ll just figure it out.’ You know what happens in a situation like that? They figure it out but everybody figures it out a different way. There’s no process, there’s no consensus, and there’s no one way of doing it.
Last but not least, its governance. A process that’s left on its own with no accountability, no oversight is going to die, and that is a fact. We’ll talk a little bit about that more when we get into the meat of the presentation. Before I do that, I think we have a question that came in.
Bob is asking me ‘how do you validate?’ That’s a great question, Bob, and I’m actually going to go through these points in a little bit more detail, so hold your question and if I don’t answer it as I get through the slides, I’d be happy to come back to that specific question. Thanks for that, Bob.
Let’s talk about identifying the gaps. As I said, you’re probably implementing the tool for a variety of reasons. You need to know what those reasons are. Are you doing it to improve a process? Are you doing it to automate? Are you doing it to get more self service capability? Are you trying to go a little more social in terms of the way you interact with your users, your colleagues and the other people in the organization? There are reasons that you want to implement the tool and those reasons have to be clearly understood before you start the implementation because those are the requirements that you have to fulfill. Understanding the gaps, why you’re implementing a new tool, is very important.
One of the other things you really need to do is also finding out the pain points. It’s interesting because you’d be surprised how many people are involved in a new tool implementation and have taken the time to sit down to see what broken in the current tool implementation. Is it too cumbersome to into a change request? Are there too many steps? Is it impossible to link an incident to a change? These are things you have to understand? What are the frustrations that people are seeing in the current implementation? If you want it to be a successful project and if you want to get people on your side saying this is great, you got to solve their problems, and that starts with understanding what some of the pain points are.
Are there certain capability gaps that you’re trying to close? Maybe you’re moving from a very PC eccentric system, you want to provide more mobility, perhaps you want to provide more social interaction, perhaps you want to provide a self service capability; are there capability gaps that you’re trying to close? What are those gaps? What are the priorities and how do we ensure that those gaps get implemented in a proper time frame?
Last but not least, do you understand the user’s point of view? I’m going to talk about this a little bit more further in the presentation, but everybody has their own perspective on things. We’re not all cut from the same dye; we’re individuals, we all have our own requirements, we all see things from our own lenses. For example, how an executive sees the requirements for a new system are very much definitely then how a manager would see them or how a technician who uses the system would see them. Again, when you’re communicating value proposition and when you’re talking to people about the value of implementing a new tool, you got to do it from the perspective. Do you understand your user’s point of view?
There’s different ways you can do this and there’s a lot of different techniques but the point I’m really trying to make is you have to do it. If you don’t spend a little bit of time up front, understanding what the gaps are, you really run the risk of not implementing something that’s going to resonating with your user community. You might want to use a couple of different techniques to do that, you might want to start with some questionnaires, you might want to survey folks, whether you’re using Survey Monkey or whether you’re using any of the different tools that are out there; a way of going out and asking folks what’s working and what’s not working. What are some of your key pain points?
You can also do that through interviews and the different between interviews and questionnaires, and both are very important, interviews allow you to really sit down and look somebody in the eye and have a dialogue. Questionnaires and pretty much one way; people will respond to the questionnaires. Questionnaires are great to go broad, but to go deep you really need to have the interviews. Sitting down and asking people, how do you use the tool today, how do you want to use the tool tomorrow, what are some of the things that really frustrate you with the current environment. You can also do that through some workshops as well, so you can have individual interviews or group work interviews through workshops. The last point, and it really shocks me how many people start on a new initiative whether that’s a process design or a process design with a tool implementation without sitting down to see how people do the work today.
I’ll give you an example of that. I was doing some work for a manufacturing company out in the Midwest and one of the interesting things we learned by sitting down at the service desk was that they had a very quick way of closing tickets. As a matter of fact, they had this one button close so that if something came in, they were able to close it out almost immediately. With a little bit more digging, we began to learn that they were being measured on not resolving incidents but closing incidents, and they have put a whole bunch effort and work and automation around closing something out very little around actually solving or getting information back into the knowledge base, etc, and you never would have learned that unless you sat down and actually communicated and talked with people. From all of this information, the questionnaires, the interviews, the workshops, the observations, it can allow you to put together a tool strategy and an implementation plan to help you address the gaps that you found as part of this exercise. You can look at it from a current and future state perspective as well. I’m a huge believer in quick wins, but quick wins doesn’t mean slapping something in. A quick win might be getting the highest used service request automated and up on a self service portal. That still requires planning, you still have to figure out what the request looks like with the flows, what the approvals look like, but just getting something like the HR boarding process or maybe acquisition of a piece of technology, up and working quickly can be a quick win without doing everything in your service catalog, but that doesn’t mean you don’t have to plan for it.
Also the road map can help you take an iterative approach and understand how you want to enhance the processes, maybe there’s a phase one or two or three; how you’re going to deal with that from a technology perspective, are you going to have a version one or two or three of the ITSM tool; how are you going to deal with things from an organizational change perspective; how are you going to keep people engaged; how are you going to make sure people are educated; how are you going to communicate the value of this ITSM tool implementation. Through this gap analysis, you can map out a plan from the current state to the future state. For those managers and executives who want to see something quick, focus on the quick wins, but make sure you communicate the value proposition back to them as to why you have to spend time analyzing and doing it right. You measure twice and cut once. It’s a lot harder to slap a tool in and try to mop up the mess later than it is to do it right.
There’s also this whole concept of not starting from scratch. I’m not an ITIL bigot; ITIL’s an okay framework, but it’s a framework. It’s a body of knowledge, it’s some best practice, and it’s not the bible by any stretch of the imagination. I think a lot of organizations, especially those who have been around doing IT, people in financial services have been doing IT for years. There is stuff that you’re doing in your organization today that works really well. Do you understand what that is? Have you taken a look at what the big process is in the organization? Are there different processes in different areas of your company? Do the guys in network services maybe do it a little bit better than the folks who deploy the servers? Can you leverage best practices even from with your own organization? Are there templates or standards you can leverage? Of course there are things like ITIL and a lot of the vendors will say ‘our tool is ITIL compliant,’ but I’m going to tell you something; there’s no such thing as ITIL compliancy. There’s no body that says that this tool is ITIL complaint and ITIL by its own nature cannot be implemented. It’s a body of knowledge, best practice, the implementation is going to vary from organization to organization. Take those templates but understand you have to make them your own.
There are other things you might be able to leverage. Perhaps your organization is big on ISO. Maybe you’ve gone through ISO 9000 certification or ISO27001. Maybe your organization looks at those things as being very important so can you tie your ITSM tool implementation and your process implementation into that program? Does your company follow Six Sigma? Is that important in your company? There’s other programs that there might be allies out there in your own organization that you can work with and build an alliance with it and help get this tool implementation done correctly.
One thing I want to caution you though is best practices, by their very nature, are accent of your company’s organization, business, cultural and technology requirements. Pull out the ITIL books, they’re not going to talk about tools specifically, they’re not going to mention service now, they’re not going to mention Sharewell, they’re not going to mention VMC remedy; they’re going to talk about a generic ITSM tool and they’re not going to really talk about your culture. This is another cautionary point. A lot of people want to organize around ITIL. I’m not sure that makes a whole lot of sense. I think you should organize as appropriate for your organization. Organizing around ITIL? You have to look at your own culture, your own environment, to make sure that it makes sense for your company.
Also, best practices know nothing about your business. The ITIL books were written for everybody; financial services, healthcare, manufacturing, retail. There’s nothing in those books that are specific to your organization so don’t expect there to be. You have to bring that back in, same with how you’re organized. To realize the full benefit of any template or any best practice, you have to reintroduce you own reality back into it, and that’s why a tool can’t be implemented out of the box because is your company out of the box? There’s no way any tool, unless you’ve forced people to adopt what’s in the tool, which never works, there’s no way a vendor is going to know how things work in your organization. In some organizations, standard changes that don’t require or have approval, they’re a matter of fact. In other organizations, that will never fly. Every company is different; you’ve got to inject your own reality back into the templates and the standards.
The next point is not trying it on your own. Processes built in a vacuum or in isolation will never get adoption. People want to know why. People need to understand why am I doing this, how is this going to help me, why is it important for what I do. People want to feel like they’ve contributed, that they had a say. Understand you have to really balance consensus with getting things done, but you also have to reach out broad enough to make sure you’re not going to get people acting passive aggressively and saying ‘I support what you do,’ and then when you implement saying ‘I didn’t approve that.’ You have to really balance this whole thing about consensus because consensus will drag you down. You can’t spend six months doing this. But there is a way of balancing consensus and actually getting things done by understanding how you should structure your program.
The other thing you need to really understand as well is your stakeholder’s requirements. You need to know what the pain points are. You need to understand what’s driving them and what’s going to make thing better for them because if you understand those requirements, you might be able to actually make things better for people.
One of the most important things of any service management implementation is understanding your stakeholders, doing a stakeholder analysis, and looking at it from the perspective of what’s in it for me, because everyone out there is saying ‘I’m really busy, I got a lot on my plate, I got a thousand things to do, why should I embrace your vision or why should I get involved in your change, what’s in it for me.’ One of the things that I want to emphasis, and sometimes as technologists, we seem to forget this, we look at things maybe through the lenses of being IT people being technologists, but everybody has their own perspective.
The CEO of the company, from their perspective, just think that IT should work. They’ve got a business to run, they got services to deliver and they’re not really overly concerned how IT gets it done; they just want IT to get it done. The CIO is more concerned about alignment. They want to understand the value proposition of this new ITSM tool implementation and to demonstrate that it’s aligned to the business objectives. But to do that, you have to make sure it is aligned to the business objectives.
The IT managers are caught in the middle. They’re getting pressure from the executive management, they’re trying to run an organization, their costs are being cut, so they got to understand, ‘I don’t have people, I can’t find any new projects, I can’t spend more time on this, I can’t allocate resources.’ Their perspective needs to be understood because you need to be able to communicate back to them in a language they understand why this project is going to help them with their own set of issues.
Of course there’s the technical staff. Those users just don’t understand ‘I’m running around, I’m trying to get things fixed’; they need to be communicated in the way that resonates with them. For example, do you know it will free up more of your time? Do you know that perhaps you won’t have to address the same issue over and over again? There are a lot of reasons why a successful ITSM tool implementation would satisfy the requirements of not only the technical staff, but everyone in the organization. But remember, everyone’s perspective is different and the value proposition is different, and maybe the reason we can’t get executive management buy in for this is because we haven’t done a good enough good communicating in their terms why it’s important.
When you’re doing a service management implementation and you’re trying to balance this consensus of getting things done, how do you go about and do that? I think it’s by creating these levels of involvement. It starts with a core team, and the core team starts at the very beginning when the gaps are being understood and is right there in the very end when training is being rolled out and the tool is being rolled out. That core team should consist of some folks who have a technical appreciation of the ITSM tool, some people who have a process appreciation of what needs to be automated and implemented, and some folks who can really communicate things in the language of the business. The core team are the ones who are going to get things done, but they can’t do it all on their own.
The next level of engagement, and if you look at how these circles work, the closer you are to the center, the more time you spend on this program. The further you are out in these rings, the less actual day to day involvement you have, but perhaps more importantly you have to get buy in support and guidance from these individuals. The core team is very busy but then they can tap onto the shoulders of subject matter expert, like how do we integrate these service management tools with active directory? How do we get the SasS application installed through our firewall, etc. The subject matter experts need to be identified and drive [speaker cuts off 0:35:58-0:36:12] when the stakeholders are critical in that they have a stake in this game.
The stakeholders are critical because it’s those requirements that you’re trying to satisfy. Stakeholders need to be kept in the loop at all stages, and stakeholders have to provide resources to you. Stakeholders will allow their people to come to your sessions, will allow people to come to your meetings, will allow you to interview their people, but you also have to communicate back to the stakeholders that here’s why we’re doing it, here’s how it’s going to benefit you and also get their buy off and approval. And then of course there could be a steering committee at the very highest levels from an executive perspective that just ensures there is an executive oversight and that you keep them in the loop as well.
Who needs to be involved? I think at the core maybe five, six or seven people maximum. You start getting beyond those numbers, it’s really too much of a team, and are they 100% full time committed? No, but is it their most important project? Yes, and they may be full time committed; that all depends on the organization. For the core team, it needs to be their number one priority.
The subject matter experts will be bought in maybe 15% or 20% of the time just to provide expertise and guidance. The stakeholders, even less; they’re involved in kickoff meetings, in updates, show and tell sessions where you’re showing the progress that you’re making within particular technology, they’re there for sign offs, and then the steering committee even less. You don’t have to boil ocean here, you don’t have get everyone in a room; you need to just basically understand the different levels of engagement and identifying the right people and making sure you’re having the right mix when you have an ITSM tool implementation.
The other one that really to me has caused a lot of ITSM tool failures is poor requirements definition, and I know that came up a number of times during the initial introduction to the presentation when I asked you folks what was wrong with most ITSM tool implementations. What I’ve seen in many cases, especially if someone is taking a very ITIL eccentric approach, they almost are proud of the fact that they don’t touch the tool; ‘ITIL says and this is the way it needs to be.’ What they seldom realize is giving somebody a Visio flow chart that says ‘open an incident,’ verify the user’s information, escalate as appropriate, is not enough requirements to actually implement this process in a tool. When you say verify the user’s information, what pieces of information are you trying to verify? Is it the name? The physical location in the organization? The person’s employee ID? How are you going to pull in this information? Is there integration with active directory? When you’re asked a question of what service is down, are these services going to be populated? Is there a category tree that’s going to help you define category, type and item? All of these things require implementation work and what I’ve seen so many times in process and tool implementation is the process people define it at such a high level then turn it over to the vendor to implement and the vendor really wasn’t part of any of your process design sessions and really decides to implement it exactly like they implemented their last project, which probably isn’t what you’re trying to do.
I have a question before I move on the core team. ‘That core team description was great, can we hear it again?’ This is all being recorded and this entire presentation’s being recorded, it’s going to be placed up on our website and it’ll be available for you to listen over and over again. If you want to reach out to me, we do have some slides I think within the organization that talks about the core team and I’d be happy to share those with you if you want to reach out to me personally. Thank you for the question.
Don’t be that technophobe. Out of the box will seldom work and there’s a whole bunch of reasons. You bring up the new tool and either the screen is overly complex with a billion fields on it or its super light with not enough information. It doesn’t mean the two can’t be configured or tailored to take some of those fields off or to add some more fields in; most of the modern technology today is extremely powerful and capable of being tailored easily, but the chances of it looking like you want it to look out of the box is very slim. The dropdowns and the values; the chance it’s going to meet your organizational requirements are very slim. It’s very important to understand when you start that out of the box doesn’t work and this has to be a message you have to keep hammering home back to your executives. Executive who come back to you and say ‘let’s SasS, it just works,’ you have to be careful when you’re selling the value proposition of your tool that you don’t oversell the out of the box nature because the minute you start selling that as an advantage of the tool, you’re setting yourself up for failure.
The next thing you’re going to do is map your business your business outcomes to tool and data requirements. I’m going to talk a little bit more about that on a follow on slide. Business outcomes are what it’s about. To the CEO, they want to be the first person to market with that new iPad application to support whatever business function it is. That’s what they want to be; they want a time to market, they want services implemented quickly, they want the ability to expand and grow market share. Business outcomes are what we in IT are here to support and you should be able to map your business outcomes down to your tool requirements. You need to be able to demonstrate to the executive that we will be faster, better, cheaper at doing those things because of the implementation of this tool, not because we have a CMDB or not because we have automated application discovery or we defined 52 attributes of a CI; that’s going to make people’s eyes roll because it’s not communicated in a language that’s going to resonate with the senior executives and that’s probably one of the reasons they push back so much because they don’t really understand the technology and the processes at the level we do. That’s really important. The processes and the technology is critical. That’s how you get things done, but they’re more interesting in why things need to be done.
From a technophobia perspective, make sure you understand what fields and mandatory, which are auto populated, which are audited in the system, and that’s not going to happen out of the box. What you should do is when you define your process and then you define your activities and your tasks, at task level, say ‘what’s the data I want, what trigger is going to move me from this task to that task.’ You got to figure all that out and make sure you’re capturing the right data to produce not only to automate the tool but capturing the right data to produce the metrics you want. You’re never going to be able to calculate mean time between service resumption if you don’t capture when it went down and when it came back up. Don’t assume that that’s all going to be there out of the box. That’s a simplistic example but there are a lot of examples of people who implemented the tool and then have to go back and manually create reports because they haven’t captured the data they need to support the metrics they want to show their management. Don’t be a technophobe. Get some people on your team who understand the tool and the technology, but also have some people on your team who’ll understand the business outcomes, get them talking and make sure what you’re implementing in the tool is exactly what you want and can give you the data and provide you with the supporting evidence that you need to demonstrate to management that you’ve done the right thing.
It has to start with business outcomes. You need to be able to tie your ITSM program, your tool implementation, to a business outcome. Boss, we’re going to be able to do things faster because of the service request process, servers are going to be implemented in one third of the time and the fact that we can do servers in one third of the time means we’re going to be first to market with this particular business function or application. Talking at the high level of being fast and quick, that’s still not enough to automate a tool. You’ve got to break it down into some requirements. How are you going to do it? Is it through a self service portal? Is it going to be through a more automated service request process? Then you need to understand the processes that support those requirements, and then and only then should be talking about the tools and technology. I know there may be some vendors on here that’ll say out of the box is the way to go; maybe for the simplest and smallest organizations, but an organization who has any kind of complex organizational requirements will may be global in nature, who have multiple departments, an out of the box implementation will never work. It’s still important to be able to go back to your boss and say ‘you know that business outcome that’s so important to you? We’re able to solve it through these requirements, these processes and this tool and data implementation.’
Then you’ve got to take that map it to the tool. You’ve got to understand the workflows, all of those pieces that come together to actually automate the process and the tool, and drive a whole set of detailed requirements. What do I mean by detailed requirements? You need to know every single piece of data that you’re collecting as part of your process, you need to know if it’s a drop down, you need to know if it’s a variable, you need to know if its system generated, you need to know if its audited, and you need to know all your tool specifications. What do you have to integrate with? You have to be able to open an incident from BMC control. How are you going to do that? How are you going to create the ticket from HP open view? You need to know your triggers, so when a process moves or when an incident or change moves through the workflow, what triggers the transition from one start through another or what triggers that to go back to the beginning or to end. These triggers have to be understood so you can create state diagrams. This isn’t going to happen out of the box; you need to know what those state transitions are. You need to know what messages you’re going to issue. I’ve seen projects where people didn’t really think that through a notification matrix and they started issuing too many messages to too many people.
Imagine this: you just spent all this time and energy, you’ve done a great job implementing your ITSM tool, and all you hear is ‘I’m getting 10x more email today than I did before, so I’m just going to ignore it.’ It happens because someone didn’t really sit down and figure out who should get what message on what condition, how do we minimize the number of messages that people get, and that can’t be done out of the box.
There’s a ton of things that need to be detailed out as part of your technical requirements and if I’ve seen anything in my experience kill an ITSM tool implementation, it’s the lack of attention to these detailed technical requirements. You want to tell you vendor or your partner or your consultant ‘here’s what I want to implement.’ You don’t want them to make the decisions for you.
The other thing that I believe is extremely important is this concept of simultaneous process and technology design. What do I mean by that? You have identified the gaps, you figured out all your stakeholders are, you’re ready to go, and it’s now time to start your project. I’m not a believer in doing the process first then the tool; you have to do it simultaneously, but what I’m trying to convey with this chart, and it might not be obvious, is the degree of effort in each area based on the timeline.
You’re beginning your project. Process is on top with an eye to technology. You’re talking about the process but you’ve got people who understand the tool saying ‘we can’t implement that, that’s going to be really hard, maybe we should consider doing that a different way.’ You’re talking about the process but you’re keeping an eye on the technical requirements you need to automate that process, and as your whole timeline moves forward, you start talking less about process and more about the tool, because you got the process all worked out with your eye to the tool, but now you’re looking at the tool with your eye to the process. That’s why the core team needs to have both process and technology people on it. If you don’t, you’re going to lose that. I call it ‘throw it over the transom syndrome,’ where some consultants come in from consulting companies, the XYZ, they build some beautiful process documentation, it’s in a nice leather binder, and then immediately goes up on the shelf and then the implementation team comes in and they basically start all over. You don’t want that; that’s a waste of time and that’s a waste of energy. As a matter of fact if you do that, you can double the length of your implementation project open yourself up to a lot of failure. It’s really important that you look at things simultaneously but as the project moves on, the emphasis shifts from process and looks more at technology, but you always look at both.
Validation is extremely important and there are a couple of things I want to talk about in terms of validation. First of all, I’m a huge proponent and I think many people are today of iterative process design. The last thing you want to do is to go into a boardroom for six months and then come out with something and say ‘let’s implement.’ It needs to be done as in the previous slide show in this whole simultaneous nature. When you’re talking about the incident management process, bring up the system. Show some of your stakeholders. These are the different people in the team; the core team can work and get a little demonstration together, get a first cut at what the incident management system might look like and then share that with the stakeholders and get the buy in. Validation is even a weekly kind of activity where you are constantly going back to your users and you are saying ‘here’s what we’ve got, how does it look, is this meeting your requirements?’
The thing you have to be very careful about in this kind of situation is scope creep and that’s where it takes an extremely strong project manager because you don’t want to keep saying ‘yes’; what you might want to say is ‘that’s a great idea but we are going to want to keep that for another release, or let’s do this at this stage of the implementation and then we will bring in that requirement a little bit later.’ It’s very important that you don’t get into scope creep because what is going to happen when you have scope creep is you are going to make nobody happy, your project is going to be over budget, is going to be delayed, you’re not going to implement, you’re not going to get those quick wins, and you’re not going to get the management buy in. Scope creep can be really problematic.
You need to validate often and you need to get sign off against the requirements. One of the things that I’ve seen, and I’ve seen this many times, is what I call a passive aggressive behavior; ‘there’s nothing wrong with our processes, we don’t need to change things, but I will just sit along and nod my head, yes that’s okay,’ and when the tool goes live, the person says ‘I didn’t agree to that, or my people who were there on your project didn’t have the authority to agree to that,’ and now you have to go back to square one. That’s why the iterative design, the use of show and tell and the validation and the sign off is critical because nobody can come back to you after the fact and say ‘I didn’t agree to this, that’s not what I wanted, there’s something wrong.’ It’s important to validate, to validate often, but to do it in a very demonstrative way.
Some of you know that Navvia, our company, has a business process management tool and we also have consulting services and in my role in the company, I have my fingers in all the pies, so I head up to the development team and my favorite time is show and tell; I love show and tell because one of my jobs as one of the architects of the product is to provide requirements. What I love to see is how those requirements were translated back into something and it’s just really gratifying to see these ideas and these visions come to life in the product, and you can make changes and course corrections sooner than if you gave somebody a bunch of written documents and requirements and six months later, you have a release and then you go back and say ‘that’s not what I wanted.’ Validate often, use show and tell, and make sure you get people to sign off.
Remember to educate. Training fosters adoption of the process. You really need to build an education curriculum and plan something that addresses all the requirements of all your stakeholders. There can be various levels of training; you have awareness training for the highest senior management, he is what we’re doing, here’s some of the basic concepts, and as you get deeper, you might have heard some very specific role-based training. Here is how you as the process owner or here is how you as the change manager approves the change. Here is how you as a technician accepts an escalation and deals with it. Here’s what you have to provide as input back into the ticket or the case and push back to the users. An education curriculum needs to address people at all levels, it needs to also address role-based training. You need to consider various training formats. Some of it might be CBT and some is instructor led. At the beginning when you’re first rolling it out, I think people are the best way to roll it out what you’re going to get new folks coming on board your company; it’s important that the new folks get a chance to see the training materials as well as.
I have a question or a comment by Gail; ‘I had some issues here at work and was unable to watch this webinar, but we’d really love to view it. Is it possible that it’ll be made available?’ No worries. You’ll get both the slides and a recorded version of the webinar. What will happen is within a day or so, you’ll all be receiving an email. If you don’t see the email, just go to our site. Its Navvia.com/resources and all our webinars are posted there, not only this one but all the webinars we do, white papers, articles and such. Thanks for that question.
Also, you should consider using people involved in the process to do the training. I like to say there’s another presentation I did a few times called ‘selling the value of your service management program,’ and there’s a concept called ‘the seven steps to persuasion.’ I think it was Steve Candalini, but I might have the name wrong, wrote an article called The Power of Persuasion: Seven Steps to Influence People. There’s a couple of interesting points in that and it’s all based on how human beings are built and basically the human condition. People are more apt to follow something if it’s been demonstrated from someone they respect, like and they see as an authority. If you can get the go-to people in your company, the people that everyone say when there’s something wrong, that’s the person I want, you’re helping it out. If you can get those people to spend some time involved in the kickoff meetings, involved in some of the training, maybe actually conducting some of the training, you’re going to have a better chance of people following the process because they’re going to look at these folks as authorities, as experts, as trusted sources, and it’s a great way of getting some adoption. Consider various training formats and consider using people involved in the process to do the training.
Your education plan should have a curriculum. The curriculum might consist of awareness all the way down to some detail training based on different roles. You need to focus on the content development; what’s this content going to look like? Is it going to be CBT taste? Are you going to be putting it in your company’s education system? Are people going to be required to certify against it? Do you need to develop tests and certification? Do you want people to recertify? What are the delivery vehicles for your training? Is it going to be CBT? Is it going to be on demand? Is it going to be live instructor? Is it going to be classroom-based? All of these things need to be thought of as part of the education plan, but education is one of the best ways to get adoption of your process. Don’t buy into this ‘we’ve got smart people that can figure it out.’ Everyone is going to look at it differently, they’re going to make assumptions, you want to make sure you cut those assumptions in half and you tell people how things need to be done.
Last but not least, you need to govern the process. You need to define some control, policies and standards. What’s governance? It’s one thing to say we have a change management process but governance says we are going to have a weekly CAB meeting, or it’s one thing to say we have an incident management process but governance says every week we are going to look at all of our incidents and determine which ones should be closed, which ones should be escalated, which ones need to go to root cause analysis to the problem management group and have some people actually actively focused in that. Governance says procedures are going to be updated every six months; prove to me that the procedures are updated and checked every six months. You need to define the controls and policies because the tool will help you automate it but most of what happens in the process is between people. It’s the questions you ask, it’s the governance, it’s the management, it’s the enforcement; those are every bit as important as the tool. The tool is just the how. The governance is really the what and the why, so it’s important to set that up. You might need to put some governance structure in place; who’s going to be looking to see this stuff is being done; who’s going to be asking the questions; is there ways to automate it.
You need to define the controls and frameworks pure required to report against. If your company goes through regular [unclear 0:59:41] audits or Cobit audits or is looking for ISO20K certification, make sure what you’re doing with your ITSM tool implementation is in alignment with that so that it’s not a scramble to prove you’re meeting those standards and those frameworks and requirements. As much as you can, automate the collection of the metrics and automate the mapping of what’s being done to the compliance frameworks.
I have a question from Rob; ‘is there a recommended strategy around how to effectively sell the value of an ITSM strategy to senior management? What is the best approach and should it be financially focused, etc?’ That’s a big question. There’s actually a webinar up on our website called something along ‘how to sell the value.’ There is a webinar up there that talks about those very points. Rob, I’ll be happy to have this as an off-line conversation with you and I do have material to share. We are just running up to the end of today’s webinar timeframe and just let me get through a couple slides and I’d be happy to stay on a little bit later to address that in a little more detail. The answer is yes; there are ways, and is it the same way for everybody? No. You really need to understand your executives and what their pain points are and how to drive them. ‘Selling the value of your ITSM program’ is a good webinar for you to watch and I’ll be happy to continue to discuss your question in a few moments.
Governance is really important. Governance is also the key to continual service improvement. That’s the other thing. If you are going to put these processes in place, you want to make sure at the very least they stay healthy, but it’s even better if they continually improve, and you’ll never know that if you don’t govern them.
A story I can tell from our past is I remember back in the day working with an organization was very intimidating from the perspective that I as a technician, I used to fix mainframe computers, I would go in and actually be told by these folks what to do; they said ‘you had this condition, you had this error, here’s the parts you should bring on-site and here’s what we expect you to do and tell us when you’ve done it.’ That was pretty intimidating to be told by operators how to fix the machine that you were trained on and have experience and they didn’t, but the reason they were able to do that is because they have governance around their processes because every time a technician fixes something, they asked what broke and what parts did you change. That went into the knowledge base. Because of the governance around the process, and these are people actions, not to actions, they were able to actually cut down their outage time by allowing us to respond more quickly.
Good governance will give you basically a more stable level of service delivery versus some organizations who allow their processes to erode till one day, change management blew up, a huge failure and all of a sudden, everyone’s interested in ITIL and a new tool. You don’t want it to get to that point; governance will keep it from getting to that point. Once you put the processes in place, govern them; that’ll keep them healthy.
We are coming up to the end of the presentation here and I guess the key point is don’t be one of the statistics. I did some research prior to this presentation, and depending on whether it’s ERP or CMR, according to Gartner, 60% to 70% of IT projects fail. You don’t want to be one of those statistics. What fails mostly in these projects is the lack of clear understanding of the requirements, a lack of a definition of the requirement and a scope creep and not getting something implemented that services the business outcomes. Understand what’s broke and build a plan to close those gaps. Collaborate with your stakeholders. Understand what their perspective is. Before you can begin to sell the value to your executive, you’ve got to understand what their pain points are, so you need to talk to them; what are their objectives; what are they being measured on; how do they get their bonus. Those are things you need to understand.
Collaborate with your stakeholders to understand and make them part of the solution; don’t make enemies out of them. Save time and don’t start from scratch; there’s some great templates out there, use those where you can but remember, things can’t be done out-of-the-box. Templates are best practices; you still have to tailor to your environment. Define and capture your technical requirements because that is going to streamline the automation and that is going to streamline the implementation; you’ll actually be implementing what you want as opposed to what the vendor wants to implement for you. Validate. Keep asking if you are on track. Show people where you are. Show people the current state. Get input from them; that’s really important. Education will drive adoption and of course governance will ensure accountability; you need to make people accountable for your processes and you need to make sure that they stay healthy and robust.
We are at the end of the presentation here today. As I said earlier and a couple times through the presentation, this will be available on our site, www.Navvia.com/resources. It’ll be up in the webinar section and there’s a few other webinars there that you might find of interest. I’d be happy to share those with you and we’d love to hear your feedback. Also, if you are so inclined, I’d be happy if you follow me @Mainville or @goNavvia. We look forward to hearing from you in all manners and this is something that we and Navvia are extremely passionate about, we’ve tried to put these webinars together to help educate and to share some of our ideas and passion with folks, I’d love to keep the discussion going and if you’re so inclined, drop me a line either on Twitter or through our website and I’d be happy to engage with you.
Once again, thank you so much for your time today. I will stick around for a few minutes to take some questions, so if there are any additional questions, I’ll be happy to do that. Otherwise, thank you for your time. Happy holidays to everybody; we’re going into the holiday season. This will be our last webinar of the year so thank you for those who have been a regular attendee to our webinars and thank you for anyone who’s come and check us out for the first time; I hope you got value out of it.
Thank you everyone and I will be sitting around for a minute or two to take questions at any come in. Have a great day and by for now.