Episode Transcript

Announcer: This episode of TechPod is brought to you by THWACK.com, the SolarWinds community for IT Pros.

Sean: Welcome to SolarWinds TechPod. I’m your host, Sean Sebring, and today I’m joined by Zeph Monette, an IT help desk analyst, and Neil Wagner, volunteer CIO of Calgary Counseling. In this episode, we’ll be talking about how to promote motions for improvements, how to balance this with operations, and how to maintain momentum for success. So, the topic we chose is near and dear to my heart. We’re calling it little fires. The idea of operations saying, “I’m too busy putting out fires.” Well, with that in mind, how do you focus on making room for improvements? So, before we get into today’s episode, I want to do some introductions. I want to start with Neil. Neil, can you give us a brief introduction of your role and experience?

Neil: Sure. So, a long, long time ago in a galaxy far, far away, I completed an MBA back in the days when spreadsheets had not yet been invented. And I started out in the finance world. And in those days, to do anything in that world, you had to know some technology. And before I knew it, I had made the shift over into technology. And at some point, fairly early now in my career then, I made the complete switch to technology and more importantly decided that I would stay as an independent. So, I’ve been selling my services for a long, long time. And I typically stay at companies anywhere from three months to five years, depending on the task. And I run programs or projects that are valued anywhere from two million to 15 million in spend. So that doesn’t seem like a lot. I know there’s a lot bigger projects out there, but that seems to be where I have settled.

Neil: Now, simultaneously, as I was doing all of these kinds of projects, which range from document management to infrastructure, my wife’s been the CEO at Calgary Counseling. And one day they had questions about technology. And before you knew it, there I was in the CIO role. And I just told them, look, if it has batteries or it’s called software or it plugs into a wall, I get final say. And that’s how I kept control of what we were doing, because I’ve seen too many times where in the not-for-profit world, they get taken for a ride by vendors who don’t really understand what not for profits really need. So that’s my background.

Sean: Well, that’s bringing us right to current. So that’s perfect. Because at Calgary Counseling, that’s where I was able to meet Zeph, and I was actually going to still ask you, Neil, if you don’t mind, give us a brief introduction of how you met Zeph to help bring him into this, where he started and what brought him to where he is now, which would be a great segue for us to really get into the topics.

Neil: Totally. So last year we made the strategic decision that we needed our own help desk solution, that we were using something provided by our service provider. Most not for profits have a backup kind of IT company that they use to execute. And we were using their help desk. And it was great for them but not great for us. As it turns out, we did what we always do, which is we start with a summer student, and we hired Zeph as a summer student. He was finishing his third year of a four-year degree at a place called Mount Royal University here in Calgary. We hired Zeph on and gave him a task. I gave him some high-level guidelines and said, this is kind of what we’re looking for. Here’s some of the products that you might want to consider. Come back to us with a method of evaluating and then let’s pick somebody and go. And so that’s how we met Zeph.

Sean: And so, we met Zeph. So, Zeph, again, this was a perfect way to get us to kick-start where I found that you would be, I think, an excellent candidate for this topic. So, and you would kind of introduce it to me picking up where Neil left off? So, you were handed this task of, I need to find and start implementing a help desk solution. And when I’m thinking about that, the reason I think this fits so well into it is there’s a lot of parallel operations that have to take place here? You can’t just put tickets on hold while you spin up a new ticket system. So, if you can, give me a quick high level, if you can, of what helped you make some of those decisions and how you really figured out what you were going to do to manage the parallel operations of, here’s what we’re still doing, and here’s how we’re going to keep fixing it while we’re doing it.

Zeph: Yeah. So essentially what happened is when I had been handed this, I had never… This was my first IT job. I had never done anything like it before, but I did have some pretty good background in customer service working with a customer service-based help desk. So, I had an idea of the kind of features I did and didn’t like and what I would want to look for in a product.

