War InterFace in der Vergangenheit schon regelmäßig mit Teilnehmern mit vertreten, so feierten wir dieses Jahr auch Premiere als Aussteller. Der Schwerpunkt unseres Auftritts lag dabei ganz auf den Themen Projektcoaching und (agilem) Projektmanagement.

Zu beiden Themen hatten wir neue Broschüren im Gepäck, die auf dem Stand zum ersten Mal der Öffentlichkeit präsentiert wurden.

Während der 2 Konferenztage konnten wir eine ganze Reihe von Besuchern an  unserem Stand begrüßen, und viele sehr interessante Gespräche führen.

Im Verlauf des ersten Tages hatte jeder Aussteller die Möglichkeit, sich im Rahmen eines einminütigen Elevator Pitches an die Teilnehmer zu richten. Dr. Roland Spengler nutzte diese Gelegenheit, um zu einer Reihe von agilen Spielen an unseren Stand einzuladen.

So kam es dann auch: Bereits kurz danach hatten sich die ersten Interessenten bei uns am Stand eingefunden. Wir hatten mehrere verschiedene Spiele vorbereitet. Aus diesen wurde die “Marshmallow Challenge” ausgewählt.

Bei der Marshmallow Challenge geht es darum, aus 20 Spaghetti, 1 Yard (= 91,4 cm) Schnur, 1 Yard Klebeband und 1 Marshmallow innerhalb von genau 18 Minuten einen Turm zu bauen. Ziel ist es, dabei so hoch wie möglich hinaus zu kommen. Am Ende muss der Turm mindestens 1 Minute frei stehen, ohne zusammenzubrechen.

2 Teams machten sich daraufhin an den Start. Schon nach kurzer Zeit wurden Unterschiede in der Herangehensweise deutlich: Während Team 1 sich daran machte, über verschiedene Lösungen zu diskutieren, probierte Team 2 einfach einige Lösungen aus und konnte so schon nach kurzer Zeit eine zwar einfache, aber dafür standfeste Lösung präsentieren.

Diskussion möglicher Lösungsansätze

Mittlerweile war etwa die Hälfte der zur Verfügung stehenden Zeit abgelaufen, 9 Minuten somit noch übrig. Team 2 hatte sich in der Zwischenzeit auf einen gemeinsamen Lösungsansatz geeinigt und war gerade dabei, die verschiedenen Turmbestandteile in Serie zu fertigen. Team 1 machte sich gerade daran, die zweite Iteration des Turms zu vollenden, die mit 40 cm in etwa doppelt so hoch war wie die erste Version. Zu ihrer Erleichterung blieb der Turm auch dieses Mal stehen.

Fertigung der verschiedenen Turmbestandteile

Nun war eine schwere Entscheidung zu treffen: Auf Sicherheit gehen und die erreichte Lösung akzeptieren, oder ein weiteres Mal den Turm verbessern? Nach einem Blick auf die Uhr (4 Minuten übrig), sowie das Konkurrenzteam, das gerade dabei war, einen Turm in ähnlicher Höhe aufzustellen, wurde entschieden, das Risiko einzugehen und den Turm doch noch zu erhöhen. Die Idee dabei war, die Marshmallow auf eine verschiebbare “Antenne” zu stecken und so die maximale Höhe, die der gegenwärtigen Turmstruktur zuzumuten ist, herauszufinden.
Team 2 hatte zu diesem Zeitpunkt den Turm in der ersten (und finalen) Version zusammengebaut und suchte noch nach einem Weg, ihn ohne Beschädigung aufzustellen.

Die Zeit war nun um. Alle Teilnehmer mussten die Hände vom Turm nehmen. Team 2 hatte es tatsächlich geschafft und seinen Turm mittels der “Antenne” um weitere 15 cm auf eine Gesamthöhe von 55 cm erhöht.

