Wann Sie Waterfall-Projektmanagement Agile vorziehen sollten

By Kate Eby | 28. September 2016

Vor der äußerst beliebten Agile-Methode gab es Waterfall. Waterfall wird als sequenzielle oder lineare Softwareentwicklungsmethode definiert, in der jede Entwicklungsphase abgeschlossen wird, bevor die nächste beginnt. Waterfall ist ein unkomplizierter, logischer Ansatz für die Produktentwicklung. In dieser Methode bestimmen Sie, was sie erstellen, planen die Entwicklung, legen einen Zeitplan fest, beschaffen sich Ihre Ressourcen, weisen Ressourcen zu, entwickeln das Produkt, geben es einem Testteam, beheben mögliche Fehler und veröffentlichen dann das Produkt. Bis zu Veröffentlichung schafft das Marketingteam etwas Begeisterung in Erwartung des Produkts, und Vertriebsmitarbeiter überzeugten Kunden, dass das neue Produkt alle ihre Probleme lösen wird. Seit der Einführung von Agile wird Waterfall nicht mehr so häufig verwendet, aber es gibt immer noch viele Fälle, in denen es sinnvoll ist, Waterfall zu verwenden. Dieser Leitfaden hilft Ihnen, zu entscheiden, wann Waterfall statt der Agile-Methode verwendet werden sollte.

Eine Geschichte der Waterfall-Methode

Waterfall ist ein logisches Muster, das sie befolgen soll – Plan, Bau, Test und Release in Sequenz. Die Geschichte von Waterfall hat ihren Ursprung im Artikel von Winston W. Royce aus dem Jahr 1970 zu den Verfahren von IEEE WESCON, der Verwaltung der Entwicklung großer Softwaresysteme. Der Artikel von Royce war wahrscheinlich die erste Diskussion von Waterfall in der Softwareentwicklung, aber das Wort „Waterfall“ wird im Artikel nicht einmal erwähnt. Der formale Begriff wurde in Thomas E. Bells und T.A. Thayers Arbeit aus dem Jahr 1976 aus dem Protokoll der 2. Internationalen Konferenz für Software Engineering, Softwareanforderungen: Sind sie wirklich ein Problem? eingeführt. Wie bereits an vielen Stellen erwähnt wurde, preiste die Arbeit von Royce jedoch die Methode nicht. Tatsächlich beschreibt er sie in wenig schmeichelhaften Worten und nennt sie fehlerhaft und in vielerlei Hinsicht fehleranfällig. Er fuhr damit fort, einen iterativeren Ansatz zu diskutieren, vielleicht die Grundlage dafür, was später einmal zu einem Agile-Ansatz werden würde. 

Bell und Thayers Arbeit diskutiert eine Veränderung des Ansatzes von Bottom-up zu Top-Down bei der Entwicklung von Softwareanforderungen, unter Verweisung der Annahme dieses Ansatzes in MIL STD 490/483 (MIL STD 490 diskutiert Spezifikationspraktiken und MIL STD 483 diskutiert Konfigurationsmanagement-Praktiken für Systeme). Die Arbeit befasst sich hauptsächlich mit der empirischen Untersuchung der Ansätze, um festzustellen, welche am besten funktioniert. Letztendlich erklärt die Arbeit, dass „in den letzten zehn Jahren mehr Struktur und Disziplin angenommen wurde, und Praktiker haben daraus geschlossen haben, dass ein Top-Down-Ansatz dem Bottom-up-Ansatz der Vergangenheit überlegen ist.“ Der Begriff „Waterfall“ wird in direktem Bezug auf die Arbeit von Winston Royce verwendet.

Trotz der von Royce beschriebenen Fehler wurde Waterfall 1985 eine bevorzugte Methode, als das Verteidigungsministerium DOD-STD-2167A,Softwarentwicklung für Verteidigungssysteme herausgegeben hat. Es beschreibt den Softwareentwicklungszyklus wie folgt:

  1. Analyse der Softwareanforderungen
  2. Vordesign
  3. Detailliertes Design
  4. Codierungs- und Einheitstests
  5. Computersoftware-Komponente (CSC) Integration und Tests
  6. CSCI-Tests 