Zeph: So essentially what I did is I just sat down and started going through the various vendors that we had available and just compiled this essentially huge master sheet spreadsheet that had all of our top picks that broke it down according to the features that were available on it, the pricing tiers, and the features that were available in each pricing tier so that when it came time for me to present my options to Neil and everybody else, no matter what question that they had for me, I was going to be able just to be able to point somewhere on the sheet and say, here’s what we’re looking for. That probably accounted for the first three weeks I was here was just compiling all the data that I needed to make an informed decision.

Sean: I think one of the reasons I like this is because this is actually me cheating and teeing up for a problem that a lot of organizations have, which is you are a dedicated resource to identifying a solution and identifying how that solution was going to help make you guys successful. And the reason I think that this is important is because a lot of organizations… And don’t get me wrong, many people have to wear many hats, but they don’t dedicate resources, when I say resources, I mean people, to these kinds of initiatives. And Zeph, you were that resource. So, after you became that resource, and as you’re implementing this, can you tell me a little bit about the initial when you first started, right? You’d already done some dabbling in the product that you were going to use, but when you guys went live, what was your kind of success criteria to say, all right, we’re going to use it. And then when you did start using it, did you have a specific procedure or process for making changes while actively using it?

Zeph: So, we actually started fairly small with what our release was. So, we had picked out kind of the most common problems that we have. So, things like issues with Microsoft Teams or OneDrive, basically based on the data that we had from our current help desk, what we saw the most, and started breaking out the subcategories of problems that would be within that and getting an idea of, if it was OneDrive, it would be like “my files aren’t syncing” or “I’m not able to log in.” Just a general basis of what users might ask. And then we would, for anything we couldn’t catch, every single category would have the option to just say “my issue wasn’t found” so that they could submit it. And we could create more categories based off that in the beginning. And that kind of allowed us, with such a small area to focus on, to really get that initial step correct so that when people started going in, we had a good foundation to work with.

Zeph: And we made sure that not only that those categories were well built out, but they were well supported, too. The intern who I worked with last summer, she put a tremendous amount of effort into building out knowledge base articles. So that for the small selection of categories that we did have, we had it all supported and ready to go as soon as we were out of the gate.

Sean: Okay. So again, I’m kind of cheating, because I’ve heard a little bit of this before, but this really does help to build this story. So, I heard another dedicated resource involved, right? So we’ve got someone else dedicated, but a couple of cheap buzzwords I’ll throw in there is you guys really started where you were. You started with a very simple foundation, and then you addressed it iteratively. So you said, let’s make some implementation and then let’s identify what’s working, what we need to make some small changes to, and you made them in those small bite-sized changes. Is that fair?

Zeph: Yeah. And I think actually one of the most important categories that we’ve had since the beginning is the option for users to submit under their category, just called feedback, where they can give their thoughts on something, if it’s working or not working and how they think we could improve it so that they all have a say in how it’s built out and help us really improve the product for them. Because at the end of the day, what might work in our mind or make sense in our mind might not work for them.

Sean: Oh, I love that. And again, talking about buzzwords, the main theme of this, if you were to go with one of the high levels, I’ll loop this into an ITIL practice, continual improvement. You’ve mentioned the word improvement in there. And I think a lot of the improvement efforts fall by the wayside because of these little fires – going full circle into our topic here, continuing improvement is necessary constantly. You even said that Zeph, you said one of the categories that’s been fundamental since the get-go and is still there is feedback, and feedback feeds the improvement. Excellent. So, I’m going to tap into Neil’s experience here and we’re going to go into another question, and we’re going to call out part of our title for this TechPod. We’re too busy putting out fires. So, when we’re looking at large project efforts, right, or just daily operations, there are going to be operational fires. There’s going to be little hazards that you’re just normally used to dealing with. When is it okay to say, all right, I have to let that burn so that I can focus on making improvement and making change?

Neil: Okay. So, it goes like this. The first problem you have in implementing a tool like this is it’s unlikely that you have a lot of good data to start with.