Und Team 1? Solange noch eine Hand am Turm war, hatte dieser eine ähnliche Höhe. Es versprach also spannend zu werden. Doch leider nur, bis die Hand weggenommen wurde: Der Turm von Team 1 war dieser Belastung (noch) nicht ganz gewachsen und stürzte ein.

Retrospektive von Team 1

Nun hatten beide Teams noch Gelegenheit, die vergangenen 18 Minuten zu analysieren und eine kleine Retrospektive durchzuführen. Team 1 nutzte diese Gelegenheit gerne und fand auch bald einige Diskussionspunkte. Als positiv wurde die rege Kommunikation im Team sowie die Beteiligung aller gesehen. Verbesserungspotenzial sah man v.a. darin, das nächste Mal entweder iterativ vorzugehen, einige der zur Verfügung stehenden Materialien für einen Prototypen zu verwenden, oder zumindest den gewählten Lösungsansatz vorab zu testen.

Am Ende wurde im Teilnehmerkreis noch munter über weitere Lösungen und Herangehensweisen diskutiert.

Über Twitter und diverse Blogs, aber auch auf Veranstaltungen aller Art, haben wir uns gefunden, eine Gruppe von freien, aufgeklärten und konstruktiv-kritisch denkenden Projektmanagern und Unternehmern.

Und weil wir gemerkt haben, dass es zwischen uns so etwas wie einen Gleichklang aus Wissen und Erfahrung gibt, haben wir beschlossen, gemeinsam mit Freunden und Gästen das

Projektmanagement Camp 2011

zu veranstalten.

Dies findet in diesem Jahr statt vom 3. bis 5. November 2011 in Dornbirn, Österreich.

Unsere Vision ist:

Eine unabhängige, offene und kollaborative Standortbestimmung jenseits des Einflusses großer PM-Organisationen ist unser Ziel. Gängige Standards sind für uns nur eine Facette des immer vielfältiger werdenden PM-Kosmos. Spannend wird es dort, wo die klassische Lehre im (scheinbaren) Gegensatz zu neuen Strömungen steht. Das PM-Camp schlägt eine Brücke zwischen (scheinbar) widerstrebenden Aspekten des gelebten Projektmanagements:

• Klassisches versus agiles PM
• Hierarchie / Linie versus Heterarchie / Teamorientierung
• Fremdorganisation versus Selbstorganisation
• Management versus Führung
• Planung versus Improvisation

Unsere Zielgruppen sind:

• Projektmanager
• Softwareentwickler
• Innovations-/Entwicklungsleiter
• Menschen mit Führungserfahrung
• Studierende

Hier geht es zur Registrierung!

Mehr zum Projektmanagement Camp 2011 findet man auf der offiziellen Website oder in den Blogs von Dr. Marcus Raitner und Dr. Stefan Hagen!

Im Laufe des letzten Jahres haben sich bei InterFace IT-Audits als neues Tätigkeitsfeld entwickelt. Dies entspricht einem Anliegen des Kunden nach unabhängigen Untersuchungen kritischer oder als problematisch empfundener Themen.

Die letzten Jahre standen im Zeichen flacher Hierarchien mit komplexer werdenden Führungsverhältnissen (Matrix- und Prozessorganisation) sowie der zunehmenden Ausgliederung von Unternehmensaufgaben an Dienstleister. Das hat letztlich für das Führungspersonal zu einer Verbreiterung der Führungsspanne im Zeichen undurchsichtiger Verantwortlichkeiten, komplexer Lieferbeziehungen und erstaunlicher Beschäftigungsverhältnisse geführt. Gesetzgeber, Justiz und Unternehmensleitung setzen durch immer neue Regularien noch eins drauf.

In dieser Situation entsteht gerade für die  Team- und Abteilungsleitung häufig Bedarf nach einer zweiten, unabhängigen Meinung zu fachlichen, aber auch organisatorischen Themen. Vermutete Fehlentwicklungen sollen untersucht, riskante Themen müssen begleitet werden, Termine mit externen Prüfungsgesellschaften oder der internen Revision sind vorzubereiten.

