Die Durchführung des Projekts

FISI-Projektarbeit: Integration statt Installationsprotokoll

Die fachliche Leistung liegt in der Beherrschung des Gesamtsystems. Zu einer Änderung gehören deshalb neben der Zielkomponente auch Kommunikationsbeziehungen, Namensauflösung, Identitäten, Berechtigungen, Protokollierung, Datensicherung, Überwachung und die Einbindung in vorhandene Betriebsprozesse. Die Durchführung zeigt, welche Abhängigkeiten vorab erkannt und wie Auswirkungen begrenzt wurden.

Als durchgehendes Beispiel kann die Einführung eines neuen zentralen Dateidienstes dienen: Kapazität und Berechtigungen werden analysiert, On-Premises-, Appliance- und Cloud-Varianten verglichen, Zielarchitektur und Migration geplant, Pilotdaten übertragen, Rechte und Zugriffspfade getestet, Rückfallkriterien bewertet und der Dienst anschließend dokumentiert übergeben. Das Kopieren der Daten ist dabei nur ein Arbeitsschritt – nicht das gesamte Projekt.

Verbindlicher Rahmen der Durchführung

Das Projekt darf erst nach der Genehmigung und innerhalb des von der zuständigen IHK freigegebenen Zeitraums bearbeitet werden. Projektarbeit und Dokumentation mit praxisbezogenen Unterlagen dürfen bei Systemintegration zusammen höchstens 40 Stunden beanspruchen. Regionale Vorgaben können zusätzliche Nachweise, Portale und Formate bestimmen.

Ändern sich im Projekt Details, wird nicht stillschweigend vom Antrag abgewichen. Die Änderung, ihre Ursache, die geprüften Folgen und die Entscheidung werden festgehalten. Verändert sich der wesentliche Projektgegenstand oder ist die genehmigte Durchführung nicht mehr möglich, muss vor einer eigenmächtigen Fortsetzung der vorgesehene Kontaktweg der zuständigen IHK genutzt werden.

• Genehmigung, Auflagen, Durchführungszeitraum und Abgabefrist vor dem Start prüfen.
• Den genehmigten Eigenanteil von Tätigkeiten des Teams, des Kunden und externer Dienstleister trennen.
• Projektzeit und Dokumentationszeit fortlaufend gegen die genehmigte Planung kontrollieren.
• Betriebliche Freigaben, Wartungsfenster, Datenschutz, Arbeitsschutz und Geheimhaltung beachten.

Vom Lastenheft zum Pflichtenheft

Das Lastenheft beschreibt aus Sicht des Auftraggebers, was erreicht werden soll. Das Pflichtenheft beschreibt aus Sicht des Auftragnehmers, wie und womit diese Anforderungen umgesetzt und geprüft werden. Ob beide Dokumente verlangt werden und welchen Umfang sie besitzen, richtet sich nach Projekt, Betrieb und IHK. Entscheidend ist die eindeutige Verbindung von Anforderung, Umsetzung und Abnahmekriterium.

Für ein FISI-Projekt gehören dazu beispielsweise Verfügbarkeit, Leistung, Benutzer- und Administrationszugänge, Netzwerkzonen, Protokollierung, Datensicherung, Wiederherstellung, Kompatibilität, Wartbarkeit und IT-Sicherheit. Anforderungen wie „sicher“ oder „schnell“ sind erst verwertbar, wenn sie messbar oder eindeutig prüfbar formuliert werden.

Projektstart und Arbeitsgrundlage

Vor dem ersten produktiven Eingriff werden Auftrag, Ansprechpartner, Kommunikationsweg, Zugänge, Abhängigkeiten und Abnahmekriterien gemeinsam geprüft. Ein kurzes Projektstartprotokoll verhindert, dass wichtige Annahmen erst während der Umsetzung auffallen.

Das Projekttagebuch als Gedächtnisstütze

Ein Projekttagebuch ist kein zweiter Projektbericht. Es hält während der Arbeit knapp fest, was tatsächlich passiert ist, und liefert später belastbare Angaben für Soll-Ist-Vergleich, Entscheidungen und Dokumentation. Zugangsdaten, personenbezogene Daten und vertrauliche Inhalte werden darin nicht ungeschützt gespeichert.