Sean: So, you’re saying it’s okay to not start with a lot of good data?

Neil: Yeah. Because you may not have any, because you probably haven’t been measuring anything. And that’s a very key point to this whole discussion. One of the reasons why we wanted to find a tool like Solar was because our previous system that we relied on was email-based, and you would send an email to a certain address and complain about your problem, and you know what kind of tickets we saw? “Help, I can’t get in.” That was a classic, a total classic.

Sean: And not a lot of data, huh?

Neil: Not a lot of data. I also recall at another client that I had where I had nothing to do with help desk, but I had uncovered a problem, and I needed some IT support for my project. And there was a bug in their help desk system, which happened to be email-based. And so, when I submitted… How do you report via the help desk system that the help desk system is broken? Because they were truncating the subject line to eight characters. So, nobody could tell what my ticket was about.

Sean: Yeah. We’re in a chicken and an egg scenario now.

Neil: Yeah. So, the other part of this, where I say you have no data, you might think you know what your common problems are, but unless you’ve been counting them and categorizing them, you don’t really know. And that’s a very, very big thing for us because when we deal with our clients in a counseling perspective, for example, we measure everything. Calgary Counseling Centre has the largest outcomes research database in Canada and probably in the U.S. And we measure how a client progresses through treatment, and they can see for themselves that they are getting better, or they are not getting better. We apply that same logic to technology. How do we know what our problems are in technology?

Neil: We think we have little fires. We try really hard to address most tickets the same day, but in terms of what our big problems were, what’s the important stuff? That was a learning process that took a year, because we kept, like Zeph’s point said, we had to keep modifying our main categories and our subcategories so that we could produce a monthly report that showed us what the counts were per topic. And we learned some really interesting stuff along the way that really helped us, because at some point, for example, your category list could grow to be too long.

Sean: I see that all the time. Yeah.

Neil: And well then you start seeing comments from the users around, I couldn’t find the right category, but once we had enough experience under our belt, Zeph came back with, hey, here’s the top eight that we see all the time. These are the top eight categories. So we placed those at the top of the drop-down list by numbering them one through eight. And we can revise that at any time, right? Continuous feedback. Zeph can dive in, reorder them every 30 days or every 60 days, whatever he wants so that it’s easier for the users to find what they want. And then anything that’s not numbered is sorted in the rest of the list alphabetically. So that’s the constant feedback loop. But to get back to how do you deal with the little fires? My assertion is that you might think you know what the little fires are and the big fires are, but that’s based on sensing. Unless you have a tool like Solar and the way we’ve implemented it, you don’t have facts. So we like to work based on the facts.

Sean: No, I love that. And I don’t know if I did this on purpose or I was just making up questions to help continue conversation. But this does play perfectly into where I wanted to go next, which you have alluded to: what helps you identify what is a fire and what isn’t a fire is that data. And without that data, without that knowledge, maybe your first thing you need to do… And set these fires aside, right? We got to set them aside because I can’t truly determine how… And I promise this is going to be a fun analogy throughout this podcast, but how hot is that fire, right? We need to identify how hot is this one? How hot is that one? Until we can truly identify that, understanding what constitutes the fire, that’s one of the first steps.

Sean: So when you think you’re ready to make improvements, what is one of the first changes? Now in this scenario, right, we’re coming into an already kind of implemented scenario. So we’re talking about an experience of the past. We already had Neil’s buy-in, Neil’s approval. Of course we were gathering evidence to justify the choice, but let’s say before we had that, Neil, what made it so that you were deciding you wanted to bring in-house, you wanted to make those improvements, make those changes, where should you start?

Neil: The answer’s a little long. I’ll try and keep it tight.  So for every business, not for profit or otherwise, it’s a matter of budget. And there are very expensive solutions out there and very inexpensive solutions out there. And there certainly was, in my mind, a budget cap for us that said, look, we’re not going to go spend a gazillion dollars on this. It has to be manageable by one person. Don’t get me wrong, there’s more people that act on tickets, but it has to be manageable. We can’t build an infrastructure behind the tool we’re buying because that would sink us. So that was one of the considerations. Another consideration was, I think, well maybe it was part of my experience, right? I’ve seen them all. My clients have been literally all over the map, from insurance companies to nuclear weapons plants. I’ve seen it all.