Gefragt ist hierbei meiner Erfahrung nach nicht der noch bessere Spezialist, sondern eine auf gutem IT-Wissen basierende Steuerungssicht. Anforderungen und Regularien sind zu sichten und zu klären, das Zusammenwirken unterschiedlicher Sichten zu prüfen. Im Gespräch soll eine fundierte und ehrliche Antwort auf die Frage nach dem Stand der Dinge erarbeitet werden. Vertrauen und Wertschätzung, die Fähigkeit zuzuhören und sich in die Welt des anderen einzufinden, aber auch  Mut und Geschick, unangenehme Dinge beim Namen zu nennen sehe ich als Bausteine des Erfolgs.

Abschließend noch ein Wort zu den Grenzen, damit keine falschen Erwartungen entstehen: Analyse ist noch keine Problembehebung. Empfehlungen sind noch nicht umgesetzt und erst recht nicht wirksam.

Am 25. November 2010 finden in München die 14. OBJEKTspektrum Information Days statt. Die Konferenz rund um das Thema Testing beinhaltet klassische Fachvorträge und Erfahrungsberichte namhafter und gestandener Experten.

Als offizieller Sponsor wird auch die InterFace AG mit einem Stand und Vortrag vertreten sein.

Oliver Niklas wird zum Thema “Testmanagement in DBMS-Migrationsprojekten. Wie kann man die Migration von Legacy-Systemen absichern?” sprechen.

Oliver Niklas hat langjährige Erfahrung mit Qualitätsmanagement und Qualitätssicherung in Großprojekten der Branchen Energie und Public Services. Als Testmanager koordinierte er in Multiprojekten den Austausch der Datenbankmanagementsysteme für sämtliche Anwendungen eines Kunden mit mehr als 100.000 Mitarbeitern.

Legacy-Systeme existieren in nahezu jedem Unternehmen. In der Regel sind diese Systeme durch sehr heterogene Dokumentation und von außen undurchschaubare Software-Lifecycles gekennzeichnet. Die Anwendungen bedienen wie selbstverständlich seit Jahren die kritischsten Geschäftsprozesse Ihres Kunden. Anhand eines Erfahrungsberichts (Austausch des DBMS für 23 IT-Verfahren eines öffentlichen Auftraggebers) zeigt der Vortrag einen Weg auf, wie das Testmanagement paralleler DBMS- Migrationsprojekte erfolgreich und wirtschaftlich betrieben werden kann.

Dieses Mal stand jedoch kein gesellschaftliches oder gar politisches Thema im Vordergrund, sondern ein fachliches:

“Agile Softwareentwicklung”

Dieses Thema galt es in möglichst vielen Facetten zu beleuchten.

Den Anfang machte Prof. Dr. Dr. h.c. Manfred Broy, Inhaber des Lehrstuhls Informatik IV: Software & Systems Engineering an der TU München und Aufsichtsratsvorsitzender der InterFace AG. Er betrachtete agile Softwareentwicklungsmethoden aus wissenschaftlicher Sicht. Zudem ging er die 4 Werte des agilen Manifests nacheinander durch und gab dazu jeweils seine Einschätzung basierend auf seine Erfahrung als Professor für Informatik, Mitentwickler des V-Modell XT und Revisor unzähliger erfolgreicher, aber auch nicht so erfolgreicher IT-Projekte, ab. Sein Resumé fiel geteilt aus.

Während einige Aspekte seine ungeteilte Zustimmung fanden, war er bei anderen eher geteilter Meinung. So sind aus seiner Erfahrung als Revisor unzähliger Softwareprojekte instabile Anforderungen einer der häufigsten Gründe des Scheiterns. Die Zeile “Responding to change over following a plan” empfindet er daher als durchaus problematisch.

