Blog

80:20 – Wieso das Pareto-Prinzip im Projekt hilft, zu priorisieren

„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. 
 

14 Aug 2018

Insights Consulting Deutsch

by Annelie



Acrontum Team Spotlight #3: James

James has been working for acrontum since June 2017. His natural talent regarding in-depth technical knowledge is a great asset for his customer-oriented working approach and makes him the perfect fit for quick and feasible solution finding!

  • First Name: James
  • Country of Origin: USA
  • What I do: I provide 2nd Level Support and IT Consulting for our clients.
  • What I like about acrontum: I love the atmosphere here at acrontum. It's a small diverse team and everyone pitches in to make it a fun place to work.
  • Hobbies: Travel, Biking, Climbing, Gaming, and spending time with my new daughter at every opportunity.

27 Jul 2018

Team English

by Katty



Documentation Driven Development - Part 1

At acrontum we made the decision after plenty of careful consideration to adopt a new and growing trend, “documentation driven development” via “swagger” and now the newly updated specification, “OpenAPI 3”.

Documentation driven development (DDD) is not something new (some of its earliest concepts date back to 2011), but up until recently it never had an officially accepted name, nor an industry standard for the world to agree upon. It is the process of describing & designing API's and what one expects as a request and should respond with. This enables a front-end team to easily use an API within their apps and mock the response without an actual API to talk to.

Documentation driven development at acrontum is very simple and essentially boils down to a two high level and basic principles:

  • Design the API first, then build it
    • The API design must adhere to the OpenAPI Specification (formerly known as Swagger)
    • The yaml file can be broken up with swagger-chunk
    • The finished result of the API design should be a Yaml or JSON file
    • The actual API routes should be built on what is documented in the design
    • The client, eg the browser, should communicate with the API via a generated file, built from a tool such as swagger-code-gen
  • An endpoint not documented should not exist
    • A JavaScript front-end engineer using a generated DDD API access file should not look outside of this file to access the API
    • As all routes must be documented, any other routes can be seen as not required &/or dangerous

Adhering to DDD has simultaneously increased development speed whilst solving a growing issue regarding how the front-end and back-end teams both build and communicate. Further more this is not limited to company cross-team dynamics but also expandable to cross-company communications. 

Case Study

A recent project for BMW saw acrontum developing multiple API’s adhering to the aforementioned DDD principles where the main API was consumed by an Angular5 application, also built by acrontum.

Before work commenced, the API’s were designed using the Swagger2.0 spec. Upon the agreed design, both the front-end and back-end team could commence work simultaneously. The front-end team knew how the API would look when complete and could simulate the API using a mock server outputting example content. Conversely the back-end team could pick and choose which routes they wanted to build as and when they felt it right: Not having to build the routes in an order requested by the front-end team resulted in a far quicker time to staging for real testing and higher quality code base.

Change request, as with any project, happen as the client realises new potential. As and when change requests arrive that affect the back-end, the first step was to evolve the API design, ie the DDD file. After publishing the changes to the new API design(s) both the front-end and back-end could pull the updated changes and keep on building.

In addition to this, one of the API’s we built would also be consumed by a 3rd party application and once again, as the API was clearly defined by the DDD principles the said 3rd party could happily mock the API’s responses to build their part without much if any interaction with the API build team.

Looking to the future

DDD has given us some very big gains as described, but what could the future look like and how do we aim to streamline this process yet further.

Currently the API design must be written in a single Yaml file. When the API gets bigger than trivial the need to break the file down into sizeable chunks becomes a must, this is where swagger-chunk comes in. swagger-chunk allows the developer to write many smaller and manageable Yaml files which swagger-chunk then combines together into one.

Swagger-chunk is one step in the right direction, but it can be easy to get lost in a myriad of similar looking files. Further more, designing an API does not necessarily depend on skill of a developer if there were an alternative to writing pure Yaml chunks…. Enter the open source project of openapi-gui.

Openapi-gui is a graphical user interface to building the API design. The API designer does not require anything more than a web browser and technical knowledge on what a RESTfull API should be and deliver. In laymans terms, the API design can now be realised by a skilled technical product owner.

At acrontum we have yet to trial this technique and tool in production, but this does not mean we are not designing new processes to trail this, stay tuned for a future analysis...

 

 

11 May 2018

Technology English

by John