Neil: So, you know, what worked and what didn’t work, I had a notion of what this should look like. And I was really, really concerned that no matter what the product was, we had to be able to generate the kind of measurement statistics that we actually are generating all the time. That was crucial in my mind to be able to understand what was going on. Another aspect of this that I thought was really important was we have other tech companies that we deal with from time to time. We have a company that supports our existing accounting implementation. We have another company that’s building out our new accounting implementation. We have another company that builds and supports our client management system. And so we needed the ability to route tickets to these guys so that it would flow smoothly without them having to log in to their calgarycounselling.com account to look at the ticket.

Sean: Let me ask you this. This is a great scenario you just brought up.  We’re talking about different support groups routing different tickets to different functional areas of the business. When you guys were launching this project, implementing a service desk tool, did all functional groups have their services flowing through the service desk at the start?

Zeph: Yeah, so primarily in the beginning, it had just been… We wanted to have our essentially contractors have a way to manage tickets better than us having to action every single one and then send it off to them. So, the first goal after we had brought all of our IT operations into the help desk was to find a way to integrate the contractors as well. And so essentially, we sat down with them, discussed kind of the topics that they felt they saw the most. And when we built that out, we looked at it in terms of, what can I handle without having to send to them, because they’re contractors, we have to pay them every time we send something to them. So, what could I action myself, and what should automatically be sent to them because it’s something that can’t be handled on my end? And so, I’ve been still working with them up until last week on building it out to kind of make their lives easier and not have to send as much extra work their way every time something happens in their systems.

Sean: It’s like you’re reading from a textbook as far as how I want to hear these answers goes because the feedback loops, Zeph. You’re cycling back to the feedback loop. And I love it because when we talk about these kinds of improvements, those are exactly the words that we want to hear, right, is how did I determine which improvement to make next? Feedback. One of the important things that I set up for, and we have both parties on the call, is that leadership buy-in. You mentioned at the start of when I asked you, Neil, budget. Not everybody controls budget. So, you need that buy-in, you need the leadership buy-in, not just for the money part, but you need that buy-in for things, let’s say, an idea, an initiative. Even if it’s free and taking your existing tools and moving in a different direction, you need that leadership buy-in.

Sean: Let’s say for example, your normal day to day, I’m going to make an assumption, is managing the service desk tool. Just based off of what we’ve kind of been talking about today. What other initiatives are under your belt, and which ones do you have to put on hold in order to continue managing, and vice versa, r  ight? So, keeping that theme of sacrificing day-to-day operations for making improvements, can you think of any scenarios you can share with us?

Zeph: Yeah. Gosh, it is pretty broad. I tell people most of what I do is help desk, but there’s so much beyond that, and even right now, I think on my task list I have eight other things assigned to me at the moment or something like that. So my primary focus, I like to try and keep my response times with people under half an hour. I like to not have people waiting around all day to get an answer on something. Especially if it’s simple, they shouldn’t have to wait a long time for a response for it. So I try and keep that as my primary focus. And then outside of that, I use my free time in between answering people to try and get other tasks done. Like we had some new switches come in recently, we’re replacing some of the older network switches.

Zeph: So had to come in early outside of regular hours to get those replaced so that I wouldn’t interrupt people. We have another intern who’s doing essentially the same job that I was last year. So I’m helping walk him through and teach him how to do all the processes as well, which adds extra time, because when you’re doing it yourself, you know what you do, you just have to click, click, click, and you’re done. When you have to actually sit down and describe the thought process behind every ticket, it adds a lot of time to it. So, it’s trying to maintain a balancing act of being both timely in a sense that you’re not holding everyone else up but trying to manage all the other projects that you have on the go at the same time. So, it’s difficult to meet that happy medium sometimes. But I do my best.