Auch der Punkt “Customer collaboration over contract negotiation” fand nicht seine ungeteilte Zustimmung. Eine konstante Mitarbeit des Kunden im Projekt ist natürlich äußerst hilfreich, wenn man ein erfolgreiches Projekt bestreiten möchte. V.a. in seiner Tätigkeit als Revisor habe er es andererseits auch schon sehr oft erlebt, dass eine unklare Vertragssituation Anlass für Streitigkeiten war, oft auch vor Gericht. Gerade bei kleinen und mittelständischen Firmen geht es dabei schnell um Summen, die das komplette Unternehmen in Schieflage bringen können. Etwas gesunde Vorsicht sei in diesem Punkt daher durchaus angebracht.

Dies waren natürlich nur einige von mehreren Punkten. Wenn Sie auch den Rest erfahren möchten, können Sie hier die Vortragsfolien herunterladen:

Im Anschluss daran gab uns Axel Maisch, einer der agilen Vorreiter der InterFace AG, eine Einführung in das Thema Scrum. Er erklärte die verschiedenen Rollen, Artefakte und Zeremonien, aus denen Scrum besteht und zeigte anhand des Alltags eines realen Softwareentwicklungsteams, wie diese einzelnen Zahnräder ineinander greifen und ein Team zu Höchstleistungen beflügeln können. Dazu gehören auch Werte wie “Stolz auf die eigene Arbeit”, “Agieren ohne Angst”, “Hohe stetige Qualität”, und nicht zuletzt “Üben, üben, üben” – Werte, die man heute unter dem Oberbegriff “Software Craftsmanship” kennt. Doch halt: Craftsmanship? Das hat doch was mit Handwerk zu tun. Ist die Informatik daher gar ein Handwerk? Mehr dazu später.

Hier und jetzt gibt es erst einmal die Folien zum herunterladen:

Ich selbst war dann im Anschluss an der Reihe. Nachdem Axel bereits etwas zu Scrum erzählt hatte, wollte ich gerne etwas zu einer anderen agilen Methode erzählen, die momentan stark im Kommen ist: Kanban. Um etwas verlorene Zeit wieder aufzuholen und alle Teilnehmer möglichst pünktlich in die Pause zu entlassen, habe ich mich bewusst etwas kürzer gehalten als ich es sonst getan hätte. Zudem habe ich, um ein wenig Abwechslung zu bieten, ausnahmsweise mal nicht auf Powerpoint gesetzt, sondern ein anderes Tool verwendet: Prezi. Da es ein webbasiertes Tool ist kann ich meine Folien an dieser Stelle direkt einbinden, sodass Sie sie hier direkt ansehen können.

Nach der wohlverdienten Pause folgte Thomas Vallon mit seinem Vortrag “Ist die Informatik ein Handwerk?”. Er verglich dabei die Informatik mit dem vorherrschenden Handwerk im Mittelalter: Dem Kathedralenbau. Dieser zeigt nämlich einige erstaunliche Parallelen zu modernen IT-Projekten. Der Bau zog sich teilweise so lange hin, dass inzwischen eine ganz andere architektonische Epoche angebrochen war (z.B. Gotik statt Romanik), die noch im Bau befindliche Kathedrale daher auf einmal – obwohl die eigentliche Funktion als Gotteshaus nicht beeinträchtigt ist – erschreckend altmodisch aussieht. Ganz den agilen Werten verpflichtet wurden daher auch damals schon Pläne geändert, Teile des Gebäudes umgebaut, abgerissen und/oder wieder neu aufgebaut. Es gibt so gut wie keine Kathedrale, bei der dies nicht der Fall war.

Auch die “Ehre” der am Bau beteiligten Handwerker ist an vielen Kathedralen zu erkennen. So sind z.B. viele der Figuren in der Fassade von Notre Dame auch auf der Rückseite noch mit demselben Detailgrad wie der Vorderseite gearbeitet, obwohl dem Künstler sicherlich klar war, dass außer ihm wohl so schnell kein anderer Mensch mehr einen Blick darauf werfen wird.

