Websites ohne Code: Was kann Elementor?

Websites lassen sich heutzutage ohne eine einzige Codezeile entwickeln. Treiber dieser Nocode-Revolution sind sogenannte Baukastensysteme, die es Anwendern ermöglichen, Webseiten visuell über vorgefertigte Bausteine zusammenzustellen. Marktführer in dieser Branche ist das WordPress-Plugin Elementor – ein mächtiger Page-Builder, der professionelle Websites in Nullkommanichts aus dem Boden stampft. Wir erklären Ihnen, was Elementor alles kann und warum er auch für Softwareentwickler hilfreich ist.

Elementor: Grundlagen, Funktionen, Einsatzzwecke

Webbaukästen wie Elementor enthalten bereits eine grafische Oberfläche (GUI) sowie eine Reihe an Elementen und Vorlagen, um eine Webseite nach dem WYSIWYG-Prinzip zu bauen. Sprich: Bausteine und Inhalte werden direkt auf der Seite bearbeitet statt im Quellcode („Live Editing“). Elementor bietet dafür eine praktische Drag & Drop-Funktionalität, mit der das Anordnen und Anpassen der einzelnen Elemente zu einem Kinderspiel wird.

Eine Besonderheit von Elementor ist, dass der Page-Builder nicht nur statische Seiten, sondern auch dynamische Templates erstellen kann. Das beginnt bei der aktuellen Jahreszahl im Copyright-Hinweis und endet bei spezifischen Popups, wenn jemand auf ein bestimmtes Feld klickt. Außerdem liefert das Plugin ein eingebautes „Responsive Editing“, mit dem Sie Ihre Seiten und Elemente für verschiedene Auflösungen steuern können.

Wie unterscheiden sich die Free- und die Pro-Version?

Für Elementor-Starter dürfte sich zunächst die Frage stellen, ob die kostenlose Basisversion für die eigenen Zwecke ausreicht oder ob der Griff zur Pro-Version (ab 49 Dollar/Jahr) sinnvoll ist. Wie nicht anders zu erwarten, ist die Auswahl an Funktionen und Vorlagen in der kostenlosen Variante stark begrenzt. Die folgenden Punkte erläutern die wichtigsten Unterschiede:

  • Templates: Templates sind Design-Vorlagen für einzelne Seiten (z.B. Landing Pages oder Beiträge). Eine große Auswahl kann Ihnen hier nur die Pro-Version bieten.
  • Widgets: Elementor Free liefert um die 40 Basis-Widgets für einfache Websites. In der Pro-Version erhalten Sie dutzende weitere, darunter auch Theme-Elemente (für Header, Footer, 404-Seiten usw.) und Widgets für WooCommerce.
  • Kits: Elementor Kits sind Layout-Packs mit mehreren Templates für eine komplette Website. In der Basisversion können Sie zwischen fünf Kits wählen, während die Pro-Version über 100 Kits bereitstellt.
  • Dynamische Inhalte: Die bereits angesprochenen dynamischen Inhalte und Tags sind nur für Pro-Nutzer verfügbar.
  • Builder-Tools: Den Drag & Drop Builder können Sie in beiden Versionen nutzen. Weitere Builder wie den Theme Builder, Popup Builder oder WooCommerce Builder gibt es ausschließlich bei Elementor Pro.

Zusammenfassend lässt sich sagen: Für einfache, statische Seiten wird Ihnen die kostenlose Version genügen. Falls Sie jedoch komplexere Inhalte benötigen oder sogar ein Shopsystem mit WooCommerce planen, kommen Sie um die Pro-Version nicht herum.

Vorteile von Elementor in der Softwareentwicklung

Elementor oder Page Builder im Generellen sind in erster Linie für Personen gedacht, die keine oder wenige Programmierkenntnisse mitbringen. Doch selbst für versierte Web Developer bieten Nocode-Entwicklungsumgebungen große Vorteile, da sie den Webentwicklungsprozess deutlich beschleunigen. Vorgefertigte Bausteine sind schnell anpassbar und in der Anwendung oft sicherer und stabiler als neu programmierter Code. Da Elementor open source ist, können Sie das Plugin mit individuellen Add-ons erweitern, ohne den Aufwand einer kompletten Websiteerstellung zu haben oder andere Plugins hinzuziehen zu müssen. Die Vorteile von Elementor auf einen Blick:

  • Intuitive Bedienung dank des visuellen Frontend Editings (auch für Neulinge)
  • Erweiterbarkeit für Developer mithilfe des Theme Builders
  • Sehr viele Designeinstellungen und einfachste Bearbeitungsoptionen
  • Globale Widgets, die über mehrere Websites hinweg verwendet werden können
  • E-Commerce Integration sowie eingebaute Marketing-Tools
  • Große Developer-Community für zusätzliche Seitenvorlagen oder Add-ons

Zusammenfassung

Elementor ist ein hochfunktionaler Page-Builder für WordPress-Seiten, der mit rein visuellen Elementen statt Quellcode-Programmierung arbeitet. Für Entwickler bietet diese Nocode-Lösung erhebliche Zeit- und Ressourcenvorteile, da im Grunde nur noch die Feinheiten angepasst werden müssen – und selbst diese erfordern nur marginale bis gar keine Code-Skills.

Wer glaubt, dass sich damit nur einfachste Seiten bauen lassen, hat sich getäuscht: Elementor Pro liefert auch komplexe Webfunktionalitäten, sei es das Erstellen dynamischer Templates oder die Integration von WooCommerce-Elementen. Diese extrem hohe Flexibilität ist einer der Gründe, warum Elementor zu Recht der erfolgreichste und am häufigsten genutzte Page-Builder für WordPress ist.

Scrum ausweiten – was ist SAFe?

Wenn ein Projekt immer größer wird und das Team stetig wächst, kann Scrum an seine Grenzen stoßen. Wie kann es dann weitergehen? Es gibt verschiedene Skalierungsframeworks, mit dessen Hilfe Sie Scrum ausweiten können. Zu den beliebten Frameworks dieser Art gehört SAFe. Wie die Skalierung damit funktioniert, erfahren Sie in diesem Artikel.

Warum sollte Scrum skaliert werden?

Scrum definiert eine feste Teamgröße. Nun ist es aber immer häufiger erforderlich, dass mehrere Teams zusammenarbeiten, da ein Projekt sonst nicht bewältigt werden kann oder sich richtig lange ziehen würde.

Skalierungsframeworks bieten den Vorteil, dass Teams agil weiterarbeiten können, das Unternehmen aber neue Strukturen zur Verfügung gestellt bekommt, um das Ganze zu steuern.

Es gibt verschiedene Skalierungsframeworks, die Scrum skalieren können. Scrum of Scrums haben wir Ihnen bereits vorgestellt, ein weiteres beliebtes Framework ist SAFe.