Neil: He’s doing a great job.

Sean: I agree. That’s why I wanted to bring you guys on. Neil, with that being said, I find Zeph to be an incredibly valuable resource based off of what I’ve heard, right? Sounds like Zeph’s worked with some other valuable resources. From your experience, how do you determine when you need more resources to dedicate to operations versus improvements? You can say budget again.

Neil: It’s always part of the equation. Don’t get me wrong. And we can plan for most things. But in some ways, our world can be a bit of a pressure cooker, and not just because of COVID, because even when everybody was working on-site, there were times when there was just a lot going on. And so a good example is all CIOs, including me, I’m always looking at… Well, I’m looking backwards in the context of what are the tickets telling me, but mostly I’m looking forwards. I can’t do anything about yesterday, but I have to be doing something about what do we look like five years from now, eight years from now? Now our business, this business particularly, is very transaction oriented. How many clients do we see in a week? Well right now, that’s averaging about a thousand. The question is where are we going to be in five years?

Neil: And in five years, look, I don’t have a perfect crystal ball, but I’m always assessing what we need in the context of, well, if our transaction volume is at 2,000 a week, there’s a lot of things that have to change. If we stay where we are, we’re probably in a good spot for now. So I’m always judging that, and what I’m always looking for is where is the operational friction? Because any place where we can remove friction is, over time, a place where we’re not hiring a body. So in that context, to bring somebody else to support Zeph, it’s pretty straightforward. It’s transaction driven, right? If our volumes are going up, we have to meet that demand. If there’s something going on where we cannot reduce some friction, then we may have to supplement that with a body. Now that’s something we actually really hate doing.

Neil: I live in this technology world, and any time somebody tells me they are hiring a body because of some process, my heart sinks, right? It’s like… That’s not a value-added proposition. It doesn’t help anybody. You’re hiring somebody into a job that’s not really a great job. And you’re doing that to supplant something that should be handled with technology so that when we hire people, we want them operating at a much higher level. So those are the things we think about, I think about, all the time, where’s the friction, how are we going to manage it?

Sean: So, I like that. That makes me think of something else. And it has to do with the resource, right? We talked about resources initially. Zeph was a resource dedicated to discovering, which is a good platform to use going forward, and then implementation. When we think about those resources, Neil, in your opinion, what makes more sense, is it a mix, would you rather have dedicated resources to just implementation, just to improvement, or should it be everyone’s role?

Neil: There’s no perfect answer here. The answer is always circumstantial. I can explain it this way. Implementing a new accounting system, yeah, we’re going to hire somebody. We have hired a little company. They are implementing for us, but they’re not going to be the long-term supporters of the solution. That’s somebody else’s job, who happens to also be a contractor, but that’s more of his thing to do. At some point, that person’s role might be better off by being an employee, might be. And I’m looking hard at that over time. But right now, that’s an outsourced role. The same thing with our client management system. That is a very unique product. We built it because there was no commercial product available. The company that built it for us, we’ve been working together for 20 years. And I imagine they’re going to continue to do that.

Neil: But when you look internal, you say, well, what kind of resources do we need? A lot of the work that is technologically supported, well, everything is, but where there’s real things going on daily, is our admin staff. Now our admin staff, they’re in the accounting system, they’re in the client management system all day long, and so that’s where, one of the places where we see friction, and that would be a place where… Those are the people we go to to find out that tickets are telling us this, give me color. I need to understand the color, the background. Why is this a problem? And they ultimately, sometimes we hire more admin staff. Sometimes we hire temporary admin staff, and it works out that we needed them because of a certain problem. But when the problem went away, we didn’t want to let that person go. She was too talented.

