Blogartikel zum Schlagwort: Projektmanagement

Auch unsere zertifizierten Berater arbeiten nach den PRINCE2 Standards

PRINCE2 – Die fürstliche Projektmanagement-Methode

Moderne Berufe lassen sich, vor allem wenn es um digitale Themen geht, nur sehr schlecht standardisieren. Jeder Kunde hat verschiedene Anforderungen, Prioritäten und finanzielle Möglichkeiten, wodurch auch das abgelieferte Produkt meist variiert. Daher werden Arbeitspakete oftmals als eigenständige Projekte bearbeitet. Doch was genau ist ein Projekt bzw. wie lässt es sich definieren?

Ein Projekt ist eine für einen befristeten Zeitraum geschaffene Organisation, die mit dem Zweck eingerichtet wurde, ein oder mehrere Produkte in Übereinstimmung mit einem vereinbarten Business Case zu liefern.

Das ist die Definition nach PRINCE2, einer der neben ICB oder PIMBOK weltweit führenden Projektmanagementmethoden, die auch unsere Arbeit bei der kreITiv maßgeblich beeinflusst. Warum nutzen wir diese Methode und was sind ihre Vorteile?

Flexibles Framework für skalierbares Projektmanagement

PRINCE steht für Projects in Controlled Enviroments und ist ein britischer Entwurf aus dem Jahr 1989. Nach einigen Verbesserungen entstand 1996 PRINCE2, das 2009 noch einmal überarbeitet wurde.

Ähnlich wie die Best-Practice-Sammlung ITIL ist PRINCE2 nicht starr. Es ist ein skalierbares Framework, das vom Hersteller zwar oft als Best-Practice-Ansatz beschrieben wird, aber nichtsdestotrotz durch deutliche Prozesse mit definierten Rollen für eine klare Struktur sorgt.

Grundlage sind 7 Grundprinzipien, 7 Themen, 7 Prozesse und die Anpassung an die Projektumgebung. Jedes Projekt ist einmalig, Anpassung bedeutet also, die passende Projektorganisation mit Rollenbesetzung und Dokumentation festzulegen. Schließlich soll der Managementaufwand nicht größer sein, als das Projektergebnis wert ist.

Das führt zu einer enormen Flexibilität und Skalierbarkeit, was diese Methode für Projekte aller Art und jeder Größe attraktiv macht. Ihre wichtigsten Aspekte sind:

  • immer auf den Business Case, die geschäftliche Rechtfertigung des Projekts, ausgerichtet
  • Fokus auf Einteilung in kontrollierbare Phasen
  • produktbasierte Planung
  • Definition des Projektmanagementteams (in der Praxis können einzelne Personen mehrere Rollen einnehmen) und der Organisationsstruktur
  • permanente Aufwands- und Risikobewertung
  • Definition der Kommunikationswege
  • „Management by Exception“ – Verantwortliche/Auftraggeber werden informiert, greifen aber nur in Ausnahmefällen ins Projekt ein

Updates für PRINCE2 – Neues aus dem Königspalast?

Im Jahr 2017 gab es nach 2009 noch einmal eine größere Überarbeitung. Bisher gibt es diese nur für die englische Sprachversion, soll aber 2018 auch für andere Sprachen zur Verfügung gestellt werden. Entsprechend des Best-Practice-Ansatzes basiert dieses Update zu großen Teilen auf Feedback von Nutzern und wurde bei Einführung mit der Community abgestimmt. Fokus liegt dabei eher auf einer weiteren Verbesserung der Anpassbarkeit, während die grundlegenden Prinzipien beibehalten wurden.

Die große Verbreitung als einer der gängigen Standards im Projektmanagement, die flexible Anwendbarkeit sowie die inhaltliche Nähe zu ITIL machen PRINCE2 zu einem idealen Ansatz gerade für IT-Service-Dienstleister wie die kreITiv. Sollten Sie Interesse an diesem Thema haben, wenden Sie sich gern an uns. Unsere Berater sind PRINCE2-zertifiziert und helfen Ihnen gern weiter.

Agiles Projektmanagement im Vergleich zu klassischen Ansätzen

Agiles Projektmanagement für ERP-Systeme – Wie geht das?