SAFe – ein neues Mindset

Das Skalierungsframework SAFe kommt in mehreren Versionen einher, je nach Projektgröße und Ziel greift eine andere Version. Dabei betrachtet es drei Ebenen: das Team, das Portfolio und das Programm. Was bedeutet das? Das Framework wird nicht einfach nur auf die Arbeit des Teams angewendet, sondern eben auf alle drei Betrachtungsebenen.

Eine der Versionen wird als Full Solution bezeichnet. In dieser Version eignet es sich, das gesamte Unternehmen umzustrukturieren. Anders als bei anderen Frameworks liegt der Fokus nicht auf den Inkrementen, die ein Team produziert, sondern auch in der Weiterentwicklung des Unternehmens. Die Ideensammlung, Reflektion und die Wertschöpfung bekommen ausreichend Raum.

Das klingt nach einem neuen Mindset? Auch darum geht es. Schließlich bekommt Führung hier eine neue Bedeutung und Prozesse und die Zusammenarbeit wird transparent. So viel Umstrukturierung und Arbeit kann auf Unternehmen abschreckend wirken. Auch dafür hat SAFe eine Lösung! Das Framework kommt mit einer Roadmap um die Ecke, die genau beschreibt, was in welchem Prozessschritt zu tun ist, damit die Implementierung stufenweise funktioniert. Und vor allem, damit alle verstehen, was vor sich geht und ein Teil der Transformation sein können.

Doch was hat es mit Scrum zu tun? Um das zu erklären, schauen wir uns an, wie SAFe funktioniert.

Ein Projekt mit SAFe auf die Schienen bringen

Was haben Projekte mit Zügen zu tun? In SAFe werden mehrere Scrum Teams zu einem übergeordneten Team zusammengefasst: dem Agile Release Train (ART). Jedes Scrum Team in diesem Zug beziehungsweise in diesem ART hat weiterhin jeweils einen Scrum Master und einen Product Owner, zusätzlich kommen drei neue Rollen hinzu:

  • Der Release Train Engineer (RTE): Er coacht die Art-Teams, ist als dienende Führungskraft zur Stelle und übernimmt die Stakeholderkommunikation.
  • Product Manager: Er kümmert sich um das Anforderungsmanagement, erstellt Produktdefinition und treibt das Design Thinking voran.
  • System Architect/Engineer: Er definiert sowohl eine architektonische als auch technische Lösung, die für das Projekt passend ist und kommuniziert/vernetzt diese in den Teams.

In einem ART können zwischen 50 und 125 Personen zusammenarbeiten, wenn es mehr sind, können die Scrum Teams auf mehrere ARTs aufgeteilt werden, die wiederum gemeinsam einen Solution Train bilden. In SAFe gibt es eine feste Länge für Product Increments (PI) und ein PI-Planning, bei welchem alle anwesend sind.

Vor- und Nachteile von Safe

Das Agile Framework bringt einige Vor- und Nachteile mit sich. Die Top 3 sind:

Vorteile:

  • Roadmap erleichtert die Implementierung
  • Ist auf das gesamte Unternehmen anwendbar
  • Die Möglichkeit zur Weiterentwicklung dadurch, dass Teams auch Organisationsziele behandeln können

Nachteile:

  • Ein guter Plan ist erforderlich und neue Prozesse müssen geschaffen werden
  • Das Top-Down Vorgehen steht in Konflikt zu den agilen Prinzipien
  • Komplexität erfordert Schulungen der Beteiligten

Fazit

Wenn Scrum an seine Grenzen kommt, steht SAFe schon parat. Je nach Personenanzahl lassen sich unterschiedlich viele Scrum Teams in ARTs zusammenfassen. So ist der Agilität auch in großen Projekten weiterhin kaum eine Grenze gesetzt.

Plattformen: Geschäftsmodell in unter 100 Wörtern erklärt

Plattformen sind das Herzstück der Digitalisierung. Tagtäglich kommen wir als Nutzer mit ihnen in Verbindung: Marktplätze wie eBay und Amazon, Suchmaschinen wie Google, soziale Netzwerke wie Facebook. Zwar sieht die Plattformlandschaft in den USA etwas anders als in Deutschland, aber auch bei uns floriert das Platform Business – besonders im B2B. Wir bringen auf den Punkt, was das Geschäftsmodell so erfolgreich macht.

Die Definition eines Plattformgeschäfts

Ein Plattformunternehmen ist ein Geschäftsmodell, das Interaktionen zwischen einer Vielzahl von Teilnehmern erleichtert. Bei diesen Interaktionen kann es sich sowohl um kurzfristige Verbindungen (v.a. im Customerbereich) als auch um den Aufbau langfristiger Beziehungen bzw. Kooperationen handeln. Die Aufgabe des Plattformunternehmens besteht darin, eine Governance-Struktur und eine Reihe von Standards und Protokollen bereitzustellen, um Anbieter, Kunden und Tools zusammenzubringen. Das heißt: Ein Plattformgeschäft bietet in der Regel keine eigenen Produkte oder Dienstleistungen an, sondern stellt lediglich eine Schnittstelle – die Plattform – für die Marktteilnehmer zur Verfügung. Aus dem komplexen Zusammenspiel von Anbietern und Kunden ergeben sich letztlich sogenannte Netzwerkeffekte.

Welche Arten von digitalen Plattformen gibt es?

Der erste Schritt in der Beratung von Plattformgeschäften ist, herauszufinden, welche Art Plattform die eigenen Anforderungen am besten erfüllt. Dazu ein grober Überblick:

Transaktionszentrierte Plattformen

Bei diesen Plattformen geht es um die reine Transaktion (Kauf, Tausch, Angebot). Sie führen ein breites Spektrum relevanter Ressourcen zusammen und vereinfachen den Austausch und Handel zwischen allen beteiligten Akteuren. Beispiele sind digitale B2C- und B2B-Marktplätze sowie On-Demand-Services wie Uber oder Paypal.

Soziale Plattformen

Im Mittelpunkt von sozialen Plattformen – etwa Facebook oder Wikipedia – steht nicht die Abwicklung einer Transaktion, sondern die Interaktion zwischen Interessengruppen. Bei dieser Art Plattform können die Rollen der Teilnehmer überlappen oder wechseln: Anbieter sind auch Kunden, Kunden sind auch Anbieter (Multi-Side-Effekt).

Datenzentrierte Plattformen

Charakteristisch für diese Plattformen ist eine datenbasierte Vernetzung. Man unterscheidet dabei zwischen Aggregatoren- und Technologie-Plattformen. Erstere sammeln Daten oder nutzen eigene Datenbestände, um daraus neue Angebote zu erstellen, wie es beispielsweise Amazon oder Google tun. Zweitere bieten Infrastrukturen für einen systemübergreifenden Datenaustausch. Beispiele für solche IoT- oder Utility-Plattformen sind Siemens Mindsphere oder Bosch IoT Suite.