Neil: And then we found out that there was a need for somebody with skills like that in another part of the organization. And that’s where she went. So, we keep people when we need them. But again, because our business is so transactionally driven that when volumes go up, which… I’ve never seen them go down, actually. When volumes go up, we have to staff accordingly. But we really test it very carefully.

Sean: Do you ever feel that there’s a place, or would there be a place where maybe business is well oiled enough or maybe it’s not oiled enough that you need a resource whose entire job… Think of project management – their job is simply discovering areas that need improvement and helping drive that change. A resource like that.

Neil: That’s like a business analyst type role.

Sean: Sure.

Neil: I absolutely see the possibility that within the next two to three years that kind of role would be a permanent hire because the company doesn’t need a full-time CIO. We don’t. I volunteer my time. I’ve volunteered 100% of it for the last two years on purpose. But in reality, my role could probably be filled. If I wasn’t around, we’d have to pay somebody for eight hours a week, maybe, right? At my level. But we would definitely have to supplant that person with a real business analyst, right? Somebody who knew how to tear into literally any part of the business, figure out what questions to ask, how to analyze the problem, and how to propose, hey, how are we going to fix this? And why is this a problem I want to fix and not that one? Identifying what’s strategic and what’s tactical is always very difficult.

Sean: Yeah, no, loud and clear. And I like this conversation, because there’s some folks who might argue one way versus the other, which is why I said, is it more well-oiled that constitutes a BA, a business analyst, or is it less oiled? And the way that you’re foreseeing it in your organization is after you guys have reached a certain level of maturity to continue being able to focus and maintain growth and momentum, let’s make sure we have a BA who’s always looking for areas to remove, and I like the term you use, that operational friction.

Neil: It’s sand in the gears. It’s actually at times shocking what you find out because in all businesses, and certainly ours, the staff, when they encounter a problem, they will work the problem and come up with a solution not knowing that there might be a much better, easier way to solve this problem. And sometimes the problem gets so bad, and I have experienced this, that somebody comes to you in tears. I can’t do this. This tool is wrong. I can’t use it. I’m like, this is the first time I’ve heard that. Why did you wait so long? Our job is not to torture you. Our job is to make your life better. You used this tool for 15 years. If it’s the wrong tool, we’ll get another one, right? Pick the one you like. So it’s that kind of thing that you have to be very sensitive to because people won’t always… You don’t want them coming to you in tears in the first place, but you have to keep digging to find out where are the issues?

Neil: And sometimes it’s not obvious. Another great example is we’ve been lucky enough to become completely 100% digital. We have shut down our file room. All our files are electronic now. And one of our senior staffers had a great… Still has a great tendency to create lists of things. And the next thing you know, I could be having a meeting with this person, and they’ll pull out a spreadsheet and start telling me that they’re recording information here. And I’m like, what the heck is this? Well, I have to record this information. This is the place… No, no, no, no, no, no, no. What you have to do is tell me, and let’s figure out where we should put this information. And then we go and modify whatever application is appropriate. And that’s where they start entering the data. But people will just create a solution, right? That’s their natural tendency. I’m going to do my job. I can keep a list. Yeah, that works for a while but doesn’t work forever, and it will get you in trouble.

Sean: So that kind of observation, Neil, bleeds into part of the question I’d asked earlier, which is is it everyone’s responsibility to be looking at areas for improvement? Just seeing that staff member without that spreadsheet to you meant area of opportunity, opportunity for improvement. So I know that there’s a bone in you that says everyone’s job is part continual improvement, right? Part momentum for change. What percentage would you throw at that? You can make a number up.

Neil: Well, I think I’m going to answer it in a different way. And the answer may surprise you. We constantly search for feedback, not only in the help desk ticket system, right? That’s one mechanism. Dealing with the counselors, they have a really tough job because nobody graduates with a psychology degree or an advanced degree in psychology or social work with the knowledge of how to run a practice. They have no clue. They’re not taught that. And when they come to our organization, we have to teach them our way, and let’s face it, that can feel restrictive to some people. And so part of my job is to maintain constant discussions, certainly with the leaders within that part of our business, to understand what they’re hearing, what needs to be better, what could we do better? All of those things.

