Change can be scary. There's no denying that. And when a company’s entire infrastructure is at play, even more so. Whether you’ve just decided to take your company to the next level by unifying all your teams under the same service desk. or you are looking to transition into a brand new service desk platform, a well organized and smooth implementation process ensures that your foray into this new territory is as hassle-free as possible.
In this piece, we’ll walk you through 5 things you can’t overlook when organizing and coordinating your implementation project plan. We’ll do an overview of the architecture and main roles involved as well as how to finesse the transitional period into a new service desk.
1. Scope, vision, and the company’s current state
When we talk about scope, we are essentially trying to gauge which aspects of the company will be affected by your service desk implementation. Are you going to move all your teams into one consolidated service desk platform? How many teams are going to be working within the same framework? These are questions you should be asking yourself even before you start mapping out your implementation project plan but especially during it.
Vision has to do with long-term planning. It has to do with what you are looking to achieve with this implementation. Clearly stating which are the goals you want to achieve with this service desk implementation will work wonders when trying to clue everybody in. You always want to work in tandem with your service desk KPIs and your IT knowledge base so that you can effectively measure how successful your implementation has actually been, but having a game plan with what you are expecting to see aids you towards that goal.
You can’t really look to expand your horizons if you don’t know where you are standing. Looking at your company’s current ITSM metrics and performance indicators can not only help you determine what the aforementioned scope and vision are, but also if your business is at a point where all of that will be achievable.
2. Clearly-defined architecture and roles
Since service desks add a brand new administrative layer to any business, knowing how the service desk will be intertwined with the company’s current infrastructure is absolutely necessary in a service desk implementation project plan.
This also includes a (preferably) visual representation of how the different roles will be connected or who will deal with customers or users directly, just to name a few. Here’s a quick overview of some roles you should definitely include in your implementation project plan:
- Service Desk Manager (SDM): They are in essence, an operation role that is in charge of overlooking service desk operations at all times, monitoring tickets that need attention (often times exceeding escalation level thresholds if necessary; read up on help desk manager duties). SDMs call the shots in terms of service monitoring, as well as giving agents a heads-up in case of alerts or if news about service interruption are being announced. As a managerial role, SDMs are expected to actively collaborate in processes of service desk improvement.
- Service Manager On Duty (SMoD): One could call this the visible face of the service desk infrastructure. They will be in charge of assisting and helping users with particular situations during working hours, as well as arbitrate and aid in complex problem resolution. However, something to keep in mind is that SMoDs don’t have operational responsibility. This means they won’t be in charge of answering help desk phone calls or enter tickets themselves, for example.
- 1st line support: These employees are, as their name imply, the first person users will come in contact with when seeking assistance. Generally, 1st line support agents trade depth for scope width. They know a little about everything, so to speak. While they might not be specially trained for a specific area, these agents stand out in terms of communication, language knowledge and they have a good mastery of service desk tools.
- 2nd line support: Agents who belong to this category are, in a way, the exact opposite of what 1st line support agents are. They have very deep knowledge of specific service domains and their training is highly specialized to their area. So specialized, in fact, that 2nd line support is oftentimes outsourced.
For more information on this, here's a handy explainer about the 5 levels of IT support.
InvGate Service Management is an example of a service desk tool that can help you obtain that clear service architecture and implement it effectively. It supports gamification, a robust self-service portal and knowledge base, and has an intuitive UI that will help you deliver an amazing customer experience.
There’s a wonderful example posted by Reddit user lfernandes on the Managed Service Providers (MSP) sub-reddit of what a possible configuration looks like and what his experience has been with that particular configuration:
“We are setup in a tiered system - we have our tier 1 techs who work most issues (our tier one are admittedly much higher qualified than most tier ones, typically jr sysadmin in a lot of ways, green in others. Our tier one escalates to the sysadmin board, sysadmin works until they can’t and escalates to the NOC, following our escalation procedures and timelines in both cases.
We do have assigned techs for batches of clients. We’ve got something like 650 clients and we have 4 teams that support them. The teams consist of a manager, a few TSSs, and a couple SAs. Each team has their own board, but the sysadmin and NOC teams share a board - one for each.
Pros:
- White glove service. Our techs know their client subsets inside and out and can provide a much higher level of service.
- Clients get to know their techs and often are happier to work with someone they know, less likely to give someone they know and work with all the time a hard time as opposed to a random agent.
Cons:
- Lose the ability to “drag and drop” techs from one team into another.
- One person out sick/vacation/etc hurts more than if it were a huge pool”
3. A risk management, issue tracking, and resolution plan
That’s a lot of plans, isn’t it? Worry not, as these three plans are inextricably bound to the same concept: fixing/preventing things from breaking. Plus, they are rather simple to understand. Let’s analyze each one of them separately:
- Risk Management Plan: This basically involves determining how to prevent risks or deal with possible fallout in the event of a nasty episode. A common practice is to propose project team meetings, interviews, or discussions with stakeholders. After identifying the risks and it’s likelihood, the impact on the project is discussed. Additionally, it’s recommended that a risk tracking list is always available for project managers and stakeholders.
- Issue Tracking and Resolution Plan: We’ve merged these two into one big plan because it’s common to see these two plans show up as one in many project plans. It ties into what we mentioned in the previous plan, as this plan clearly details how issues will be tracked, how the issue escalation will work and which are the possible resolution approaches according to the issue’s nature. In this section of the service desk implementation plan, we really want to be as detailed as possible. Prevention is key but swift action in face of an issue can be the difference between a successful reso4lution and an extra long night shift.
4. A communication plan
This one is pretty simple. You want to have a concise and easy to understand chart where you delineate how communication should be handled. You want to let everyone know how to reach agents, team leaders and specific service desk areas in case they need to. To better explain how you should go about doing this, we could simplify it by considering these entries in our hypothetical chart:
- Target audience: Basically, which area of IT you want to reach. Yes, you will most likely talk to just one person but we are talking committees, the help desk, entire areas or communities here.
- Primary contact: Now this is what you might have thought target audience was. This is literally the person/people who you’ll me contacting. Depending on what the target audience might be, you might have to contact more than one person. Never above 2 more people, ideally.
- Communication mechanism: As the name implies, this is the “how”. Will it be just by email? Will a message pop up on their service desk interface? Will it be through in-person meetings or presentations? You want to be clear and to the point so as to avoid confusion.
- Frequency: How often will these communication instances happen? Plan this according to urgency of response and the area’s needs. Perhaps committees are held monthly while direct contact with the SMoD is needed daily.
- Purpose/description of communication: Here, you’d describe what kind of information you’d likely share. Perhaps the purpose might be just routinely updates, while others might have to do with planning and decision making.
5. The location and necessary tools
Last but certainly not least is the actual physical space where all this Service Desk infrastructure will be placed. Yes, perhaps a big chunk of it will be handled virtually but not all businesses offer products or services that can be delivered virtually, of course. Thus, accommodating for these instances where you might have a literal desk with someone tending to the needs of customers and a whole other team that provides assistance remotely is extremely important.
Just like with architecture and roles, you want to have a visual representation of the premises and where servers and different service desk areas will be located. A detailed blueprint of how things will be placed is ideal. Here's a list of 5 things to consider before moving to a cloud-based ITSM solution.
The same thing applies to all the software and hardware that will be needed to implement this new service desk infrastructure. How many pieces of hardware will you need for my help desk operations? Are there any compatibility issues you should be looking out for? How much does all of this cost? Who will be your vendor? Cloud vs. on-premise: which is better? All questions that should be taken into consideration when planning this out.
The bottom line
You really want to know where you are and where you want to be. What kind of impact you are looking to have on your business with this service desk implementation. Additionally, you want to make sure your service desk’s architecture and its roles are clearly defined (ideally create a flowchart that illustrates the different moving parts and delegations).
Another aspect to keep in mind is just what is the level of risk of such a maneuver. Keep in mind what could go wrong and how the company should respond to such occurrences. Also, letting everybody in the company know just how and when they should contact committees and teams as clearly as possible. In our detailed explanation we proposed perhaps having a chart that sums everything up in a neat way.
Finally, know exactly what you need to get the ball rolling and where this will all take place in. Think about the premises, just how much space you have available, if you will lease part of the equipment or if you will use a cloud-hosted infrastructure instead.
