Share this webinar
- Setting standards for process design and documentation
- How to lead the ITSM tool selection
- Standardization and integration
- Defining functional specifications for tool implementation
- Developing metrics and reporting
- Leading continual service improvement efforts
- Assisting the business with the development of processes and procedures
- How to set up governance for the processes and take corrective action where required.
The Value of an ITSM Program Office
Lisa: Hello, everyone. I would like to welcome you to today’s 2013 webinar series. Today’s topic is ‘It’s a matter of focus! “The value of an ITSM program office.’ Before we begin, I would like to introduce you to David Mainville.
David Mainville’s passion about service management comes from over 30 years of practical experience and proven success. David is a frequent contributor to ITSM publications, an experienced speaker and lecturer. He has been a guest on numerous webinars and podcasts and is an active blogger on topics as wide ranging as effective process design, ITSM governance and Cloud computing.
I’d also like to introduce you to George Spalding. George is the coauthor of ITIL B3’s Continual Service Improvement core Volume. George was recently awarded the 2012 [unclear 0:01:26] lifetime achievement award from HDI and is one of the world’s most insightful and engaging IT service management and support experts. In addition to his extensive commitment to improve the industry, George has spent several years as a consultant to the White House on technical presentations and White House conferences. He has also coordinated technical presentations for members of the president’s cabinet, The Smithsonian Institute and the Federal Bureau of Investigation.
George is an ITIL expert. He is a regular author of IT articles and white papers and is a presenter at global ITSM conferences and events. George, if I can ask you to take it away?
George: Thanks. What I would like to do is I’d like to start off today by setting the context, if you will, for the discussion. What we got at [unclear 0:02:24] is we often get a conversation or a question from CIOs and higher ups dealing with this world of IT service management and ITIL, and they’re very on board with the whole concept of ITSM; they’ve been through some of the more basic processes, incident, problem and change; they understand the challenge behind CMVBs and release; they bought into the basic concept of turning their organization into a service providing organization so they’ve already done all that. Now the question comes up, they start asking the big question which is ‘should I change my organizational structure?’
The answer that we give them of course because we’re consultants is ‘it all depends.’ What does that mean? It means that I have seen people who have been so smitten with ITIL and so smitten with the basic processes around ITIL that they have indeed looked the entire organizational structure on its head, they took away the network groups and created a change management group. They took away the database groups and created something else, and it didn’t work. It really didn’t work and it was certainly not by our advice that they did that, but it was interesting for us once we heard that they were doing it, we wanted to just see and watch and it didn’t work. In fact, it was a total miserable failure. But does that mean you shouldn’t change your work structure? We’ll get into this in a second.
The first concept I want to talk about is ITIL and ITSM and effective IT in general should be built around the concept of ownership and accountability. IT as a whole and as a concept really hasn’t focused on accountability throughout its history. In fact, we have words that we use in some agreements sometimes that seem to me to actually want to codify a lack of accountability; like we offer best effort support. Best effort support, what does this mean? I’m a really good person and I’m going to try really hard, but if I can’t then I won’t? Or if I’m really busy today you get worse service levels than if it were not? I even ran into one client who had in their agreements best effort support from the side of IT, and on the other side the client will participate in a spirit of cooperation, which is like what kind of contract is it that we’re writing? Is this a touchy-feely, let’s all do granola and sandals?
I just want to know what you’re going to give me. What are you promising me? How well are you going to do it? How fast are you going to do it? How much is it going to cost?
From the IT, that’s what the client wants to know. From the IT side, everything needs an owner and I mean something all the way down to a request or a single incident; they need an owner so that its one person, one human being, who knows that it’s their responsibility to resolve the incident or fulfill the request all the way up through process ownership to service ownership. Each service needs an owner and I’ve been to client sites where his people were playing in the world of ITSM for six or seven years and I ask a simple question, which was ‘who owned this service,’ and the answer was ‘nobody.’ They had application owners, they had data owners, they had infrastructure owners, but they didn’t have the service owner. It seems so simple but when it gets to reality, it’s not that simple.
I want specific ownership and when I say specific ownership, I mean I don’t want a department to own it and I don’t want a group to own it. I want a single human being to own what it is they own; service owner, process owner, incident owner, etc. I want this one human being, I want one throat to choke so that I know who’s accountable and I know that I’m going to get the right information from that one person hopefully. I want to know who’s accountable, what their specific deliverables are, what their responsibilities are, and this is going to be ongoing as we develop and change. I’m going to need that kind of accountability and ownership built in through almost everything we do in the world of ITSM.
When I look at day to day operations, in most organizations, and I do believe this is true, [speaker cuts off 0:07:38-0:08:01] in any language and we also, not necessarily within that silo that certain spending a lot of time in there are as project management. Then we have a lot of other pieces in this world of IT. We have a lot of other roles in IT that we don’t really have a silo for and they don’t really fit in the definitions what I just laid out there. There are a huge number of things where we have specific roles that really only IT focused while they should be more business focused and maybe some of them aren’t, but they don’t fit in either one of these silos, so we create these roles and we do dotted line reporting to the CIO or a CTO.
Look on the right side of the screen. We have those two silos I mentioned; infrastructure and application development. If we’re going to institute processes like incident management, change management, and release management, all those processes that we implement are going to be horizontal and are going to run across all the vertical silos that we have within the organization. Each one of those major silo infrastructures has their own little minor silos like network or VBA or workstations and such; little minor silos within the big silos. The processes run horizontally across these major silos and then if we made the move and bit the bullet that we’re going to become a service organization, the services that IT offers, the actual implementation of the real stuff inside those services, is going to across these various silos as well, horizontally.
Over on the left side, we’ve got all of these pieces and all those positions that don’t really fit into a silo; business relationship management, which is a little higher up than service level management; supplier management where we might even have a vendor management office; human resources; IT human resources; IT audit, if we’re in an organization or a vertical market that requires us to comply, then that’s going to be a big deal – IT audit, risk management, compliance, all a part of it certainly by definition cannot be in one of those other silos; it has to be outside of it; then IT finance; procurement; enterprise architecture. The truth is of course enterprise architecture has been around forever. In the old model of ‘plan, build and run,’ they were always in the plan area, but truthfully nobody really listened to them, even though they were right and they still are right.
Basically we have to keep taking an enterprise view to all of IT and especially to ITSM which we’ll get to in a second. More planning; internal consulting; performance management; service level management; the true PMO – the project management office would be over there; the QA and testing – quality assurance would be there; IT security and maybe just security in general would be there; and finally we get to that ITSM program management office. Within that, we would have all those owners we talked about. You can easily see that the process owners should not be in the network group. I should not have the process owner of change management be somebody from networks; it doesn’t make sense. What makes sense is for the process owners having a horizontal view of the other two silos of the service owners to be over on the left side over what we’ll call the ‘enterprise service delivery silo.’ Service owners, process owners, and in general the entire ITSM program should be run out of that area. That’s what makes the most sense.
You didn’t really at [unclear 0:12:39] decide that this should be true. What we ended up doing was we started looking at clients. We ran across most of our clients who have the traditional infrastructure app dev and then a bunch of disparate little boxes on their chart with dotted lines going to the CIO. Then we ran across some clients that looked a little bit more like this, and it just was a light bulb for us; a big ‘aha’ moment. This may be a little bit futuristic but it makes total sense. The entire service delivery model is on the left side there and governed by service level management going to the customer. That’s really what controls what the left hand silo does; this new silo.
What we believe is that the concept of a program management office for ITSM is something whose time has truly come makes complete sense, it keeps up from having to shoehorn these old little items into an IT work structure that was never service focused and never really that much focused on improvement. It was just so focused on operations and getting things done and keeping it up and running and such. It makes complete sense and I’m going to turn it over to David and he will talk a little more specifically about this IT service program management office. Take it away, David.
David: Thanks, George. Before I get started, I just want to say the one thing that really resonated in your opening comments was that the concept of ownership and accountability because for my perspective, it really comes down to a matter of focus and whether the people I look up to and just from the perspective of someone being incredibly focused and attention to detail; Steve Jobs, one of his more famous quote has been one of my mantras, focus and simplicity. I think when it comes to service management, one of the things that have often gotten programs off the rails is that lack of focus. George, what do you think? Looking at this quote, how do you think focus and simplicity really applies to the world of ITSM?
George: I agree with you that people seem to go off the rail sometimes in the world of ITSM and these are well meaning people. These are not people who are trying to get things wrong but what they do is they look at the new version of ITIL, which is 26 processes, and they get excited and they say that’s great, and of course that’s just not possible, not certainly in the short term. What we find is that when we tell them it’s going to take a while, more than six months, more than a year to get to where I think you want to be, we try and keep them focused, eyes on the prize, what are we trying to achieve, and what are we going for. We also try and get them to crawl before they walk or run because we have people coming in and say ‘I want to do services right off the bat, that’s the first thing I want to do because services are what my business is demanding and the ability for me to provide services, that’s what I’m after.’ Without doing what I call the blocking and tackling, which is ‘let’s get incident management, problem management, change management, out of the way, let’s get them tight, mature, structured, let’s make it happen,’ and then we can focus on the more what I call the sexier elements of ITIL, which is a service focused organization and a true business integration with the organization at the business process and IT service level.
David: George, you’re singing to the choir from my perspective because if you can’t deal with the incidents coming in and if you can’t put changes into the organization without shooting yourself in the foot, how are you going to spend time focusing on service level management or any of the higher audit processes? I look at it in terms of Maslow’s hierarchy of needs where without food and shelter, you’re not going to become altruistic. Without the food and shelter from an IT perspective, being incident, problem and change, how are you ever going t get a CMDB in place? How are you going to get service level management? How are you going to define your services? I’m often a little surprised when I come into organizations and they say ‘I want to start with service level management,’ so ‘how’s your incident process?’ ‘We have all kinds of issues down there.’ I think focus is incredibly important, and to tie this back to the PMO for a second, I think the PMO is a group that can place that focus on the whole program. Unless somebody’s looking at it, everybody else just gets tied up in their day to day jobs and without some kind of focus, the program can easily go off the rails.
We’ve all seen examples of very high profile organizations who have been doing IT for many years and all of a sudden, they hit the front page of the newspaper because of a major catastrophic failure perhaps because a change went bad or something along those natures, and you sit back and wonder ‘how could someone like that get it wrong,’ and a lot of times it’s just that lack of focus.
We talk about programs and we’ve both been around the block and we’ve see a lot of programs that were very successful and a lot of ITSM projects that were epic fails. What do you think are some of the reasons these programs basically fall off the rails or all of a sudden, you get to a point in the organization where senior management says ‘I don’t want to hear another word about process, don’t talk about ITIL anymore, that didn’t work the last place I was at’? What do you think are some of the key things that cause these programs to fail?
George: One of my favorite things is to Google the word ‘computer glitch’ because that’s the media always calls all this stuff. It has nothing to do with computer glitches but that’s the popular term, and you get to find out all the outages and all the stuff that’s gone on over the last year or two and it’s amazing. I just finished doing an internal study of downtime and there’s some great stuff out there, and the causes of downtime, the costs of downtime and such are unbelievable; the average cost for most organizations is $5,600 a minute which is about $300,000 an hour. It’s amazing how much money we can waste on this stuff, but 80% of downtime is caused by people or process failures and half of that is because by change and configuration issues.
When you Google ‘computer glitch,’ in almost every case, and it really is amazing how consistent this is, if you read through the first two paragraphs, you see the issue happened after an upgrade by [unclear 0:21:01] after they changed the configuration of [unclear 0:21:04] and some of these things today, David, you and I have been around for a long time, and a couple of hours is okay for an outrage but we’re seeing things that are lasting two days. In one case, one of the airlines a couple years ago, 10 days would cost millions of dollars all because a piece of software failed or configuration failed or somebody made an update to the infrastructure. Most of these epic failures, and this is the sad part, are people based; either they bit off more than they can chew, the size of the project was just or enormous, they never were able to define it in its entirety, so therefore it was doomed to failure, or it was a rush, or a ‘floating scope’ of the project, which means the project was never locked down. We get back to your focus and simplicity discussion; the project never had a specific definition. It had a starting definition and then after that, what happened? The business came up with a new idea and they threw in the kitchen sink and they threw this and this in, and the developers and the project manager didn’t have the courage to say ‘no’ or to say ‘that’s why God invented versions release so that we’re going to release the version we started with, what you’re describing is the next version.’
That’s one of the reasons why these projects fail epically because in many respects it’s not just dribble and drabble; it is literally we spent X millions of dollars and it simply doesn’t work.
David: Scope creep for me is one of the biggest reasons these programs fail. For example, it’ll start off maybe there was an epic failure of a process, people want to bring in a new tool because they think the tool was the reason that whole thing failed, so they bring the next release of a tool, they define a new change management process, and all of a sudden, ‘what if we can do this or what if we send notifications to these folks or can we make these workloads a little more complex,’ and before you know it, the requirements are out of control and what ends up being something that should be implement in three to four months is six months later and the end result because it was designed by committee sort of speak is a project that’s completely off the rails and it doesn’t meet those requirements.
There’s a couple of things that I’ve seen and it tied back to this PMO because I agree that the PMO is such an important area of focus to get back to that concept of focus. Someone is looking at the program as a whole. Someone is putting some constraints around the requirements. Someone is saying ‘we’ll do all that but let’s do it in a phase manner and let’s get some success out the door, we don’t want the new tool to be a four letter word around this organization, we want success,’ and like you said, it’s always about people; it’s never really about the tools or processes. There needs to be someone who can herd the cats and get everybody moving in the right direction.
When I first got started in IT, it was really interesting. I could walk up and meet the change manager, I could meet the release management, and I could go into the person who was responsible for the service management and monitoring tools. When I first began in the industry, the structure of IT was very focused on those areas. Many of the companies that I went in and did some work with were extremely diligent. As a vendor, if I would come in to make a change to a piece of hardware, they would ask me ‘what are you doing, what did you change, what were the symptoms that caused you to change that,’ and really have this documented in a ticket. They had that knowledge base and what I noticed as financial pressures occurs, much in the same way that the IT architecture group went to the sidelines, I noticed a lot of these disciplines like change management, release management, configuration management and planning, those disciplines just start to spread up amongst multiple people, and that’s when I really noticed a lot of organizations going through some real problems with reliability and availability in terms of their organization.
Why I think we need an ITSM PMO is to put that area focus. If someone who can actually make ITSM part of their daily job and bring in folks from around the organization as subject matter expertise, be it security and application development, IT operations and infrastructure and networking, be the glue that holds all these different disciplines together and as you said in your introductory comments, be that cost functional piece that can go across and say ‘we can show you how to design a process easily, we can give you the metrics you need to really make this process measurable, we can provide you with guidance and support so that we can automate these processes in the particular tools.’ Does that resonate with you, George?
George: It makes sense. Usually when you get a practitioner organization, by the time they get to us, there’s somebody who thinks this is a good idea. Usually it’s not necessarily the CIO; they seem to have their focus on something else, but we have a number of CIOs. When this person who thinks all this is really a good thing, ‘best things in sliced bread, that’s what I want, I want ITSM,’ that makes the most sense. The other reason is ‘I want processes not because I’m so thrilled with processes but because the opposite of process is heroism,’ and that’s the way most IT organizations have gotten to where they are today; by hiring a bunch of heroes or people they’ve turned into heroes. People who basically said ‘I’m going to go above and beyond but everyday I’m going to go above and beyond because its chaos.’ It’s chaotic in IT and I guess that’s the nature of the beast, and we just don’t believe that that’s the nature of the beast. We believe that IT does not need to be chaotic, that it can be process driven, it can be sane and that we can get a handle and get ahead of it instead of always chasing the snowball down the hill.
From a PMO standpoint, a program management office for service management, we are on board a tank. We believe that most of the successful customers that we have had something like this. They have something that’s not part of the day to day silos that actually taking that view that you talked about and looking at the entire program from an enterprise standpoint and keeping it on the rails, keeping it under control, not getting and even tempering down some excitement about people going ‘yeah, yeah, yeah,’ especially as you get good news when you get one organization or department or area doing good reporting and show positive gains. Suddenly you got people knocking on your door saying ‘we want to do that,’ because these other people are getting strokes and they’re actually getting called up in meetings and saying, from the CIO or CEO who really doesn’t necessarily know what’s going on, ‘I don’t know why you’re doing it, but you’re doing a hell of a job,’ so these other people want to be part of that. This PMO has a sense and becomes in many respects an internal consulting organization because they have the expertise as well to take this one. It’s a great idea.
David: When it comes to setting this up, it’s not one size fits all. I’ve seen this in the larger organizations being a more dedicated group of people, but even in those organizations, it consists of a combination of full time and matrix resources, like the process owners. In some organizations I’ve seen the process owners being dedicated here but in others the process owners actually lived out in the field sort of speak and they were part of this group by matrix [unclear 0:30:01] where the only core skill set for more in the area coordination, maybe some specialized skills around process designs and specialized skills around the tool. I agree with everything you said in terms of why it’s important; focus is someone being accountable for making the program a success.
When we talk about who should be in this program, I really think it’s a combination of different folks. Obviously the process owners need to be there, there needs to be some representation for more senior management from a steering perspective. I personally believe there’s got to be some expertise around reporting, metrics, analytics, something around continual service improvement so that you have some skill sets that can identify when a process or an aspect of a program is going off the rail and put something into place. All of those things together bring that area of focus and skill sets required to make the program a success.
A process left on its own will degrade over time. There’s entropy that comes into the equation and what happens is people get lack; ‘I didn’t get that change in on time or I didn’t get a backup plan in that particular request,’ and things start breaking down. Without someone looking at how many incidents have not been closed, how many problems are still outstanding, what’s the percentage of emergency changes being put in and is that only because of bad planning as opposed to a real emergency. Without that focus, I think things begin to degrade.
I think there are a lot of things that ITSM PMO can do and these are just some of the areas, and I talked to some of these already, but take communication for example. You can’t stop selling the value of service management. What’s interesting is a lot of ITs aren’t the best marketers, but you really need to communicate the value of the program, and it’s different for everyone you talk to. The value of ITSM to a CEO or CIO is pretty different to the value of an ITSM to a person who works on the frontline perhaps on a service desk or working an in infrastructure support group resolving incidents. Down at the grass roots level, you want to make sure you have a good knowledge so that if an incident reoccurs, you know what to do to fix it. You want to have known errors so you have a procedure to deal with those things. Down at the grass roots level, it can really help make someone’s job easier, but at the highest level up at a CEO or CIO, it’s all about alignment to the business and it’s really about how you can get new services in production faster and how you can deal with the business issues. Communications is a really important part of the ITSM PMO that’s selling of the value. Also, I think they can bring in some great expertise around design.
Designing a process isn’t rocket science, but if it’s not the thing you do every day, you’re not going to have the skill set to do it. Subject matter expertise around design, perhaps around reporting and metrics, continual service improvement, I think all of those things are really good areas that the ITSM PMO can focus on across all the services and across all the processes. George, do you have any other ideas at what might be some of the good roles for a program office?
George: You mention some great ones here. Communication becomes the key and what we find is that people tend to do this on an ad hoc basis; they don’t necessarily plan how they’re going to communicate along the way and what we urge them to do is actually start this way before with a communications plan, so that they know exactly how much and how often and what it’s going to say with a specific audience taken into account because a lot of times, what you tell one doesn’t mean anything to the other.
I don’t want to take any more time away from the demonstration that I am actually quite anxious to see and how it relates to this ITSM PMO.
David: Just a couple of things getting started. One of the things that I suggest for anyone looking at an IT service management program after square one is to really think about how they’re organize for that. As George said, organizing by the ITIL books, not always a great way of doing it, but there does need to be some organizational consideration. A couple of people need to be really focused on the program around communications, around governance, around metrics, around continual service improvement.
One of the best ways I think to get started is if there’s a catalyst for change, if you’ve maybe done an assessment of your processes and identified some gaps, maybe there’s been a major outage, perhaps you’re bringing in a new tool set, those are all great catalysts to say ‘why don’t we take a different approach, rather than treating this as a project of getting the new version of XYZ tool in, why don’t we treat this as a way of improving the business services, improving the quality that we deliver to our customers?’ One of the ways of getting started is to look for an opportunity, be that gaps in your existent processes, some major issues that are concerned, a new tool implementation, and use that as opportunity to be build your project more as a program.
What we tried to do is we tried to say ‘if there’s going to be such a place, a program office for service management, how can we give them some tools to help?’ We are all aware of discovery tools, CMDB tools, we’re aware of process automation tools like many of the service desk systems that are out there today, but one of the things that we saw a gap in the marketplace was a tool to really help the program office. We at Navvia, we’ve been around for 14 years, we’ve done a lot of consulting, and we’ve come to the very similar conclusion to George and our friends over at Pink, that this program office is really important and we wanted to empower it with the tool that can really help enable the whole program.
The Navvia toolkit is a SasS application that allows you to do a number of different things. It allows you to survey where you are. If you want to use a survey as an opportunity to identify gaps and build a catalyst for change, we have some technology within the toolkit that will allow you to survey your current state and set a baseline so you can do comparisons down the road.
The other thing we did is tried to make a very simple and easy to use designer so you can build and design and document and communicate your processes without having to spend a whole lot of time and tools like Visio and Excel and Word and all of those other areas and to actually provide a common repository where everyone can get access to process documentation.
The other thing, and this to me is one of the most important pieces, is once you’ve done all that hard work at defining the documenting your processes and rolling it out to the organization, you want to make sure they’re being followed. You want to track and verify that the processes are in fact delivering value. One of the things we built into the tool was the capability to verify your process against certain control objectives that you set.
Finally, if you do determine that there’s a continual service improvement initiative that you want to spawn off to be able to document and track that CSI program through its life cycle. We came up with the Navvia platform and Navvia is a SasS application. We released it about three years ago and it’s in about 120 commercial organizations primarily in North America but also in Australia and Europe and Southeast Asia. It’s a SasS, it’s in financial services, the healthcare higher education across a wide variety of organizations and what it’s being used for primarily is to support the concept of an ITSM PMO.
I’m going to give you a brief demonstration of what the tool can do, maybe 5 to 10 minutes. Here we are at the Navvia application. Like I said before, it’s a secure SasS application, we have ensured that the data center that it’s hosted in is SSA 16, SasS 70 certified, we’ve gone through countless compliance checks, ethical hacking by our clients to ensure and with government clients, financial service clients, you can be assured we’ve taken every caution to make it secure.
When you log into the application, you log in with the user ID obviously, and there’s two types of user IDs; there’s the standard user which basically allows you to do anything in the tool, and there’s a basic user which is more of a read only user, you can respond to surveys, look at the process documentation that’s been designed specifically for your organization, respond to governance tasks, and take some online education. The basic users are free and unlimited. What you pay for in our subscription model is basically the users who are going to build, design and create things. I’ll log in right now and here I am at the Navvia home page, and the first thing I want to point out is how easy it is to get around the application.
We have the ability to go to the survey module, the design module, the verify module, and something we call ‘learn’ where you get access to product education in both enrolling in a live product education course or getting them live on demand through a recorded vehicle. We also have report and user administration. We have a ‘getting started’ page which gives you access to all the documentation and some tips to get up and running with the tool. We also have a suggestion box where as a client you can provide your suggestions about the tool and hopefully we can take those into account into future releases of the product. A lot of what we’ve designed here actually was based on clients’ suggestions.
We also have some tabs here along the bottom which actually presents to the user who’s logged in the processes they have access to see, like I have access to incident management, and a quick click on incident management will bring me into a component of the incident management process where I can navigate through the activities, the tasks, I can see whose responsible for those, I can look at the roles in the process, I can see everything the incident coordinator does, I can drill into a task and get a lot of detail, but I’ll come back and show you a little bit more about this aspect of the designer in a few moments.
Also, I have access to development tasks. When we build a process, we also [unclear 0:41:31] technical specifications needed to implement the process in the tool and then we can assign those development tasks off the folks in the organization in order to ensure the process is actually implement on spec within the tool. We have the ability to take assessment questionnaires; if someone had sent a survey to me, I would see the list of survey questions here. Same with governance tasks; if I’ve been asked to respond to a different task, like show that change status tracking is on track or show that a role’s responsibility’s matrix exists, these tasks can be defined and assigned and evidence of compliance can be specified to support those tasks.
You can also, for example, if CAB minutes were one of the pieces of evidence requested, you can actually attach samples of the CAB minutes or point to a URL in your organization so not only are you asking people for evidence of compliance to the process, you are also capturing the evidence of compliance and then later on I’ll show you how that can be mapped to dashboards and other reports.
The survey tool is really simple. Everything is based on a project so these are examples of a Cobit assessment, a baseline ITSM assessment, an ISO15504 assessment and creating a new project is simple as clicking on ‘new project,’ providing some information, the name, the description, the status of the project, the type of project you want to run whether its Cobit, ISO, etc, the style of the project, and basically setting that up and building it. Once you have a project set up, you load it up with questionnaires. Here’s a list of the questionnaires that I have loaded into the baseline ITSM project. Getting a new questionnaire into the project is as simple as pulling it in from one of the many templates that we have; one of your own templates, if you wanted to build your own template outside of ours, you can do that; or create an empty questionnaire. We use this survey engine for not only process maturity assessments but gathering requirements about tools or asking if a training course was satisfactory. Internally we sent out our marketing surveys and questionnaires to this tool so you can actually design any kind of survey within the product.
Navigating around the product is really simple. I click on the baseline ITSM assessment, you can see I have the ability to set the project description to add or modify question sets; as a matter of fact, if I click on a question set, you can see all the particular questions in a question set, the answers we’ve identified as begin potential answers for that question, what scores are capturing and capture any comments that need to be captured to support that particular response. We can control all the branching in terms of the surveys so you can make complex surveys; have you received BITIL training, for example, yes or no, branched to different parts of the survey; we allow you to customize the messages that come up when you first click on a survey link or when the survey completes; we can even test the survey questionnaire before it goes out. If I click on the test, all of this commentary is completely customizable including the logo, you click on ‘next,’ you can see the first question, you can respond to an answer even be prompted for comments. You can add questions to any of the particular questionnaires and you can edit questions and answers; all very much customizable.
We’ve also tried to design the interface to be extremely easy to use so I’m in the survey module, questions sets, questions and answers for service asset and configuration management. I can move on then at the project level and say ‘who am I going to send this to? Am I going to send it to the management team, to Europe, to Canada, to new employees?’ I can specify groups and then add participants to the group. We’ll integrate with active directories; when I say integration, I mean we can upload information from active directory in our repository and then select users and assign them which questionnaires within that project people need to respond to.
We can customize the email messages that comprise the launch of the project and then once the project is launched, everybody who’s in that list receives an email with detailed instructions and links to take all of the questionnaires that have been assigned to them. Then we can come back and notify folks; if somebody hasn’t completed or started their questionnaire, I can hit the notify button and that’ll allow me to notify anyone who has not started or completed and I can even select customized message which I created to notify them with. The beauty of it is I have dashboards and reports so once this survey’s been launched, I can basically track to see how many questionnaires in the project have been completed, not completed or started, what the maturity level is at this point in time, what groups I’ve sent it to, and then I can really drill in with over 30 different specific assessment reports so you can slice and dice the data any way you want.
This is a great way of setting a baseline, to engage people, to check where you are in this specific point of time, to create your own surveys; really easy to use.
The design tool also is a very simple tool to use because we allow you to design any process within our system. You can basically create a new workspace and in that workspace, you can load it up with any number of processes. These processes come from a prebuilt library of processes such as our ITIL V3 library, so I can bring in an incident management process or you can build processes from scratch or you can copy a process from another workspace; very simple to build a workspace with the processes that you’re working on. You can have as many workspaces as you want, a workspace that can be focused on developing the processes, you can have a workspace where the processes are actually being published.
Once the process is in the workspace, you click on the process and it’s really like looking at a chapter of a book. We have the design module, the overview chapter which consists of description, goal, objective, roles, and definition as it relates to the process. The beauty of this tool is you just work through this interface and then we produce the Word document, we automatically build the RACI diagrams, we build the swim lane diagrams, all of the artifacts that you would normally have as part of your process communications would be built automatically by the tool and housed in a central repository. If you don’t like the description from our template, modify it. If this was a brand new process you are creating from scratch, obviously you would add a description.
We can see the goal of the process so the goal of incident management is to get something up quickly and back in service; what are the objectives of incident management; what are the roles; you can have a description of the role, you can add new roles, you can rename a role; if you don’t like the service desk agent as a role name, you can change it to ‘CSR’ knowing that it’s been changed in your Word document, AC diagrams, swim lane diagrams, anywhere that’s referred to has been now changed; saves a ton of work in terms of building a document in the process. We drill down into all of the workflow of the process. Here are all the activities that make up incident management. You open up an activity, here’s the task within. Open a new incident, verify the user’s information, capture the incident details, you can add ne activities, you can add new tasks, or you can just quickly click on the diagram and see this in a new graphical representation, and I can modify it from here. I can add a new activity right from this screen, for example, if I want to create a major incident activity, it’s as simple as doing that. The activities created, I can then add the first task to major incident, I can declare a major incident, I can specify the role and that came from that list of roles we defined earlier so maybe the incident coordinator and what duties does the person have in relation. It’s as simple as that creating the swim lane diagram. I can even drill in and see information and then populate information such as the successors, inter-process relationships, the roles, the data that you capture as part of declaring an incident, the procedures you might have to follow; very powerful. I can even branch to other parts of the process just by saying I’ll branch to ‘open a new incident,’ and you’ll see that we automatically create that in the swim lane diagram and you’ll see here that we now branch from ‘declare’ to ‘open new incident’; if I click on ‘open new incident,’ it takes me that screen. You can export this to Visio or a PDF, but this is all actually going to be automatically created in your Word document for you. Very easy to build and design processes.
We capture all the process control information such as control, metrics, policies and governance. All the technical specifications, states, approval states, triggers, state diagrams, all the data specs, every piece of data that you might want to capture as part of the incident process, your tool specifications, the notification rules, what messages are you going to send to what people based on what conditions and all kinds of very detailed information. Then on a click of a button, we create the full technical design document which you can use to basically take this process and customize it in a service management tool. Just as simple as that. Navvia process management made easy. The introduction of this document, the data specs, the tool specs, the triggers, all of those things are captured in the document.
We also capture from a report and document perspective the state diagrams, various reports such as duties by role; if I click on ‘duties by role,’ it’ll iterate through the database and bring up a report that actually shows, and in this example, you’ll see where we’ve changed the name of service desk agent to CSR, all the duties they perform, what tasks they perform, what their RACI value is specific to that task; everything can be exported into formats outside of our tool plus there’s an online portal where you can see this information in a very easy to read format. We even product the full process document, so we’ll iterate through the actual database and, for example, if I want to create an executive summary for the process, I just click on this and all of these templates can be modified, you can choose what from the database you want to include in part of your Word document, but this Word document was built in real time, it’s not a static document; table of contents, flow diagram, all of this basically built for you.
A really great way of capturing your process documentation down to a level of detail. This is the executive summary document, there’s a more detailed process document as well or going into all of these individual reports which include things like RACI diagram or all the metrics associated with the process. All of this is produced automatically from the database and it also acts as your central repository for the process documentation.
How does this help a program office? It helps a program office because you can establish a baseline where you are. You can define document and communicate your processes. Then you can verify those processes are being followed by creating governance instances which apply controls to the various processes. In this example here, I created one based on Cobit and ITIL, and everything you see here was pulled in from our templates, so we’re saying in support of the change management process, AI 6.4, we’re going to have the change process manager every quarter perform this task and these tasks are emailed to the individuals, they log into the tool and respond to them, and we can even specific which evidence of compliance is required, but if you want to add other evidence, you can select it from our whole list of evidence records. We tie this very closely, we’re licensed by ASAKA, we’ve used a lot of the Cobit content as part of our license agreement with them, we’ve used information from the audit guide to build up a nice control framework, but you can build any sort of governance in here or you can actually create a governance instance that allows you to specify continual service improvement activities, build the tasks as you can create your own, and add your own evidence of compliance; so this can be, for example, a governance instance around a continual service improvement program, you want somebody to provide a program charter, you can assign a task that a program charter has to be created, it gets scheduled, it can upload that program charter and then it’s reflected on various dashboard and reports as to how well you’re performing in terms of responding to those tasks. If someone’s failed to respond we even have the ability to remediate those tasks by moving them through this workflow which includes pending verification, pending remediation and actually be complete. Then a whole bunch of reports that allow you to see how well things are being governed.
As a program’s perspective, you now have some continual service improvement, some ongoing verification that your processers are being followed, you’ve got a great library of designed processes, either built from our templates or built any business process from scratch or go out and survey folks to see how well things are doing, both maybe at the beginning of a program and periodically as your program is unfolding to see if you are actually making improvements as time goes on, and then the ability to get a whole bunch of education, either Life Forces which are web based through a live instructor on specific dates and times or a growing library of recorded courses which allow you to communicate the value of the service management program.
What we tried to do is build something that followed this continual group and cycle; survey to see where you are, design to get better, verify that you’re doing it, and learn so that you can be better in what you do from a day to day perspective. To make this as a cornerstone of a PMO gives you those tools to actually take some of the drudgery out of doing this; instead of chasing people down with emails, instead of building stuff manually with Visio, Excel and other programs, instead of having to run around with spreadsheets, this brings it all into one central repository, lots of great permissions, a great dashboard that allows you to see the process in a very efficient and clear way. I think all in all it’s a good to help automate a lot of the aspects of a program office.
That’s a quick demo. If anyone’s interested, you can get a free test drive of our tool. You just go to Navvia.com/tools/test-drive and that’ll give you the ability to get up and running within a day. Also, we have a lot of resources up on our website; the recorded webinars such as the one we did today, articles, white papers and such.
George, we just come up to the end of our presentation here today. Any final thoughts before we sign off?
George: That’s incredibly impressive in terms of I think that people looking towards an IT service management PMO and probably when they first look at it, they think it’s an incredible amount of work, which of course they’re right, but a tool like this would allow this to seem a lot more possible and they’d be a lot more capable without hiring tons of people and spending major money on staff. They’re able to accomplish things in a much shorter time frame and get up to speed much quicker. Excellent job, David.
David: Thank you very much. I just want to take an opportunity to thank you, George. It’s always a pleasure. We’ve had a chance to interact on panels and other opportunities and I look forward to seeing you down at the Pink conference, you’re a sponsor of the Pink conference, we’re really excited, long time sponsor of Pink conference, one of the best conferences we get involved with so kudos to you guys for doing that. I look forward to seeing you. I think I’m on one of your panel discussions at the conference, and Lisa, I’ll see you down there as well.
Lisa: Absolutely. This takes us to our conclusion of today’s webinar. I’d like to thank also both you David and George and everyone for joining us. Have a great day everyone.