Wissen Sie, wie die Einführung eines neuen ERP-Systems in Unternehmen normalerweise abläuft? Wir skizzieren den Ablauf für ein agiles Projektmanagement im ERP-Bereich von der Konzeption bis zur Implementierung am Beispiel der fiktiven Schneidereit & Söhne GmbH.

 

Die klassische ERP-Einführung im Fallbeispiel

Die für das Einführungsprojekt zuständigen Schneidereit-Mitarbeiter füllen Seiten über Seiten von Standardvorlagen mit möglichst klar formulierten Anforderungen, die den gewünschten Funktionsumfang des Systems abschließend beschreiben sollen. Diese werden in ein Pflichtenheft gegossen, das vom Auftraggeber und dem Beratungsunternehmen akzeptiert und vertraglich abgesichert wird. Danach wird Phase für Phase des Projektplans abgearbeitet bis das Pflichtenheft in allen Punkten zu ausreichender Zufriedenheit erfüllt wurde.

Immerhin 1/3 der Unternehmen können so glücklich in eine effizientere Zukunft starten. 2/3 aller Firmen begegnen auf diesem Weg jedoch Stolpersteine: Das Projekt verzögert sich, die Kosten explodieren, Krisensitzungen werden anberaumt und im schlimmsten Fall wird das Projekt abgebrochen. Dann können Auftraggeber und -nehmer nur noch hoffen, dass der Vertrag gut genug ausgearbeitet war und niemand finanziell ruiniert wird.

Vielen projektgefährdenden Hürden könnte man mit einem agileren Projektmanagement Herr werden. Was genau darunter zu verstehen ist, erfahren Sie in unserem Artikel zu den Grundlagen agiler Softwareentwicklung. Im Grunde handelt es sich um einen Überbegriff für Ansätze, die Projekte in kleinen Teams Output-orientiert steuern. Der weitere Projektablauf geschieht in Sprints” und wird phasenweise je nach Fortschritt geplant.

Das ermöglicht ein deutlich flexibleres Projektvorgehen, setzt aber auch gegenseitiges Vertrauen voraus. Während sich agiles Projektmanagement in der Softwareentwicklung längst durchgesetzt hat, werden ERP-Projekte oftmals noch immer nach dem etwas angestaubt wirkenden Wasserfallmodell, einem linearen Phasenmodell, durchgeführt. Trauen sich Projektmanager einfach nicht an innovative Ansätze heran oder gibt es gute Gründe dafür?

Agile ERP-Projekte, wie geht das denn?

Ein agilerer Ansatz für die komplexere Einführung von Unternehmenssoftware könnte nach unserem Fallbeispiel folgendermaßen aussehen.

 

Agiles Projektmanagement im Modell

Statt per Pflichtenheft den Leistungsumfang zu definieren, legt Schneidereit & Söhne ein bestimmtes Zeitfenster und Geldbudget fest. In regelmäßigen Abstimmungsmeetings wird der Fortschritt des Projektes analysiert und gemeinsam das weitere Vorgehen beschlossen. Bei knappen Ressourcen ist es unwahrscheinlich, dass jede Anforderung bis ins letzte Detail erfüllt werden kann. Das macht es notwendig, gemeinsam Prioritäten für jede Anforderung festzulegen, wobei höher priorisierte Bestandteile zuerst realisiert werden.

Sind Zeit und/oder Geld aufgebraucht, wird das Projekt (in der Regel) beendet. Doch dann sind die wichtigsten Anforderungen bereits realisiert worden. Nun kann beraten werden, ob sich weiterer Aufwand lohnt, um die verbleibenden „unwichtigen“ Anforderungen noch nachzuliefern. Damit wird der Situation vorgebeugt, dass immer weitere Gimmicks ins ERP-System integriert werden sollen und den Projektrahmen aufblähen.

Durch den oftmals modularen Aufbau von Unternehmenssoftware ist dieser Ansatz prinzipiell gut umsetzbar. Er fördert die Kommunikation der Projektbeteiligten und zwingt das einführende Unternehmen, genauer zu reflektieren, zu welchem Zweck ein ERP-System eigentlich eingeführt werden soll und welchen objektiven Wert einzelne Systembestandteile bieten.