Welche Vorteile haben digitale Plattformen?

Klassische „Pipeline“-Geschäftsmodelle basieren auf einer linearen Wertschöpfungskette: Aus einem Rohstoff wird ein Produkt, das wir am Markt an den Kunden verkaufen. Das Problem an diesen Systemen ist, dass sie schwer zu skalieren sind. Wachstum lässt sich nur mit einem überproportional großen Mehraufwand und auch nur bis zu einer gewissen Grenze erzeugen, während das Prozessmanagement immer komplexer wird.

Plattformökosysteme haben diese Einschränkungen nicht. Darüber hinaus bieten sie zahlreiche Vorteile, die in der heutigen digitalen Geschäftswelt immer unerlässlicher werden:

  • Niedrige Transaktionskosten: Kennzeichnend für digitale Plattformen sind zwar relativ hohe Fixkosten, aber nur geringe marginale Kosten für zusätzliche Kunden.
  • Hohe Skalierbarkeit: Eine virtuelle Plattform, die selbst nur als Intermediär agiert und feste Kostenstrukturen besitzt, kann nahezu beliebig skaliert werden.
  • Nachhaltigkeit: Innovative Plattformgeschäfte sind für Unternehmen zukunftsweisend. Sie schaffen Handlungsspielraum, steigern die Effizienz und stärken die Wettbewerbsfähigkeit. 
  • Netzwerkeffekte: Plattformen schaffen (Mehr-)Werte durch die vielseitigen Verbindungen von Anbietern, Kunden und Ressourcen. Je mehr Anbieter eine Plattform nutzen, desto attraktiver wird sie auch für Kunden, weil das Angebot steigt. Umgekehrt steigt die Lukrativität einer Plattform, je mehr Kunden sich darauf befinden. Diese Gegenseitigkeit bezeichnet man als Netzwerkeffekt, der zu exponentiellen Wachstumssteigerungen führen kann.

Bevor Sie sich nun in wilde Überlegungen stürzen, wie Sie Ihr eigenes Platform Business aufbauen: Halt! Bedenken Sie, dass eine Plattform nicht für jedes Unternehmen geeignet ist – oft kann es zum Beispiel sinnvoller sein, sich als Partner an bereits vorhandenen Plattformen zu beteiligen. Im Consulting wird dieser Punkt ausführlich geklärt und analysiert.

Zusammenfassung

Digitale Plattformen rücken immer weiter ins Zentrum von Marktstrukturen und verdrängen damit traditionelle, einseitig ausgelegte Märkte. Sie vereinfachen den Handel und Austausch zwischen Interessengruppen in einer einheitlichen virtuellen Umgebung, sind zudem hoch skalierbar und können für verschiedenste Branchen und Zwecke eingesetzt werden. Kurz und knapp: Wer langfristig im nationalen und globalen Wettbewerb mithalten will, kommt um das Plattformgeschäftsmodell nicht mehr herum.

Agiles Projektmanagement – warum nicht alles SMART sein kann

Ziele gehören zu einem Projekt wie das Amen in die Kirche. Es heißt immer wieder, dass Ziele SMART formuliert sein müssen. Ist das wirklich so? Was versteckt sich hinter der SMART-Formel und warum kann es von Vorteil sein, eher auf agile Methoden zu setzen? Genau diese Fragen werden wir nun behandeln.

SMART – was bedeutet das?

Um Ziele im klassischen Projektmanagement zu formulieren, setzen Projektleiter häufig auf die Smartformel. SMART ist ein Akronym und steht für:

S – Spezifisch

M – Messbar

A – Akzeptiert, Attraktiv

R – Realistisch

T – Terminiert

Das bedeutet, dass ein Ziel alle oben genannten Kriterien erfüllen muss. Entworfen wurde diese Formel, um Ziele zu konkretisieren und zu verhindern, dass diese schwammig formuliert sind.

Das ist logisch und natürlich sinnvoll, aber eben nicht überall. Was ist, wenn das Ziel eines Projektes offen ist? Es kommt außerdem oft genug vor, dass neue Anforderungen die Projektleitung dazu zwingen, die Richtung zu ändern.

Und hier zeigen sich auch die Nachteile der SMART-Formel. Die mangelnde Flexibilität.

Zudem sind realistische und akzeptierte Ziele nicht immer auch ambitioniert. Wer nach den Sternen greifen möchte, kommt mit der Formel also nicht an sein Ziel. Die smarte Formulierung lässt zudem kaum Spielraum für Auslegungen, sollten sich die Umstände verändern.

Ein weiteres Problem: Die Projektleitung formuliert die Ziele zu Projektbeginn und das Projekt nimmt seinen Lauf durch diverse Phasen hindurch. Ein Eingreifen oder Verändern der Phasen ist im klassischen Projektmanagement nicht möglich. Bei Zielverfehlung geht man zurück in die Phase der Zielsetzung und beginnt die Phasen von Neuem.

Vorteile vom agilen Projektmanagement

Agile Methoden sind im Vergleich zum klassischen Projektmanagement eher jung. Sie befriedigen aber das Bedürfnis, das durch die Digitalisierung und die damit veränderten Anforderungen entsteht.

Was sind diese Bedürfnisse? Ein Prozess und Ziele, die eine stetige Weiterentwicklung zulassen und die Möglichkeit, in den Prozess einzugreifen, um Änderung schnell herbeizuführen.

Im klassischen Projektmanagement scheitern viele Projekte daran, dass sie ihr Ziele nach mehreren Jahren nicht erreichen konnten. Die Ursachen dafür sind vielfältig. So können die Bedingungen zum Zeitpunkt der Zielsetzung anders gewesen, neue Anforderungen könnten erst im Laufe des Projektes dazugekommen sein. Smarte Ziele sind darauf nicht vorbereitet, während agile Methoden durchaus darauf reagieren können.

Wie schafft das agile Projektmanagement den Spagat zwischen Zielen und neuen Anforderungen? Zum einen hat es mit einer anderen Art der Zielsetzung zu tun. So setzt sich das Team kein spezifisches Ziel, welches sie beispielsweise in zwei Jahren erreichen wollen. Es betrachtet stattdessen kleinere Zeitperioden. Meistens gibt es zudem eine Rückkopplungsschleife, in welcher das Team den Ist-Zustand prüft und bei neuen Anforderungen die Zielsetzung anpasst.

Agiles Projektmanagement hebt sich also vom klassischen Projektmanagement durch seine Dynamik ab. Dabei gibt es verschiedene agile Methoden, die dem Team unterschiedlich viel Spielraum lassen.

Methoden im agilen Projektmanagement

