An der Internet Expo im Jahre 2001 hielt ich den Vortrag über Projekt Management bei Internet Projekten. Der Vortrag ist unverändert hochgeladen inkl. den “weltweiten” Namics-Standorten aus der betrunkenen Zeit (Internet Bubble.)

1. Top 10 Mistakes of
Internet Project Management
IEX 2001 | Seminar c-3 (Projekt Webseite)
Dienstag, 6. Februar 2001
Jürg Stuker
Frankfurt, Genf, Konstanz, Lausanne, Los Angeles, Milano, San Francisco, St.Gallen, Zug, Zürich
info@namics.com www.namics.com team–based net solutions

2. Agenda
» Einleitung
» Top 10 Mistakes
» Tipps für die Implementierung
» Anhang

3. Einleitung

4. Augenmerk auf die Systementwicklung
Strategie Analyse Konzeption Implemen- Roll-Out Betrieb Aus- Weiter-
tierung wertung entwicklung
Prozess-Organisation
Marketing
Management
Technik
„Endlich hacken ;-)“

5. Anwendungstypen
» Internet- resp. Webanwendungen werden
häufig noch mit „Webseiten“ verwechselt.
» Zahlreiche Webanwendungen sind heute
unternehmenskritisch.
» Teilweise Ablösung von hocheffizienten aber
proprietären SW-Clients mit Benutzungs-
schnittstellen in Webbrowser.
» Anforderungen bei der Projektumsetzung sind
je nach Anwendungstyp gigantisch anders.

6. Integrationstiefe
INFORMATION INTERAKTION TRANSAKTION INTEGRATION
Online-Marketing Kundenanfragen Geschäftsprozesse Backend-Daten
Produkt-Infos Support/Beratung Online-Bestellung Beschaffung
Service-Infos Kollaboration Online-Bezahlung Abwicklung

7. Anwendungstyp:
Statische Website
» Merkmale
– Statische Seiten (HTML,
JavaScript etc.) und
wenig serverseitige
Logik.
– Geringe Wartung,
sporadische
Weiterentwicklung.
– Information und evt.
Web-Server
Interaktion.
– Webmaster jongliert.
– Hosting irgendwo.

8. Anwendungstyp:
Dynamische Website (Webanwendung)
» Merkmale
– Teils statische teils dynamisch
erzeugte Webseiten.
– Bereiche werden online
gepflegt, koordinierte
Weiterentwicklung.
Firewall – Integration eines Content
Management Systems (CMS)
Load Balancer und/oder kleiner Anwendungen
(AWP).
Web-Server Web-Server – Unternehmensweit verankert.
Information, Interaktion und evt.
CMS / AWP CMS / AWP Transaktion.
– Hohe Verfügbarkeit und (evt.)
Sicherheit, leistungsfähiges
Hosting.

9. Anwendungstyp:
Dynamische Website (Webanwendung)
» Merkmale
Dispatcher
– Eigene und fremd erstellte
Seitenelemente werden
Partner dynamisch gemischt.
– Komplexe Weiterentwicklung
Cashing als Managementaufgabe,
Stdby Partnermanagement.
Country
Firewall / LB – Synchrone und asynchrone
Integration unterschiedlichster
Web-Server Bank Content Anwendungen.
– Hochgradig integriertes
Middleware / Application Bus Informationssystem.
CRM ERP PPS Pymt Pricing
– Verteiltes System mit höchster
Verfügbarkeit und
Skalierbarkeit, individuelles
Bank Marktpl. Hosting/Homing.

10. Webprojekte: Was ist speziell?
» Ist weder Printkampagne noch eine SAP
Implementation…
» Hohe Durchdringung und Auswirkung.
» Sehr häufig kurze Zeitpläne.
» Fast alle SW ist unreif (beta, beta, beta).
» Und…

11. Webprojekte:
Integration vom Kompetenzen
Consulting
Interdisziplinäre
Teams:
» Integration
unterschiedlichster
Kompetenzen und
Charakteren
» Andere Wertesystem
» Andere Sprache
» Andere nonverbale
Kommunikation
Technology Design