Das Vorige besagt, dass „dieser Standard dynamisch und reaktionsschnell auf den sich schnell entwickelnden Softwaretechnologiebereich reagieren soll. Dieser Standard sollte daher selektiv angewendet und an die einzigartigen Merkmale jedes Softwarebeschaffungsprogramms angepasst werden.“ Die Anforderung wurde jedoch in Black und White angelegt und folgte logisch.

Die Beliebtheit der Waterfall-Methode begann, zu schwinden, als die Führungskräfte in der Branche frustriert wurden mit ihrer Inflexibilität, und das Agile-Manifest entwickelten. Seit diesem Tag haben immer mehr Unternehmen Agile übernommen, doch viele Unternehmen halten weiterhin an Waterfall fest und das aus gutem Grund. Waterfall hat seine Fehler, aber es hat auch seine Vorteile und in der richtigen Umgebung kann es die beste Vorgehensweise sein.

Project Management Guide

Your one-stop shop for everything project management

the 101 guide to project management

Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.

View the guide

Vorteile des Waterfall-Projektmanagements

Trotz aller Kritik an Waterfall gibt es einige echte Vorteile bei seiner Umsetzung:

  • Es ist ein einfacher, direkter Ansatz.
  • Es ist leicht, einen Plan für die Verwaltung eines Waterfall-Projekts zu entwickeln, da jede Phase einen Anfang und ein Ende hat, und Sie vor der Codierung wissen, was entwickelt werden muss, wann es fällig ist, wann Tests beginnen, usw.
  • Die frühe Planung bietet eine gute Grundlage für die Gestaltung von Komponenten, die sich in externe Systeme integrieren.
  • Es ist einfach, Ressourcen für Waterfall zu planen, denn auch hier wissen Sie, wann alles beginnen und enden soll.
  • Kunden, die endgültige Anfangs- und Enddaten wünschen, können Waterfall als versichernd empfinden.  Kunden kann das Datum genannt werden, an dem sie ein Produkt in ihren Händen halten werden, und wenn sich das Projekt für einen Waterfall-Ansatz eignet, wird es an diesem Datum geliefert.
  • Die Kosten der Entwicklung können im Voraus festgelegt werden.
  • Detaillierte Verfahren können verwendet werden, um jeden Teil des Prozesses zu regeln.
  • Der designintensive Ansatz von Waterfall erzwingt einen disziplinierten Ansatz der Entwicklung und legt klare Erwartungen fest.
  • Teammitglieder können an anderen Projekten teilnehmen, bevor ihre Phase beginnt oder nach Abschluss ihrer Phase, und bei Bedarf zum Projekt zurückkehren.
  • Die Abhängigkeit von der Designdokumentation reduziert den Stress auf das Entwickler-Turnover.
  • Der designintensive Ansatz bedeutet, dass Fehler in der Designphase erkannt werden können. Es gibt offensichtliche Tücken dafür und jeder, der mit der Waterfall-Methode gearbeitet hat, weiß, dass Designfehler auftreten, aber mit einem erfahrenen Team und einem Plan erhalten Sie oft ein solides Design, das gemäß Plan ausgeführt werden kann.

 

Nachteile des Waterfall-Projektmanagements

