Half the project is about people

An ITSM system can be configured in a few weeks. Getting an organization to stop emailing the technician they usually email takes longer.

The implementations we have seen fail have almost never failed due to the technology. They failed because the process was perceived as an obstacle, and was therefore bypassed. A bypassed process provides less traceability than no process at all.

Therefore, plan for communication and buy-in as part of the project, not as something that happens afterwards.

Start with two processes

The most common mistake is to implement all of ITIL at once.

Incident management first. Highest volume, clearest benefits, and easiest to get people on board with. Registration, categorization, prioritization, and assignment.

Then requests. Orders via a service catalog with approval workflows. Start with the ten most common – not a catalog with sixty items.

Once those two are working and the statistics start to become useful, it is time for change management, problem management, and CMDB. By then, you will also have the data needed to build them correctly.

What you should prepare

A picture of the current state. How many tickets are coming in, how are they arriving, and what are they about? If you don't have any statistics, that in itself is a reason to implement the system.

A designated system owner. Someone with the mandate to decide on categories, prioritization rules, and SLAs. Without this person, the project will stall between meetings.

The services you actually deliver. Harder than it sounds, and the foundation for both your service catalog and SLAs.

The requirements you must meet. Audits, ISO certification, or NIS2 affect how change management and logging should be structured. Include these from the start instead of trying to patch them in later.

The phases

Mapping. Current state, services, workflows, integrations, and target state.

Basic configuration. Ticket types, categories, priority models, SLAs, permissions, and queues.

Portal and service catalog. Self-service for the most common requests, with approval workflows where needed.

Integrations. Microsoft 365 and Entra ID first, then monitoring and documentation.

Automation. Assignment, escalation, and account management for onboarding and offboarding – see automation.

Training and launch. Technicians and administrators first, followed by information for end users before the portal opens.

Follow-up. After a few weeks of operation, we adjust categories, SLAs, and workflows based on actual usage.

The portal determines how the project is perceived

For most people in the organization, the self-service portal is the entire ITSM project. It is the only part they see.

It must therefore be faster than sending an email. A few clear choices, predictable feedback, and no forms with twenty mandatory fields. A portal that feels cumbersome will lose to the shared inbox every time, regardless of what management has decided.

Where things usually go wrong

Too many categories. A structure with sixty options is filled out carelessly and thus becomes useless as a data source.

SLAs that are not met. Set levels you can manage with your current staffing. A promise you break every week is worse than no promise at all.

The change process is built too heavily. If everything requires approval, everything becomes urgent instead. Start lighter than you think you need to.

End users are informed too late. The portal opens on Monday and no one knows why. This leads to an unnecessary spike in tickets and a poor first impression.

Why us

In the ITSM space, we are the largest and most experienced distributor and implementation partner in the Nordics for HaloITSM, and we also provide Freshservice. This allows us to focus on what you actually need, rather than what we have to sell.

If you are looking to switch from an existing system, see migration to HaloITSM.