Microsoft Project für Bauprojekte

Baustellenkalender einrichten, bevor Sie sich auf den Fertigstellungstermin verlassen

Beginnen Sie die Bauablaufplanung mit dem Projektstarttermin und dem Arbeitskalender. Ergänzen Sie anschließend Feiertage, geplante Betriebsunterbrechungen und arbeitsfreie Wochenenden. Legen Sie separate Ressourcenkalender an, wenn Kolonnen oder Baumaschinen in unterschiedlichen Schichten eingesetzt werden. In Project bestimmt die Arbeitszeit, wie Vorgangsdauern in konkrete Termine umgerechnet werden: Ein fünftägiger Vorgang umfasst nicht zwangsläufig fünf aufeinanderfolgende Kalendertage. Prüfen Sie auch die Einstellung für die Stunden pro Tag. Eine Änderung dieses Umrechnungswerts ändert nicht automatisch die Arbeitszeiten im Kalender.

Verwenden Sie automatisch geplante Vorgänge für Arbeiten, deren Termine sich an Abhängigkeiten und der Ressourcenverfügbarkeit orientieren sollen. Verknüpfen Sie die Vorgänge entsprechend dem tatsächlichen Bauablauf. Nutzen Sie vorzugsweise Ende-Anfang-Beziehungen, wo dies sinnvoll ist, und andere Anordnungsbeziehungen nur dann, wenn die zeitliche Überlappung sachlich begründet ist. Vermeiden Sie es, jeden Vorgang mit der Einschränkung „Must Start On“ festzuschreiben, da dies sinnvolle Neuberechnungen einschränkt. Der Kapazitätsabgleich kann geeignete Vorgänge verzögern oder unterbrechen, um Ressourcenüberlastungen zu beheben. Er kann jedoch nicht beurteilen, ob ein geänderter Ablauf in der Praxis sicher oder vertraglich zulässig ist.

• Tragen Sie Baustillstände als Kalenderausnahmen ein, statt dafür künstliche Vorgänge anzulegen.
• Verwenden Sie Stichtage, um Überschreitungen von Zielterminen zu kennzeichnen, ohne den Vorgangstermin festzuschreiben.
• Prüfen Sie, ob Ressourcenkalender unerwartete Lücken im Bauzeitenplan erklären.
• Prüfen Sie die Einstellungen für den Kapazitätsabgleich, bevor Sie Vorgangsunterbrechungen zulassen.
• Kontrollieren Sie nach Kalender- oder Ressourcenänderungen erneut den kritischen Pfad.

Wöchentliche Fortschrittsaktualisierung durchführen, ohne den Basisplan zu überschreiben

Speichern Sie einen Basisplan, nachdem der abgestimmte Bauzeitenplan geprüft wurde, und bewahren Sie eine datierte Kopie der herausgegebenen Datei auf. Ein Basisplan speichert Referenzwerte für spätere Vergleiche. Er ist jedoch weder ein gesperrter noch ein unabhängig genehmigter Nachweis. Project unterstützt einen ursprünglichen Basisplan sowie zehn weitere nummerierte Basispläne. Nutzen Sie diese gezielt für genehmigte Änderungen, statt den ursprünglichen Basisplan jede Woche zu ersetzen. Dokumentieren Sie, welcher Basisplan den vertraglichen Bauzeitenplan, eine genehmigte Änderung oder ein internes Aufholszenario abbildet.

Legen Sie für jeden Berichtszyklus ein Statusdatum fest und erfassen Sie mit dem Baustellenteam die tatsächlichen Anfangs- und Endtermine sowie die verbleibenden Vorgangsdauern. Setzen Sie den prozentualen Fertigstellungsgrad eines Vorgangs nicht mit den tatsächlich ausgeführten Mengen gleich: Das Feld „% Complete“ in Project basiert auf der Dauer, während sich „% Work Complete“ auf die Arbeit bezieht. Aktualisieren Sie die Prognose für die verbleibenden Arbeiten. Nutzen Sie anschließend bei Bedarf die Optionen zur Neuplanung, um noch nicht abgeschlossene Arbeiten auf einen Zeitpunkt nach dem Statusdatum zu verschieben. Prüfen Sie Fortschritte, die vom geplanten Ablauf abweichen, sowie Meilensteinabweichungen, bevor Sie einen neuen Bericht herausgeben.

• Vereinbaren Sie mit allen Nachunternehmern einen einheitlichen Berichtsstichtag.
• Erfassen Sie ausgeführte Mengen separat, wenn der dauerbezogene Fortschritt ein irreführendes Bild ergibt.
• Prüfen Sie tatsächliche Termine, die nach dem Berichtsstichtag liegen.
• Verwenden Sie „Tracking Gantt“, um den aktuellen Bauzeitenplan mit einem Basisplan zu vergleichen.
• Führen Sie ein Änderungsprotokoll, das genehmigte Änderungen und Verschiebungen der Terminprognose erläutert.