Hier sind einige der wichtigsten Bedenken und Kritiken zu Waterfall:

  • Zeit bis zur Veröffentlichung ist für große Projekte ungewöhnlich lang. Die Arbeit von Royce lobte Waterfall, wenn es um kleine, interne Projekte ging, aber sah die Methode als ziemlich fehlerhaft für größere, komplexere Projekte an. Tatsächlich ist dies wahrscheinlich der primäre Grund, warum Agile so beliebt geworden ist. Projekte, die zu groß waren, wurden abgebrochen, bevor sie über die Waterfall-Methode zur Fertigstellung gelangen konnten.
  • Die zweite führende Kritik an Waterfall besteht darin, dass Veränderungen unerwünscht sind. Sobald Tests beginnen, ist es äußerst teuer, zur Entwicklung zurückzukehren oder das Projekt neu zu gestalten. Das Design muss sorgfältig und korrekt geschrieben werden, bevor es zu weit geht.
  • Arbeitssoftware wird erst spät im Projekt angezeigt.
  • Fehler, die frühzeitig im Projekt geschrieben wurden, können große Kopfschmerzen für späteren Code bereiten, aber nichts davon ist ersichtlich, bevor die Tests beginnen, was die Korrektur des Codes teuer und zeitaufwändig macht.
  • Es ist kein objektorientierter Ansatz. Waterfall-Projekte sind stark integriert. Dies ist ein weiterer Aspekt von Waterfall, der die Flexibilität reduziert.
  • Es ist keine gute Methode für Wartungs- und andere Arten von langfristigen Projekten.
  • Hand in Hand mit den vorhergehenden Kritiken geht die Tatsache, dass Kunden oft nicht wissen, was sie wollen, bevor das Projekt beginnt.
  • Wenn das Team unerfahren ist oder Neuland betritt, kommt es zu Hindernissen, die für das Projekt gefährdend sind.
  • Tests können zu kurz kommen, um im Zeitplan zu bleiben, weshalb der Kunde eventuelle Fehler entdecken wird, nachdem das Produkt geliefert wurde.
  • Umstände könnten erzwingen, dass das gesamte Projekt aufgegeben wird. So könnten beispielsweise Veränderungen in der Branche, die während der Entwicklungsphase auftreten, das gesamte Projekt obsolet machen. Ein anderes Ereignis kann die Entdeckung eines Designfehlers sein, der so schwer ist, dass das gesamte Projekt neu designt werden muss, was so kostspielig sein kann, dass der Kunde das Projekt abbricht.

 

Vergleich von Waterfall mit Agile

Waterfall konzentriert sich auf die Designphase eines Projekts, während Agile nur minimale Zeit beim Design umfasst. Beide Projektmanagementoptionen zielen darauf ab, funktionierende Software zu liefern, aber Waterfall-Projekte liefern in der Regel einmal oder zweimal pro Jahr ein Release (oder sogar weniger häufig), während Agile eine funktionierende Software bis zu einmal pro Woche liefern kann. Die Lieferungen in Waterfall können groß sein und benötigen einen langen Zeitraum von Tests, wobei viele Unternehmen auch Kunden zur Bereitstellung von Beta-Tests verwenden. Agile testet Software, während sie erstellt wird, wobei oft der Entwickler die Tests durchführt.

Ein wichtiger Unterschied zwischen Waterfall und Agile ist, dass Waterfall eine Methode ist, aber Agile eine „Bewegung“ mit einer Vielzahl von abgeleiteten Methoden, die die Prinzipien und Werte von Agile anwenden. Scrum, eXtreme Programming (XP), Kanban, Scrumban und eine Reihe anderer Methoden ermöglichen dem Entwicklungsteam Optionen, so dass es eine beste Wahl darunter geben kann.

Eine Agile-Methode ist eine überlegene Wahl, wenn der Kunde über Anforderungen unsicher ist oder eng am Entwicklungsprozess beteiligt sein möchte, und wenn Zeitabläufe kurz sind und eine schnelle Lieferung gewünscht ist.  Waterfall ist überlegen, wenn es komplexe Abhängigkeiten gibt, aber Agile ist vorzuziehen, wenn Abhängigkeiten minimal sind. Agile ist auch am besten geeignet, wenn Geschwindigkeit wichtiger als Qualität ist.

Einige Nachteile von Agile sind: 

  • Erfordert die Beteiligung des Kunden
  • Kosten und Zeitpläne sind unsicher 
  • Planung ist schwierig
  • Mangelnde Klarheit über das Endergebnis
  • Minimale Dokumentation
  • Teammitglieder müssen funktionsübergreifend sein – einige, die in ungewohnten Rollen unerfahren sind
  • Entwickler sind für ein einzelnes Projekt zuständig
  • Scope-Creep ist ein Risiko – wenn ein Projekt Änderungen unterliegt, kann es außer Kontrolle geraten und seinen Lieferterm überschreiten

