März 2016

Auch Fortschritt braucht Rückblick!

Vier Navigationsregeln für den Projekterfolg mit ComConsult Structured Scrum

Einleitung ................................................................................................................................................................................. 2

1. Plan-Build-Run: Das ewige Prinzip .................................................................................................................... 3 »Früher war mehr Planung«: Wasserfall »Heute sind wir viel agiler«: Scrum »Das Beste zweier Welten«: ComConsult Structured Scrum »Wähle weise!«: Das Teufelsquadrat

2. Best Practice: Vier Navigationsregeln für den Projekterfolg .................................................................. 7 Navigationsregel I: Beratung Navigationsregel II: Architektur Navigationsregel III: Verantwortung Navigationsregel IV: Dokumentation

3. Projekterfolg: Mit Karte, Kompass und einer Handvoll Regeln ........................................................... 12

Unser Angebot ..................................................................................................................................................................... 13

Die Autoren ........................................................................................................................................................................... 14

Das Motto »Neue Besen kehren gut« ist generell

mit Vorsicht zu genießen – dies gilt auch bei

neuen Methodiken im Projektmanagement. Denn

gerade dann, wenn die neuen Besen bestimmte

Ecken sichtbar besser kehren als die alten,

besteht die Gefahr, dass mit den alten Besen

Bewährtes und Nützliches über Bord geworfen

wird:

Ewige Prinzipien als Parameter, die sich auch mit

der Einführung neuer Methodiken nicht geändert

haben oder ändern werden.

Erfahrung aus vielen Projekten über viele Jahre,

mit denen unsere Berater ein Kundenprojekt

bereits im Vorfeld präzise einschätzen können.

Vier Navigationsregeln als Best Practices, die das

Neue mit dem Bewährten für den bestmöglichen

Projektverlauf verbinden.

Unser Whitepaper beschreibt, auf welche Weise

wir die spezifischen Stärken alter und neuer Projekt­

methodiken für den Erfolg unserer Kunden

nutzen.

3 |Auch Fortschritt braucht Rückblick!

März 2016

1. Plan-Build-Run: Das ewige Prinzip

Auslöser für die Entwicklung dieses Whitepapers

war die konkrete Anfrage eines Großkunden nach

»einem Stück Configuration Management« als

Gewerk zum Festpreis. Die Frage nach einem Lasten­

heft wurde beantwortet mit dem Hinweis auf die

agile Entwicklungsmethodik »Scrum« und auf unsere

langjährige erfolgreiche Projekterfahrung. Da

wüssten wir ja schon, was gebraucht wird! Um das

Happy End vorwegzunehmen: auch dieses Projekt

wurde von uns erfolgreich abgeschlossen. Aber

nicht so, wie ursprünglich angefragt. Denn entlang

unserer Erfahrung aus mehr als 25 Jahren erfolg­

reicher Umsetzung großer Projekte haben sich »vier

Navigationsregeln« als Best Practices herauskris­

tallisiert, die wir in diesem Whitepaper illustrieren

möchten. Lassen Sie uns den Hintergrund dieser vier

Regeln durch die Zeit verfolgen: wie früher geplant

wurde, womit heute gesteuert wird, was davon

zukunftssicher ist und warum bestimmte Dinge sich

aus guten Gründen nie verändern werden.

»Früher war mehr Planung«: Wasserfall

Großprojekte stellten zu allen Zeiten ein ernst­

zunehmendes Risiko dar, und früher begegnete man

diesem Risiko mit der »Wasserfall«­Methodik. Diese

Methodik erforderte es, viel Zeit und Energie in

akribische Planung und Konzeptarbeit zu investieren,

in der die Anforderungen und Abnahmekriterien

vor Beginn der Implementierung genau festgelegt

wurden. Bevor ein Projekt in See stach, wurde jedes

Teil der Bordausrüstung sorgfältig ausgewählt, und

jedem Projektmitglied wurden klar definierte Aufgaben

zugewiesen und die genaue Rudertaktung vorgegeben.

Dies zog sich von Vorplanung, Grobkonzept und

Pflichtenheft zum Lastenheft über den Prototypen

und darüber hinaus immer weiter durch das

gesamte Konzept. Neben dem erheblichen Aufwand,

den diese Methode verursachte, hatte dies auch zur

Konsequenz, dass sichtbare Funktionalität erst spät

im Rahmen der Entwicklung geliefert wurde, wie die

nachfolgende Darstellung zeigt.

»Heute sind wir viel agiler«: Scrum

