Blog

„Ein gutes Pferd springt nicht höher, als es muss.“

So sagt es der Volksmund und das Pferd soll recht behalten: denn in vielen Fällen kann schon mit 20% des Einsatzes rund 80% des Ergebnisses erreicht werden. Zwar stellte Vilfredo Pareto sein 80:20-Prinzip für die Verteilung von Boden in der italienischen Bevölkerung auf, doch zahlreiche (Projekt-)Beispiele zeigen, dass er mit dem Paretoprinzip nicht nur einen statistischen Wert beschrieben hat. Im Projekt kann diese Regel helfen, um die wesentlichen Arbeitspakete zu identifizieren und Ressourcen entsprechend einzuplanen. Wichtig dabei ist: zu erkennen, wo die 20% liegen.

Das Wesentliche fokussieren: die 20% identifizieren

Eine meiner ersten Lernkurven war die 80:20-Regel: In einem großen Turnaround-Projekt mussten mehr als 100 Maßnahmen getrackt werden – aufwändige Kalkulationstabellen, riesige Sheets, tagelange Diskussionen, Datenschlachten rund um Zahlen. Und als uns die Datendarstellung um die Ohren flog, kam der Hinweis, zu prüfen, wie viele der einzelnen Maßnahmen den größten Erfolg erwirtschaften sollten. Eine schnelle Analyse ergab: rund 20% ergaben 80% des angestrebten Einsparpotenzials. Mal von der technischen Perspektive abgesehen, dass Trackingtools auf solche Spitzen abzielen sollten, war so schnell klar, auf welche Themen sich auch der Projektleiter fokussieren sollte. Oder auch: Wie hoch das Pferd springen muss. Seitdem prüfe ich meine Projekte auf diese Regel: welche der definierten Maßnahmen, Epics, Storys tragen zum größten Teil zum Erfolg bei.

Was sind 100% im Projekt?

Oder: wo lässt sich die Regel anwenden? Stolperstein beim Pareto-Prinzip kann sein, zu übersehen, dass 100% Ergebnis freilich immer nur durch 100% der Leistung erzielt werden können. Und Paretos Hinweis zur Unabhängigkeit der Teile einer Gesamtmenge: Habe ich also eine Wirkkette meiner Teilprojekte zueinander, kann ich die Regel eventuell nicht auf das Gesamte anwenden. Diese Interdependenzen gilt es zu identifizieren. Anschließend kann dann priorisiert werden (Stichwort: Scope & Out of Scope definieren). Im Wald der Priorisierung hilft es oft, zu erkennen, welche der Maßnahmen die kritischen sind und als Schlüsselprojekte umgesetzt werden müssen. In den Teilprojekten wiederum sollte definiert werden, wie viel notwendig ist, um das Gesamtergebnis erreichen zu können – und welche Themen „Schöner Wohnen“ sind. Im agilen kann das natürlich iterativ auch in der Backlog-Pflege erfolgen; die grobe Einteilung sollte aber schon in der Angebotserstellung/Kickoff-Unterlage deutlich werden. 

Die Unternehmensebene

Auf Unternehmensebene kann das Paretoprinzip dazu dienen, Schlüsselkunden zu identifizieren und entsprechend Ressourcen zu planen, Wissen aufzubauen – oder gar im Gegenteil: Gegengewichte zu schaffen. Auch das Prinzip, E-Mail-freie oder Meeting-freie Zeiten zu definieren kann dieser Idee folgen: am Endes eines Tages zu überprüfen, welche wesentlichen To-Dos an einem Tag erledigt werden konnten – und wie viel Zeit dafür prozentual notwendig war. Erschreckend ehrlich, oder?

Auf die Meta-Ebene

Gibt es 100% überhaupt? Am Höhepunkt des Projektes hilft manchmal alles zu priorisieren, alles zu sortieren und alles auszudiskutieren nichts mehr: nun gilt es zu fragen, wo die 100% liegen. In der Funktionalität des Produkts, im Design, in der Zeitleiste oder in den Kosten? Nicht nur über Geschmack lässt sich nicht streiten, gleiches gilt auch für die zu erreichenden Hundertprozent. Je nach Budgethöhe, variierenden Referenzpunkten, vorhandener Erfahrung und eigenem Anspruch ist „fertig“ zu einem unterschiedlichen Grad erreichbar. In agilen Teams kann eine sogenannte "Definition of Done" hier ein Stück weit den Anspruch lenken und einen Kompromiss zwischen „schneller Lösung“ und „Perfektion“ einleiten. 100% erreichen wir nie: also lassen wir das Pferd nur so hochspringen, wie es muss.