Die Idee, dass Agile ein dramatischer Weggang von Waterfall ist, ist nicht ganz wahr. Der Agile-Ansatz ist tatsächlich mehr ein angepasster Waterfall-Ansatz, ein Versuch, einige der Nachteile von Waterfall in Bezug auf Widerstand gegen Veränderungen und lange Liefertermine zu adressieren. Die mangelnde Flexibilität  und eine hohe Anzahl an abgebrochenen Projekten führte dazu, dass viele Teams von Waterfall zu Agile wechselten. Es ist jedoch wichtig, zu verstehen, dass Agile immer noch einen sequenziellen Ansatz benötigt – es verwendet nur eine kürzere Sequenz. Agile enthält noch einige Anforderungenanalysen und Design zu Beginn, aber die Codierung beginnt erst, wenn die Anforderungen und das Design abgeschlossen sind, und Sie können keinen Code testen, der nicht geschrieben wurde oder Code liefern, der nicht getestet und integriert wurde. Daher kann Agile als flexiblere, schnelle Form des Waterfall-Projektmanagements angesehen werden.

Tipps und Best Practices für Ihr nächstes Projekt mit der Agile-Methode.

 

Erfahren Sie alles über Agile-Projektmanagement und Tipps, die Ihnen helfen, bewährte Vorgehensweisen für Agile-Projektmanagement zu implementieren.

 

Erhalten Sie das kostenlose E-Book, um meine Agile-Best Practices zu implementieren

Verwendung der Waterfall-Methode für das Projektmanagement

Die Entscheidung zwischen Waterfall und Agile erfolgt basierend auf der Untersuchung der Merkmale des Projekts und der Bedürfnisse des Kunden. Achten Sie insbesondere auf die Anforderungen, das Ziel und die Zielsetzung des Projekts. Waterfall ist oft eine bessere Wahl, wenn:

  • Die Anforderungen gut verstanden werden und sich wahrscheinlich nicht ändern.
  • Der Kunde ist nicht dazu geneigt, Änderungen zu fordern.
  • Der Kunde zieht es vor, nicht an der Entwicklung beteiligt zu sein, sondern möchte zu Beginn beratend mitwirken und am Ende ein funktionierendes Paket erhalten. Agile funktioniert am besten, wenn der Kunde an allen Phasen beteiligt ist (die Überprüfung des Produkts bei jeder Iteration), aber Waterfall-Kunden müssen nur eine Release erhalten und sie installieren. (Hinweis: Dies ist eine Vereinfachung. Kunden müssen auch in der Verwendung des Systems geschult werden und das kann ein langwieriger und wichtiger Schritt sein. Dies ist unabhängig von der verwendeten Methode das gleiche, und es kann sein, dass Benutzer einmal oder zweimal im Jahr über neue Funktionen für eine größere Version zu schulen, weniger aufdringlich ist, als die monatliche oder sogar wöchentliche Schulung eines Kunden über eine kleinere Anzahl von Funktionen. Denken Sie auch daran, dass Kunden, die involviert sein möchten, an einem Waterfall-basierten Projekt beteiligt sein können. Wenn der Kunde für häufige Überprüfungen mit einbezogen wird, kann es ablenken und zu ungewollten Änderungsanforderungen führen, aber es kann das Projekt auch stärker auf die Kundenbedürfnisse fokussieren.)
  • Das Projekt ist klein.
  • Das Liefertempo ist nicht wichtig.
  • Die Lieferung muss auf ein veraltetes System angewendet werden, das nicht auf Änderungen ausgelegt ist.
  • Sie werden in Zukunft ähnliche Projekte haben, was die Wiederverwendung des Projektplans ermöglicht und die Lehren aus der schwerfälligen Dokumentation des vorherigen Projekts ziehen kann.

 