Durch dieses schrittweise Vorgehen, wird der inhaltliche und ökonomische Zweck des nächsten Leistungspaketes regelmäßig hinterfragt, was der steigenden Komplexität der einzuführenden Systeme gerechter wird. Warum wird also nicht immer so vorgegangen?

Woran agile Ansätze scheitern können

Im Gegensatz zum typischen Projekt in der Softwareentwicklung ist der Kunde in eine ERP-Einführung wesentlich stärker eingebunden. Das vereinfacht zwar viele Dinge, etwa bei der Anforderungserhebung, heißt aber auch, dass der Einführungsdienstleister bei der Wahl seines Projektplanungsansatzes stärker auf den Kunden Rücksicht nehmen muss.

  • Lassen die individuellen Gegebenheiten überhaupt einen flexibleren Ansatz zu?
  • Wie verhandelbar sind Preise, Termine oder Anforderungen während des Projektverlaufs?
  • Hat das einführende Unternehmen das nötige Vertrauen, auf die agilen Ansätze einzugehen?

Agile Managementansätze wie Scrum oder Kanban setzen kleine, selbststeuernde Teams voraus. Diese Autonomie erhöht in der Regel die Zufriedenheit der Mitarbeiter, verlangt vom Projektmanagement aber Vertrauen ins Team und die Projektpartner sowie gute Kenntnisse über deren Fähigkeiten. Diese Gegebenheiten bietet allerdings nicht jedes Einführungsprojekt.

Die kundenseitige Bereitschaft zu agilem Projektmanagement kann man nicht immer voraussetzen, auch wenn sich neue Denkansätze schnell per PowerPoint vermitteln lassen. Ebenso kann niemand zu dem sehr hohen Kommunikationsbedarf gezwungen werden. Trotz vieler Vorteile kann es also sein, dass die Umstände eine agile Projektdurchführung nicht zulassen oder die Beteiligten den damit verbundenen Kontrollverlust nicht wünschen, wodurch auf klassische Ansätze zurückgegriffen werden muss.

Klassische oder agile Methoden im Projektmanagement?

Wie entkommt man nun dieser Falle? Die Wahrheit liegt wie so oft in der Mitte. Ein guter Projektmanager sollte auch agile Managementansätze anwenden können. In der Praxis muss im Einzelfall entschieden werden, wo klassisches Vorgehen notwendig ist und projektstabilisierend wirkt und wo durch flexibleres Vorgehen das Projekt effektiv unterstützt werden kann.

Der wichtigste Ansatz ist, sich immer am Kundennutzen zu orientieren, denn der wichtigste Indikator für den Projekterfolg ist letztendlich die erzeugte Wertschöpfung sowie die Zufriedenheit des einführenden Unternehmens mit dem fertiggestellten System. Wir von kreITiv unterstützen Sie gern bei der Planung und Durchführung Ihres eigenen Einführungsprojektes – welcher Managementansatz auch der Beste ist.

Sinn und Zweck der Entwicklung eines Prototyps in einem Software-Projekt

3 Arten von Prototyping in der Softwareentwicklung

Prototyping ist ein seit langem verbreitetes Prinzip in der Softwareentwicklung. Doch um was genau handelt es sich dabei und was ist der Unterschied zu einem Mock-up?

Der Grund für die Existenz beider Prinzipien ist das Entwickeln einer gemeinsamen Basis, die dem Kunden auf der einen und dem Entwicklerteam auf der anderen Seite bei der Kommunikation helfen. Eine konkrete Modellierung hilft beiden Parteien, ein besseres Verständnis vom Zielsystem aufzubauen.

Dabei sind Prototypen funktionsfähige Entwürfe, die bereits grundlegende Funktionalitäten beinhalten. Mock-ups dagegen sind Attrappen und besitzen normalerweise keine Funktionalität, sind also nicht mit Programmlogik angereichert. Dafür können Mock-ups dem Kunden ein deutlicheres Bild vom Endergebnis vermitteln als ein teils funktionsfähiger Prototyp.

Ein Prototyp als erster Schritt zur Software

