Top 5 Costs Clients Don’t Anticipate When Deploying an ITSM Platform
Here’s a common scenario. Your organization evaluated various incident management platforms or ticketing systems. After months of research, you’ve settled on the most robust, feature rich, ITIL friendly platform, one that has infinite capabilities and addresses every conceivable need for all IT departments. On top of that, the vendor of choice is one of the leaders in cloud-based IT Service Management software. A safe bet for any CIO, right? However, upon deployment, you quickly realize the product doesn’t automatically deliver everything you had expected out of the box. As it turns out, nothing about releasing a new ITSM platform to your IT environment is as simple as plug and play. On the contrary, due to those countless, customizable features, it will require extensive development to enable it to perform even the most basic functions. If this sounds like you, you’re not alone. In fact, some companies are still struggling with the post-implementation blues years after the initial purchase.
So if you’re on the market to deploy your own ITSM system in-house, here are the top 5 cost considerations that frequently go overlooked:
1. Product Purchase/Subscription Fees
While getting a total price at the bottom of all those line items is easy enough, to get an apples-to-apples quote, some upfront questions need to be asked such as what are the base product IT user license fees? Are there additional fees for non-IT users who access it or perform service request approvals? What are some of the optional product features and are there fees associated with them? Examples might include asset discovery/CMDB import tools, dedicated server fees (common with cloud-based solutions allowing purchaser to use a server dedicated solely to them), additional instance fees (for access to a second instance of the software often used as a development sandbox), and enhanced data center security upgrade fee (ensuring data center meets the security standards required by financial institutions or healthcare organizations required to operate within federal guidelines).
2. Development Team Costs
Since a majority of the legwork involved in the implementation process will be performed by the development team, getting a clear understanding of the actual number of hours each individual contributes to the project is essential to determining your actual costs. For in-house staff, what are their salaries and benefits on an hourly basis including time for ongoing training to use the platform itself? If hiring consultants or another third party to perform those tasks, how are they invoiced? How many different developers will be assigned to the project? If they don’t have the same familiarity with system (i.e. the same product development experience as the product owner) or sufficient knowledge of your organization’s processes and environment, how does that tally from a time is money standpoint?
In some instances, the cost of skimping on a skeleton crew or even a lone developer may have long-term impacts associated with limited functionality such as self-help tools, FAQs, and populating a comprehensive knowledge base. When backend development is prolonged due to lack of internal personnel, client IT management have forced end users to either call the service desk directly or select from a very limited service catalog while it remained “under construction.”
In the interim, smaller teams tend to focus on reworking the Incident Management application which requires custom workflow development and a plethora of custom forms. These tasks can be time-consuming enough with a larger development team, but they quickly become overwhelmed with a smaller team and directly lead to a lack of focus on reporting. Larger priorities, at least initially, are often customizing and implementing Service Request Management, Problem Management, Change Management, Configuration Management (CMDB), and fully flesh out the Service Catalog and customer satisfaction tracking system. That’s if they don’t already have their hands full with Asset Management or moving from SharePoint to Knowledge Management solution. When you consider the ambitious workload in just getting the ITIL framework in place, it’s understandable that reporting would take a back seat.
As for training on the new system, what administrative, developer, and end-user oriented courses are offered by the product owner? What are their costs? How long are the sessions and are they conducted remotely or via a Web Ex? Are video tutorials offered for employees newly on-boarded after release? Does the training include step-by-step instructions for interacting with the Service Desk including submitting an incident or service request via the Service Catalog contained within the portal? Organizations can certainly develop their own in-house training materials and programs, but unless they have full-time training staff already on their payroll, they must consider the productivity costs of other staff being redirected to training functions on an intermittent basis.
4. Quality of Reporting
More often than not incident management tools are limited in terms of the types of standard reports they can generate on day one. This virtually guarantees custom reporting development will be necessary to retrieve business-critical information. To that end, it’s important to consider how flexible and intuitive the ad-hoc reporting tool will be for the IT management staff to create on their own versus kicking it back to the development team. Also, how accessible is the backend data required to deliver advanced reporting capabilities?
Some clients take years and thousands of hours of development before they can even attempt to create management dashboards that enable operational analytics such as tracking open and aging tickets and other performance metrics. Some tools don’t support time-based reporting analysis, but merely provide a single graph type of report and do not support dashboard-style reporting out of the box. Database backend manipulation and reporting of data is prohibited from an ethical and best practices standpoint which forces developers and staff to work exclusively with the ad-hoc reporting tool which may also impede more advanced report development.
5. Product Installation to Release Time
In order to transition from mere uploading of the ITSM platform to the server for release to the end user population, additional support staff time and compensation must also be taken into account including project manager who oversees the process and conducts touch point meetings, existing staff leveraged for the duration, the committee reviewing priorities, task lists, timelines, approvals, etc. Despite the full-time team effort, there are often developmental delays related to unforeseen compatibility issues in integrating with other homegrown or proprietary systems. Usually, quality control staff test and evaluate impacts in a beta environment before final approval on rolling out the nascent system.
Can all of the above be handled in-house by any organization? Absolutely! With enough time, resources, and expertise a winning ITSM platform can be developed to its utmost potential. It’s all a matter of being prepared, budgeting appropriately, and if any resources are limited to establishing realistic expectations and priorities of what can be achieved in the short term. If not, the long-term costs may be a lot more than you bargained for.