Ein kurzes Blick auf die Top-Projektmanagementmethoden
Waterfall ist nur eine der vielen konkurrierenden Methoden. Wenn Sie die Entscheidung treffen, das eine oder andere umzusetzen, hilft es, eine Vorstellung davon zu haben, was sie sind. Das Folgende ist ein kurzer Blick auf die wichtigsten Projektmanagementmethoden, die derzeit verwendet werden. 

Waterfall
Die Waterfall-Methode wird in der Regel als traditioneller Ansatz für das Projektmanagement angesehen. Waterfall basiert auf der Vorstellung, dass alles in Sequenz passiert, d. h. eine Phase eines Projekts endet, bevor eine andere beginnt. Dies schaffte viele Abhängigkeiten und führte auch zu ziemlich katastrophalen Situationen für die Softwareentwicklung. Projekte waren oft im Verzug und über dem Budget, und in einigen Fällen komplett abgebrochen, wenn sich die Technologie zu schnell ändert. 

Die CPM-Methode (CPM)
Die CPM-Methode ist eine weitere sequenzielle Methode, die davon abhängt, dass jeder Schritt von der Fertigstellung des vorherigen Schritts abhängt. In der Planungsphase eines CPM-Projekts geht es mehr darum, die intensivsten Teile des Projekts zu identifizieren, um Ressourcen zuzuweisen und Engpässe zu vermeiden. Die Anwendung der Methode erfolgt folgendermaßen:

  • Identifizieren erforderlicher Aufgaben und die Definition der Sequenz für die Erledigung dieser Aufgaben.
  • Die Definition der Abhängigkeiten für die erforderlichen Aufgaben.
  • Die Festlegung der Beziehungen, die zwischen den Aufgaben entscheidend sind und nicht entscheidend sind.
  • Planen der erwarteten Zeitleiste für jede Aufgabe.
  • Entwickeln eines Plan Bs für kritische Pfade.

Critical Chain Project Management (CCPM)
Waterfall konzentriert sich auf Design und CPM konzentriert sich auf Aufgaben, aber CCPM konzentriert sich auf Ressourcen- und Ressourcenzuweisung. CCPM konzentriert sich auf die Faktoren, die sich auf Zeitachsen, Kosten, Leistung und das Risiko der Minderlieferung auswirken können. Der Ansatz von CCPM besteht darin, die kritische Kette zu definieren, Ressourcen anzuwenden, die den größten Vorteil bieten, und schließlich Zeitpuffer für die kritischen Aufgaben einzuführen, um eine zeitnahe Lieferung zu gewährleisten, wenn Probleme auftreten.

PMI PMBOK® Guide
Die PMI-PMBOK®Guide-Methode des Projektmanagements verwendet die fünf Prozessgruppen des PMI aus dem Text „A Guide to Project Management Body of Knowledge“. Hier ist eine Übersicht über diese Gruppen auf hoher Ebene:

  • Initiierung – Legen Sie die Vision fest. Dies ist auch die Prozessgruppe, in der der Projektmanager ausgewählt wird.
  • Planung – Legen Sie den Umfang fest. Die PMBOK beschreibt 24 Prozesse in der Planungsphase.
  • Ausführen – Setzen Sie den Plan um.
  • Überwachung und Kontrolle – Dies findet während des gesamten Projekts statt und ist keine sequenzielle Phase, die auf das Ende einer anderen Phase wartet.
  • Abschluss – Kommt vor, wenn der Kunde mit der Annahme des Projekts einverstanden ist.

Agile-Methoden
Agile ist als Bewegung definiert, nicht als Methode, doch eine Familie von Agile-Methoden wurden in Übereinstimmung mit den Agile-Werten und -Prinzipien entwickelt.