Im agilen Projektmanagement bezeichnet man agile Methoden auch als Frameworks. Dieser Begriff ist durchaus treffend, denn sie geben Rahmenbedingungen und Leitlinien vor, die einen Rahmen für das Projektmanagement bilden.

Zu den beliebtesten Frameworks gehören Scrum und Kanban, die sich durch folgende Merkmale auszeichnen:

Scrum:

  • gibt eine klare Struktur mit festgelegten Terminen, Teamgröße, Rollen und Instrumenten vor
  • Grundgedanke: ein Produkt ist niemals fertig, als Ergebnis produziert das Team Inkremente
  • das Team arbeitet in Sprints, die nicht länger als vier Wochen dauern
  • das Team setzt sich Sprintziele, neue Anforderungen können nach Sprintende hinzugefügt werden

Kanban:

  • eine Methode zur Visualisierung von Aufgaben (offen, in Arbeit, erledigt) auf einem Board
  • das Team kann jederzeit neue Anforderungen hinzufügen
  • Rollen, Termine und Dauer sind nicht festgelegt
  • Hauptelement: Work-in-progress Limit, welcher festlegt, wie viele Aufgaben gleichzeitig in Bearbeitung sein dürfen

Fazit

Sowohl das klassische Projektmanagement mit seinen smarten Zielen, als auch das dynamische agile Projektmanagement haben natürlich ihre Daseinsberechtigung. Beide haben jedoch unterschiedliche Ansprüche und Ziele. Die verschiedenen agilen Methoden bieten aber zahlreiche Alternativen zum klassischen, smarten Vorgehen.

Projektcontrolling Kennzahl: Contract Controllable Income (CCI)

Jedes Projekt hat zum Zeitpunkt seines Vertragsschlusses einen erwarteten Gewinn, der im Rahmen der Budgetierung aus geschätzten Einnahmen und Ausgaben ermittelt wird. Ändern sich diese Größen zum Beispiel durch Hinzufügen weiterer Ressourcen, verändern sich auch die Projektmargen. Eine nützliche Kennzahl zur Analyse dieser Problematik ist der sogenannte CCI oder Contract Controllable Income. Er gilt als bestes Maß für die Kontrolle des Projektbudgets und damit für die Performance eines Projekts.

Wie wird der CCI berechnet?

Im Grunde ist der CCI nur eine schicke Umschreibung für Gewinnspannen – er gibt die geschätzte Rentabilität Ihres Projekts an. Dazu verwendet er die erzielten Einnahmen (Abrechnung Ihrer Zeit und Ihres Aufwands) und stellt sie den kontrollierbaren Kosten für die Erbringung der Dienstleistung gegenüber:

Kontrollierbarer Gewinn (CCI) = Einnahmen – kontrollierbare Kosten

Ausschlaggebend ist dabei die Unterscheidung zwischen kontrollierbaren und unkontrollierbaren Kosten. Da der CCI auf Vertrags- bzw. Projektebene ermittelt wird, dürfen Sie nur solche Kosten berücksichtigen, die im Zusammenhang mit dem Projekt stehen und Ihrer Kontrolle unterliegen. Dazu zählen zum Beispiel Projektverzögerungen, die dem Kunden nicht in Rechnung gestellt werden, oder die Zuhilfenahme externer Dienstleister. Charakteristisch für diese Kosten ist, dass sie relativ kurzfristig auf der Grundlage geschäftlicher Entscheidungen verändert werden können.

Unkontrollierbare Kosten hingegen sind in der Regel Ausgaben auf Unternehmensebene, wie beispielsweise Abschreibungen, Mieten oder bestimmte Investitionen, auf die das Projektmanagement keinen direkten Einfluss hat. Diese Gemeinkosten sind deshalb auch nicht Bestandteil des CCI.

Inwiefern hilft der CCI beim Projektcontrolling?

Budgetüberschreitungen sind der klassische Erfolgskiller eines Projekts. Selbst bei guter Budgetplanung ergeben sich immer wieder Stolperfallen und unvorhergesehene Schwierigkeiten, die die Kosten in Windeseile aus dem Ruder laufen lassen. Was soll der CCI in diesem Fall ausrichten?

Die Kenntnis über den kontrollierbaren Gewinn Ihres Projekts kann Kostenschwankungen nicht verhindern, doch können Sie schneller und gezielter darauf reagieren. Betrachten Sie den CCI dabei als Zielprozentsatz oder Zielmarge, die in jedem Fall eingehalten werden muss. Ein Beispiel: Sie haben ein Projekt mit einem festgelegten CCI von 45-55 %. Bei einem Umsatz von 100k dürfen die Kosten maximal 55k betragen, um das Projekt rentabel abzuschließen. Im Verlauf des Projekts müssen Sie einige zusätzliche Ausgaben tätigen, die den CCI auf nurmehr 40 % reduzieren. Um die Projektleistung zu steigern, können Sie nun entweder die Einnahmen erhöhen oder versuchen, andere Ausgaben zu verringern – oder beides.

Im Projektcontrolling erfüllt der CCI verschiedene Aufgaben:

  • Er liefert konkrete Zahlen zum geschätzten Gewinn des Projekts.
  • Er vereinfacht die Kontrolle der Projekteinnahmen und -ausgaben.
  • Er gibt Auskunft über die Rentabilität bzw. Performance eines Projekts.
  • Er dient als hilfreiche Orientierung bei Projektanpassungen.

Die Komplexität der Projekte spielt hierfür keine Rolle. Ganz im Gegenteil kann der CCI gerade bei umfangreichen Projekten besonders nützlich sein: Erstens, da er deren Leistung auf eine auswertbare Zahl herunterbricht, und zweitens, da er (wie sein Name impliziert) auf Vertragsebene zum Einsatz kommt, wodurch er auch für Teilverträge bzw. Teilprojekte genutzt werden kann. Denken Sie aber auch in diesem Fall daran, dass immer nur diejenigen Kosten einkalkuliert werden dürfen, die innerhalb der jeweiligen Projektphase kontrollierbar und somit änderbar sind.  

Zusammenfassung

Der Contract Controllable Income oder kurz CCI ist ein wichtiger Indikator für die Rentabilität eines Projekts. Er berechnet sich aus der Subtraktion der Projekteinnahmen und Projektausgaben, wobei letztere kontrollierbar sein müssen. Der CCI wird immer auf Vertragsebene ermittelt und bezieht sich daher auf ein bestimmtes Projekt oder eine bestimmte Projektphase. Für das Projektcontrolling ist er deshalb so wertvoll, weil er die Kontrolle des Budgets vereinfacht, effektiv vor Kostenüberschreitungen schützt und die Marge des Projekts sichert. Keine andere Zahl zeigt so schonungslos auf, wie es um den Ertrag und den Erfolg Ihrer Projekte steht – nutzen Sie das auch!

Was ist Magic Estimation?