12. Top 10 Mistakes

13. Achtung!
» Wir befinden uns in der Implementierung und gehen
davon aus, die früheren Phasenresultate existieren in
guter Qualität;-)

14. Top 10 Mistakes (die ersten fünf)
» Das Budget ist nicht wichtig, wir brauchen die Site.
» Ein Zeitplan ist dank dem iterativen Vorgehen
überflüssig.
» Für die Zustimmung der Geschäftsleitung sorgen wir
uns intern im Rahmen unseres üblichen Reportings.
» Für die Spezifikation des Systems fragen Sie mich
einfach sobald die etwas brauchen; Ich bin kein Fan von
Dokumentationen.
» Inhalt haben wir mehr als genug -- auch in vier
Sprachen.

15. Top 10 Mistakes (der Rest)
» Seventh Party Syndrome.
» Den Inhalt und die Sitesuche haben wir mit der CMS-
Software TopQuarkFettPro im Griff.
» Wegen dem Termin haben wir noch ein paar
Programmierer dazugenommen.
» Ich will keine Usabilitytests durch Endbenutzer, die
nehmen uns und nur den Drive. Unser IT-Leiter testet
die Sache persönlich.
» Zum Glück gehen wir in zwei Wochen live, dann läuft
der Karren endlich und die Sache ist vorbei.

16. Budget
Ein definiertes Budget und dessen dauernde
Überwachung schaffen Vertrauen.
» Das Budget ist nicht das Sparschwein für die
Dienstleister aber ein wichtiges Planungs- und
Kontrollinstrument.
» Unterschiede zu anderen Projekten (z.B. Werbung oder
IT) erzeugen oft Misstrauen.
» Frühzeitige Zuordnung des Budgets zu Arbeitsschritten,
Ressourcen und Personen.
» Einigkeit über die Struktur der Rapportierung und dem
Modus der Verrechnung.

17. Budget: Aufwand-Verlauf Plan und Ist
Plan
Aufwand
Ist
Beginn
Umsetzung Testing
Review
Kick-off
Live- Zeit
Schaltung

18. Budget: Gute Toolunterstützung

19. Zeitplan
Der Zeitplan ist das zentrale Instrument zur
Projektkommunikation und -steuerung.
» Kein Projektvorgehen entbindet von der Erstellung eines
Zeitplans (Szenarien).
» Der Zeitplan dient vor allem auch der Ressourcen-
allokation und der Abstimmung mit externen Partnern.
» Er erlaubt die Konsistenzprüfung mit anderen
Planungsinstrumenten und gehört dauernd angepasst.
» Es gibt nie zu viele Meilensteine.

20. Zeitplan: Ein A4 Blatt für alle Beteiligten
Eindeutige
Tasks mit ID
Wer
Meilensteine:
Inkl. Builds etc.
Ferien

21. Zeitplan: Iterationen
1. B » Iteration erlaubt Durchspielen
R des „ganzen“ Ablaufs.
A
I » Eine Iteration dauert 4 bis 6
T Wochen.
2. B D
R » Am Ende wird über die Reife
A des Phasenproduktes
I entschieden.
T
3. B D
R
A
I
T
D

22. Unterstützung der Geschäftsleitung
Je umfassender ein Projekt ist, desto wichtiger
ist die dauernde Präsenz eines GL-Mitgliedes.
» Projekttyp ist meist neuartig und sehr IT-lastig.
» Kenntnisstand der GL ist sehr wichtig für die Qualität der
Entscheide.
» Ein Webprojekt hat häufig einen massiven Einfluss auf
bestehende Prozesse und Strukturen.
» Bestehende Richtlinien tragen den neuen Technologien
selten Rechung (z.B. Security, oder
Arbeitsplatzsoftware).

