// How we work · assess, plan, deliver, operate
Understand first, build second, then stay for the long run
Four steps we take on every project. Not because a process manual demands them, but because the expensive mistakes happen in the gaps between them.
// Starting point
A quotation written without looking is guesswork
Anyone who wants to judge an IT environment has to have seen it. So our first step is never a product proposal but a round of questions: what runs where, who uses it, where does work pile up, which contracts expire when, and what has failed three times in the past two years.
The answers form a picture that often contains half the solution already. Frequently the technology turns out not to be the problem at all — it is an ownership question nobody settled, or a licence that never matched what the business actually needed.
Only then do we propose something, with the reasoning attached: why this option and what the alternatives would have cost. You should still be able to follow the decision months later.
// Sequence
Four steps, four things you can hold in your hand
Each step ends with something tangible. When the deliverable is missing, the step is not finished — whatever the schedule says.
Record what exists
Systems, network, contracts, access, risks and goals. We talk to the people who use it daily, not only to management. Deliverable: an overview that belongs to you.
Target picture and order
An architecture that matches how you operate, plus priorities by risk and effort. Deliverable: a roadmap with reasoning — including what we consciously leave out.
In stages you can carry
Agreed time windows, a way back for every larger change, sign-off per section. Deliverable: a working environment, with drawings, port assignments and measurement reports where we cabled.
Run it and keep tuning
Monitoring, maintenance, fault handling and a regular review. Deliverable: a setup that does not quietly drift apart again over the next two years.
// What you end up with
Three documents you keep afterwards
They are not a bonus. They are the reason the next incident ends sooner — and the reason switching providers stays possible for you at any time.
The survey
What is installed, in what condition, under which contracts and with which open risks. The basis for every later decision.
Drawings and assignments
Network diagram, port assignments, address ranges and, for cabling work, the measurement report for sign-off. No guesswork at the next expansion.
The operations handbook
Who owns what, what is monitored, what happens during an incident and how to get back to a working state after a failure.
// Principles
Once properly beats three times quickly
Four principles that settle the argument when the faster option looks tempting.
What we take onOn the third identical incident we stop clearing the fault and go after whatever keeps producing it.
Knowledge that lives in one person’s head is not available while that person is on holiday.
Every larger change has a defined route back to the previous state before it begins.
Not every plan is worth doing. We say so before money is committed to it.
// Typical projects
Three patterns we keep running into
Generalised examples from our working week — not client references. Names, sectors and sizes are deliberately left out because we publish no cases that were not cleared for publication.
A network that grew inside an old building
Runs added over years, no documentation, a switch sitting in the cleaning cupboard. We record what is there, replace it section by section and hand over diagrams, assignments and a measurement report — while the business keeps working.
Go to network cabling
Moving to the cloud without a hard cut
The old server is at end of life, the line-of-business application has to stay. We migrate in stages, run both paths in parallel for a while and only switch off once nothing points at the old one.
Security work after a near miss
A phishing mail almost worked. We review accounts, separate network zones and harden endpoints — starting with a test of whether the existing backup can actually be restored.
// Working together
What this means on your side
Projects rarely fail on the technology. They fail because someone is waiting on a decision nobody is making.
From you
- One person who is allowed to decide
- Access to rooms, systems and contracts
- An honest account of what actually annoys people
- Feedback on time windows before we schedule
From us
- A named contact for the whole project
- Advance notice whenever something goes down
- Documents that stay readable without us
- A clear opinion when we think an idea is wrong
// No surprises
Four things we settle before we start
They cost half an hour at the beginning and remove the arguments that make projects expensive later.
-
Who decides
One named person on each side. With several locations, one per location.
-
What is in scope
And what expressly is not. Additions later are fine — they are simply priced where you can see them.
-
When a section counts as done
One checkable criterion per section. "It runs" is not an acceptance criterion.
-
Who operates it afterwards
Your IT, ours, or both together. That is agreed before delivery, not once it is finished.
// Questions about our approach
What companies ask before a first project
01 What happens first?
Listening, followed by a survey. We look at what is installed, which contracts are running, where the working day gets stuck and what is planned for the coming years. Technology comes up after that, not before.
02 Do we get the findings in writing?
Yes. After the survey you receive an assessment with a target picture and a sequence: what comes first, what comes later, what we would deliberately leave alone. The document is yours, even if you continue with someone else.
03 Does everything have to happen at once?
No, and we usually advise against it. Sensible order follows risk and effort: whatever threatens operations or costs time every day comes first. The rest can wait as long as everyone knows it is still coming.
04 Will the work disrupt our business?
We agree time windows that suit how you operate — much of it happens outside core hours or alongside the existing setup. Where an interruption is unavoidable, you hear beforehand how long it lasts and who it affects.
05 What if something goes wrong during the rollout?
Then you hear it from us rather than a smoothed-over version. Every larger step has a way back defined before it starts, so we know how to restore the previous state if a change does not hold.
06 What happens once the work is finished?
You decide whether we take over operations. If we do, monitoring, maintenance and fault handling move into ongoing support. If not, we hand over documentation and access in full and step back.
07 Can you work alongside our own IT department?
Yes, and that is a common arrangement. We agree at the outset who owns which area and put it in writing. Shared responsibility that was never defined is the most reliable source of gaps.
Related pages
Request an initial call
Let's begin with the survey.
Nothing to prepare on your side. A conversation, a walk through the building, a handful of questions — after that you know where you stand, and so do we.