Ich will an dieser Stelle aber nun nicht zu viel vorgreifen und Sie stattdessen auf das Manuskript verweisen. In seiner ihm eigenen, gründlichen Art, hat sich Thomas die Mühe gemacht, ein solches auszuarbeiten. Ich wünsche Ihnen jetzt schon viel Spaß beim Lesen – der Vortrag war wirklich exzellent. Zudem betrachtet er die IT mal aus einem ganz anderen Blickwinkel als sonst. Unbedingt lesen!

Dr. Christof Stierlen, der auf Thomas Vallon folgte, war dann bereits der letzte Vortragende des Abends. Er gab den Anwesenden einen Überblick über die Aktivitäten der InterFace AG im Bereich agiler Softwareentwicklung, den damit erzielten Erfolgen, aber auch den Herausforderungen, die auf diesem Weg zu meistern waren. Als Beispiel dienten ihm dabei einige konkrete Projekte der jüngeren Vergangenheit, in denen sich gezeigt hat, dass vor allem kurze Iterationen, an deren Ende lauffähige Software steht, Vertrauen auch auf Kundenseite schaffen, wodurch sich die Zusammenarbeit auch mit (zu Beginn noch) sehr skeptischen Kunden entscheidet verbessert hat. Zeitgleich wurden alle bekannten Fehler gezielt beseitigt und das Projekt vor der Zeit und innerhalb des Budgets abgeschlossen. Ein voller Erfolg also.

Ich hoffe Sie haben dennoch Verständnis dafür, dass wir diese konkreten Beispiele hier nicht mit veröffentlichen können und daher schweren Herzens wieder aus dem Foliensatz entfernt haben.

Beim anschließenden Buffet zu Ehren von Roland Dürre’s 60. Geburtstag waren die Rückmeldungen der Anwesenden durchwegs positiv. Viele fragten nach den Foliensätzen, welche wir hiermit gerne zur Verfügung stellen.

Wir hoffen Sie alle beim nächsten IF-Forum wieder begrüßen zu dürfen.

Am Montag, den 15.3., um 19:00 ist es bereits so weit.

Hier deswegen nun die Agenda, die wir uns für Montag ausgedacht haben:

1. Standup mal ganz anders: Ein agiles Kennenlernen
2. Krishan Mathis erzählt vom ScrumGathring diese Woche in Orlando
3. “Agile Monday”-Backlog: Themen für zukünftige Stammtische
4. “Agility at a napkin”: Kurzvorstellungen von Scrum, Kanban und anderen agilen Themen auf einem FlipChart (evtl. mit Gastrednern)

Diese Reihenfolge kann sich am Montag natürlich noch etwas ändern, je nachdem was die Teilnehmer am meisten interessiert.

Für die nächsten Male ist es dann unser Plan, jeden Abend unter ein anderes Thema zu stellen. Am besten natürlich unter eines, das aus der Community selbst entstanden ist! Deswegen möchte ich alle dazu ermuntern, sich Gedanken zu machen und diese am Montag einzubringen.

Wer am Montag verhindert ist, kann natürlich auch in der XING-Gruppe Vorschläge einbringen.

Am 25.2.2010 findet ab 17:00 wieder das monatliche Treffen der Nürnberger Kollegen in unserer Geschäftsstelle im Südwestpark statt.

Folgende Agenda ist geplant:

17:00-17:30 Bericht

17:30-18:30 Vortrag von Bernhard Maischberger zum Thema “Lernen und Veränderung”

ab 18:30 Gemütliches Beisammensein

Bis dann.

Warum Scrum? Gründe für das Management (1/2)

Bernhard Findeiss, Samstag, der 30. Januar 2010

Sind nur selbstorganisierende Teams echte Teams?

Bernhard Findeiss, Mittwoch, der 13. Januar 2010