Abhilfe schaffen für die beiden Nachteile der Wasser ­

fall­Methode sollte die Umstellung auf die moderne

Projekt­ und Entwicklungsmethode Scrum: mit einer

drastischen Reduzierung der Zeiten und Aufwände

und einer erheblich früheren Sichtbarkeit von Funk­

tionalität. Aber auch Scrum hat seine Grenzen und

eignet sich daher nicht für jedes denkbare Projekt.

Scrum eignet sich hervorragend unter den folgenden

Projektbedingungen:

• Die Zielsetzung ist eher unklar und soll

iterativ verfestigt werden.

• Die Aufgabenstellung bleibt im unteren bis

mittleren Komplexitätsbereich.

• Die Anforderungen lassen sich einfach in

kleinere Bausteine zerlegen.

• Marketing oder Politik diktieren, dass Ergeb­

nisse schneller als üblich präsentiert werden

müssen.

Scrum ist dagegen weniger geeignet unter den

folgenden Projektbedingungen:

• Sehr große Projekte mit hohem Komplexitäts­

grad (bauen Sie mal einen Flughafen mit Scrum­

Methodik!).

• Enge formale Rahmenbedingungen, die agilen

Methoden widersprechen.

• Sehr geringer Entwicklungsanteil im Vergleich

zu Abstimmung & Konzeption.

Ein Auslöser der begründeten Begeisterung für die

Scrum­Methodik ist unserer Erfahrung nach die

Umstellung auf kleine, sehr kollaborativ und lösungs­

orientiert arbeitende Teams. Alle Crew­Mitglieder

reagieren in ihren Verantwortungsbereichen zügig

und flexibel auf Stromschnellen und halten das

Projekt auf Kurs und über Wasser, ohne entlang

länglicher Verantwortungsketten erst Befehle

vom Steuermann einholen zu müssen. Aus diesen

Gründen finden sich auch viele intrinsisch motivierte

Mitarbeiter, die selbstgesteuert »ihre Arbeit« zum

Erfolg führen. Diese Grundhaltung wird durch Scrum

gefördert, und viele Entwickler empfinden dies als

Befreiung im Vergleich zu klassischen, deutlich

formaleren Methodiken.

5 |Auch Fortschritt braucht Rückblick!

März 2016

Doch auch Scrum nutzt das »ewige Prinzip« des

Plan­Build­Run, allerdings aufgeteilt in »Sprints« als

eine Vielzahl kleinerer Zyklen. Auf diese Weise führt

Scrum auch sehr schnell zu sichtbarer Funktionalität.

Ein klarer Vorteil, der jedoch auch seine Schatten­

seite hat. Denn mit der deutlich früheren Sichtbarkeit

der Funktionalität kommt eine deutlich spätere

Sichtbarkeit der übergreifenden Anforderungen.

Dies sorgt im Projektverlauf auch für ein deutlich

raueres Fahrerlebnis als im Wasserfallmodell:

Entwicklungsteile müssen mehrfach verworfen

und neu geschrieben werden, wenn sich der volle

Umfang der übergreifenden Anforderungen erst zu

einem späten Zeitpunkt herauskristallisiert.

Unabhängig von der genutzten Projektmethodik

geht es in jedem Projekt darum, die eigentliche

Anforderung zu verstehen, richtig zu interpretieren,

zu spiegeln und gegebenenfalls gar nicht oder

auf eine andere Art zu lösen. Ein Fehler, der sich

häufig bei Scrum­Projekten findet, heißt »los­

programmieren«. Nach unserer Erfahrung müssen

20 % der ursprünglichen Anforderungen gar nicht

ausprogrammiert werden, wenn diese besprochen

und alternative Lösungsvorschläge erarbeitet

wurden – im Gesamtprojekt ebenso wie in den

Teilprojekten, z. B. vor jedem »Epic« als logischer

Bündelung von Storys.

»Das Beste zweier Welten«: ComConsult Structured Scrum

Das eingangs erwähnte Projekt wurde deshalb ein

Erfolg, weil wir den Kunden von einer vorgeschal­

teten Konzeptphase überzeugen konnten. In dieser

Phase wurde das Fachkonzept mit den wesentlichen

Anforderungen und Abgrenzungen erstellt.

Viele Anforderungen konnten in Diskussionen auf­

gehoben oder umgewandelt werden, ohne dass

Entwicklungszeit investiert wurde. Aufbauend auf

dieses Fachkonzept wurde das Gewerk in kürzester

Zeit und sehr zielführend mit Scrum­Methodik