Scrum
Die Scrum-Methode hat ein kleines Agile-Team, das von einem Scrum-Master geleitet wird. Die Rolle des Scrum-Masters besteht darin, die Arbeit des Teams zu erleichtern. Die Planung ist minimal und eine Liste wird von den zu erledigenden Aufgaben erstellt. Aufgaben werden in „Sprints“ abgearbeitet, die in der Regel zwei bis vier Wochen lang sind. Kurze tägliche Meetings (sogenannte Daily Scrums) werden gehalten, um die Aufgaben des Tages durchzugehen und Hindernisse zu identifizieren. Team-Mitglieder führen alle traditionellen Aufgaben eines Projekts durch, designen im Prozess und testen beim Abschließen einer Aufgabe. Das Ziel des Scrum besteht darin, funktionierende Software zu übergeben. Wenn ein Sprint endet, beginnt der nächste, wobei das Team eine Reihe von Aufgaben aus dem Projekt-Backlog gezogen hat. Wenn die Gesamtprojektziele erfüllt wurden und es keine weiteren Aufgaben gibt, ist das Projekt abgeschlossen.

Kanban
Die Kanban-Methode eignet sich am besten für Wartungsprojekte. Der Kern der Kanban-Methode ist das Kanban-Board, eine Liste aller Aufgaben (auch Kanban-Karten genannt), die ständig aktualisiert werden und leicht für alle Teammitglieder sichtbar sind. Wenn eine Ressource (Teammitglied) verfügbar ist, übernimmt dieses Teammitglied eine Aufgabe aus dem Board und arbeitet daran. Aufgaben werden dem Board hinzugefügt und ständig bearbeitet. Es gibt keinen definierten Anfang oder Ende des Projekts.

Extreme Programming (XP)
Sprints sind in der Regel eine Woche lang mit vielen Iterationen. In XP ist Veränderung der Schlüssel, und XP-Programmierer arbeiten eng mit den Stakeholdern zusammen. XP ist ideal für Umgebungen, in denen sich die Anforderungen ständig ändern. Aufgaben können inmitten des Sprints ersetzt werden.

Adaptive Projekt Framework (APF)
APF nimmt an, dass IT-Projekte so weit variieren, dass kein einzelner Ansatz jemals Sinn macht. IT-Projekte unterscheiden sich in Risiken, Kosten, Länge und Komplexität und beinhalten oft Unsicherheiten im Markt, im Geschäftswert, in der Kundenbeteiligung und bei den Zielen. Ein APF-Projekt beginnt daher mit der Analyse der Anforderungen, um strategische Ziele zu definieren. Das Projekt wird iterativ ausgeführt und Post-Mortem-Projekte werden nach Iterationen durchgeführt, um den Prozess zu verbessern. Die Analyse erfolgt in der Regel, damit das gesamte Projekt neu definiert oder angepasst werden kann, wenn es auf die Unsicherheitsprobleme reagiert, um den Geschäftswert zu erhalten oder zu steigern.

Lean
Lean soll Verschwendung reduzieren und den Wert maximieren. Die Kernwerte von Lean sind kontinuierliche Verbesserung und Respekt für die Mitarbeiter. Lean konzentriert sich auf die Bereitstellung des größten Mehrwerts für den Kunden, die Einhaltung des Arbeitsflusses, die gleichmäßige Zuweisung der Arbeit und vor allem auf die Eliminierung von Verschwendung.

Six Sigma
Bei Six Sigma geht es darum, Fehler in der Entwicklung durch effiziente Prozesse und kontinuierliche Verbesserung von Prozessen zu eliminieren. Eine Bewertung von Six Sigma bedeutet, dass das Produkt zu 99,99966 % frei von Fehlern ist. Wenn Sie einen Prozess mit einer Six Sigma-Bewertung haben, bedeutet dies, dass für jedes über diese Produkte gelieferte Produkt das gleiche Ergebnis erwartet werden kann.

Lean Six Sigma
Lean Six Sigma versucht, die Lean- und Six Sigma-Ansätze zu kombinieren und Verschwendung zu eliminieren, um Prozesse effizienter zu machen und hohe Werte und geringe Fehler für den Kunden zu liefern.