“Done”, oder: Wann ist etwas fertig?

Bernhard Findeiss, Dienstag, der 3. November 2009

Unser Scrum Plakat jetzt in Version 2 verfügbar!

Bernhard Findeiss, Mittwoch, der 30. September 2009

Scrum vs. Kanban (2/2)

Bernhard Findeiss, Mittwoch, der 8. Juli 2009

Scrum vs. Kanban (1/2)

Bernhard Findeiss, Dienstag, der 30. Juni 2009

InterPM 2009: “Retrospektiven als Basis agilen Projektmanagements: gelebte Streitkultur”

Alexander Maisch, Donnerstag, der 25. Juni 2009

ScrumDay München: Keynote von Ken Schwaber

Bernhard Findeiss, Montag, der 11. Mai 2009

Vortrag zum Thema Retrospektiven auf dem ScrumDay München

Bernhard Findeiss, Donnerstag, der 7. Mai 2009

Scrum und Hyperproduktivität Teil 2 – oder: Scrum für Fortgeschrittene

Bernhard Findeiss, Mittwoch, der 29. April 2009

Agile Retrospektiven (Teil 2)

Bernhard Findeiss, Montag, der 6. April 2009

Agile Retrospektiven (Teil 1)

Bernhard Findeiss, Montag, der 30. März 2009

Scrum Smells – oder: Schlechte Angewohnheiten

Bernhard Findeiss, Montag, der 9. März 2009

Scrum und der “hyperproduktive Zustand”

Bernhard Findeiss, Dienstag, der 3. Februar 2009

Scrum und CMMI (Teil 1/2)

Bernhard Findeiss, Dienstag, der 16. Dezember 2008

Was ist Agilität?

Bernhard Findeiss, Freitag, der 12. Dezember 2008

Dr. Scrums Tagebuch #3

Gastautor(en), Dienstag, der 4. November 2008

Agiles Schätzen und Planen Teil 3

Bernhard Findeiss, Montag, der 3. November 2008

Der Über-Product-Owner

Alexander Maisch, Dienstag, der 28. Oktober 2008

Hurra, hurra – das Scrum-Plakat ist da!

Roland Dürre, Dienstag, der 28. Oktober 2008

InterFace Geschichte #10 – Ein “HIT” wird geboren! oder: 25 Jahre Scrum!

Roland Dürre, Donnerstag, der 23. Oktober 2008

Dr. Scrums Tagebuch #2

Gastautor(en), Montag, der 20. Oktober 2008

Agiles Schätzen und Planen Teil 2

Bernhard Findeiss, Freitag, der 17. Oktober 2008

Agiles Schätzen und Planen

Bernhard Findeiss, Freitag, der 10. Oktober 2008

Impressionen aus Kalifornien

Christof Stierlen, Donnerstag, der 9. Oktober 2008

Dr. Scrums Tagebuch #1

Gastautor(en), Donnerstag, der 9. Oktober 2008

Nächste Schritte mit der TU-München

Christof Stierlen, Mittwoch, der 1. Oktober 2008

Agile Auftraggeber – Warum gibt es sowas nicht öfters?

Bernhard Findeiss, Samstag, der 13. September 2008

Teilnehmererlebnisse – Creative Scrum Workshop

Christof Stierlen, Mittwoch, der 10. September 2008

Kreativitätsunterstützung für SCRUM Teams

Florian Forster, Montag, der 25. August 2008

Creative Scrum Teams – Pilot Workshop (August 2008)

Christof Stierlen, Dienstag, der 19. August 2008

Scrum und Festpreisverträge

Bernhard Findeiss, Freitag, der 15. August 2008

Creative Scrum Teams – Mitstreiter an der Universität (Juli 2008)

Christof Stierlen, Donnerstag, der 14. August 2008

Creative Scrum Teams – Die Idee dahinter (Juni 2008)

Christof Stierlen, Donnerstag, der 14. August 2008