Neil: And sometimes we act on those items, and we actually keep a punch list of all the things we want to do to improve in our client management system. It’s a very long list. Sometimes people ask us if they can do certain things, and they propose solutions, and the answer is no. And not only is the answer no, but it’s frequently, this is not a democracy. You can actually ask for things, and a lot of people have really great ideas, but at the end of the day, only one idea can survive this problem. We can’t be all over the map. We have to focus in on overall the best way of solving a problem for everyone, not just for one group. That’s a tough pill to swallow for a lot of people, right? They get very attached to their ideas. They don’t understand why the answer is no, but no means no. And it’s a pretty serious thing.

Sean: Have you heard that before, Zeph? Have you heard the big no?

Zeph: I think there’s been a couple things I’ve raised where that was the answer for it, but it makes sense. Like I’ve said, it’s easy to sit here in your own head and think, yeah, this makes sense. But once you present it to people, they have a really good way of picking it apart and making you understand no, this was actually not the right approach to take for that.

Neil: Yeah. So I’m very old school in that way. And the way I try and explain it is our user’s job is to tell us what they need. Tell us your requirements. We need to know that. It’s not the user’s job to pick solutions or to design processes on their own. It can’t be that because from my spot in the pyramid, the things that I have to worry about go way beyond, hey, this is a cool-looking product. We look at is the data geofenced in Canada? Is the security something that we could live with? Does this require encryption? Is the vendor of a reputation that we… On and on. There’s so many things that we are concerned about. Is there data collection going on based on our traffic between us and the cloud vendor, even if they’re geofenced in Canada? Can we allow that? These are really big questions, and users are frequently surprised when I explain why the answer is no.

Sean: No, and that’s super important to understand, right? But the feedback is what I think is even more important of a takeaway is that you’re giving them the opportunity to present the feedback.  Even if the answer happens to be no. Now, Zeph, there’s been a common theme. What have you done when you saw that there’s been a problem with one of your improvements and you had to kind of circle back and take a learning opportunity from that so that when you wanted to, let’s say, let one of those fires burn and let’s try and focus on improvements, right, how have you taken… a failed experiment and turned it into a win through knowledge?

Zeph: Yeah. Well, we actually had this not too long ago when we had attempted to move some of our manual invoice processes into the help desk because we had discussed with admin, what would you guys like to see to simplify this on your end? Because they’re very complicated processes, crazy complicated. And we spent a good amount of time building them out and testing them. But when we actually revealed this to all the counselors, the reception was very frosty. They actually gave us quite a bit of pushback on it. We were kind of surprised by it. And it turned out that a lot of it had been a failure, not so much in what we had built itself, but in how we had presented it to them and explained how this new system was going to work.

Zeph: And essentially what it took for me to fix things with everybody is sitting down and actually walking them through how the process worked and having them show me what they thought might make improvements for it as well. Because up until that point, we’ve really had only taken admin teams notes on how it looked and not as much the counselors. So, we tried to fold as much of their input in to make it a little bit simpler for them while still maintaining all the points that admin wanted us to keep in unveiling this product. So, it gave us some good feedback for the future on how we should be building out these processes but also just how we delivered the announcement of it to make sure that it lands stronger than this one did.

Sean: So, if you were to summarize that, because I have my own inference of what caused it to not be successful, which step was missed in that specific example?

Zeph: I think the biggest one there was communication.

Sean: Communication. I gotcha. Yeah. So not all of the necessary stakeholders were involved in that.

Zeph: Correct.