implementiert. Kleinere Anpassungen ließen wir

reibungslos einfließen, aber der große Rahmen

wurde vorab abgestimmt.

ComConsult Structured Scrum ist unsere hybride

Lösung aus Bewährtem und Neuem, die beide Wel ten

mit den besten Eigenschaften aus beiden Projekt­

methodiken für eine gute Kundenlösung und eine

weitere ComConsult­Success­Story verbindet!

»Wähle weise!«: Das Teufelsquadrat

Methodendiskussionen sind eng verknüpft mit der

Idee, durch die Entscheidung für eine bestimmte

Methode oder einen Methodenwechsel Projekt­

laufzeiten zu verkürzen und Aufwände zu reduzieren.

Mit anderen Worten: alles soll »schneller« und

»günstiger« werden. Aber natürlich so, dass weder

Funktionsumfang noch Qualität darunter leiden!

Diese Vorstellungen treffen allerdings auf eine

Realität, in der bestimmte »ewige Prinzipien« für

Projekte gelten, die sich nicht durch einen Wechsel

der Methodik verändern oder verbessern lassen.

Plan­Build­Run ist ein solches Prinzip, aber auch

das Abhängigkeitsverhältnis der Projektparameter

Qualität, Leistungsumfang, Projektdauer und Preis,

das sich in Anlehnung an Harry Sneeds »Teufels­

quadrat« (1987) modellieren lässt.

Das Quadrat verhält sich wie ein Rahsegel. Wenn

Sie an einem Ende ziehen, hat dies Einwirkungen

auf den Kurs, aber die Gesamtfläche bleibt stets

konstant: die anderen Ecken folgen Ihrem Zug, ob

Sie wollen oder nicht. Es ist verständlich, warum

Einkäufer diese Zusammenhänge nur schwer

akzeptieren können. Die Wirklichkeit zeigt jedoch,

dass dieses theoretische Modell in der Projektpraxis

stets wirksam ist.

Unsere Berater von ComConsult zeichnet die

Fähigkeit aus, in kürzester Zeit, oft nur in ein oder

zwei Stunden, bei gegebenem Funktionsumfang

eine belastbare Größenordnung für die Dimensionen

Projektdauer und Preis einzuschätzen. Sogar

wir selbst sind immer wieder positiv überrascht,

wie unsere Schätzungen rückblickend nur in

einem Rahmen von +/­ 10 % von der Wirklichkeit

abweichen.

»Erfahrung hat man – oder man muss sie erst noch

machen«: Die beschriebene Fähigkeit unserer

Berater ist das Resultat von Erfahrung aus vielen

Projekten über viele Jahre. Und aus der Gesamt­

summe dieser Erfahrungen sind unsere Best

Practices entstanden, die wir Ihnen im Folgenden

vorstellen möchten als »Navigationsregeln für den

Projekterfolg«.

7 |Auch Fortschritt braucht Rückblick!

März 2016

2. Best Practice: Vier Navigationsregeln für den Projekterfolg

Navigationsregel I: Beratung

Was immer eine neue Projektmethodik leistet:

eine gute Beratung kann und wird sie nicht

ersetzen. Das gilt für Scrum ebenso wie für jede

andere Methodik.

Der Schwerpunkt von Scrum liegt, wie beschrieben,

auf der Verbesserung der Software-Entwicklungs-

prozesse. Beratung setzt aber weit früher an und

spart später viel Irritation, Aufwand und Ärger.

Demonstrieren lässt sich das an einem simplen

Beispiel. Die Story des Kunden lautet: »Ich will

eine Bohrmaschine. Damit will ich Löcher bohren

können.«

•Ein Entwickler baut entsprechend dieser Story

einen recht aufwendigen ein- und ausschalt-

baren Motor mit fest verschweißtem Bohrkopf.

Damit kann man Löcher bohren. Nach zehn

Löchern ist der Bohrer stumpf. Über auswechsel -

bare Bohrer stand nichts in der Story. Daher

gibt es bald einen ChangeRequest für die

Erweiterung »Wechselbohrer«.

•Ein Berater von ComConsult fragt als erstes,

wofür die Löcher überhaupt benötigt werden.

Es stellt sich heraus, dass Haken in die Wand

geschraubt werden sollen; hierfür benötigt man

Dübellöcher. Als nächstes fragt unser Berater,

wofür die Haken denn benötigt werden. Die

Antwort darauf lautet, dass es eine Vielzahl von

Mitarbeitern gibt, die ihre Jacken aufhängen