Klassische Beispiele

In der Diskussion um das Paretoprinzip wird neben dem ursprünglichen Ergebnis Paretos, dass 80% des italienischen Grundes nur rund 20% der Bevölkerung gehört, oft darauf verwiesen, dass auch die Verteilung des Weltvermögens einem ähnlichen Verhältnis folgt. Klassische, weitere Beispiele sind etwa, dass oft nur 20% der Kunden zu bereits 80% des Umsatzes führen – und auch das Verhältnis von Anzahl an Produkten zu erwirtschaftetem Gewinn dieser Aufteilung oft gleicht. Wichtig ist nur: das ist keine absolute Wahrheit. Es gilt, zu prüfen, ob es im eigenen Projekt oder Unternehmen so zutrifft. Übrigens: Neben dem Paretoprinzip ist der Namensgeber auch noch verantwortlich für das Pareto-Optimum. 
 

by Annelie



Acrontum Insights: ein Tag als IT-Berater

03 Dec 2018

Insights Deutsch

Unser IT-Berater Julien beschreibt einen typischen Arbeitstag als IT-Berater bei acrontum, im Büro und beim Kunden vor Ort.

Ich habe mich für den Beruf IT-Berater/Projektmanager entschieden, da jeder Tag eine willkommene neue Herausforderung darstellt. Der Mix aus Kundenkommunikation, Projektorganisation, internen Abstimmungen mit Entwicklern sowie die konzeptionelle Lösungsfindung im Allgemeinen bietet mir viel Freiräume in Gestaltung und persönlicher Weiterentwicklung. Darüber hinaus ist das Team einfach klasse!

Da sich die Arbeit als IT-Berater stark von „klassischen“ Unternehmensberatertätigkeiten unterscheidet, habe ich einen typischen Tag im Büro beziehungsweise beim Kunden festgehalten.

08:30 Uhr

Ich komme im Büro an, stöpsle den Laptop an und drehe eine Guten-Morgen Runde. Mein tägliches Ritual endet wie immer an der italienischen Siebträgermaschine, an welcher ich mir einen leckeren Cappucino mache.

09:00 Uhr

An oberster Stelle stehen immer die Kunden-E-Mails, welche ich sukzessive durchgehe und mir Notizen zum aktuellen Projektverlauf mache. Aktuell geht das Gesamtprojekt eine ruhigen und stetigen Lauf in Richtung Go-Live, weswegen die Nachrichten rein informativer Natur sind.

09:30 Uhr

Mein Hauptansprechpartner beim Kunden ruft an und wünscht ein kurzes Update zu allen offenen Themen. Ich greife dazu auf meine Notizen zurück, welche ich immer digital festhalte. Wir identifzieren eine technische Hürde beim Import von Inhalten in eine bekannte SaaS-Lösung, welche wir aufgrund des nahenden Go-Live schnell überwinden sollten. Meinen Vorschlag zum weiteren Vorgehen bestätigt der Kunde und wir vereinbaren einen späteren Rückruf.

10:00 Uhr

Der Lösungsvorschlag hat sich als grundsätzlich belastbar heraus gestellt und ich konzipiere mit Unterstützung eines Techies ad-hoc einen Prozess zur Importierung. Zur Darstellung nutzen wir MS Visio und haben unseren Ansatz schnell visualisiert.

10:15 Uhr

Zeit für eine Banane – ich freue mich über die wöchentliche Obstlieferung, um so mehr an intensiven Tagen wie heute.

10:45 Uhr

Ich rufe den Kunden zurück und präsentiere den Lösungsansatz via Screensharing. Zudem zeige ich eine Folie, welche die Randbedigungen aufzeigt und offene Punkte auflistet. Der Kunde bittet um ein Arbeitsmeeting am Nachmittag, um die Lösung zu evaluieren und festzuzurren – die Zeit drängt.

11:00 Uhr

Schnell prüfe ich noch die Social Media Kanäle von acrontum nach möglichen Interaktionen und antworte engagierten Usern!

11:15 Uhr

Kurz vor meiner Abfahrt tausche ich mich mit einer Junior Beraterin aus und bespreche den aktuellen Stand interner Projekte. Wir stellen fest, dass unsere Ansätze zwar unterschiedlich sind, sich allerdings hervorragend ergänzen. Die Kollegin aggregiert im weiteren Verlauf des Tages die Unterlage zur Besprechung in unserem persönlichen Jour Fixe am nächsten Tag.

