Infrastructure, Services & Tools
Last modified by Veronika Kocher on Friday, 04 Sep 2026 14:45
Start from the task — not the tool.
Describe what the project needs to do first: store, collaborate, produce, document,
analyse, present, publish or hand over for the long term. Only then choose a specific system.
Institutional solutions matter especially when responsibility must extend beyond individual people.
This is particularly relevant for shared accounts, access rights, support, data protection, technical handover
and whether project materials will still be accessible after project closure.
STEP 1 · DESCRIBE THE NEED
Define the requirements that infrastructure or a tool must meet
A clear needs description makes it easier to assess existing institutional offers and avoid unsuitable one-off solutions.
Function: What needs support — storage, collaboration, production, analysis, documentation, presentation or publication?
Users: Who will use it — an individual, internal team, external partners, participants or the public?
Access: Which roles need to read, edit, administer or only view?
Data / materials: Which formats, volumes, devices or physical resources are involved?
Protection needs: Are there personal, confidential, licence-restricted or otherwise sensitive materials?
Support: How critical is specialist or technical support for ongoing operation?
Export / handover: Will data, files, settings or results need to leave the system later?
Costs / duration: Are there recurring fees, consumables, licences or project-specific acquisition costs?
Availability: How long must the infrastructure remain usable and what happens after project closure?
Dependencies: Which other systems, accounts, rooms, devices or services must work with it?
KEY DISTINCTIONS
These questions should not disappear into a single tool decision
Tool ≠ service.
A technical product may exist without institutional support, advice or responsibility being defined.
A technical product may exist without institutional support, advice or responsibility being defined.
Available ≠ suitable.
A system being technically usable does not automatically make it appropriate for protection needs, collaboration or handover.
A system being technically usable does not automatically make it appropriate for protection needs, collaboration or handover.
Personal account ≠ project infrastructure.
If a project depends on individual private or personal accounts, handover and long-term responsibility can become difficult.
If a project depends on individual private or personal accounts, handover and long-term responsibility can become difficult.
Storage space ≠ complete working environment.
Collaboration may additionally require roles, versioning, approvals, documentation, backup or export options.
Collaboration may additionally require roles, versioning, approvals, documentation, backup or export options.
Purchase ≠ operational readiness.
For equipment or software, installation, maintenance, support, space, safety, training and follow-up costs can matter as much as the purchase price.
For equipment or software, installation, maintenance, support, space, safety, training and follow-up costs can matter as much as the purchase price.
Project end ≠ end of all dependencies.
Accounts, licences, data, equipment and access often need to be handed over, closed, exported or continued deliberately.
Accounts, licences, data, equipment and access often need to be handed over, closed, exported or continued deliberately.
STEP 2 · CHECK INSTITUTIONAL OPTIONS
Review existing systems, services and specialist units first
01
Assign the need to a category
Classify the requirement as digital infrastructure, room/building service, equipment/lab or another specialist service.
02
Look for existing options
Check whether the University already provides an intended system, service or responsible specialist unit.
03
Clarify specialist responsibility
Identify who actually owns use, support, approval, maintenance or technical responsibility.
04
Check the access route
Clarify whether accounts, reservations, approvals, training or internal lead times are required.
05
Check protection requirements
Include data protection, access, confidentiality and other project-specific restrictions.
06
Check costs & resources
Include licence, operating, consumable, installation or follow-up costs in the project budget.
07
Clarify export and handover
Check how files, data, settings, equipment or access can be transferred or closed when the project ends.
08
Document the decision
Record which solution was chosen, who is responsible and which dependencies remain unresolved.
STEP 3 · COMPARE OPTIONS
Compare requirements and constraints systematically
A simple comparison helps prevent choosing a tool only because it is familiar or immediately available.
| Criterion | What to check | Why it matters |
|---|---|---|
| Functional fit | Does the solution support the tasks and workflows the project actually needs? | Prevents tool selection without a clear project purpose. |
| Institutional responsibility | Is there a responsible unit, support route or defined operational owner? | Makes use and escalation routes traceable. |
| Access & roles | Can required roles and permissions be represented appropriately? | Supports collaboration and protection needs. |
| Data protection / confidentiality | Is the intended use compatible with project requirements? | Prevents unsuitable storage or processing of sensitive material. |
| Exportability | Can files, data, metadata or settings be exported in a usable form? | Reduces dependence on a single system. |
| Interoperability | Does the solution work with other required tools, formats or devices? | Prevents isolated technical silos. |
| Support & maintenance | Who helps with incidents, updates, operation or use? | Makes real operational readiness visible. |
| Costs | Which purchase, licence, operating, consumable or follow-up costs arise? | Connects infrastructure to realistic project planning. |
| Duration | Will the solution remain available throughout the project and handover period? | Prevents dependence on short-lived individual access. |
| Project closure | How will accounts, equipment, data, licences and access be handled at the end? | Makes handover and closure manageable. |
COMMON SCENARIOS
Infrastructure needs look very different depending on the project
Shared digital working environment
Consider accounts, roles, storage, collaboration, backup, export and handover together rather than as separate decisions.
Large media or research data
Consider storage, transfer, backup, access rights, processing and any need for specialised infrastructure.
Equipment, workshops or labs
Clarify availability, access rules, training, safety, consumables, maintenance and technical support.
Rooms & building services
Check capacity, accessibility, technical connections, setup time, safety and the relevant facility processes early.
Specialist software or platform
Check licence, duration, accounts, export, technical dependencies and what happens to data or projects after closure.
Funded collaborative project
Partners may bring different systems and responsibilities. Clarify shared working routes, handovers and institutional ownership early.
STEP 4 · DOCUMENT THE INFRASTRUCTURE PLAN
Keep the key systems, responsibilities and dependencies in one place
The infrastructure plan can be part of project planning or the Data Management Plan. What matters is that technical dependencies are not only implicit knowledge.
System / service: Which infrastructure or tool is being used?
Purpose: Which concrete project function does it support?
Responsible unit: Who is responsible institutionally or within the project?
Access route: How do team members obtain accounts, permissions, reservations or approvals?
Costs: Which one-off or recurring costs need to be planned?
Dependencies: Which equipment, rooms, software, accounts or data formats are additionally required?
Protection requirements: Which data-protection, confidentiality or security questions apply?
Export / handover: How will data, files, equipment or access be handled when the project closes?
STOP & CHECK
Common warning signs in infrastructure and tool decisions
The tool was chosen before the need was clear.
The project adapts unnecessarily to a product instead of the solution supporting the task.
The project adapts unnecessarily to a product instead of the solution supporting the task.
Core project work depends on a private or personal account.
Access, handover and institutional responsibility are at risk.
Access, handover and institutional responsibility are at risk.
No one knows the responsible specialist unit.
There is no clear escalation route for incidents, approvals, maintenance or project closure.
There is no clear escalation route for incidents, approvals, maintenance or project closure.
Export or data portability was never checked.
Important project materials may become trapped in a system at the end.
Important project materials may become trapped in a system at the end.
Only the purchase price was planned.
Licence, operation, maintenance, consumables, space, safety, training or support are missing from the project plan.
Licence, operation, maintenance, consumables, space, safety, training or support are missing from the project plan.
Technical dependencies are undocumented.
After staff changes or project closure, it is unclear which systems are needed to understand or continue the work.
After staff changes or project closure, it is unclear which systems are needed to understand or continue the work.
SERVICES & SUPPORT
Which specialist service is responsible depends on the infrastructure type
IT & Digitalisation / ZID
Primary specialist responsibility for digital systems, accounts, digital working environments and technical infrastructure.
Facility Management
Primary responsibility for rooms and building services and the corresponding internal processes.
Relevant specialist unit
For equipment, labs, workshops or other specialist infrastructure, responsibility remains with the designated unit.
Support Kunst und Forschung (SKF)
Coordinates infrastructure needs and internal routes for research projects, especially funded projects; specialist responsibility remains with the responsible unit.
RELATED TOPICS
Infrastructure decisions are closely connected to these project topics
TRAINING & WORKSHOPS
Training, workshops & consultation sessions
Relevant opportunities for this topic will be shown here automatically from the central calendar.
COMING SOONPRACTICAL RESOURCES
Info sheets, tutorials and templates
Info SheetsCOMING SOON
Short guidance on selecting institutional systems, services, rooms, equipment and tools.
TutorialsCOMING SOON
Step-by-step workflows for needs analysis, option comparison and handover planning.
Checklists & TemplatesCOMING SOON
Template for an infrastructure plan, tool comparison and technical project handover.
Need help finding the right internal route?
Start with the specialist service responsible for the relevant infrastructure type.
In funded or project-based research involving several units, SKF can coordinate the project route and infrastructure dependencies.
Search terms & related topics
infrastructure · services · tools · digital systems · IT · ZID · Facility Management · rooms · building services · equipment · labs · workshops · software · platform · accounts · access rights · collaboration · storage · backup · support · maintenance · licence · export · interoperability · data protection · project handover · research infrastructure · project infrastructure