HERMES is the project management method of the Swiss federal administration and the de facto standard for many public projects. Anyone working as a supplier to the public sector, or running a project inside an administration, meets it sooner or later — usually as a requirement rather than a choice.
The first reaction is often resistance. HERMES looks formal, document-heavy and slow. That impression is not wrong, but it misreads what the method was built for. It is not an answer to how to ship software fastest, but to how an administration steers a project traceably when it is financed with public money and runs across several terms of office and changes of personnel.
What the method actually solves
In a private-sector project, a management team can take a decision and reverse it later without explaining itself. In a public project that is not possible. It must stay traceable who decided what, when, and on what basis — to the supervisory body, to financial control, and to a successor who asks the same question in three years.
That is exactly what the phase approvals are for, the ones that look like bureaucracy from outside. They force a documented decision point: is what we have achieved such that we continue? That question goes unasked in many projects, and undertakings run on because they are running. HERMES turns continuing into a deliberate act.
Scenarios instead of one size
The most common criticism — that HERMES is far too heavy for small projects — does not hit the method but its application. HERMES works with scenarios: depending on the type and size of the project, a fitting cut is chosen that determines which outputs are actually produced. A small project produces correspondingly few.
In practice that tailoring is often skipped. A team takes the full list of possible outputs and works through it, because nobody wants to decide what to leave out. The result is an over-documented small project — and the reputation that HERMES is cumbersome. Choosing the scenario is therefore not a formality at the start but the single most important decision in the whole project.
Outputs are tools, not an obligation
Every output in HERMES has a purpose: it answers a question that would otherwise stay open. A study answers whether and how the project makes sense at all. An operating concept answers who carries the result after rollout — the question on which projects most often fail after go-live.
Producing an output without knowing that question produces a document. Knowing it produces a basis for a decision. The difference is not the length but whether anybody actually reads it later.
Roles and the most common miscasting
HERMES separates the roles clearly, and the most important separation is between the client and the project manager. The client decides on goal, resources and continuation; the project manager steers delivery. In practice that separation is regularly eroded — a client who is unavailable, or a project manager effectively filling both roles.
The consequence is always the same: there is no longer anybody who can stop the project. A project manager who is their own client will not cancel their project. Whether the client actually exercises the role is therefore the best single indicator of whether a HERMES project is being steered or merely running.
Agile and HERMES are not mutually exclusive
The widespread assumption that HERMES is the opposite of agile does not survive contact with practice. The phase structure governs steering and decision points; it does not prescribe how work happens inside delivery. A team can develop in iterations and still obtain approval at defined points.
What genuinely stands in tension is not method against method but how much is fixed in advance. A project whose scope shifts substantially during delivery sits badly with an approval that confirmed that scope beforehand. No choice of method resolves that tension — it is eased by how the approvals are designed, not by abolishing them.
What works in practice
Three things separate a HERMES project that holds from one that produces paper. First: choose the scenario deliberately and record the reasoning, rather than working through the full list. Second: bind the client into the approvals with dates fixed before the phase begins. Third: measure every output against whether it answers an open question — if it does not, it belongs cut from the tailoring.
Doing that does not give you a lighter method, but one that creates effort where effort pays. That is the realistic expectation of HERMES: not speed, but traceability at a defensible price.