Expertise and Approach

Five situations that show how we work.

No case studies with client names. Instead the patterns that repeat in almost every engagement, and what we make of them.

Contract and process review

The argument about "reasonable effort"

A contract term that each side reads differently produces conflict every single day. Only a shared definition turns it into an agreement.

Situation: A new support contract states "reasonable effort" as its response time. The provider reads that as "after the weekend", the business unit as "immediately".
Approach: Do not interpret the term, strike it. What takes its place are measures both sides accept. What does reasonable mean, measured against what, when does the clock start, who decides in case of doubt. Those answers become the service level agreements. The same test runs across the other indefinite terms in the contract.
Result: A wording everyone understood differently becomes a commitment both sides can be measured against.

Process rollout

From prose to tool

A process is not designed at a desk. It emerges by collecting what people write anyway, and only then making binding what has proven to be necessary.

Situation: A team is to record incidents and changes properly, incident management and change enablement in one procedure. The usual route would be to design a ticket form straight away and impose it on everyone.
Approach: The reverse order. First everyone may write freely, unsorted as well. After the first week it is settled which follow-up questions were needed again and again. Those questions become a form. If it stays unchanged for four weeks, it moves into the tool.
Result: Only then does the procedure move into the service management tool, ServiceNow, Jira or another. The tool reproduces a procedure that was already working. Nobody has to fill in a form whose fields somebody thought up.

Method

Nobody runs a marathon without training

Service management rarely fails at its goal. It fails because the steps are chosen too large.

Situation: The target picture is usually clear: end-to-end service management operation with clean data, roles and metrics. The mistake is planning that end state as the first step.
Approach: The goal stays, the route is broken into stages that hold on their own. Every stage has to work in daily practice before the next one begins.
Result: Every stage ends with a metric that shows whether it holds, and with service reporting that carries it. A structure the organisation goes along with, instead of a target picture that is abandoned after the rollout.

Existing ITSM platform

The platform is in place, the process is not

An existing ITSM platform is not improved on the drawing board. First it has to be clear what it delivers today and which parts of it hold up.

Situation: An ITSM platform has been in use for years. Nobody knows in full which processes are held in it, and whether those processes actually help the users has never been measured.
Approach: Every process is walked through together with the people it concerns: the client, the users, the administrators and the subject matter experts. It runs from beginning to end, from the ticket a user opens to the moment it is closed to that user's satisfaction. The results of those conversations are then assessed and the next steps decided together.
Result: What becomes visible are the bottlenecks and the work that serves nobody. Whatever can be reused stays; only what there is a reason for is changed.

Operations and monitoring

Catching errors where they arise

An error that only shows up in a report is days old. It has to be caught where it arises.

Situation: Users complained that faulty data was having serious consequences. Those records could only be spotted days later, when somebody ran a report.
Approach: Not a better report, but an earlier look. Together with the developer of the application, monitoring was built that detects faulty records as they are created.
Result: The errors show up while they arise, no longer days later in a report.

Where these examples come from

All five come from our own work. Clients are not named, because project records belong to the client and current engagements are no use as references. What remains is the approach, and that can be examined.

Two terms behind this way of working.

Both pages are in German.

Iterative und kollaborative Zusammenarbeit
Iterative, collaborative work. "From prose to tool" is exactly that: small steps, each one discussed, assessed and planned with the people who have to walk it.
Start where you are
The walk through an existing platform starts from what is there, and looks inside it for what can be carried forward.

The 23 terms that settle this in conversation are collected under Wissen, in German.

Next step

Does this sound like your situation?

Which steps this turns into is under Services.

Discuss your challenge How an engagement works

Or the direct way