Sean: And when you talked about gathering data from the admins, that’s kind of where my whole full-circle scenario was going to come in, which is data. The whole theme of today was talking about, we’ve got fires in our organization, how do we determine what to let burn to make room for improvement? How do we even determine how to make improvement? Everything’s coming back to data, so a better understanding of what you’re doing, how you’re doing it, what needs to be done, and as Zeph just identified, who’s involved? I think identifying who’s involved is a step that especially smaller organizations can forget sometimes because they don’t have the right organizational chart, maybe. The dedicated resources might not be as familiar with BA work, project management work – a lot of what I’ve seen is help desk managers trying to do a lot of this business relationship management or lack thereof.

Sean: So… And I loved that simple example, but how can you transform that into a practice, to take your exercise of implementing, even if it was successful, even in this case, if it wasn’t quite successful, and do a postmortem to identify what could we have done better, right? What are good ways to make it a practice?

Zeph: Yeah, well, I would say the first step we should have taken was identify in meeting with all parties that were involved with it, not half of them like we did this time, and including them in the full process of building it, because when we were building out all of the spreadsheets and forms and eventually what it would look like in SolarWinds, I think I met with admin probably three or four times to walk through the changes that we made based on the discussions that we had. And I think if I had included the counselors in the same manner that I had included admin, it would’ve led to a better result right off the bat. And I think going forward as we aim to not only add more manual invoices but the next big process that gets folded in, it’s going to be important to continue to have that amount of collaboration while we are building that process.

Neil: With all our students on board, this fall, we’ll be in the 150-person range. So that’s not a very big organization, but you could see, transactionally, we are quite large. But the biggest thing that I think that you’re talking about here, and I think I’ve minimally introduced this concept to you after we had this problem, Zeph, was the concept of a RACI chart. That’s the place to start because you got to know who’s getting this done, who are we consulting with, and who are we just informing?

Sean: Just to break it down for everybody, go ahead with what is a RACI?

Neil: RACI is… So, it’s a very simple way of classifying different activities in a project. It’s a place where you literally always start when you’re identifying a project. As you get into it, you’re identifying all these activities, imagine them as rows, and then imagine columns, and one column is R, “responsible”, that’s usually the person doing the work. A is who’s accountable, only one person can ever hold the A. Typically in a project like this, Zeph would’ve held the A and the R. And who owns the C, which groups? Well, that would’ve been the admin staff and probably some of the counseling supervisors. Because you can’t do all of them, but we certainly can engage some of them, right?

Neil: And I is “inform”. Who are we telling? So, we just tell because they need to know that it’s coming. So ultimately when you roll this stuff out, well, you’re going to tell all the counseling staff. Great, because they need to know, and you better identify all of them. So that’s what we mean by a RACI. Great way to build out a project. It’s a living list. You can add, modify as the project proceeds, it gets more and more complex, but it’s a great way to make sure that you haven’t missed anybody or haven’t missed a step.

Sean: No, I think that’s a wonderful way to make sure that in that scenario we get all the right stakeholders involved. Yeah, absolutely. So, to really wrap things up, I wanted to choose this topic, and I like this concept because I’m an ITIL study, so in ITIL, I like to think of incidents, right, as your fires. Someone says, “I have a problem.” Well, in your IT language, that’s an incident. That’s just you, your service is down, we need to get it fixed. If you have many people submitting the same kind of incident, right now we’re reaching into the problem territory. So, I like to think of my incidents as my fires and my problems are my spark.

Sean: So, when do we make room to address the spark and not just say, I need to keep putting out this fire? And the whole thing kind of circles around a collection of data. It circles around having resources dedicated to making these improvements. We can’t just keep answering one ticket at a time. We could instead stop allowing these tickets to need to be created. So, I love this concept. I love this analogy. Thank you so much, Neil, Zeph, you guys have been great joining us today.

Neil: Thank you. It’s been my pleasure. This has been a lot of fun.

Zeph: Thanks for seeing, I guess, the value and work that I had put into building out our help desk and giving us the opportunity to be here. It means a lot for me.

Sean: Thank you so much for joining me on SolarWinds TechPod, and a special thanks to Zeph and Neil for joining us and to all the listeners out there. This is Sean Sebring, your TechPod host. Thank you.