11:45 Uhr

Los geht es! Ich setze mich auf meine 30 Jahre alte Vespa und fahre los Richtung Kunde. Die Sonne scheint mir auf den Anzug und der Fahrtwind hilft mir dabei, die Gedanken zu ordnen. In diesen Momenten freue ich mich am meisten darüber, Berater zu sein und jeden Tag das Gleiche zu machen.

12:30 Uhr

Der Kunde und ich genießen unser gemeinsames Lunch in der Sonne. Neben beruflichen Dingen sprechen wir auch über private Themen; die gemeinsame Arbeit an intensiven Konzern-Projekten schweißt zusammen und schafft Vertrauen.

13:30 Uhr

Ich telefoniere mit einem unseren Entwickler und gebe neue Ideen durch. Wir diskutieren kurz die Sinnhaftigkeit und vereinbaren ein persönliches Gespräch am nächsten Tag.

13:45 Uhr

Im Arbeitsmeeting präsentiere ich mehreren Mitarbeiter des Kunden die am Vormittag konzipierte Lösung. Änderungen skizzieren wir auf dem Surface Hub direkt in das Dokument. Das Konzept gefällt und soll weiter verfolgt werden.

15:00 Uhr

Eine kurzfristige Anforderung kommt via E-Mail rein: der Kunde benötigt schnell eine PowerPoint-Unterlage für ein Statusupdate, ich soll in einer Stunde einen Zwischenstand zeigen.

15:35 Uhr

Eine Kollegin ruft mich an und benötigt Infos – das muss warten, Kundenaufgaben haben immer Vorrang. Wir wollen uns später via Chatprogramm austauschen.

16:00 Uhr

Der Aufschlag gefällt, es gibt noch kosmetische Anpassungen.

16:15 Uhr

Ich prüfe die User Stories für ein internes Projekt und schärfe die Anforderungen und Acceptance Criteria. Bevor die Arbeit an den Tickets los geht, müssen die Stories priorisiert werden – ich stelle dafür einen Termin mit der Geschäftsführung ein.

17:00 Uhr

Bevor ein weiteres Projekt beim Kunden seitens der Führungskräfte genehmigt werden kann, müssen entsprechende Unterlagen erstellt werden. Die Präsentation habe ich bereits finalisiert, jetzt ist das Operational Manual dran, also die Dokumentation sowie Arbeitsabläufe für den Betrieb der IT Lösung nach der Projektierung.

18:30 Uhr

Ich bespreche den Zwischenstand des Manuals mit dem Kunden und plane den nächsten Tag. Das heutige Resümee fällt sehr positiv aus, das laufende Projekt sowie die neue Intitiative sind jeweils ein gutes Stück vorwärts gekommen. Happy schwinge ich mich auf die Vespa und fahre zu meiner Freundin, um den Abend im Biergarten ausklingen zu lassen.

by Julien



Oder: was hat Editorial Storytelling mit UI zu tun?

 

Zweieinhalb Tage, mehr als 70 Sprecher, vom unveröffentlichten Indie- bis zum arrivierten Zeit-Magazin, junge Illustratoren und erfahrene Magazin-Denker, gelangweilte Modefotografen, Datenjournalisten die Feuer und Flamme sind für das, was sie tun. Klassische Typografen, „Wir sind Journalisten“ und Infografiker: alle versammelt in der alten Kongresshalle in München.

Die bekannten Gesichter der Branche sind auch da. Wirklich interessant aber sind Projekte wie republik, Büros wie yaay, Magazine wie Missy, the Mold oder Weapons of Reason, Fotografen wie Claudia Kent.

Und, ja: was hat das alles mit der Entwicklung und Gestaltung von nutzerzentrierten, smarten User-Interfaces zu tun? Das: wie bei Walden muss ein bekanntes Thema neu gedacht und klassisch verpackt werden, muss die eine Idee konsequent dekliniert werden (das neue Erscheinungsbild von Isuzu) und wie bei dem von Verena Gerlach gestalteten Buch „Houses of Taswir“ braucht der Nutzer eine sehr genaue visuelle Anleitung dessen was zu lesen bzw. zu klicken ist.

„Storytelling“ ist also nicht nur ein redaktionelles Werkzeug, „Storytelling“ ist auch ein Werkzeug UIs verständlich und funktionell eindeutig aufzubauen, sie in ein Corporate Design einzubinden und so zu gestalten das der User sie gerne nutzt.

Illustration: Son Luu Vu hier und hier