Die Backlogs von Projekten sind oft voll und unübersichtlich. Um eine Struktur hineinzubringen, nehmen sich Scrum Teams Zeit, um die Items gemeinsam zu schätzen. Planning Poker ist eine beliebte Methode dafür, eine weitere Möglichkeit stellt aber auch Magic Estimation dar. Was daran so magisch ist und wie das Ganze funktioniert, erfahren Sie hier.

Wo liegt die Magie?

Warum sollten Sie Magic Estimation verwenden, wenn Planning Poker doch genauso zum Ziel führt und in den meisten Teams bereits im Einsatz ist? Die Magie des Schätzverfahrens liegt in der Zeiteinsparung!

Beim Planning Poker gibt es im Vorfeld viel zu klären. Erst wenn keine Fragen mehr offen sind, beginnt die verdeckte Schätzung. Dabei ist jedes Teammitglied an jeder einzelnen Schätzung beteiligt. Das hat zwar den Vorteil, dass jeder seine Stimme abgibt, es nimmt jedoch auch viel Zeit in Anspruch.

Nach jedem Durchgang kommt es zusätzlich zu einer Diskussion zwischen der höchsten und der niedrigsten Schätzung. Zielführend? Bestimmt. Aber wir wissen alle, dass Zeit in Projekten eine Mangelware darstellt.

Wie funktioniert es?

Magic Estimation soll den Zeitaufwand beim Schätzen reduzieren. Es ist wie Planning Poker ein relatives Schätzverfahren, das Team setzt die Items also in Verhältnis zu einer Referenzstory.

Was muss vorbereitet werden?

  • Die Fibonacci-Reihe sollte auf dem Tisch, an der Wand oder am Whiteboard angebracht sein – je nachdem, wo das Team arbeitet
  • Die Storys müssen auf einzelnen Kärtchen vorliegen
  • Im Vorfeld wird eine Story beispielsweise per Planning Poker geschätzt, welche dann als Referenz gilt
  • Die Items aus dem Backlog müssen klar verständlich sein

Nun kommen wir zum Ablauf. Zu Beginn eines Durchlaufes liegt die Referenzstory bereits an dem geschätzten Fibonacci-Wert. Jeder Teilnehmer erhält zufällig einige ausgedruckte Storys.

Wichtig: Beim Schätzen der Storys wird nicht gesprochen!

Schritt 1: Jeder Teilnehmer platziert seine Storys innerhalb der Fibonacci-Reihe. Er orientiert sich dabei an der Referenzstory und darf die Karten nur direkt, nicht zwischen den Werten platzieren.

Schritt 2: Die Teilnehmer erhalten jetzt einige Minuten Zeit, um zu schauen, wie die Teammitglieder andere Storys geschätzt haben. Stimmt man deren Ansicht zu, verändert man nichts. Ist der Teilnehmer jedoch der Ansicht, dass eine Story zu hoch oder zu niedrig geschätzt ist, kann er diese verschieben. Er braucht die Verschiebung nicht begründen, muss die Karte aber mit einem Punkt oder einem Strich versehen. Damit können auch andere erkennen, dass diese Karte schon mal verschoben wurde. Diese Phase endet, wenn es keine Bewegung mehr auf dem Board gibt.

Schritt 3: Eine Karte kann mehrfach die Position wechseln. Sind auf einer Karte jedoch 3 Punkte vorhanden, scheint es noch Gesprächsbedarf zu geben. Dies ist in Form einer Diskussion möglich. Alle Karten mit drei Markierungen werden für diese Diskussion herausgezogen. Ab jetzt dürfen die Teilnehmer natürlich wieder sprechen. Ziel der Diskussion ist es, die Story zufriedenstellend im Board zu platzieren.

Herausforderungen und Vorteile von Magic Estimation

Damit Magic Estimation funktioniert, müssen die Items aus dem Backlog klar definiert und für alle verständlich sein. Ist dies nicht der Fall, ist der Diskussionsbedarf sehr hoch.

Ist dies jedoch gegeben, liegt der größte Vorteil klar auf der Hand: Anstatt dass alle Items nacheinander von jedem Einzelnen geschätzt werden müssen, schätzen die Teammitglieder die Storys im Magic Estimation parallel. Anschließend überprüfen sie diese. Es kommt nur zu einem Gespräch, wenn abweichende Meinungen vorliegen. Ist ein Team in diesem Verfahren bereits eingespielt, ist die Zeitersparnis enorm. Aus der Praxis berichten einige Teams, dass sie anstelle von ein bis drei Stunden nur noch maximal eine halbe Stunde für einen Schätzvorgang benötigen.

Ein weiterer Vorteil: Es lässt sich schnell erkennen, welche Storys zu groß sind und weiter zerlegt und ausdefiniert werden müssen.

Buzzwords: Was ist Zero Trust?

Im Zuge der digitalen Transformation ist es wichtiger denn je, wie zuverlässig Unternehmen und Dienste vor Cyberangriffen und Datenklau geschützt sind. Klassische, perimeterbasierte Sicherheitskonzepte zum Schutz von Unternehmensnetzwerken stoßen zunehmend an ihre Grenzen, weil sie davon ausgehen, dass interne Zugriffe keine Gefahr darstellen. Doch wem kann man noch vertrauen? Das Zero Trust-Konzept beantwortet diese Kernfrage schon im Wortlaut: niemandem.

„Vertraue niemandem, verifiziere jeden“

Bei Zero Trust handelt es sich um ein IT-Sicherheitsmodell, das grundsätzlich keinem Gerät und keinem Nutzer traut – weder innerhalb noch außerhalb des Netzwerks. Nach der Maxime „Never trust, always verify“ (zu Deutsch: „Vertraue niemandem, verifiziere jeden“) fordert es für jeden Zugriff und jeden Datenfluss eine Authentifizierung. Das heißt: Jede einzelne Anfrage muss neu verifiziert werden, bevor man Zugang zum System erhält.

Zum Vergleich: Bei traditionellen Sicherheitsarchitekturen genügt eine einmalige Verifizierung, um als vertrauenswürdig eingestuft zu werden. Das mag zwar eine komfortable Lösung sein, setzt aber voraus, dass Angreifer immer nur von außen und niemals von innen auftreten können – eine naive Annahme, die im heutigen digitalen Ökosystem keinen Bestand mehr hat. Zero Trust schiebt dem Ganzen einen Riegel vor und rückt den Schutz der Daten in den Mittelpunkt.

Die wichtigsten Grundsätze von Zero Trust

