Consulting & project planning

Clarify the technical starting point, prepare architecture decisions, and plan actionable project or migration paths.

Consulting and planning are the usual starting point when critical functions depend on infrastructure that has grown over time, is only partly documented, or needs to change. We primarily work with regulated, public-sector, social-service, and outage-sensitive organisations. We consider demanding private-client projects individually.

Typical starting situations

  • Important applications, networks, interfaces, or responsibilities are only partly documented.
  • Incidents cannot easily be traced to a technical or organisational dependency.
  • Sites, network segments, routing, or radio links have evolved over time and changes are difficult to assess.
  • The intended change is known, but its sequence, responsibilities, transitions, and fallback paths remain open.
  • A shared, traceable basis for decisions is missing before an investment, migration, or implementation.

Objective and scope

We clarify the relevant information chain, the function it needs to provide, known constraints, and responsibilities. Depending on the question, the agreed scope may include one or more of these starting points:

Technical situation assessment

We map relevant applications, processes, interfaces, networks, and communication paths. Existing documents and technology are included; dependencies, responsibilities, and open questions are structured.

Architecture and network review

We assess an existing or planned architecture against function, dependencies, operability, and recoverability. This may cover local networks, site connections, routing, radio networks, and microwave links. Recommendations are based on technical reasoning and are not tied to product or licence sales.

Project and migration planning

We record the objective, requirements, constraints, and exclusions, then structure work packages, dependencies, decision points, and responsibilities. Transitions, fallback paths, and the eventual operational handover are considered from the outset.

Approach and possible artefacts

At the outset, we jointly define the question, affected functions, and available information. We then map and review the agreed environment, organise findings and dependencies, and prepare the decisions ahead.

Depending on the engagement, possible artefacts include:

  • a structured technical situation assessment;
  • an overview of relevant information chains, interfaces, and dependencies;
  • a review report with findings and reasoned recommendations;
  • an updated architecture or network diagram;
  • a project or migration plan with work packages and responsibilities;
  • a list of open questions, risks, decision options, and next steps;
  • an approach to handover, fallback, and recovery.

These are possible working artefacts, not generally promised outcomes. The specific engagement determines which documents are needed and how detailed they will be.

Roles and client contribution

We provide the moderating and technical review role and the agreed planning. A reliable basis requires both decision-makers and people on the client team who understand the applications, operations, and existing technology.

The client team provides available documents, system information, and access, identifies internal and external interfaces, and explains operational priorities, approval paths, and constraints. Review times, operating windows, and the involvement of other service providers are coordinated jointly.

From planning to implementation and operations

Consulting and planning provide a basis for a decision or implementation. Agreed technical work packages can then be implemented by one team, but remain a separate, explicitly agreed scope.

After implementation, a defined area can be reviewed to determine whether documentation, responsibilities, access, backups, and recovery paths are usable for operations and handover. Support and maintenance are only available under a separate agreement and do not create general operational responsibility.

Boundaries and exclusions

  • no free consulting, fixed prices, or guarantees concerning deadlines, availability, or outcomes;
  • no general response times, SLAs, or blanket 24/7 operations;
  • no penetration test, certification, or standardised compliance audit;
  • no product or licence sales and no conventional reseller model;
  • no general PC, printer, or small-ticket support;
  • no automatic implementation of identified measures without a separate engagement.

The service overview places consulting and planning within the overall offer. Read more about the technical principles in Principles for controllable systems and our approach. Anonymised project profiles show bounded examples without naming clients or confidential operational details.

Discuss your project

Describe the starting situation, affected functions, available documents, and the decision ahead. We can then determine together which starting point and scope fit the project.

Discuss your project

Search IT-Nerds

Enter a search term.