Prozessbasiertes Projektmanagement Im Prozess-basierten Projektmanagement
besteht der Fokus darauf, jedes Projekt mit der Unternehmensmission und den Werten in Einklang zu bringen. Projekte werden in der Unternehmensstrategie untergeordnet. Daher werden solche traditionellen Aspekte der Projektanalyse, wie Metriken, verwendet, um festzustellen, wie genau dieses Ziel erreicht wird.

PRINCE2
Die PRINCE2-Methode basiert auf der weniger erfolgreichen PRINCE-Methode. Die PRINCE-Methode war nicht sehr beliebt, da sie zu umständlich war. Sie wurde 1996 von einem Ausschuss aus 150 europäischen Organisationen Zu PRINCE2 überarbeitet. Während PRINCE beabsichtigte, die IT-Kosten und Zeitüberschreitungen zu reduzieren, wurde es auch als Projektmanagementmethode für jede Art von Projekt entwickelt. PRINCE2 gab 2009 eine große Überarbeitung aus, die die Methode einfacher machte und sieben Grundprinzipien des Projekterfolgs eingeführt hat.

Project Integrating Sustainable Methods (PRiSM)
PRiSM konzentriert sich auf sozial verantwortliches Projektmanagement. Ihre Absicht ist es, Projekte zu verwalten und gleichzeitig negative Auswirkungen auf das Umfeld zu reduzieren und sozial vorteilhafte Projekte zu fördern.

Benefits Realization
Die Methode der Benefits Realization dreht sich vollständig um den Kunden. Von Anfang bis Ende zielt die Methode darauf ab, sicherzustellen, dass der Kunde den maximalen Nutzen aus dem Produkt erhält, auch wenn es die Kosten oder Fristen überschreitet.

 

Viele Projektmanagementmethoden bedeuten viele Möglichkeiten

Es gibt viele Methoden in der Welt des Projektmanagements. Die meisten haben sich um neue Ansätze und verschiedene Bedürfnisse entwickelt, die nur offensichtlich wurden, da die Softwareindustrie sowohl komplexer (Vielzahl von Methoden und Sprachen) als auch einfacher wurde (mehr Benutzerfreundlichkeit beim Schreiben von Code). Die alten Methoden des Projektmanagements behalten jedoch immer noch ihren Wert in den richtigen Umgebungen, wie von den Unternehmen nachgewiesen wird, die noch Projekte unter der Waterfall-Methode entwickeln. Viele Kunden wollen immer noch wissen, was es kosten wird und wann es fertig ist, bevor sie der Entwicklung zustimmen, und sie wollen auch wissen, welcher Nutzen für sie enthalten ist. Wie würden sie ohne diese wichtigen Informationen wissen, ob das Produkt einen geschäftlichen Wert für sie hat?

Warum Smartsheet ein leistungsstarkes Tool für das Waterfall-Projektmanagement ist

Von einfacher Aufgabenverwaltung und Projektplanung bis zu komplexem Ressourcen- und Portfoliomanagement hilft Ihnen Smartsheet, die Zusammenarbeit zu verbessern und das Arbeitstempo zu erhöhen – und befähigt Sie, mehr zu schaffen. Mit der Plattform von Smartsheet ist es einfach, Arbeiten von überall zu planen, zu erfassen, zu verwalten und darüber zu berichten. So helfen Sie Ihrem Team, effektiver zu sein und mehr zu schaffen. Sie können über die Schlüsselmetriken Bericht erstatten und erhalten Echtzeit-Einblicke in laufende Arbeiten durch Rollup-Berichte, Dashboards und automatisierte Workflows, mit denen Ihr Team stets miteinander verbunden und informiert ist. Es ist erstaunlich, wie viel mehr Teams in der gleichen Zeit erledigen können, wenn sie ein klares Bild von der geleisteten Arbeit haben. Testen Sie Smartsheet gleich heute kostenlos.

Entdecken Sie eine bessere Methode, Workflows zu straffen und Silos endgültig abzuschaffen.

Smartsheet kostenlos testen Get a Free Smartsheet Demo