Wie jedes Konzept beruht auch Zero Trust auf einer Kombination verschiedener Prinzipien und Technologien zur umfassenden Abwehr von Cyberangriffen in digitalen Geschäftsumgebungen. Die wichtigsten davon sind:

  • Least Privilege: Das Least Privilege-Prinzip verlangt so wenige Zugriffsberechtigungen wie möglich. Menschliche als auch nicht menschliche Benutzer erhalten demnach nur so viele Privilegien und Informationen wie unbedingt nötig (Just-in-Time / Just-Enough-Access).
  • Datenzentrierung: Die Basis einer lückenlosen Sicherheit und Compliance bildet bei Zero Trust der Schutz der Daten und nicht des Perimeters. Daher liegt der Fokus des Ansatzes vorrangig auf der Sicherung, Verschlüsselung und Verwaltung der Daten sowie der Entwicklung von Datenklassifikationsschemata.
  • Zugriffskontrollen: Durch laufende Identitäts- und Datenprüfungen wird protokolliert, wer wann auf welche Ressourcen Zugriff hat, um interne und externe Bedrohungen rechtzeitig zu erkennen. Privilegierte Accounts gelten als besonders beliebtes Angriffsziel und müssen deshalb verstärkt geschützt und überwacht werden. Je mehr Datenpunkte (Identität, Standort, Datenklassifizierung, Workload etc.) in die Autorisierung einfließen, desto besser.
  • Mikrosegmentierung: Bei dieser Methode werden Sicherheitsperimeter in kleinere, voneinander getrennte Zonen aufgeteilt, die jeweils eigene Zugriffsautorisierungen erfordern. So soll sichergestellt werden, dass ein Benutzer oder ein Programm mit Zugriff auf eine der Zonen nicht automatisch auch auf alle anderen zugreifen kann. Sollte in einem der Segmente ein Angreifer entdeckt werden, lässt sich das kompromittierte Gerät sehr viel leichter unter Quarantäne stellen und vom Rest des Netzwerks trennen.
  • Multifaktor-Authentifizierung (MFA): Für den Zugriff auf geschäftskritische Ressourcen ist ein Passwort allein nicht ausreichend. Viele Online-Dienste und Plattformen nutzen daher eine MFA wie beispielsweise die 2-Faktor-Autorisierung (2FA), bei der Benutzer mehr als einen Identitätsnachweis angeben müssen. Nach der Eingabe des Passworts wird dazu ein Code an ein anderes Gerät versendet, der für die Zugriffsfreigabe erforderlich ist.

Fazit: Zero Trust als Paradigmenwechsel in der IT-Security

Das Zero Trust-Modell ersetzt zum Großteil den traditionellen IT-Sicherheitsansatz, nach dem sämtliche Zugriffe innerhalb des Netzwerkperimeters legitim sind und nicht als Bedrohung für das Unternehmen gesehen werden. Gemäß seiner Maxime „Vertraue niemandem“ muss bei Zero Trust jeder Zugriff verifiziert und überwacht werden. Die Implementierung dieses Konzepts kann auf ganz unterschiedlichen Wegen erfolgen, da es nicht „die eine“ Zero Trust-Strategie gibt. Wirksame Technologien sind zum Beispiel Mikrosegmentierung, Multifaktor-Authentifizierung (MFA) oder Identity and Access Management (IAM), um einen kontrollierten Zugriff von Benutzern und Identitäten zu gewährleisten. Klar ist, dass Zero Trust weiter an Bedeutung gewinnen wird, da die zunehmende Komplexität unserer IT-Landschaft ein grundlegendes Sicherheitsumdenken erfordert. Nicht das Netzwerk als solches, sondern seine Daten und Ressourcen müssen ins Zentrum gerückt und geschützt werden.

Was ist Scrum of Scrums?

Projekte werden zunehmend komplexer und immer mehr Personen sind in ein Projekt eingebunden. Das agile Framework Scrum definiert jedoch eine eindeutige Teamgröße, die nicht überschritten werden soll. Stößt Scrum bei Großprojekten also an seine Grenze? Ganz bestimmt nicht. Die Lösung liegt im Scrum of Scrums.

Worum handelt es sich?

Laut Scrum liegt die optimale Teamgröße bei nicht mehr als 9 Personen. Untersuchungen haben gezeigt, dass 4,6 Personen perfekt wären. Abgesehen davon, dass dieser Wert in der Praxis schwierig umzusetzen wäre, zeigt die Erfahrung, dass Teams eher größer statt kleiner sind.

Große Organisationen und Projekte können dann das Scrum of Scrums, auch SoS genannt, nutzen. Dieses Format dient der Vernetzung und der Kommunikation mehrerer Scrum Teams, die gemeinsam an einem großen Ziel oder Projekt arbeiten.

Kurz gesagt: SoS ist eine agile Methode zur Zusammenarbeit mehrerer Scrum Teams. Ziel ist die Vernetzung zwischen den Teams, die Kommunikation und Förderung der Zusammenarbeit. Abhängigkeiten können hier schnell sichtbar gemacht werden um Lösungen gemeinsam zu entwickeln.

Wie funktioniert es?

Das SoS ist vergleichbar mit dem Daily Scrum eines Scrum Teams, mit dem Unterschied, dass dieses nicht standardisiert ist. Die Frequenz, Dauer und die Teilnehmer des Meetings können die Teams selber bestimmen. Jedes Scrum Team entsendet einen Botschafter in dieses Meeting, welcher aber auch wechseln kann.

Im Daily Scrum beantworten die Teammitglieder die drei klassischen Fragen, die sich auf das Sprintziel beziehen:

  • Was habe ich seit gestern getan?
  • Was erledige ich bis morgen?
  • Was behindert meine Arbeit?

Im Scrum of Scrums sind die Fragen auf das Team bezogen, die Fragen werden also leicht umformuliert und ergänzt:

  • Was hat mein Team seit dem letzten Meeting geschafft?
  • Was wird mein Team bis zum nächsten Meeting erledigen?
  • Welche Hindernisse behindern mein Team?
  • Hat eine Tätigkeit meines Teams Auswirkung auf eines der anderen?

Ist SoS nun die Lösung für alle Großprojekte? Nicht ganz, denn auch diese Methode ist auf eine Größe beschränkt. Es sollten nicht mehr als 9 Scrum Teams zum Scrum of Scrum zusammenkommen. Was ist aber, wenn es mehr Teams gibt? Bei großen Unternehmen arbeiten auch schon mal mehr als 20 Scrum Teams an einem Projekt.

Scrum bietet auch hierfür eine Lösung – bitte festhalten: Das Scrum of Scrum of Scrums. So einfach wie es sich anhört, ist es doch kein Wunder, dass sich dieser Begriff nicht durchgesetzt hat. Es ist dennoch eine sinnvolle Methode, die Teams auf einer höheren Ebene miteinander zu vernetzen.

Herausforderungen und Vorteile von Scrum of Scrums

SoS erfordert neue Rollen wie einen Chief Product Owner und einen Scrum of Scrums Master. Natürlich sollte nicht verschwiegen werden, dass die Scrum Teams zunächst mit neuen Herausforderungen rechnen müssen:

Der Scrum Master muss stärker auf die Abhängigkeiten zu den anderen Teams achten, da sich diese auch auf das Sprint Planning auswirken. Die Kommunikation in solch großen Strukturen ist aufwendig aber umso wichtiger. Die Arbeitslast kann beim Scrum Master und auch beim Product Owner steigen.

Dem Aufwand stehen aber große Vorteile gegenüber:

Die Teams vernetzen sich stärker miteinander und können Abhängigkeiten reduzieren. Gleichzeitig ist der Projektfortschritt für alle Beteiligten sichtbar und die eigene Rolle transparent. Damit reduzieren sich Risiken, denn die Teams achten stärker darauf, mit ihrer Arbeit nicht die anderen Teams zu behindern oder sich einfach kopflos in die Entwicklung zu stürzen. Die Vorgänge sind gut aufeinander abgestimmt und sollten Probleme auftreten, werden sie gemeinsam gelöst.

Tipps für das Scrum of Scrums

Damit die Implementierung gelingt und nicht für Frust sorgt, hier ein paar Tipps und Fragen, die Sie vorher klären sollten:

  • Welche Frequenz und Dauer ist die Richtige und wer nimmt teil?
  • Halten Sie sich an die 4 Fragen – anders als beim Daily Scrum sollte dieser Rahmen auch genutzt werden um Probleme zu besprechen um Lösungen zu finden
  • Eine Retrospective of Retrospectives kann helfen gemeinsame Prozesse und Arbeitsweisen zu verbessern

Was bedeutet WebAssembly für IT-Projekte?

Eine der jüngsten Entwicklungen in der Weblandschaft ist WebAssembly – ein Binärformat, das unter Web- und App-Entwicklern längst in aller Munde ist. Völlig zu Recht, denn es zeichnet sich ab, dass WebAssembly über kurz oder lang neue Maßstäbe in der Softwareentwicklung setzen wird. Doch was bedeutet das für zukünftige IT-Projekte?

Basics first: Was kann WebAssembly?

WebAssembly (Wasm) ist eine Low Level Assemblersprache, die nativ in Webbrowsern kompiliert werden kann. Im Vergleich zu JavaScript liegt das Format sehr viel näher am Maschinencode und unterscheidet sich in seiner Leistung kaum von nativen Apps. Es läuft in allen großen Browsern – Chrome, Firefox, Safari und Edge – und ist vom W3C als offizieller Web Standard anerkannt. Das Besondere an WebAssembly ist, dass man in der Regel nicht direkt damit programmiert, sondern dass es als Kompilierziel für andere Sprachen fungiert. Da es bereits im Binärformat vorliegt, erfolgt das Parsing deutlich schneller als bei JavaScript.

Konkret heißt das: WebAssembly bietet die Möglichkeit, gängige Hochsprachen (z.B. C, C++, Java, Python) in ein ladezeitoptimiertes Format zu kompilieren, das crossbrowser und crossplatform Einsätze möglich macht. Jede Desktop Anwendung, die sich in WebAssembly kompilieren lässt, können Sie auf diese Weise ohne Leistungseinbußen im Browser ausführen. Damit dient WebAssembly als ideale Ergänzung zu JavaScript, um dessen Overheads auszubügeln und auch komplexe, rechenintensive Anwendungen im Browser auszuführen.

Was bedeutet das für IT-Projekte?

Seit WebAssembly ist JavaScript nicht mehr einzige Option, um Code für den Browser zu schreiben. Und das hat Folgen: Denn statt sich auf die bisherigen Objektprototypen von JavaScript zu beschränken, haben Entwickler zum ersten Mal eine Auswahl. Im Grunde können Sie jede Funktion Ihrer Anwendung in einer beliebigen Sprache programmieren und diese im Anschluss zu Wasm kompilieren. Voraussetzung ist natürlich, dass die gewählte Sprache über einen WebAssembly-Compiler verfügt.

Ein weiterer Vorteil von WebAssembly: Sie können den Wasm Code wiederverwenden und damit eine Brücke zwischen C#-Backend (als Beispiel) und JS-Frontend bilden. Wenn Sie Ihre DLL mit WebAssembly als Ziel kompilieren, sparen Sie sich den Schritt sie in JavaScript zu implementieren – und das spart Entwicklungszeit.

IT-Projekte stehen damit vor ganz neuen Chancen, aber auch Herausforderungen. In Bereichen, in denen die Rechenleistung von JavaScript an ihre Grenzen stößt, kann zukünftig mit Wasm gearbeitet werden – zum Beispiel bei 3D Gaming, Image Editing oder Virtual Reality. Desktop und Mobile Apps, für die bisher keine webbasierte Variante geplant war, können mit Wasm problemlos im Browser kompiliert werden. Und ja, das betrifft auch Java Anwendungen und alle anderen „web-fernen“ Sprachen.

Wird zukünftig nur noch mit WebAssembly programmiert?

WebAssembly wurde mit dem primären Ziel entwickelt, leistungsstärkere Webanwendungen zu ermöglichen. Der Trend hin zu browserbasierten Applikationen wird dadurch natürlich verstärkt, denn der Vorteil ist: Web Apps haben ein breiteres Publikum. Gleichzeitig macht WebAssembly die Programmierung solcher Apps effizienter, schneller und günstiger. Da inzwischen alle großen Browser das Format unterstützen, ist es eigentlich nur eine Frage der Zeit, bis es sich komplett in der Webentwicklung etabliert hat – vor allem in jenen Bereichen, wo Performance eine große, wenn nicht sogar entscheidende Rolle spielt. Wiederum wird es JavaScript nicht ersetzen, allein schon deshalb, weil die Wasm Module mit JavaScript geladen werden. Es ist und bleibt daher eine Ergänzung, die die bisherigen bestehenden Grenzen in der Softwareentwicklung ein großes Stück aufbricht. 

Zusammenfassung

WebAssembly mag in erster Linie für Performancesteigerungen konzipiert worden sein, doch das Format kann weitaus mehr. Entwicklungsteams, die plattformübergreifend oder mit einer Client-Server-Aufteilung arbeiten, profitieren zum Beispiel von kürzeren Lieferzeiten und mehr Flexibilität beim Programmieren selbst. So ist man nicht mehr an die lose Typisierung von JavaScript gebunden, sondern kann jede Hochsprache, die in Wasm kompiliert werden kann, für die gewünschten Funktionen nutzen – von Rust und C bis hin zu Java. Das Web von morgen wird Apps der Desktop-Klasse mit nativer Leistung ausführen, und WebAssembly macht es möglich.

Aus den Fehlern der Anderen lernen: Wege zum Erfolg im IT-Projektmanagement

3 Tipps, um auch große IT-Projekte erfolgreich zu steuern