Änderungen sicher und nachvollziehbar umsetzen

Produktive Änderungen benötigen einen kontrollierten Ablauf. Vorher wird geprüft, was betroffen ist und wie der vorherige Zustand wiederhergestellt werden kann. Während der Umsetzung werden nur projektbezogene Konfigurationen dokumentiert; Passwörter, Schlüssel und andere Geheimnisse gehören in vorgesehene sichere Systeme, nicht in Screenshots oder den Projektbericht.

• Konfigurationsstand oder Systemzustand vor der Änderung nachvollziehbar sichern.
• Änderungsreihenfolge, Abhängigkeiten und Rückfallkriterien vorab festlegen.
• Änderungen möglichst zuerst in einer geeigneten Test- oder Staging-Umgebung prüfen.
• Herstellerfreigaben, Kompatibilität, Lizenzen und Supportfähigkeit berücksichtigen.
• Administrationszugriffe mit minimal notwendigen Rechten und protokollierbar durchführen.
• Nach jedem wesentlichen Schritt einen definierten Zwischenzustand kontrollieren.

FISI-spezifische Qualitäts- und Sicherheitsprüfung

Ein erfolgreicher Ping beweist nur einen kleinen Teil der Funktion. Testfälle werden aus den Anforderungen abgeleitet und enthalten Ausgangslage, Durchführung, erwartetes Ergebnis, tatsächliches Ergebnis und Bewertung. Auch ein fehlgeschlagener Test ist wertvoll, wenn Ursache, Korrektur und Wiederholung nachvollziehbar sind.

Abweichungen und Probleme fachlich behandeln

Ein glaubwürdiges Projekt kann Abweichungen enthalten. Bewertbar wird die eigene Leistung durch die Analyse: Was war geplant, was ist eingetreten, welche Möglichkeiten bestanden, welche Entscheidung wurde getroffen und welche Folgen hatte sie für Zeit, Kosten, Sicherheit, Qualität und Projektziel?

Nicht jedes Problem gehört ausführlich in den Projektbericht. Relevant sind Ereignisse, die eine fachliche Bewertung, Anpassung oder Entscheidung zeigen. Flüchtigkeitsfehler werden nicht künstlich aufgebläht; technische oder organisatorische Folgen werden dagegen nicht verschwiegen.

Übergabe und Projektabschluss

Die Übergabe ist ein eigener Projektschritt. Ein technisch funktionierendes System ist nicht vollständig abgeschlossen, solange Betrieb, Zuständigkeiten, bekannte Einschränkungen, Wartung und Abnahme ungeklärt sind.

• Abnahmekriterien gemeinsam prüfen und Ergebnisse protokollieren.
• Offene Punkte, Restrisiken und vereinbarte Nacharbeiten mit Verantwortlichen und Terminen festhalten.
• Kunden- und Betriebsdokumentation in passender Zielgruppentiefe übergeben.
• Monitoring, Backup, Wiederherstellung, Patchprozess und Eskalationsweg erläutern.
• Zugänge und temporäre Berechtigungen bereinigen; Geheimnisse sicher übergeben oder erneuern.
• Soll-Ist-Vergleich für Leistung, Zeit, Kosten und Zielerreichung vorbereiten.

Tipps aus der Praxis

• Testfälle vor der Konfiguration schreiben: So wird nicht nur geprüft, was zufällig umgesetzt wurde.
• Bei Netzwerkänderungen immer Managementzugang und Rückfallweg getrennt vom zu ändernden Pfad planen.
• Konfigurationsausschnitte nur dann sichern, wenn sie eine Entscheidung oder einen Nachweis tragen; Geheimnisse vorher entfernen.
• Messwerte mit Einheit, Werkzeug, Zeitpunkt und Rahmenbedingungen dokumentieren.
• Bei Migrationen Datenkonsistenz, Unterbrechung, Parallelbetrieb und Rückmigration ausdrücklich behandeln.
• Bei Automatisierung Skriptversion, Eingaben, Fehlerbehandlung und sicheren Wiederholungsfall festhalten.
• Nach jedem Meilenstein sofort zwei Sätze notieren: Was wurde erreicht? Was muss als Nächstes entschieden werden?