23. Spezifikation
Die Anforderungsdefinition der zentralen
Projektaspekte ist zwingend.
» Spezifikationsdokumente sind nicht Prosatext in dicken
Bundesordnern.
» Konsensfindung sowohl auf Kundenseite wie auch im
interdisziplinären Projektteam passiert weder per Zufall
noch mündlich.
» Webprojekte sind Weltmeister in dauernden marginalen
Änderungen.

24. Spezifikation: Design

25. Spezifikation: Consulting
Marktanteil erhöhen Kunden-
Durchgehendes Design Preis Neue Zielgruppen befragung
G estaltung/ Belohnung für Branchenführer
2-Sprachigkeit
O pass
berfläche Internetkauf
Internet-
Marktbearbeitung zu neuen
Zugang
Kunde hat auch S
Frischer Auftritt
Leader wie C
bei Banken
S im Internet Marktsegmenten
Internet-Adresse Nr. für den Kunden
Offerten Neukundenanmeldung
Beschleunigung
Auskunft Lieferzeit Auftragsbearbeitung
Kundenbindung Bestellsystem Unterstützung
Kundenbindung Innovatives Auftrags- von G eschäfts-
Image
Persönliche R
Beziehung zum
ückmeldung an
den Kunden
information
transaktionen
Unternehmen Prozessunterstützung
Bestell- Verfügbarkei
schaffen transparenz ts-abfragen
Nicht nur verkaufen, Wettbewerb Preisinfo
Schnell- auch beraten Link zu CD-ROM
service
Support 24h- Unterlagen
Nutzinhalt/
Flexiblere Lieferbedingungen hotline bestellen Interaktivität
Einkauftrends
Bestellzeiten
E-Mail-
Ansprechpartner Neue Produkte Sortiment Finanzauskunft
Vorstellung der
Fundgrube Infor über
Auskunfs- Effizienter Firma
Veranstaltungen
Dienst bestellen
wie Messen Diskussions-
forum
Kunden selbständig
untereinander
kommunizieren
lassen
Prozessübersicht Beispiel AG
08.08.2000
Draft V 0.8, E1B1
Einkauf Vertrieb Auftragserfassung
Kunde akquirieren
«system»
«system»
ERP-System
«department» CRM-System
Vertrieb Rahmenvertrag entwerfen
[nicht einverstanden]
«business process» Rahmenvertrag prüfen
Verkauf
[einverstanden]
«department»
Auftragserfassung «customer»
Einkauf
Rahmenvertrag unterzeichnen
«business process»
Herstellung
«department»
Produktion Bedarf ermitteln Beschaffung vorschlagen
«business process»
Auslieferung «customer»
Wareneingang
Lieferanten auswählen [nicht erfolgreich]
«department»
Logistik Artikelauswahl Auftrag akquirieren
«precondition»
{Bonität des Kunden muss bereits überprüft sein.}
[erfolgreich]
«third party»
Spediteur Auftrag erteilen
Auftrag entgegennehmen
Auftrag erfassen
«business process»
After Sales
Auftrag bestätigen
«department» «customer»
Kundendienst Anwender
Prozessablauf "Verkauf"
8.8.2000
Draft V0.1, E1B1
«system»
CRM-System

26. Spezifikation: Technology

27. Spezifikation: Arbeit mit Prototypen
Strategie, Vision und Grobkonzept Usablity
Richtlinien
Design UI and IT
Vorstudie
Navigation
IT
CI/CD HTML Proto 1
Prototyp
Usablity
Test
Konzeption
Design IT
HTML Proto 2
Iteration Prototyp
Usablity
Test
Review IT
HTML Proto 3
Design Prototyp
Implementation

28. Spezifikation: Pick two!
Kosten
Ziele/Qualität Zeit