Die Scrum-Sprechstunde: Rollen in Scrum

Alexander Maisch, Donnerstag, der 3. Juli 2008

Die Scrum-Sprechstunde: der Nokia-Test

Alexander Maisch, Freitag, der 13. Juni 2008

Agile Softwareentwicklung mit Scrum

Christof Stierlen, Dienstag, der 3. Juni 2008

Projekte kennen häufig auch regelmäßige Besprechungen in Form eines jour fixe. Vier oder fünf Personen kommen zusammen, verbringen ein oder zwei Stunden zusammen – macht zusammen als Arbeitszeit schnell einen halben oder ganzen Arbeitstag.

Dagegen ist auch gar nichts einzuwenden, gäbe es da nicht das Problem mit der Erinnerung. Im Normalfall kann sich am nächsten Tag kaum noch jemand erinnern, was genau besprochen wurde, welche Ergebnisse erzielt wurden und warum. Jeder hat seine Erinnerung, seine Bruchstücke der Veranstaltung, mit ziemlicher Sicherheit auch mit widersprüchlichen Erinnerungen, vergleichen wir sie mit denen der anderen Teilnehmer.

Resultat: Abgesehen von der gemeinsam verbrachten Zeit und der Kontaktpflege ist nicht viel geblieben. Kontaktpflege ist schon viel, aber oft eben zu wenig.

Somit sind wir also bei der Aufgabe, Ergebnisse festzuhalten, vielfach gelöst durch Mitschriften, Protokoll in Textform, eine mühselige Angelegenheit, unbeliebt, fast schon eine Strafe. Jeder macht sich vorher Notizen, die meisten notieren auch für sich mit, aber Protokoll – Nein Danke!

Warum könnte das so sein? Vermutung: Stichworte sind schnell geschrieben, Ausformulieren ist jedoch mühsam und langwierig. Stichworte in einer Textmitschrift sind wohl auch irgendwie peinlich. Die Textform übt einen Zwang zum Ausformulieren aus. Deshalb, so meine Erfahrung aus dem letzten Monat, ist das folgende Bild in den meisten Fällen ein völlig ausreichende Lösung:

Beispiel einer Besprechungsnotiz

Vor der Besprechung einige Minuten hingesetzt, die rechte Seite mit Ideen und vorhandenen Infos gefüllt. Das reicht und hilft dabei, die meisten Sitzungen zu strukturieren.

Und danach: Die linke Seite füllen, mit Stichpunkten, und als Notiz versenden. Fertig! Weil das auch technisch so einfach ist, kenne ich einige Kollegen, die sich während der Besprechung bereits ihre Notizen in ihr Notebook schreiben.
Visuelle Darstellungen mit oben verwendeter MindMap-Methode sind gerade in weniger formellen Situationen viel leichter erfassbar, einfach unkomplizierter. Und technische Unterstützung gibt es für jeden Geldbeutel: zum Beispiel MindManager (Bild oben, kostet, verwende ich gern), FreeMind (kostenlos), xMind (kostenfreie oder Bezahlversion).

Jetzt wird jemand sagen, das ist doch billig! Ja, genau, das ist es! Im Projekt ganz billig vorangekommen!

Allgemeinverständlichkeit ist aber geradezu lebenswichtig, neben dem allgegenwärtigen vertrieblichen Interesse auch wegen des Kooperationsbedarfs in einer offenen, demokratischen Gesellschaft, sowie der Notwendigkeit, Menschen für unser Berufsfeld zu gewinnen, wenn nicht sogar zu begeistern.

Deshalb nun der Versuch, für ein Thema ein intuitives Verständnis, ein Gefühl, eine Ahnung zu gewinnen. Keine Wissenschaft, keine Vollständigkeit, keine Rezepte, kein Projektbericht!

Was hat es also mit Service Reporting auf sich?