Prototyping steht am Anfang eines Softwareprojekts für die Entwicklung eines Musters. Es ist ein Verfahren, welches im Software-Engineering eingesetzt wird. Gegenstand des Prototypings ist die Entwicklung einer lauffähigen Software bzw. einer Softwarekomponente, die bestimmte Kernfunktionen abdeckt. Das Verfahren ist kostengünstiger, da es weniger Zeit in Anspruch nimmt als die Komplettentwicklung. Der Prototyp kann erstellt und getestet werden. Fehler können somit frühzeitig erkannt und Änderungswünsche besser berücksichtigt werden als bei der fertigen Software.

Empfehlenswert ist der Einsatz vor allem dann, wenn die endgültigen Anforderungen und Spezifikationen für die komplette Software noch nicht ausgearbeitet werden. Dabei kann man es als iterativen Prozess betrachten, der zwischen Entwicklerteam und Auftraggeber stattfindet.

Es haben sich unter anderem folgende Arten herausgebildet: Exploratives, experimentelles und evolutionäres Prototyping. Daneben gibt es noch das Rapid-Prototyping für die schnelle Herstellung eines Musters.

1. Exploratives Prototyping – Ermittlung verschiedener Lösungsansätze

Das explorative Prototyping dient dazu, den Entwicklern einen Einblick in den Anwendungsbereich zu vermitteln, mit dem Auftraggeber verschiedene Lösungsansätze zu diskutieren und die Realisierungsmöglichkeiten abzuschätzen. Dazu wird auf Grundlage der Anwendung und Kundenvorstellungen ein Prototyp entwickelt. Beim explorativen Prototyping geht es in erster Linie um die Funktionalität des Systems, weniger um dessen (optische) Qualität.

2. Experimentelles Prototyping – Verdeutlichung eines Gesamtsystems

Einen anderen Ansatz verfolgt das experimentelle Prototyping. Hierbei sollen sämtliche Teilsysteme für die spätere Implementierung vollständig definiert werden. Anschließend soll die Funktion der Teilsysteme nachgewiesen und die jeweiligen Schnittstellen überprüft werden. Im Vordergrund stehen also die Einzelkomponenten und ihr Zusammenspiel.

3. Evolutionäres Prototyping – Schrittweise zum Endprodukt

Beim evolutionären Prototyping geht es um eine stufenweise Systementwicklung. Das System soll schrittweise nach den exakten, definierten Spezifikationen aufgebaut werden. Jeder Zwischenschritt dient als Grundlage für die inkrementelle Weiterentwicklung, basierend auf weiteren Spezifikationen. Das evolutionäre Prototyping ist eine Vorgehensweise, bei dem der Prototyp grundsätzlich das fertige Produkt darstellt.

Softwareentwicklung bei der kreITiv

Zusammenfassend sehen wir Prototyping in der Softwareentwicklung als effiziente Technik, um die späteren Anwender frühzeitig und kontinuierlich in die Entwicklung einzubeziehen. Dadurch lässt sich das Risiko von Fehlentwicklungen reduzieren und Kunden sind mit dem Endergebnis deutlich zufriedener.

Auch wir als Team der kreITiv wissen um die Mehrwerte, die Prototyping mit sich bringt und setzen vermehrt auf dieses Werkzeug, um bei jedem Projekt von Anfang an mit dem Kunden ein einheitliches und gemeinsames Verständnis vom Endergebnis zu entwickeln.

Das "Manifest für agile Softwareentwicklung" dokumentiert allgemeine Prinzipien

Scrum oder Kanban – Die Grundlagen agiler Softwareentwicklung

Im Projektmanagement und der Prozesssteuerung existieren heute zahlreiche agile Methoden und Tools, die jeweils eigenen Regeln und Vorgehensweisen folgen. Einige dieser Ansätze ziehen einen sehr engen Rahmen, andere lassen mehr Freiheiten. Trotz aller Unterschiede basieren sie aber alle auf denselben Prinzipien, die im „Manifest für agile Softwareentwicklung“ dokumentiert sind.

  • Das Manifest besagt unter anderem, dass es wichtiger ist, schnell auf geänderte Anforderungen zu reagieren, als strikt einem Plan zu folgen.
  • Als wichtiger Erfolgsfaktor für agil geführte Projekte gilt, dass alle Beteiligten die richtige Einstellung haben, um in einem agilen Projektumfeld arbeiten zu können.
  • Die Offenheit, möglichst auch verschiedene Komponenten unterschiedlicher Methoden zu kombinieren, ist ein weiterer wichtiger Aspekt des Manifests. Im Ergebnis sollen die eigenen Ansprüche optimal bedient werden. Wichtig sind das Bewusstsein und die Möglichkeit zur Kombination.