29. Honey, I've Shrunk the Content
Mediengerechte Inhalte in guter Qualität sind
sehr aufwändig in der Erstellung.
» Leute die gute Text/Inhalte für online Medien verfassen
sind sehr selten.
» Häufig werden bestimmte Daten erstmals Kunden
gezeigt (Bsp. Auftragszusatztexte)
» Der Dienstleister (die Agentur) kann die Inhalte nicht
selbst verfassen ;-(
» Budget ist schon aufgebraucht.

30. Seventh Party Syndrome
Grosse IT-lastige Projekte brauchen viele Third
Parties – „Ich bin nicht schuld“
» Glasklar definierte Verantwortlichkeiten.
» Regelmässige und straff geführte Reviews.
» Sonst verbringen alle nur noch ihre Zeit damit, gut
Argumente dafür zu suchen, dass der andere Schuld ist.

31. Tools
„A fool with a tool is still a fool“.
» Weder die SW noch ein Werkzeug nimmt inhaltliche
Arbeit ab.
» Finden auf einer Site ist Sache der (guten) Struktur,
Sprache, Konsistenz und Design (und nicht Search
Engine).
» Ein CMS ermöglicht die verteilte Inhaltspflege, macht
aber weder Autoren noch Inhaltsverantwortliche
Arbeitslos.
» Etc.

32. Add (no) manpower
Das optimale Team hat so wenig Leute zu 100%
wie nur möglich.
» Geschwindigkeitsgewinn mit mehr Leuten setzt die
Teilbarkeit der Aufgabe voraus.
» Percentage Paradoxon: N Leute kommunizieren mit n-1
Leuten…
– 10 mal 30% ist nicht gleich 300%.
– Es macht keinen Sinn das gewünschte Projektteam in
20%-Commitment-Einheiten zusammenzukratzen.

33. QS/Testing
Qualität entsteht nicht durch Prüfung ist aber
das Resultat der Arbeitsweise alle Beteiligten.
» Qualität entsteht nicht bei der Q-Abteilung aber ist eine
Arbeitseinstellung.
» Häufige Reviews, Tests, Prüfungen v.a. aber auch
Arbeitsmethodik, Techniken u.s.w.
» Geplante Tests werden nicht wegen einer Verzögerung
im Zeitplan ausgelassen.
» Kein Projekt ist so geheim dass nicht (extern) getestet
werden kann.

34. QS/Testing: Min. drei Kaskaden
 Programmierumfeld
development  „Non Standard“
Publikation: Manuel
 Testumfeld, Inhaltserfassung
staging  „Identisch“ live
Versionierung Publikation: Automatisiert, wiederholbar
Rollback
 Produktionsumfeld
live  Skaliert, sicher, etc.

35. Endlich Live
Mit der Live-Schaltung des Webprojektes endet
das Projekt nicht; Es beginnt der Betrieb.
» Der Betrieb einer anspruchsvollen Webpräsenz kann
deutlich aufwändiger sein als dessen Bau.
» Keine exotischen I*Irgendwas-Abteilung aber integriert
die Unternehmensprozesse.
» Going Live
– Schulung und interne Information
– Unternehmenskommunikation (intern und extern)
– Webannouncement
– Nachzügler
– Feedbackprozesse

36. Tipps für die Implementierung

37. Immer mitnehmen ;-)
» Voraussetzungen schaffen (Wissen, Kultur, Budget,
Sponsoring).
» Klare und durch alle getragene Vision.
» Spezifikation.
» Eine „Buchhalter“ der Zeit und Ressourcen plant und
kontrolliert.
» Interdisziplinäre Teams mit wenig sehr guten Leuten
bilden.
» Kurze Iterationen für sämtliche Arbeitsprozesse.
» Standards einspielen (v.a. Integration und QS).

38. Anhang

39. Referenzen
» The Mythical Man-Month : Essays on Software
Engineering. Frederick P., Jr. Brooks.
» Collaborative Web Development: Strategies and Best
Practices for Web Teams. Jessica R. Burdman.
» Projektmanagement mit dem Rational Unified Process.
Gerhard Versteegen.
» Rapid Development: Taming Wild Software Schedules.
Steve C McConnell

40. Vielen Dank für Ihre Aufmerksamkeit
juerg.stuker@namics.com
Frankfurt, Genf, Konstanz, Lausanne, Los Angeles, Milano, San Francisco, St.Gallen, Zug, Zürich
info@namics.com www.namics.com team–based net solutions