Blog
Projektmanager, was könnt Ihr auf den Weg zur Agilität nehmen? - Teil 3 - Planen
Gelegentlich braucht man eine Aufwandsschätzung für ein strategisches Projekt auch in einer agilen Umgebung. Man hat nicht genügend Information im Voraus aber eine ungefähre Einschätzung wird dringend benötigt. Unter diesen Umständen kannst Du deine Fähigkeiten bezüglich Aufgaben-Planung und deren Zerlegung erfolgreich einsetzen, um diese wichtigen strategischen Projekte zu bewerten. Normalerweise haben solche Projekte mehrere Einschränkungen bezüglich Funktionalität, Lieferungsdatum und möglicherweise laufende Outsourcing-Verträge. Deshalb ist es empfehlenswert, die User Stories in Aufgaben zu zerlegen, die benötigten Zeitdauer dieser Aufgaben in Stunden zu schätzen und nachher zu betrachten wie viele Stunden in eine Iteration hineinpassen und mit wie vielen Story Points diese Stunden quantifiziert werden können. Die Gantt Charts die die Zuordnung der User Stories zu Iterationen auf Team-Ebene darstellen sind auch sinnvoll. Solche Charts stellen die Zeitdauer der User Stories als die gesamte Iteration und so stellt man klar, dass diese User Stories am Ende der Iteration 100% durch fertig werden sollten. Diese Vorgehensweise ist während der Transition zu Agile besondern zu empfehlen. Wenn man große Projekte mit mehreren Teams planen muss ist es nützlich einen Zeitplanpuffer gleichwertig mit zwei Standardabweichungen einzusetzen. Der wird als die Quadratwurzel der Summe aller Quadrate der Differenzen zwischen den 90%-akkurater Wahrscheinlichkeit und den 50%-akkurater Wahrscheinlichkeit der Einschätzungen berechnet. Diese Formel gibt die beste Genauigkeit wenn man mehr als zehn User Stories verfügbar sind. Falls nicht, dann ist es empfehlenswert die Hälfte der Summe der Story Points als Zeitpuffer in Betrachtung zu ziehen (maximal 20% der totalen Projekteinschätzung). Man sollte den Feature-Puffer aber nicht vergessen, eine gute Einschätzung wäre, 30% aller Features als optional zu betrachten. Gemäß der Dynamic Systems Development Method (DSDM), Budget-Puffers sind sinnvoll insbesondere für große Projekte für welche die User Stories drei Iterationen im Voraus spezifiziert werden sollten. Es ist wichtig diese User Stories mit allen Teams einzuschätzen so dass eine allgemeine Baseline für die Einschätzung vorhanden ist. Die Abhängigkeiten zwischen den unterschiedlichen Teams sollten auch nicht vergessen werden und diese sollten mit passenden Zeitplanpuffern beschützt werden. Diese Methoden für die Projektplanung die Du schon gut kennst werden Dir auf den Weg zur Agilität bestimmt behilflich sein. |
Projektmanager, was könnt Ihr auf den Weg zur Agilität nehmen? Teil 2 - Risikomanagement
In Deiner bisherigen Projektmanagement-Erfahrung für jedes Projekt hast Du ein gewisses Risikomanagement entweder auf qualitative oder auf quantitative Ebene ausgeführt. Währenddessen hast Du die wichtigsten Drohungen (negative Risiken) und Gelegenheiten (positive Risiken) identifiziert, die Dir dabei helfen würden Dich und Dein Team gegen das Unerwartete auszurüsten. Während der fokussierten Workshops zur Risikoidentifizierung und deren Auslöser eine qualitative Risikoanalyse wird in der Regel durchgeführt um Risiken zu kategorisieren und falls notwendig, wird in der Regel auch eine detaillierte, quantitative Risikoanalyse durchgeführt. Beide Prozeduren der Risikoanalyse können, mit einem wesentlichen Erfolg, auch in einer agilen Umgebung eingesetzt werden. Wo genau? In der Priorisierung von User Stories. Es gibt einige Faktoren (wie z.B finanzieller Wert, das Gewinn von Wissen über das Produkt und das Projekt, aufgedeckte Risiken) die im Rahmen der User Story-Priorisierung eine wesentliche Rolle spielen - und Risiken können für ein Produkt die Differenz zwischen Erfolg und Niederlage bedeuten. Deswegen ist es wichtig die User Story-Priorisierung in die richtige Richtung zu lenken so dass diese effizient gesteuert sein kann - und dabei wird Dein Wissen bezüglich Risikomanagement Dich auf den richtigen Pfad bringen. |
Projektmanager, was könnt Ihr auf den Weg zur Agilität nehmen? Teil 1 - Ihr Wissen über Projektauswahl-Kriterien
Du bist Projektmanager, mit fundierter Erfahrung in dem Ansatz von klassischen Projektmanagement-Methoden wie PMI und PRINCE2 und bist jetzt auf dem Weg zum agilen Projektmanagement (Scrum, Dynamic Systems Development Method (DSDM)) oder eine andere agile Vorgehensweise. Eine Menge Artikel sagen Dir, was Du ändern müsstest - in Hinsicht der Ansätze und Deiner Denkweise wenn es darauf ankommt, Projekte erfolgreich mit agilen Methoden zu liefern. Aber…es gibt ein Aber…gibt es nicht irgendwas dass Du schon optimal beherrschst und leicht in einem agilen Kontext umsetzen kannst? Und sogar mit garantiertem Erfolg - Ja, das ist möglich. Was sind diese Aspekte? Die werden hier in dieser Serie genauer diskutiert. Erstmals gibt es diese klassischen finanziellen Maßstäbe die bei der Auswahl von Projekten als Teil der Programme oder des Portfolios zum Einsatz kommen: Net Present Value (NPV) Internal Rate of Return (IRR) Discounted Payback Period Diese Voraussagen können sehr gut auf User-Story-Ebene für eine Zeitspanne von einem Jahr bis zu anderthalb Jahren eingesetzt werden. Sie können verwendet werden, um die Priorität einer User Story zu berechnen und gleichzeitig deren Businesswert zu betrachten. In dieser Art und Weise wird es möglich sein, zwei verschiedene User Stories bezüglich ihrer Priorität zu vergleichen und sie innerhalb des Backlogs effizient zu priorisieren. Als zweite Ebene der Priorisierung kann man das Wissen bezüglich Enterprise Environmental Factors zum Einsatz bringen, in dem man die gesamte Risikotoleranz des Unternehmens betrachtet um User Stories auch in dieser Risiko-bezogenen Hinsicht zu priorisieren. Es gibt mehr Wissen über das Du schon verfügst und Du kannst es schnell einsetzen und über diese Aspekte wird in dieser Serie weiter diskutiert... |
Der Top-Trend in der IT Heute
Ich habe mich schon gefragt, wie man die Haupteigenschaft der IT und der digitalen Bewegung der letzten Jahre mit einem einzigen Wort beschreiben könne und die Schlussfolgerung war: der "MICRO" Trend. Nicht nur ist dieser Trend einheitlich durch verschiedene Geschäfts- und IT-Anliegen verbreitet , sondern kann es als gesamter antreibender Einfluss in dem online digitalen Geschäft heutzutage betrachtet werden. Erstens denk über die IT und Software-Architektur nach. Die muss hoch-skalierbar, performant und auf verschiedene Geräte verfügbar sein. Das Hauptkonzept um dieses Ziel zu erreichen ist durch die Verwendung der "MICRO"-Services. Die Architektur wird nach dem "Single Responsibility Design" Prinzip entworfen und dieses Prinzip wird verwendet, um die IT und die Business-Strategy auf einer solchen Grundlage zu etablieren. Das findet heute statt und dieser Trend wird sich in den nächsten Jahren weiterentwickeln. Wenn man die Business-Seite betrachtet, sieht man, dass viele Unternehmen entweder die Agilität konsolidieren oder eine Transformation in Richtung Agilität durchführen. Ein wichtiges Mittel für diesen Zweck sind Projektmanagement und Änderungsmanagement-Prozesse oder das Prinzip der kontinuierlichen Verbesserung der Abläufe. Und wie nennt man so etwas? "MICRO"-Erfolge die am besten anerkannt, gefeiert und als solide Basis für weitere Entwicklungen verwendet werden. Diese Idee wird sowohl in dem siebten Schritt des John Kotter's Change Model (Build on the Change) als auch in der kontinuierlichen Verbesserung durch Retrospektiven (Scrum), formuliert. Der "MICRO"-Trend überbrückt unterschiedliche Disziplinen und Konzepte in einer neuen Art und Weise und vereinigt die Business und IT-Seiten und durch dieses Vorgehen etabliert sich eine Release-Roadmap mit klaren und effektiven Iterationen, effizienten Software-Designs und skalierbaren Deployments die von dem "MICRO"-Trend geleitet werden. Die Iterationen bauen auf einander und durch diesen Ablauf wird Veränderung in einem Unternehmen effizient eingeflößt. |
Change Management Methodologie - Ist Ihr Änderungsmanagement-Prozess komplett?
Es gibt einige Änderungsmanagement-Elemente die üblicherweise betrachtet werden bevor man ein Änderungsmanagement-Bestreben durchführt wie z.B.: die Unternehmenstrucktur, die Unternehmenskultur, die unternehmensübergreifende Steuerung und jegliche automatschen Change-Tools mit deren Vorlagen, Abläufen und Prozeduren die den Zweck haben, den Veränderungsprozess zu unterstützen und die benötigten Ressourcen, das Wissen und die Kompetenz die in einem gewissen Gebiet erforderlich sind um die Änderungsvision zu gestalten und umzusetzen. Die Essenz aller Aufgaben liegt aber in der Änderungsmethodologie die die ganze Umsetzung steuert. Außer im Hause entwickelten Änderungsmanagement-Prozessen die wahrscheinlich in einem Project Management Office (PMO) Kontext entwickelt worden waren, gibt es erfolgreiche, weltweit-erkannte Modelle für Änderungsmanagement und die sind:
Das erste Modell bezieht sich auf die Unternehmensebene während das zweite Einsichten und Empfehlungen bezüglich der wichtigsten Aspekte der Änderung auf persönliche Ebene zurückliefert. Um die Anpassung zu beschläunigen ist es empfehlenswert eine End-to-End Perspektive zum Änderungsmodell einzusetzen, um effizient von einer Seite des Änderungsspektrums zur anderen durch eine Kombination der beiden Modelle agieren zu können. Diese Art und Weise die Änderung zu betrachten ermöglicht uns eine Checkliste auf alle Ebenen des Änderungsmanagementprozesses umzusetzen um zu gewährleisten dass alle wichtigen Elemente beachtet worden waren. Wir können die grafische Darstellung (siehe Anhang) als Richlinie verwenden. |
| Anhänge:
changeModels.png
Kontinuierlicher Verbesserungsprozess & Prozess-Verbesserungsplan
Um einen einheitlichen Rahmen für einen Prozess-Verbesserungsplan zu bilden ist es wichtig einen Kontext für einen kontinuierlichen Verbesserungsprozess auf Unternehmensebene als Anfangspunkt zu betrachten. Zu diesem Zweck ist es sinnvoll eine Bewertung des Engagements zu kritischen Erfolgsfaktoren durchzuführen. Der wichtigste Teil davon ist eine Menge von Fragen die sich auf das Thema der kontinuierlichen Verbesserung ausrichtet - z.B.:
Nachdem kontinuierliche Verbesserung auf Unternehmensebene bewertet wird, kann man den nächsten Schritt angehen und Prozess-Verbesserungspläne für die darunter liegende Entitäten definieren. Eine mögliche konzise Struktur für eine solche Prozess-Verbesserungsplan Vorlage wäre:
Kontinuierliche Analyse, Überwachung und Bewertung eines solchen Prozess-Verbesserungsplan wird während des gesamten Lebenszyklus eines Projekts, Programms oder Portfolio erforderlich um die Verbesserungsstrategie optimal umzusetzen. |
Abschreibung
In dem letzten Artikel haben wir gesehen dass Abschreibung eine Dimension des operativen Cash Flows ist die aus operativer Sicht und nicht aus finanzieller Sicht betrachtet werden muss. Jetzt die Frage die sich stellt ist wie man die Abschreibung berechnen kann. Die Methode der Berechnung variiert mit der Art von Asset aber der allgemeine Aspekt für jedes Asset ist dass es während der Zeit Wert verliert. Wie viel von diesem aktuellen verlorenen Wert von einem Asset kann jedes Jahr als Teil des operativen Cash Flows betrachtet werden? Wir werden drei allgemein verwendete Methoden für die Berechnung der Abschreibung in Erwägung ziehen:
Der gleiche Prozentsatz wird jedes Jahr abgeschrieben und der Wert des Prozentes basiert auf der gesamten Lebenserwartung des Produkts. Am Ende wird der Buchwert null wenn die Abschreibung komplett ist. 2.Die doppelt geometrisch-degressive Abschreibung Die geradlinige Abschreibung wird verdoppelt und dieser doppelte Wert wird jährlich von dem verbliebenen Asset-Wert abgezogen. Das bedeutet, dass in den ersten Jahren das Asset eine Menge an seinem Wert verliert und nachher, in den darauffolgenden Jahren wird der Wertverlust weniger. 3.Digitale Abschreibung Die abschreibbaren Kosten werden als Bruch der gesamten Lebenserwartung des Assets berechnet. Die Methode verursacht eine beschleunigte Abschreibung im Vergleich mit der geradlinigen Methode aber eine langsamere Abschiebung im Vergleich mit der doppelt geometrisch-degressiven Methode. In diesem Fall wenn die Lebenserwartung eines Assets 3 Jahre beträgt, die Summe der Jahre ist 6 und die Abschreibung für die einzelnen Jahre wird wie folgt aussehen: 3/6 für das erste Jahr, 2/6 für das zweite Jahr und 1/6 für das dritte Jahr. Dieser Wert wird jährlich von dem verbliebenen Asset-Wert abgezogen. Wir können folgende Schlussfolgerung ziehen: das erste Abschreibungsmodell wird zu einem relativ gleichmäßigen operativen Cash Flow während der Jahre führen aber die doppelt geometrisch-degressive Abschreibung wird Wertschwankungen von einem Jahr zum anderen einführen. Die Abschreibung spielt eine wichtige Rolle bei der Berechnung des operativen Cash Flows und sollte nicht missachtet werden. |
Cash-Flow aus der operativen Geschäftstätigkeit
Im Rahmen der Projekte spielt der Cash-Flow aus der operativen Geschäftstätigkeit eine bedeutende Rolle wenn es um das Budgeting und um die Kostenüberwachung und Kontrolle während des gesamten Lebenszyklus eines Projektes geht. Die Verfügbarkeit eines ausreichenden Cash-Flows versichert die Fähigkeit dass lang-laufende Projekte fortfahren können. Die Basis für die Berechnung des Cash-Flows ist die Gewinn- und Verlustrechnung die die Umsätze und die Ausgaben die während einer gewissen Zeitspanne, üblicherweise jährlich oder vierteljährlich stattgefunden haben, auflistet. Das Nettoeinkommen ist eine wichtige Komponente die uns hilft, den Cash-Flow zu berechnen. Es stellt die Differenz zwischen dem eingetragenen Umsatz und die Kosten die in einer gewissen Zeitspanne entstanden sind und kann anhand des folgenden Ausgleichs zusammengefasst werden: Nettoeinkommen = Umsatz - Kosten Die Erfolgsrechnung beinhaltet alle Informationen die notwendig sind, um den gesamten Wert der Umsätze und Ausgaben in Erfahrung zu bringen. Der Umsatz ist die Summe aller Einkommen-Kategorien. Die Ausgaben sind in verschiedene Gruppen unterteilt: Umsatzaufwendungen (Verkaufskosten), allgemeine, administrative Kosten, andere Kosten-Kategorien, Abschreibung, Zinsaufwand und Einkommensteuer. Cash-Flow aus der operativen Geschäftstätigkeit = Nettoeinkommen + Abschreibung + Zinsaufwand Wie in der oben genannten Formel zu sehen ist, wird der Zinsaufwand als Teil der finanzierenden Entscheidungen eines Unternehmens betrachtet und nicht als Teil der operativen Entscheidungen die mit einer Firma verbunden sind. Weil der Cash-Flow aus der operativen Geschäftstätigkeit die Geldmittel die durch die normale, operative Tätigkeit eines Unternehmens entstanden sind darstellt, wird die Abschreibung außerhalb des Cash-Flows betrachtet. Während der Zinsaufwand relativ klar zu quantifizieren ist, gibt es verschiedene Mittel die Abschreibung zu berechnen und darüber werden wir mehr in den folgenden Artikel betrachten... |
Agile Ursprünge Teil 3 - Theory of Constraints & Lösung der Hindernisse
Die fünf Schritte der Theory of Constraints wurden von der Softwarewelt durch die agilen Methoden die die iterative und kontinuierliche Beseitigung der Hindernisse fördert, angenommen. Lasst uns ein Beispiel betrachten: SCHRITT 1: Identifiziere die Einschränkungen des Systems. Als Beispiel, nehmen wir an, dass das Problem das zu lösen ist, ist die Feststellung dass Bugs zu spät in dem Softwareentwickungsprozess entdeckt werden und manchmal sogar von dem Kunden. Die Einschränkung hier ist der Testen-Ablauf die als Inventar angesehen wird (die Arbeitsmenge die die noch nicht getestete Software darstellt) und die Betriebskosten (die Mitarbeiter die das Testen von Software ausführen). SCHRITT 2: Entscheide die Art und Weise in der diese Einschränkung auszunutzen ist. Das Testen muss kontinuierlich, früh und oft ausgeführt werden um potentielle Bugs schnell zu entdecken, zu einem Zeitpunkt in dem deren Behebungskosten noch billig sind. Das Team wird in diesem Fall Aufwand investieren, um das Testen zu automatisieren und um die Testen-Ansätze durch die verschiedenen Rollen eines Teams zu verbreiten so das diese Testen-Methoden unabhängig von der Anwesenheit aller Teammitglieder ausgeführt werden können. Das beinhaltet die Automatisierungssysteme und deren Integration in dem Buildprozess. SCHRITT 3: Unterordne Alles dieser Entscheidung. Der Testen-Ablauf stellt in diesem Fall eine Eingangsaktivität für die Entscheidung bezüglich der Fortsetzung jeden Schrittes der Softwarelieferung dar. Das ganze Team weiß von dieser Entscheidung Bescheid und ist imstande ihre Arbeitsweise zu organisieren so dass diese Regel überall, auf alle Ebenen erfüllt wird (z.B. durch Techniken wie Test First Programmierung und Fail Fast Builds im Falle von gescheiterter Testausführung). SCHRITT 4: Erhebe die Einschränkungen des Systems. Verwende alle verfügbaren Rechner um Tests automatisch und nebenläufig ausführen zu lassen. SCHRITT 5: Falls während des letzten Schrittes eine Einschränkung gebrochen wurde, kehre zum ersten Schritt zurück. Während der Durchführung der o.g. Schritte kann es sein, dass eine andere Aktivität sich als Flaschenhals erweist z.B. die Programmierung der Test Cases die die parallele Ausführung der Tests erlauben. In diesem Fall diese Aktivität - die Programmierung würde die nächste Einschränkung die von uns Aufmerksamkeit erfordert darstellen. Es ist erstaunlich dass diese fünf Schritte in so vielen verschiedenen Branchen und Unternehmen mit erfolgreichen Ergebnissen verwendet werden können und das für eine längere Zeitspanne die mehrere Jahrzehnte beträgt. Diese Tatsache beweist die außergewöhnliche Kraft der Vision für kontinuierliche Verbesserungen die Goldratt im Rahmen des "The Goal" Businessromans erfasst hat. |
Agile Ursprünge Teil 2 - Erhöhe den Durchsatz und reduziere die Inventar-verbundene und die operativen Kosten
Durch Durchsatz verstehen wir die Summe der Gelder die durch das Verkaufen von Produkten und Diensten gewonnen wird. Das heißt, dass nur die aktiven Teile - die die Geld produzieren, stehen im Fokus. Agile Iterationen und Sprints sind auf der Priorisierung der Arbeit auf Basis von Businesswert der die Nachfrage widerspiegelt, basiert und das bedeutet, dass die Arbeit auf Zwecke der Monetarisierung die zu einem Business-Kontext und zu einer gewissen Bereitstellung für Risikoaufnahme angepasst ist, ausgerichtet ist. Als Auswirkung des o.g. Ansatzes, wird das Inventar reduziert. In der Software-Branche wird das Inventar nicht in der selben Art und Weise als sichtbar wahrgenommen, im Vergleich mit anderen Branchen. Tatsache ist, dass dieses Inventar auch in Software mit zusätzlichen Kosten verbunden ist und diese Kosten sind meistens schwer einschätzbar. Agile Methoden haben das Inventar durch das Einführen von Mitteln die die in Ausführung befindliche Arbeit minimieren, reduziert. Sprints die in einem festgelegten Zeitintervall auszuführen sind, die Erstellung der User-Stories und deren Umwandlung in Aufgaben die gemeint sind, den Prozess der Software-Lieferung so schnell wie möglich in einem finalen Zustand zu bringen und der Feedback-Mechanismus der für den Entscheidungsprozess wichtig ist ob das Feature es in einem Produkt-Release schafft oder nicht stellt die Hauptbausteine die die Agilen Frameworks für diesen Aspekt eingeführt haben, dar. Die in Ausführung befindliche Arbeit kann in der Software-Branche als Inventar angesehen werden weil sie nicht zu dem direkten Durchsatz beitragen kann. Ihre Existenz erzeugt die Möglichkeit, mehrere Bugs zu produzieren die mit der Zeit zur erheblichen und teueren Fehlerbehebung und Technical Debt führen kann. Fixe Zeitintervalle für Sprints und die Priorisierung der Arbeit in Scrum und Kanban helfen, diese Kosten zu sinken. Es gibt auch andere technische Strategien wie z.B. Continuous Delivery die über das agile Framework hinausgehen und in der Lage sind, die Senkung dieser Kosten zu verursachen, aber die sind normalerweise zusammen mit einem Agile Framework eingesetzt. Die Reduzierung der operativen Kosten liegt im Zusammenhang mit der Senkung der Inventarkosten weil in agilen Setups die funktionsübergreifende Teams beinhalten die Idee generalisierende Spezialisten zu entwickeln. Das bedeutet, dass wichtige Kompetenzen die für die Software-Lieferung entscheidend sind werden schnell und effektiv innerhalb des Teams verbreitet und das sorgt für schnelle Lieferungen, sinkt die Produkteinführungszeit und erlaubt eine effiziente Risikominderung. Andere Techniken wie z.B. Automatisierung der Testaufgaben und des Deployments als Teil der Continous Delivery sinken auch die operativen Kosten aber die werden gewöhnlich zusammen mit einem agilen Framework eingesetzt. Schnelles Feedback, falls negativ, erlaubt die Entscheidung eine Initiative zu einem passenden Zeitpunkt (zu dem nicht zu viel Geld bereits geflossen ist) zu stoppen und das hilft, Geld zu sparen - weil die Inventarmenge (die in Ausführung befindliche Arbeit) und deren verbundenen Kosten reduziert werden. Agile Methoden liefern Unterstützung für solches Feedback frühzeitig und oft, auf eine iterative Basis, durch Sprint Retrospektiven und Demos. In der Software-Branche, wie in allen anderen Branchen, ist das Hauptziel, Geld zu verdienen und dieses Ziel kann als erhöhten Durchsatz mit niedrigen Inventarkosten und operativen Kosten übersetzt werden. Agile Methoden haben ein klares Framework das das Erreichen des Zieles erlaubt, erfolgreich geliefert. |
1-10 of 21