Leistungen der Informationstechnik werden schon seit Jahren unter dem Aspekt “Was nutzt es mir?” betrachtet. Die Zeiten, in denen alles, was mit Computern zusammenhängt einfach nur modern war und nicht weiter hinterfragt wurde, sind vorbei. Hin und wieder gelingt es natürlich der Industrie, einen Trend zu setzen, dem viele begeistert folgen und zweifelnde Fragen erst einmal beiseite schieben.

Auf die Begeisterung folgt dann zwangsläufig irgendwann die Normalität mit den Fragen: “Was nutzt es?”, “Warum kostet es so viel?”, “Brauchen wir das überhaupt?”. Wer also in der Informationstechnik Leistungen anbietet, wird über kurz oder lang vor der Frage stehen, wie er seine Leistungen darstellt. – Warum ist das schwierig?

Aus meiner Erfahrung am Schwierigsten ist der Perspektivenwechsel. Haben wir es nicht mit einem technikbegeisterten Kunden zu tun, hat er schlicht andere Interessen. Er will nicht wissen, welche tollen Probleme wir gelöst haben, sondern seinen Nutzen erkennen. Und dazu müssen wir lernen und verstehen, was unser Kunde unter Nutzen versteht, was er will und was er wertschätzt.

Ein Beispiel: Die Abhängigkeit des Unternehmens von der Technik wird nirgends mehr bezweifelt. Die Leistung der Technik soll nun daran gemessen werden, wie zuverlässig die technischen Systeme/Anwendungen sind, die wirklich kritisch für das Unternehmen sind, von denen das Unternehmen abhängt. Die Anforderung lautet also: Berichtet uns monatlich, wie zuverlässig eure Dienstleistungen/Systeme sind; wir wollen nur kritische Dienstleistungen sehen, von denen wir abhängig sind. Die Fragen, die sich nun aufdrängen, lauten: Definiere kritische Dienstleistung, definiere Zuverlässigkeit. Um zu erfahren, was wirklich kritisch ist, muss man lernen, wie das Unternehmen tickt, worauf es ankommt.

Nicht zu vergessen: Vielen Menschen ist mittlerweile nicht mehr bewusst, welche ihrer Tätigkeiten von Informationstechnik abhängen. Um zu lernen, was Zuverlässigkeit für meinen Kunden bedeutet, muss ich auch wissen, wann und in welchem Umfang er meine Leistungen in Anspruch nimmt.

Habe ich das alles geleistet und verstanden, geht es daran, eine Form zu finden, in der die Ergebnisse erstellt und aufbereitet werden. Wieder am Beispiel: Wenn ich letztens eine schwere Störung durchmachen musste, sollte ein Bericht nicht ‘Alles Sonnenschein’ ausweisen. Was heißt Zuverlässigkeit 99%? Ist das gut oder nicht? Deckt sich das mit meinem persönlichen Eindruck? Zahlen müssen immer interpretiert werden. Was bedeuten Veränderungen? Wie sieht die Zukunft aus? Gibt es einen Trend? Bei schlechten Nachrichten: Was unternehmen wir dagegen?

Nachdem nun ein Eindruck von der Aufgabe ‘Service Reporting’ entstanden ist: Was ist nun mein Anteil an diesem Thema?

Zunächst einmal stelle ich genau die eben gelesenen Fragen. Gemeinsam mit den Kollegen aus der Technik gehen wir den Perspektivenwechsel an, sprechen mit Kunden, ermitteln, was für Kunden wichtig ist. Auf viele Fragen gibt es keine optimalen Antworten, aber Erfahrungen, die weiter helfen. Diese Erfahrungen bringe ich ein. Schließlich und nicht zuletzt gehen wir das Thema an. Wir klären, wie wir mit vernünftigem Aufwand an aussagekräftige Zahlen gelangen, entwerfen Berichte, sind mit den Beteiligten im Gespräch darüber, ob das so passt und legen zu guter Letzt einen Bericht vor.