Auch die Softwareentwicklung folgt seit den letzten Jahren häufig einer agilen Methode. Die zwei verbreitetsten Ansätze auf diesem Gebiet sind Scrum und Kanban.

Vergleich von Scrum und Kanban

Ein oft erwähnter Vorteil solcher Methoden ist, dass Projekte durch den Einsatz der agilen Prinzipien schneller abgeschlossen werden können. Erreicht wird das durch Prozessoptimierung. Höhere Transparenz soll Optimierungspotenziale aufzeigen und dadurch eine Effizienzverbesserung ermöglichen.

Sowohl Scrum als auch Kanban setzen voraus, dass die Beteiligten ihre Umgebung anpassen. Es existieren Gerüste aus Regeln, in denen die Teams den gegebenen Spielraum nutzen können. Grundsätzlich kann man sagen, dass Kanban einen etwas flexibleren Rahmen vorgibt als Scrum. Aber ziehen wir einmal einen Direktvergleich…

Gemeinsamkeiten

  • leicht verständlich und schnell einführbar
  • lassen die Beteiligten entscheiden, wann sie welche ToDos bearbeiten
  • basieren auf fortlaufender Prozessoptimierung
  • betonen, dass die schnelle Anpassung wichtiger ist, als einem festen Plan zu folgen
  • setzen auf Transparenz, um Prozessverbesserungen zu beschleunigen
  • sind darauf ausgerichtet, Software schnell auszuliefern
  • unterteilen anfallende Aufgaben in kleinere Pakete
  • helfen dabei, durch empirische Daten kontinuierlich den Release-Plan zu optimieren

Vorteile von Scrum

  • kurze Kommunikationswege
  • hohe Flexibilität/Agilität durch adaptives Planen
  • hohe Effektivität durch Selbstorganisation
  • hohe Transparenz durch regelmäßige Meetings und Backlogs
  • zeitnahe Realisation neuer Produkteigenschaften bzw. Inkremente
  • kontinuierlicher Verbesserungsprozess
  • kurzfristige Problem-Identifikation
  • geringer Administrations- und Dokumentationsaufwand

Vorteile von Kanban

  • direkte Visualisierung des Projektablaufs macht Probleme anhand von Ticket-Häufungen schnell sichtbar
  • übergreifendes System, das prinzipiell auf jeden bestehenden Entwicklungsprozess aufgesetzt werden kann
  • negatives Multitasking optimal vermieden
  • geringe Größe der einzelnen Tickets hat zur Folge, dass die Beschreibung der verschiedenen Tasks auf das Wesentliche beschränkt ist
  • Board dient als Kommunikationsgrundlage und Fundament, über das sich das Team synchronisiert

 

Start in die agile Softwareentwicklung mit einem Kanban Board

Ein einfaches Kanban Board, Bildquelle: Kanban Tool (CC BY-SA 2.0)

Ein Kanban Board repräsentiert den individuellen Bearbeitungsprozess eines Teams, das klassische Scrum Board ist dagegen immer gleich aufgebaut. Letzteres begrenzt die Arbeitsbelastung indirekt durch die Einschränkung der Anzahl der Karten im Sprint Backlog. Ein Kanban Board kann die Anzahl der Karten je Spalte direkt begrenzen.

Kanban oder Scrum – Was ist besser?

Neben Scrum und Kanban gibt es noch weitere agile Ansätze, von denen einige auf den beiden vorgestellten Methoden basieren. Jedes Team, das agil arbeiten möchte, muss für sich die relevanten Elemente der verschiedenen Ansätze finden und passend kombinieren. Da es keine Allround-Methode für alle denkbaren Projekte gibt, ist Ausprobieren und Variieren notwendig, um die optimale Lösung zu finden.

Auch wir arbeiten seit vielen Jahren nach den Prinzipien agiler Softwareentwicklungsmethoden, was nicht nur bei Mitarbeitern, sondern insbesondere bei Partnern und Kunden für erfolgreiche Projektabschlüsse sorgt. Gerne beraten wir Sie auch zu diesen Themen.