müssen.UnserBeraterempfiehltdaraufhin:

»Links hinter der Tür ist im Standard eine

Garderobe enthalten, die vom Hersteller

laufend erweitert wird. Erfüllt das Ihre Anfor-

derung?« Natürlich erfüllt es die Anforderung,

und der Kunde ist zufrieden. Es war eine

Möglichkeit, von der er gar nichts wusste.

Der Unterschied liegt darin, dass im ersten Fall

Probleme gelöst werden, unter Umständen sogar

brillant und schnell, die im zweiten Fall gar nicht

erst entstehen – ein präzise mit Karte und Kompass

geplanter Projektkurs benötigt weder rasante

Wende- noch spektakuläre Rettungsmanöver.

Ohne Beratung leiden viele Projekte im Umfeld

von ServiceNow unter unpräzisen Storys, deren

Interpretationsspielraum oft so weit gesteckt ist,

dass die verunsicherten Entwickler alles Mögliche

produzieren. Dies wiederum führt uns zur zweiten

Navigationsregel: Architektur.

»Mit ComConsult Structured Scrum spart der Kunde in der Beratungsphase bereits 20 % des Entwicklungs­aufwands durch präzise Analyse der Anforderungen.«

Navigationsregel II: Architektur

ComConsult macht kein »klassisches« Scrum – aus

gutem Grund.

Denn im Enterprise­Umfeld muss eine zentrale

Stelle übergreifende Entscheidungen durchdenken,

bewerten und langfristige Vorgaben für die

Projekt entwicklung machen. Diese zentrale Stelle

ist das Architekturboard.

Im Architekturboard werden Erfahrungen gebün­

delt und gemeinsam die Vorgaben je Epic oder

sogar Story erarbeitet. Gibt es noch keine Ent­

wicklungsrichtlinien, werden diese hier festgelegt.

Häufig sind der Scrum­Master und der Gesamtprojekt­

leiter Mitglied oder Berater des Architekturboards,

um den Gesamtüberblick zu behalten.

In großen Projekten hat es sich bewährt, auch

den Hersteller punktuell ins Projekt einzubinden.

ServiceNow bietet »Configuration Reviews« als

Dienstleistungspaket­Paket an. Spätestens zum

Projektabschluss sollte es den offiziellen Stempel

des Herstellers mit dem »Production Readiness

Service« geben, um vor dem Produktionsstart das

Sicherheitsgefühl zu optimieren.

Dies wiederum führt uns zur dritten Navigationsregel:

Verantwortung.

»Mit ComConsult Structured Scrum spart der Kunde in der Umsetzungsphase weitere 10 % des Entwicklungsaufwands durch Entwicklungs- und Verfahrensstandards: dank ›Lessons Learned‹-Kommunikation und Transparenz führt der Kurs nie im Kreis, sondern immer geradeaus.«

9 |Auch Fortschritt braucht Rückblick!

März 2016

Navigationsregel III: Verantwortung

Große Projekte entwickeln häufig businesskritische

Anwendungen. Damit werden Funktionsfähigkeit,

Verfügbarkeit und Performanz der Plattform zu

extrem wichtigen Faktoren für das Unternehmen.

Aber wer stellt sich auf die Kommandobrücke und

übernimmt die Verantwortung, wenn sich Probleme

einstellen?

Wenn alles gut läuft, fragt zunächst niemand nach

Verantwortungsgrenzen. Bei Problemen oder bei

Release­ oder Technologiewechseln jedoch sind

Nachfragen nicht selten.

Zunächst gibt es die drei Grundperspektiven von

Hersteller, Kunde und Entwickler, die auf den

ersten Blick zweckmäßig und ausreichend erscheinen:

• Der Hersteller betreibt im Umfeld SaaS die

technische Plattform (Server, Datenbank

usw.) und stellt die Basis­Software mit Kon­

figurations­ und Customizing­Optionen zur

Verfügung. Für Probleme außerhalb seiner

Zuständigkeit trägt er keine Verantwortung.

• Der Kunde nutzt die Plattform und beauftragt

interne oder externe Entwickler/Projektierer

mit der Konfiguration und dem Customizing

der Basis­Software einschließlich Entwick­ lungsrichtlinien. Er trägt die Verantwortung für

die performante und sichere Anbindung an die

Plattform.

• Die Entwickler nutzen Best Practices des

Herstellers, verwenden gängige Lösungen der

Community und halten sich an die Entwick­

lungsrichtlinien des Kunden.