Schon mal von einem großen IT-Projekt gehört, das in der geplanten Zeit und im Rahmen des vorgesehenen Budgets erfolgreich abgeschlossen wurde? Nein? Kein Wunder. In der IT-Welt haben Großprojekte, die ihr Ziel innerhalb der vorgesehenen Zeit und ohne Überschreitung des Budgets erreichen, Seltenheitswert. Wir zeigen drei typische Fehler, die in großen Softwareprojekten vorkommen und Wege, sie zu vermeiden.

Eine gemeinsame Studie von McKinsey und der Oxford-Universität hat gezeigt: Alle großen IT-Projekte (Startbudget über 15 Millionen USD) erfordern fast 50% mehr Budget als geplant und 7% davon überziehen die vorgesehene Projektzeit, während sie etwa die Hälfte der Ziele verfehlen. Die schwarzen Schafe sind die Softwareprojekte. Nichteinhaltung von Kosten- und Zeitrahmen sind hier fast schon vorprogrammiert.

Problem 1: Mangelndes Interesse des Managements

Zeigt das Management kaum Interesse, ist es kein Wunder, wenn das Projekt nicht fortschreitet. Wenn das Management nichts tut, mit der Behauptung, sich mit der IT nicht auszukennen, die ganzen „IT-Sachen” dem technischen Team überlässt, wird das Techniker-Team selbst die Führung übernehmen und alle Entscheidungen treffen. Dadurch können neue Probleme entstehen. Meistens fehlt dem technischen Team nicht das fachliche Know-How, sondern der klare Blick auf die geschäftlichen Ziele. So kann es dazu kommen, dass die Techniker Entscheidungen treffen, welche unbeabsichtigter Weise mit Geschäftsinteressen kollidieren.

Die Lösung: Durch Präsenz und Commitment sind Sie immer auf dem Laufenden und vermeiden so, dass „die Techniker“ die Projektführung übernehmen und prozessbezogene Belange oder Geschäftsinteressen übersehen. Management-Präsenz und regelmäßige Kommunikation mit dem technischen Team sind die Voraussetzung dafür, dass Prozesse und Geschäftsziele mit der technischen Umsetzung harmonieren. Das gesamte IT-Projekt profitiert von einer Kultur, die auf regelmäßigem Austausch zwischen Management und dem technischen Team beruht. Ein gutes technisches Team wird jederzeit in der Lage sein, klar darzustellen, was es tut. Anderenfalls gehen Sie davon aus, dass das Team gar nicht richtig weiß, was es tut.

Problem 2: Zu starker Fokus auf Kostenreduzierung

Gerade in Krisenzeiten sucht jeder Wege, um kostenreduzierend und effizient zu handeln. Einsparungen sind gut, doch kann der Schuss auch nach hinten losgehen: beispielsweise dann, wenn dafür Projektmitarbeiter eingespart werden oder weniger gut ausgebildetes Projektpersonal eingekauft wird. Projekte mit weniger spezialisierten Ressourcen sind bekannt dafür, den Zeitplan und das Budget nicht einzuhalten sowie für Qualitätsprobleme oder Abstriche bei der Umsetzung der Anforderungen.

Die Lösung: Berechnen Sie das Budget so, dass Sie die Kosten für gut ausgebildete, erfahrene Projektmitarbeiter einplanen. Dann finden Sie die richtigen Leute für die anstehenden Aufgaben viel leichter. „Quick and dirty“ rechnet sich selten. Sollten Sie an Outsourcing ins billigere Ausland denken, berücksichtigen Sie eventuelle Probleme durch Sprachhürden, unterschiedliche Kommunikations- und Arbeitskulturen, Erreichbarkeit, z.B. bedingt durch Zeitverschiebungen. Bedenken Sie auch, dass ein. erfolgreiches Projekt nicht nur Entwickler braucht. Die vernünftige Projektsteuerung und Zielverfolgung ist Aufgabe des Projekt-Managements. Erfolgsentscheidend sind auch die Ergebnisse der Business Analysten und der Tester. Bevor Sie den Rotstift ansetzen, überlege Sie, wie viele, für die anstehenden Aufgaben nicht ausreichend qualifizierte Mitarbeiter, das Projekt, bzw. das Unternehmen sich leisten kann.

Problem 3: Fehlende Zielklarheit

Technikfreaks neigen in ihrer Begeisterung dazu, Dinge sofort anzupacken. Was auch immer dieses Verhalten herbeiführt, es führt immer zu mangelhafter oder gar fehlendende Planung. Ohne den Umfang, die Zeile, und das erwartete Projektergebnis genau zu verstehen, kann der Versuch, auf dieser Basis ein Projekt zu lenken, nur scheitern. Ein erfolgreiches Projekt bedeutet mehr als die Lieferung des endgültigen Softwareprodukts. Es geht auch um das Erreichen des erwünschten Projektergebnisses innerhalb des geplanten Zeitraums und Budgets. Fehlt eine koordinierte Planung, tritt Folgendes auf:

  • Unklarheit über Umfang und Ziel
  • Verwirrung bezüglich Rollen und Verantwortlichkeiten
  • Ineffiziente Ressourcennutzung
  • Nichtverfügbarkeit von Ressourcen zu kritischen Zeiten
  • Ungleichmäßige Arbeitsbelastung des Teams
  • Falsche Zeit- und Kosteneinschätzungen (durch unerwartete Ereignisse)
  • Schwache Leistung u.a. durch Überarbeitung, Frust, verspätete Lieferung, fehlerhafte Ergebnisse etc.

Die Lösung: Es scheint banal: diese Nebenwirkungen fehlender Zielklarheit in einem Großprojekt sind mittels expliziter, klarer Festlegung und durch regelmäßige Zielkommunikation vermeidbar. Durch die engmaschige Verfolgung der Ziele und des Ist- Zustandes in jeder Phase, erkennen Sie frühzeitig Zielabweichungen und Unklarheiten Zielerreichung gesamt und im Detail zu betrachten verstärkt die Klarheit. Auch wenn ausschließlich Spezialisten am Werk sind, kann es bei Unklarheiten über das Ziel des Projekts zu Chaos und Frustration verursachenden Effekten kommen. Stellen Sie sich ein Orchester vor, in dem lauter Virtuosen der jeweiligen Instrumente spielen, aber der Dirigent fehlt. Das will keiner hören!

Fazit

In IT-Projekten ist engmaschige Kommunikation essentiell, um auf der Zielgeraden zu bleiben, wie überall, wo Menschen mit Menschen zusammenkommen und ein Gemeinschaftswerk zum Erfolg bringen wollen. Ohne ein gutes, engagiertes Management mit Leitbildcharakter sowie Absprachen und Zielklarheit in jeder Phase sind Chaos, Frust und Fehler vorprogrammiert. Ebenso, wenn Sie am falschen Ende sparen.