Primavera-Datenübergaben prüfen, statt XER-Kompatibilität vorauszusetzen

Die Desktopanwendung Microsoft Project kann Primavera P6 XER-Dateien nicht nativ öffnen. Wenn der Hauptauftragnehmer XER-Dateien bereitstellt, vereinbaren Sie vor der Festlegung Ihres Workflows einen geeigneten Austauschweg: Fordern Sie einen kompatiblen Export an oder nutzen Sie ein separat geprüftes Konvertierungstool. Microsoft Project XML und Primavera XML sind nicht allein deshalb austauschbar, weil beide die Dateiendung .xml verwenden. Testen Sie zunächst einen repräsentativen Bauzeitenplan. Das ist besonders wichtig, wenn vertragliche Anforderungen von der exakten Kalenderlogik, Vorgangscodes, Zeitabständen zwischen verknüpften Vorgängen oder Ressourcenzuordnungen abhängen.

Behandeln Sie jeden konvertierten Bauzeitenplan als neuen Datensatz, der abgeglichen werden muss, und nicht als exakte Kopie des ursprünglichen Terminplans. Vergleichen Sie die Anzahl der Vorgänge, Meilensteintermine, Arbeitskalender, Vorgangsdauern und Vorgängerbeziehungen mit einem Referenzbericht aus P6. Prüfen Sie Einschränkungen sowie alle Vorgänge, deren Termine sich bei der Konvertierung verschoben haben. Bewahren Sie die Originaldatei und die Konvertierungseinstellungen auf, damit sich Abweichungen nachvollziehen lassen. Vereinbaren Sie bei regelmäßigem Datenaustausch stabile Kennungen und Feldzuordnungen, statt Vorgänge ausschließlich anhand ihrer Namen zuzuordnen.

• Fordern Sie beim Absender das Datendatum und die Kalenderdefinitionen des ursprünglichen Terminplans an.
• Klären Sie, welche Anwendung und welches Format für vertraglich einzureichende Unterlagen maßgeblich sind.
• Prüfen Sie ausdrücklich fortlaufende Dauern und die Einheiten der Zeitabstände.
• Kontrollieren Sie die WBS-Struktur und die Zuordnung benutzerdefinierter Felder.
• Übermitteln Sie eine Liste der Abweichungen, bevor Sie den konvertierten Bauzeitenplan akzeptieren.

Desktoplizenz, gemeinsamen Zugriff und Serverdienste getrennt betrachten

Wählen Sie die Edition anhand der benötigten Funktionen und prüfen Sie anschließend den Lizenzkanal und die Bereitstellungsrechte. Eine eigenständige Project-Desktoplizenz ist von einer Lizenz für eine Office-Suite getrennt. Der Besitz von Office gewährt keine Nutzungsrechte für Project. Die Microsoft-Lizenzbedingungen für Desktopprodukte im Einzelhandel erlauben in der Regel die Installation und Nutzung auf einem lizenzierten Gerät durch jeweils eine Person. Für Volumenlizenzen und Abonnements gelten eigene Bedingungen. Gehen Sie daher nicht davon aus, dass ein Produktschlüssel allein eine Nutzungsberechtigung oder Übertragungsrechte belegt.

Die Serveranbindung von Project Professional umfasst weder einen gehosteten Dienst noch eine Serverlizenz oder sämtliche erforderlichen Zugriffsrechte. Project Online und Project Server sind unterschiedliche Angebote. Microsoft hat die Einstellung von Project Online zum 30. September 2026 angekündigt; diese Ankündigung betrifft nicht die Project-Desktopanwendung. Klären Sie vor dem Kauf für die Zusammenarbeit, welcher Dienst tatsächlich eingesetzt werden soll, welchen Produktlebenszyklus er hat und welche Clientversionen kompatibel sind. Prüfen Sie für Remote Desktop Services, gemeinsam genutzte virtuelle Maschinen oder den Zugriff externer Auftragnehmer die jeweils geltenden Microsoft-Bedingungen, statt die Regeln einer Einzel-PC-Installation darauf zu übertragen.

• Lassen Sie sich Unterlagen geben, die Produkt, Edition und Lizenzkanal eindeutig ausweisen.
• Prüfen Sie die geltenden Übertragungsregeln, bevor Sie Project auf einen anderen PC umziehen.
• Klären Sie Serverlizenzen und Benutzerzugriffsrechte getrennt von der Desktoplizenzierung.
• Planen Sie eine unterstützte Alternative ein, bevor Sie auf Project Online setzen.
• Verwenden Sie PDF-Berichte für Empfänger, die herausgegebene Bauzeitenpläne lediglich lesen müssen.

Für die Bauablaufplanung relevante Desktopfunktionen von Project 2024