So weit ist dies sicher für jeden verständlich. Was

aber, wenn zum Beispiel die folgenden Fragen auf­

geworfen werden:

• Wer garantiert den reibungslosen Release­

wechsel?

• Wer ist im Rahmen normaler Innovationszyklen

mit Technologiewechsel beim Hersteller

(z. B. AngularJS) für die Umstellung der Ent­

wicklungen im Kundenumfeld zuständig?

• Wer pflegt den »Baukasten« der Plattform im

Umfeld des Kunden?

Externer Prüfer Revision

Gesetze KonfigurationCustomizing

gut | böse

Freelancer

inhouseremote

nearshore offshore

Entwicklung

interne Entwickler

Hersteller

Kunde Dienstleister

Kunden des Kunden

SaaS-Plattform

Ver

trag

Ver

trag

Vertrag

Wohl dem, der einen hohen Erfahrungsschatz im

Architekturboard gebündelt hat, damit »Böses Cus­

tomizing« frühzeitig erkannt und verhindert oder,

wenn es »nicht anders geht«, auf eine Ausnahmen­

liste gesetzt werden kann. Hilfreich sind in diesem

Zusammenhang automatische Validierungen, über­

greifende Konsistenzregeln und individuelle Güte­/

Compliance­Reports, um den aktuellen Zustand

der Lösung überwiegend automatisiert ermitteln zu

können.

Wurden im Problemfall der verursachende Code

oder die Objekte identifiziert, bleibt immer

noch herauszufinden, welche Auswirkungen

eine Änderung oder Deaktivierung haben kann.

Hilfreich wäre auch zu wissen, warum dieser Code

oder diese Objekte damals so entwickelt worden

sind … was uns schließlich zur vierten Navigations­

regel führt: Dokumentation.

Navigationsregel IV: Dokumentation

Im Zentrum dieser vierten und letzten Navigations­

regel steht ein berühmter Imperativ: »Wehret den

Anfängen!«

Kaum etwas ist so wichtig wie eine zielführende Ent­

wickler­Dokumentation, und kaum etwas ist bei

Entwicklern so verhasst wie zusätzlicher Dokumen­

tationsaufwand. Rationalisiert werden die häufig

empörten Einwände bei Anforderungen nach zusätz­

licher Dokumentation mit Argumenten wie »Der

Code ist doch selbsterklärend!« oder »Jeder sieht

doch in ServiceNow, wer das wann ent wickelt hat!«.

Ohne zusätzliche Dokumentation lassen sich aber

Fragen wie diese gar nicht beantworten:

• Im Kontext welcher Anforderungen wurde

dieser Code so entwickelt?

• Warum wurde dieser Code angepasst?

• Wo wird dieser Code überall genutzt und

welche weiteren Auswirkungen kann er haben?

Für die mittel­ und langfristige Tragfähigkeit der

Gesamtlösung liefert zusätzliche Dokumentation

ohne Medienbruch einen unschätzbaren Nutzen –

bei gleichzeitig geringem Mehraufwand für den

einzelnen Entwickler.

Hinsichtlich der besten Lösung für eine zielführende

Dokumentation ist die Antwort tatsächlich eine

Frage nach der Methodik!

ServiceNow unterstützt vorwiegend den Entwick­

lungsprozess (Modul SDLC). Dies kann über das

PPS­Modul (Project and Portfolio Suite) erweitert

11 |Auch Fortschritt braucht Rückblick!

März 2016

werden, dann kommt Demand Management

und ein einfaches Test Management. Dies wird

noch wenig genutzt und ist häufig zu flach. Die

ComConsult Structured Scrum­Methode liefert

sofort die Erweiterung der Entwicklungsmethodik

mit der Dokumentation von Konzept und Anforde­

rung bis zum entwickelten Objekt und zugehörigem

Testfall.

Die nebenstehende Darstellung zeigt die bei

ComConsult Structured Scrum gebräuchliche

Struktur im Umfeld ServiceNow:

Mit dieser Methode wird eine Nachvollziehbarkeit

erzielt, die auch von den Entwicklern selbst gerne

und häufig genutzt wird.

• sie ermöglicht eine viel schnellere Analyse der

möglichen Auswirkung einer Anpassung bei

zukünftigen Erweiterungen;

• sie ermöglicht eine viel schnellere Analyse im

Fehlerfall.

Die ist besonders wichtig beim Multiprojekt­

management (viele Steuermänner) und in

Entwicklungsteilen, die für Querschnittsfunktionen

zuständig sind und damit gemeinsam genutzt

