Public administration has a binding method for its projects. For what comes after the project, it has none. Why this gap has, since April 2025, become more than a matter of tidiness.
There was once a document meant to connect HERMES and ITIL. It was called eCH-0109 "HERMES und ITIL verbinden" (connecting HERMES and ITIL), published in 2009 and withdrawn in 2014. It was never replaced. That is not a detail for method enthusiasts. It describes the problem quite precisely: Swiss public administrations work with a recognised standard for the path to a solution, and with none for the life that follows it.
1. The standard that once existed
eCH-0109 was never a major undertaking. It was an aid, essentially a table that mapped HERMES deliverables to their corresponding ITIL outputs, so that project managers and operations managers could find a common language. It was withdrawn on 3 September 2014. Since then, the eCH association has published standards on project methodology, portfolio methodology, identity and access management, and archiving. On the question of how an organisation runs its IT services in operation, there is none.
You could shrug this off. Standards get withdrawn when they become outdated. Except this one was never replaced, and the question it was meant to answer has, if anything, grown larger since.
2. What HERMES delivers, and where it deliberately stops
HERMES is the project management method of the Swiss Confederation. Federal bodies have been required to use it since 2015, and many cantons, cities and federally affiliated organisations have adopted it too. As eCH-0054, it is a recognised standard, currently at version 3.1.1 from January 2026. Anyone setting up an IT project in Swiss public administration works with HERMES. That is not a matter of preference.
With HERMES 2022, the method gained a phase model that allows classic and agile approaches side by side. In the classic path, a project runs through Initiation, Concept, Implementation and Deployment. In the agile path, a single phase sits between Initiation and the end, called "Umsetzung" (delivery). Both paths finish the same way, in the Closure phase, which was newly added with the 2022 update.
This is exactly where opinions diverge. A project has an end. A service does not. HERMES, as a project method, is designed to reach a conclusion, and that is not a flaw, it is correct. The mistake only happens where an organisation believes the job is done once it reaches the project closure milestone.
3. HERMES builds the door. Not the house behind it.
To be fair, HERMES does not ignore operations. The method has its own "Modul IT-Betrieb" (IT operations module), a task called "Betrieb realisieren" (implement operations), a deliverable called "Betrieb aktiviert" (operations activated), and, in the "Betriebsverantwortlicher" (operations manager), a role that represents the operator's side within the project. There is even a defined deliverable called the "Betriebshandbuch" (operations manual), which describes across twelve areas what the operator needs to know: system overview, "Betriebsaufnahme" (go-live), monitoring, support organisation, change management, security provisions.
That is more than many project methods offer. And it still is not enough.
Because the operations manual describes one system. It says how this one business application is operated, who monitors it, how a change to it proceeds. What it does not say: how the wider organisation works, the one that also runs two hundred other systems alongside it. Whether this application's escalation path is the same as everyone else's. Whether its incident classification matches the existing one. Whether anyone even has an overview of which services the administration actually owes its departments.
HERMES delivers a clean handover per project. What is missing is the framework the handover is made into.
4. What ITIL contributes, and what it does not
A clarification is due here, because it regularly causes friction within public administrations: ITIL is not a competitor to HERMES. The two answer different questions. HERMES answers how you get from an idea to a solution ready for operation. ITIL answers how an organisation runs services that have long been live.
ITIL 5 makes this division of labour more visible than earlier versions did. The new version's lifecycle runs from Discover through Design, Acquire, Build and Transition to Operate, Deliver and Support. The first five stages largely overlap with what a HERMES project does. The last three begin exactly where HERMES celebrates its project closure. That is not a contradiction between two methods. It is a connection point.
The honest caveat belongs here too: ITIL is not mandatory, not for the federal government and not for the cantons. It is not a norm but a collection of good practice, and nobody is audited against it. ISO/IEC 20000 is certifiable, ITIL is not. So anyone waiting for a regulation that governs the operations side the way HERMES governs the project side is probably waiting in vain. No authority closes this gap. Every organisation closes it itself.
5. Since April 2025, the gap costs money
Until recently, this was a matter of tidiness. Annoying, but tolerable. That has changed.
Since 1 April 2025, Switzerland has had a reporting obligation for cyberattacks on critical infrastructure. An attack must be reported to the Federal Office for Cyber Security (BACS) within 24 hours of its discovery, with the full report to be completed within 14 days after that. Failing to report risks a fine of up to CHF 100,000. Under the Cyber Security Ordinance, the reporting obligation explicitly extends to cantonal and municipal authorities too, though a catalogue of criteria and thresholds sets out exceptions.
24 hours is not a project question. It is an operational one, and it gets decided the moment the attack is noticed: who detects it, who classifies it, who decides it is reportable, who actually files the report? These are precisely the decisions an incident management process makes, and no single application's operations manual can provide them. An organisation that only sorts out its operating structure after go-live already has the clock running when the real incident hits.
A word on NIS2, because the directive often comes up in Swiss meeting rooms as though it were already applicable law: it is not. There is, to date, no formal recognition of the Swiss rules as NIS2-equivalent either. It is felt anyway, through supply chains and through European clients who pass their requirements down the chain. Anyone working for the EU market gets asked for evidence, whether the directive binds them directly or not.
6. Four handovers that make the difference
Nobody needs to invent the bridge between HERMES and ITIL. It consists of four decisions that an administration can make itself, and none of them requires a project.
- Appoint the operations manager early. HERMES provides for the role. In practice it is often filled only in the Deployment phase, once the architecture is already fixed. Appointing it from Initiation onward builds operability into the design instead of adding operating costs as an afterthought.
- Treat the operations manual as a record, not a document. A manual that sits in a folder after go-live starts ageing from day one. The same information held as a service and configuration record in the existing ITSM tool stays part of live operations.
- Clarify the reporting path before go-live. For every system that falls within scope, it needs to be documented before the production start who decides in a suspected incident and who files the report. After the production start, it is too late.
- Tie project closure to an operational condition. A project counts as closed once the service is listed in the service catalogue, has a named owner, and is known to the incident intake. That single condition prevents more orphaned applications than any amount of retrospective documentation.
Conclusion: two methods, one handover point
HERMES and ITIL do not contradict each other. They touch at exactly one point, and in most public administrations that point is unstaffed. Not because anyone was careless, but because one side has a project end and the other has no project start, and each side assumes the other is taking care of it.
The withdrawn eCH-0109 is a fitting symbol of this: a narrow bridge, dismantled, and missed by nobody — until it mattered.
Our practical tip: Take the last application your organisation put into production and ask three questions. Is it listed in your service catalogue? Does it have a named operations manager who is still with the organisation? Does your incident intake know it exists? If you cannot answer one of these questions, the gap is not somewhere in the future. It is already behind you.
Request a no-obligation conversation
Florian Nitz is a Consultant at Qudits AG and an ITIL 4 Managing Professional. He is responsible for technical and digital projects — from IT service management to the further development of digital platforms — and combines strategic clarity with pragmatic execution.
Thomas is Executive Partner at Qudits AG and an ITIL V3 Expert. His focus lies in managing complex IT programmes and projects — particularly in the life sciences — as well as in building and continuously improving IT service management organisations. He develops teams and people with passion.