werden (ein Kombüseneinerlei für alle, das leicht

zur Meuterei führt).

»Die entlang von ComConsult Structured Scrum erstellte medienbruchfreie Doku-mentation ermöglicht eine 30 % schnellere Analyse im Fehler- oder Anpassungsfall.«

Entwicklung

Einfache und schnelle Dokumentation ohne Medienbruch auf Objektebene

Qualitätskontrolle

Compliance Report zur automatisierten Überprü-fung der Dokumentation

Tests

Revisionssichere Durchgängigkeit von des Testfällen bis hin zu den einzelnen Objekten

M N

N

N

N

1

1 1

1

1

Kapitel Story

Entwickelte Objekte

Epic Testfall

Documentation Task

Spezifikationen SDLC QS-Dokumentation

3. Projekterfolg: Mit Karte, Kompass und einer Handvoll Regeln

Marktveränderung erfordert auch Methoden-veränderung.

ComConsult ist ein modernes Unternehmen,

das seine Methoden immer wieder auf den

Prüfstand stellt und anpasst, wenn es zum Projekt­

ziel beiträgt.

Aber auch neue Methoden müssen sich »ewigen Gesetzen« beugen.

Parameter wie Plan­Build­Run und das »Teufels­

quadrat« werden auch in Zukunft Gültigkeit

behalten.

Auf bewährte Verfahren sollte nicht vollständig verzichtet werden.

Beratung, Architektur, Verantwortung und

Dokumentation als Best Practices finden auch in

neuen Projektmethodiken ihren Platz.

Auch und vor allem für entwicklungsintensive Projekte gilt: »Erst denken, dann handeln!«

Mit diesen Leitgedanken und der Kombination

aus Neuem und Bewährten sichern wir für unsere

Kunden seit über 25 Jahren den Projekterfolg.

13 |Auch Fortschritt braucht Rückblick!

März 2016

Unser Angebot

Gerne unterstützen wir Sie bei der IST­Aufnahme,

der Analyse und der Empfehlung von Handlungs­

alternativen vor dem Hintergrund Ihres individuellen

Umfeldes.

Für jede unserer Leistungen bieten wir Ihnen das

gesamte Servicespektrum moderner IT­Projekte:

• Analyse, Zieldefinition, Konzeption,

Produktauswahl

• Customizing, Individualisierung,

Implemen tierung

• Prozessmigration, Inbetriebnahme,

Dokumentation

• Projektmanagement, Projektmarketing,

Reviews

• Produktschulung, Pflege, 24/7 Hotline, Support

Viele unserer Senior Berater und Beraterinnen

sind bereits mehr als zehn Jahre mit an Bord:

Geringe Mitarbeiterfluktuation, die Nutzung des

guten Ausbildungs­ und Arbeitsmarktniveaus

am Wissenschaftsstandort Aachen sowie eigene

Ausbildungsinitiativen und interne Schulungen

garantieren Ihnen Projektierungsteams auf

höchstem fachlichen Niveau.

Ist Ihr Interesse geweckt? Sprechen Sie uns an!

Wir freuen uns auf ein persönliches Gespräch.

Die Autoren

Roger Jakobs

Dr.­Ing. Roger Jakobs ist einer der Strategieberater

der ComConsult Kommunikationstechnik GmbH.

Als gelernter »Raketendoktor« (Promotion in Luft­

und Raumfahrttechnik) fühlt er sich im komplexen

Mehrprodukte­Umfeld bei Großkunden wie

zuhause.

Er sammelte Erfahrung als Ausbilder, Systemberater

und Projektleiter von internationalen Rollouts bei

Großunternehmen. Nach

mehrjähriger Tätigkeit als

IT­Leiter und im höheren

Management unterstützt er

seit 2002 das Projekt­ und

Beratungsportfolio der

ComConsult.

Martin Woyke

Dipl. Kfm. Martin Woyke ist einer der beiden

Geschäftsführer der ComConsult

Kommunikationstechnik GmbH.

Seit der Gründung des Unternehmens 1986

wird er als anerkannter Strategieberater auf

Geschäftsleitungsebene geschätzt.

© Copyright by:

ComConsult Kommunikationstechnik GmbH

Pascalstr. 25

52076 Aachen

Germany

Tel. +49 (0) 2408 149 01

ComConsult Kommunikationstechnik AG

Stapfenstraße 5

3098 Köniz

Switzerland

Tel. +41 (0) 3139 801 41

solutions@comconsult.de

www.comconsult.de