Ohne viel Aufsehens hat Google einen neuen Dienst online geschaltet. Das Google Translator Toolkit. Das Toolkit verbessert die Übersetzung von Dokumenten. Zwar kommt die selbe Technologie wie bei Google Translate zum Einsatz, doch im Gegensatz zu Translate lassen sich die Übersetzungen einfacher überarbeiten und sogar exportieren.

Beim Google Translator Tool lassen sich Dateien der Formate HTML (.html), Microsoft Word (.doc), OpenDocument Text (.odt), Plain Text (.txt) und Rich Text (.rtf) hochladen. Jede Datei darf maximal ein MB groß sein. Vor dem Upload wählt man noch, in welche Sprache man es übersetzen möchte, wo die Datei gespeichert werden soll und ob für bestimmte Wörter ein Glossar verwendet werden soll. Aber auch Webseiten, Wikipedia Artikel und Knols lassen sich über die URL importieren.
Das Dokument oder die URL wird dann in der sogenannten „Workbench“ geöffnet.

In den Optionen kann man festlegen, ob Google Translator Toolkit gleich eine maschinelle Übersetzung machen soll oder ob auch der Originaltext auf der rechten Seite erscheinen soll. Egal was man macht, bei beiden lässt sich der Text auf der rechten Seite bearbeiten. Sehr nützlich ist es, dass Google den Text in einzelne Abschnitte gliedert und immer nur einer dieser Abschnitte angezeigt wird, wenn man etwas bearbeitet. Links wird der Abschnitt dann gelb hinterlegt. Gleichzeitig kann man die Übersetzung für andere Benutzer freigeben, so dass mehrere Leute daran arbeiten können. Diese Einstellungen und alle Dokumente, die noch in Bearbeitung sind, werden dabei in Google Docs manier angezeigt und verwaltet.

Bei Wikipedia und Knol lassen sich die Übersetzungen dann über das Share-Menü auch gleich auf der jeweiligen Seite veröffentlichen.

Schon lange wollte ich wiedereinmal einen Blogpost schreiben, der sich um die eigentliche Zusammenarbeit dreht. Wie ich in einem früheren Blogpost bereits erwähnt habe, arbeite ich zurzeit bei einem Kunden, der nach dem Agile-Framework Prinzip Software entwickelt. Ich persönlich finde dieses Agile-Framework sehr interessant. So interessant, dass ich es euch (für diejenigen, die es noch nicht kennen) gerne vorstellen  und meine Gedanken dazu schreiben möchte.

Im Grunde genommen ist das Agile-Software Development Framework nichts anders als eine schlaue Art, Teams, Personen und deren Aufgaben zu organisieren. Es beinhaltet Elemente aus dem Projektmanagement, Team-Führung, Aufgabenmanagement und Psychologie. Agile verbindet diese Elemente zu einem Paket, welches die Ausführung und die Übersicht von komplexen Aufgaben stark vereinfacht.

Agile development process

Eines der grossen Vorteile von Agile ist, dass man dieses Framework völlig auf die eigenen Arbeitsgewohnheiten anpassen kann. Es ist unmöglich, Agile falsch anzuwenden. Man entscheidet wohl eher, wie oft und wie intensiv man die Agile Methodik anwenden will.
Es gibt vielleicht Methoden in Agile, die nicht auf Ihre Unternehmensphilosophie oder Arbeitsweise passen. So what? Man lässt sie einfach weg oder passt die Methoden an. Ein Beispiel: es gibt eine Methode um die Komplexität von Aufgaben zu bestimmen, die sich “Estimation poker” (Engl. Schätzungs-Poker) nennt. Estimation Poker ist eine spielerische Art, ein mehr oder weniger langweiliger Prozess interessant und spannend zu machen. Wie Estimation Poker funktioniert, werde ich unten noch erklären. Estimation Poker mag vielleicht nicht allen passen. Dann macht man die Schätzungen der Aufgaben einfach anders.

Elemente des Agile Framework

Epic: Epics sind längere, komplexe Aufgaben. Epics können kleine Projekte, Subprojekte oder Aufgaben sein, die mehrere Wochen benötigen um fertig gestellt zu werden. Zum Beispiel die Erstellung einer komplexen MOSS 2007 Farm-Architektur könnte man in die Kategorie Epic werfen.

User Stories: Innerhalb von Epics werden User Stories definiert. Diese User Stories sind gruppierte Aufgaben, die im Bezug zueinander stehen. In der Regel wird die Komplexität von User Stories bewertet. Man einigt sich auf eine Skala von Werten (meistens die Fibonacci Zahlenreihe) um der Komplexität einer Story eine Gewichtung zu geben. Die Komplexität (Story points) aller Userstories innerhalb eines Epics werden summiert und somit wird die Gesamtkomplexität des Epics ausgerechnet.
Die Evaluation einer neuen SSO Technologie kann man als User Story bezeichnen.

Tasks: User Stories werden in einzelne genau definierte Tasks (Aufgaben) unterteilt. Jede Aufgabe muss so klar definiert sein, dass einzelne Aufgaben innerhalb des Teams weitergegeben werden können. Für jede Aufgabe wird der Aufwand in Stunden geschätzt. Die Summe der Stunden aller Tasks ergeben die Anzahl Stunden für die User Story. Die Summe der Stunden aller User Stories ergibt die Anzahl Stunden eines Epics. Beispiel für einen Task: Die Dokumentation einer Applikation oder Teile der Applikation.

Scrum:  Scrumming ist wohl die Essenz des Agile-Frameworks. In den Scrums (deutsch: Gedränge) treffen sich Teammitglieder, Teams oder sogar das ganze Unternehmen für Planung, Kommunikation, Retrospectives (deutsch: Rückblicke), Zeitrapportierung, usw. Der Hauptunterschied zwischen Scrums und konventionellen Meetings besteht darin, dass der Informationsfluss viel strukturierter abläuft als in „normalen“ Meetings. Bei jeder Art von Scrum ist genau definiert, was der Informations-Input ist und was dabei heraus schauen soll. Im Scrum dreht sich grundsätzlich alles um den „Sprint“. In einem Daily Scrum werden täglich Informationen zum laufenden Sprint ausgetauscht. Man kann sogar so weit gehen, dass man stündlich Micro-Scrums abhält um hochkomplexe Aufgaben im Team zu bewältigen.

Sprint: Das Agile Gegenstück zum Scrum ist der Sprint. In einem Sprint geschieht die eigentliche Magie . Sprints sind zeitlich begrenzte Arbeitsphasen. In Sprints werden die geplanten Aufgaben erledigt. Teammittglieder suchen sich eine passende User Story für den Sprint aus und arbeiten die dazu gehörigen Aufgaben ab. Daily Scrums sind dazu da, den Fortschritt der Arbeit an den User Stories zu rapportieren oder an andere Teammitglieder weiterzugeben.

Burndown chart: Für jede Aufgabe wird der Aufwand in Anzahl Stunden geschätzt. Während des Sprints rapportiert die Person die verbrauchten Stunden für den Task. In einem Burndown Chart werden die geschätzten und effektiv verbrauchten Stunden für eine Aufgabe gegenüber gestellt. Anhand des Burndown-Charts kann man die Aufgabenerledigungs-Geschwindigkeit (Velocity) des ganzen Teams ablesen.

Sample burndown chart

Retrospective: Ist ein Sprint zu Ende, wird ein Retrospective-Meeting einberufen. In diesem Meeting hat man die Möglichkeit, Positives oder Negatives über den vergangenen Sprint auf den Tisch zu bringen und zu gewichten. Normalerweise laufen Retrospectives so ab: Jedes Teammitglied überlegt sich für „Stop doing“, „Keep on doing“ und „Start doing“ Items aus. Diese Items werden gesammelt und dann gewichtet. Normalerweise bekommt man pro Kategorie drei Stimmen. Für jene „Stop doing“ Items, welche nur eine Stimme kriegen werden Verbesserungs-Massnahmen diskutiert. Ergebnisse von Retrospectives werden immer an das Mittlere oder sogar höhere Kader kommuniziert.

Backlog: Eine Liste von User Stories sortiert nach Priorität und kategorisiert nach Projekt oder Projekt-Team. Im Backlog werden alle anfallenden Arbeiten für das Aktuelle Projekt (oder was auch immer) gesammelt und verwaltet. Jedes Entwickler Team, jede Abteilung und sogar das ganze Unternehmen hat seinen eigenen Backlog.

Estimation poker: Dies ist eine tolle Methode, eine trockene und eher mühselige Aufgabe in eine spannende und produktive Sitzung zu verwandeln. Es geht darum, im Team die Komplexität von User Stories zu bestimmen. Man nimmt eine User Story vom Backlog und diskutiert die Story im Team, bis alle ein gemeinsames Verständnis der Story haben. Danach denkt sich jedes Mitglied im Kopf eine Zahl aus, die seines Ermessens der Komplexität der User Story entspricht. Auf ein Zeichen hin zeigt jedes Teammitglied mittels Estimation Poker Karten oder Post-It Zettel die Zahl, die für die User Story angedacht wurde. Jene Zahl, die überwiegend erscheint, wird als Komplexität für die User Story angenommen. Weichen die Estimations zu sehr voneinander ab, kann man davon ausgehen, dass die User Story nicht ganz einheitlich verstanden wurde.

Sprint Demo: Für jeden Sprint werden Sprint-Ziele definiert. Die Arbeit, um diese Ziele zu erreichen, werden jeweils nach einem Sprint während einer Demo-Sitzung anderen Teams demonstriert. In diesen Demositzungen haben Teams aus anderen Abteilungen die Möglichkeit, in die Arbeit anderer Teams einzusehen und zu kommentieren und ggf. Synergien zu erzeugen. Sprint Demos sind in der Regel für alle Mitarbeiter des Unternehmens offen. Es empfiehlt sich jedoch, die Sprint Demo Sitzung in eine allgemeine und technische Demo aufzuspalten.

Scrum Wall: Die Scrum-Wall ist das Herzstück eines jeden Teams, welches mit dem Agile-Framework arbeitet. Die Scrum-Wall konsolidiert alle wichtigsten Informationen für den aktiven Sprint. Dank der Scrum Wall behalten alle mitglieder des Teams die Übersicht über die Laufenden, anstehenden und erledigten Aufgaben.

Sample scrum wall

Scrum Master: Der Scrum Master erledigt neben seinen Sprint-Aufgaben administrative Aufgaben um die Informationen vor, während und nach einem Sprint in die richtigen Kanäle fliessen zu lassen. Der Scrum Master koordiniert die Tasks, Scrums und Reporting der verbrauchten Stunden.

Product Owner: Der Product Owner ist mit anderen Worten der Kunde des Agile-Teams. Der Product Owner erstellt und priorisiert die User Stories und gibt dem Team vor, welche Aufgaben zu erledigen sind und warum.

Somit habe ich euch die wichtigsten Begriffe des Agile-Frameworks etwas näher gebracht. Wie oben schon erwähnt steht es jedem Team frei, auch nur wenige Elemente des Agile anzuwenden oder es auch völlig ganz wegzulassen. Jedoch gibt es heutzutage schon viele Software-Entwicklungs Unternehmen, die dieses Zusammenarbeits-Framework verwenden.
Man kann dieses Framework auch auf ganz andere Arbeiten anwenden. Wir haben dieses Framework sogar schon benutzt um ein komplexes Konzept zu schreiben. Stündlich haben wir ein Scrumming gemacht, weitere Aufgaben verteilt und die Arbeiten rapportiert.
Mit dieser Methode haben wir innerhalb eines Tages in einem Dreierteam ortsunabhänig ein sehr kompliziertes und umfangreiches Konzept geschrieben. Dies hat wunderbar geklappt und hat uns viel Zeit eingespart.

Falls ihr mehr über Agile und Scrum erfahren möchtet: Trainings, Ressourcen, Artikel und Zertifikate für Agile und Scrum findet man hier.

Auf jeden Fall: ich persönlich bin ein Fan dieses Frameworks, weil die Regeln einfach zu verstehen und anzupassen sind und man trotz den Regeln selbstständig und flexibel arbeiten kann.

Zurzeit arbeite ich bei einem Kunden in Helsinki, der ein sehr interessantes Tool einsetzt, um intern Informationen auszutauschen. Die Rede hierbei ist von Atlassians Confluence Enterprise Wiki. Der Kunde ist eine Internet-Entwicklungsfirma welche Software auf Javabasis programmiert und die Agile Softwareentwicklungsmethodik anwendet.

Diese Art von Entwicklungsmethodik erfordert eine intensive und transparente Kommunikation unter den Entwicklerteams. Häufig sind die Software-Entwickler so mit Entwicklungsaufgaben beschäftigt, dass sie auf eine transparente und vollständige Dokumentation der Systeme und Applikationen angewiesen sind. Hierfür eignet sich ein Wiki-System perfekt. Die Benutzer können einfach und rasch Wiki-Seiten erstellen, verändern und kommentieren.

Confluence Enterprise Wiki, ist nicht nur ein einfaches Wikisystem. Diverse kostenlose Plugins (z.B. Social Bookmarking, Tagclouds, etc.) helfen dabei, die Standardinstallation mit intelligenten Features zu erweitern und den Anforderungen an das Informations-Management System anzupassen. Hier eine Übersicht der Features von Confluence.

Bei der Arbeit mit Confluence sind mir – trotz den vielen Vorteilen – auch einige “Unschönheiten” aufgefallen:
- Confluence eignet sich nicht, Files effizient auszutauschen. Es können zwar Attachments an Wikiseiten gehängt werden. Jene Attachments können dann (etwas umständlich) über ein Makro in einer Liste angezeigt werden. Um  trotzdem elegant Files auszutauschen gibt es die Möglichkeit, eine SharePoint Document Library mit Confluence über einen Connector zu verbinden. Hierbei können alle Vorteile von SharePoint in Confluence genutzt werden und vice versa.

Alternativ dazu gibt es ein Office Connector Plugin, welches die direkte Einbindung von MS Office Dokumenten in Wikiseiten erlaubt. Open Office wird zur Zeit meines Wissens nicht unterstützt.

- Ist keine Wiki-Struktur vorgegeben, kann die Wiki-Site extrem chaotisch werden. Hierbei ist es wichtig, dass sich die Benutzer dazu bereit erklären, vorgängig eine Wiki-Struktur zu definieren und das Wiki-System aktiv zu pflegen. Wird dies regelmässig durchgeführt, finden sich die Benutzer schneller im Wiki-System zurecht und die Akzeptanz des Systems steigt.

- Es gibt standardmässig eine Suche in Confluence. Diese funktioniert auch relativ gut. Jedoch kann man nur im gesamten Confluence-System nach Informationen suchen. Es gibt nur begrenzte Möglichkeiten, die Standardsuche anzupassen (wie wir das z.B. von den Search Scopes in SharePoint gewohnt sind). Es gibt jedoch ein Advanced Search Plugin, welches die Suchfunktion immerhin um ein paar nützliche Features erweitert.

Wie schon erwähnt eignet sich Confluence bestens dazu, schnell und einfach eine grosse Menge von unstrukturierten Informationen zu verteilen. Um jedoch ein voll integratives Informationsmanagement-System im Unternehmen aufzubauen, reicht wohl Confluence  allein  nicht ganz aus, kann aber dabei ein wichtiger Teil einnehmen.

Google stellt seit kurzem eine browserunabhängige Voice- und Videochaterweiterung zur Verfügung. Dafür ist ein PlugIn nötig. Google bietet dieses PlugIn ganz diskret an: Wählt man in der bestehenden Chat-Funktion bei einem Kontakt das Menü “Mehr” aus, wird einem das PlugIn angeboten. Nach der Installation des exe-Files steht die neue Funktion in jedem Browser zur Verfügung. Jussi und ich haben erfolgreich mit dem IE7, Firefox3 und Chrome gechatet.

Damit erweitert Google seine Collaboration-Palette um ein weiteres Puzzle-Teilchen. Alles sieht danach aus, dass Google irgendwann sein Gesamtwerk fertig hat. Bis jetzt aber kann Google noch nicht mit den wirklich ausgereiften Collaboration-Produkten mithalten; zu zerstückelt kommt das alles noch daher. Wir sind gespannt, wie sich die Goolge-Collaboration-Plattform weiter entwickelt.

People Search wird immer wichtiger. Diverse Projekte kamen in letzter Zeit auf uns zu, bei denen dieses Thema ein wichtiger Baustein der gesamten Suchstrategie ist. Nun, People Search ist mehr als nur Mitarbeiter zu finden. Ansonsten könnte man auch das Globale Adressbuch benutzen. Aber für was wird People Search wirklich gebraucht. Diese Frage ist in jedem Unternehmen verschieden. Um das herauszufinden haben wir uns hier einen Fragekatalog zurechtgelegt, der diese Fragen beantworten und ein klareres Bild geben soll. Aus dieser Analyse heraus lassen sich dann die Einflüsse auf die Topologie, das Design und die neuen „managed properties“ des Portales bestimmen.

In welchen Zusammenhang suchen Sie heute nach Mitarbeitern?
Bei dieser Frage geht es nur darum zu verstehen, wie das Unternehmen innerhalb der Wertschöpfungskette auf das Suchen und vor allem Finden von Personen angewiesen ist. Es ist wichtig, den Zusammenhang zu verstehen zwischen Menschen und Knowhow. Man sollte aber auch nach der sozialen Komponente fragen. Etwa, wie kommt man zu Informationen; mehr in der Kaffepause (informell) oder mehr im E-Mail vom Chef (formell). Dies hat einen Einfluss auf den generellen Einsatz von Social Media im Unternehmen und gibt der Diskussion darüber die nötige Grundlage. Man sollte es in dieser Phase vermeiden, eine Demo über SharePoint People Search zu geben. Diese engt zu diesem Zeitpunkt nur die Gedanken ein. Besser ist es, ein Beispiel aus dem Internet zu nehmen, wie etwa Facebook. Solche Plattformen konzentrieren sich fast ausschliesslich auf das vernetzten und auffinden von Personen. Wenn man solche Plattformen als Einstieg für die Diskussion verwendet, öffnet dies meistens die Diskussionsrunde, da die Benutzervertreter verstehen um was es geht und das „the sky ist he limit“ angesagt ist.

Welche Gruppen innerhalb der Firma könnten People Search brauchen?
Mögliche Antworten 
- Nur die Leute am Empfang, lediglich um die richtige Personen zu finden
- Nur die Projektteams (Info Worker)
- Jeder von Zeit zu Zeit, um einen entfernten Kollegen in der Firma zu finden
Einflüsse auf:
- Einflüsse auf das Design und die „managed properties“ der MySite
- Einflüsse auf weitere Software Lösungen, wie etwa Präsenz Informationen (Office Communication Server 2007)
- Einflüsse auf Funktionen wie etwa „wild card“-Suche

Wann könnte People Search eingesetzt werden und was ist das erwartete Resultat der Suche?
Mögliche Antworten:
- Am Anfang eines Projektes um Mitarbeiter zu finden
- Während eines Projektes um Spezialisten-Knowhow zu finden
- Fortlaufend, um zu sehen, was meine Berufskollegen so machen
- Gar nicht, wir brauchen Facebook
Einflüsse auf:
- Einflüsse auf das Design und die „managed properties“ der MySite
- Einflüsse auf die Entwicklung von speziellen Web Parts

Wie unterscheiden sich die Gruppen, die People Search einsetzten?
Mögliche Antworten:
- Die eine Abteilung sucht nur nach Abteilungen und Zuständigkeiten
- Die andere Abteilungen sucht nach Knowhow
Einflüsse auf:
- Einflüsse auf das Design und die „managed properties“ der MySite
- Einflüsse auf Entwicklung von speziellen Web Parts
- Einflüsse auf Search Scopes (Tabs) und Audiences

Wann ist die Suche nach Personen fertig?
Mögliche Antworten:
- Ich suche drei Mitarbeiter und vergleiche die Angaben der MySite miteinander
- Zu dem Mitarbeiter, zu dem ich eine „Verbindung“ über einen Kollegen habe, den kontaktiere ich
- Sobald ich eine Zusage für die Projekt-Ressource bekommen habe
Einflüsse auf:
- Einflüsse auf das Design und die „managed properties“ der MySite
- Einflüsse auf Entwicklung von speziellen Web Parts
- Einflüsse auf Entwicklungen von Workflows welche People Search unterstützen
- Einflüsse auf „best bets“ für People Search

Gute technische Links zum Theme People Search die mir Michael Greth noch zugespielt hat:

Colleagues, Social Distance & Relevance in People Search; Social Networking tools
“Social Computing and SharePoint” Präsentation

Heute hat George Strohmayer von Cisco an den ComDays einen interessanten Vortrag zum Thema “How much bandwidth do we need” gehalten. Dabei wurde er erstaunlich konkret und hat einige Brücken zum Thema Collaboration geschlagen.

Bisher waren vor allem P2P Anwendungen die Haupttreiber der Bandbreitensteigerungen. Im Vergleich zu dem was uns noch bevorsteht war das aber marginal. In Zukunft wird die Übermittlung von  Videocontent (in irgend einer Form) den Löwenanteil der Bandbreite wegfressen. Während heute der durchschnittliche Bedarf des Downstreams bei 3.75 Mbps liegt, rechnet Cisco morgen mit 11.25 Mbps, mittelfristig gar mit 30 Mbps.

Nicht weniger wichtig ist die wachsende Erwartungshaltung der Kunden nicht nur bei den Transferraten, sondern bei der Qualität der Übertragung – also bei der Latency. Heute werden gemäss Untersuchungen 95ms Verzögerung als qualitativ gut akzeptiert, in naher Zukunft rechnet Cisco mit 60ms als Akzeptanzgrenze.

Und spätestens hier sind wir bei unserem Thema. Durch die Zunahme manigfaltigster Videoinhalte und Anwendungen in guter Qualität sowie die weite Verbreitung von Social Networks werde es eine Verschmelzung der beiden Bereiche geben. Cisco hat auch gleich eine Wortschöfung parat: Visual Networking!

Cisco macht ja gleich selber vor, wie sie sich diese Zukunft vorstellt. Wir haben ja bereits über die High-End-Video-Conferencing-Lösung TelePresence berichtet. Ein interessanter Nachtrag dazu: rund 60 Prozent des Cisco-internen Datenverkehrs machen mittlerweile TelePresence-Sessions aus, eine Zahl, die auch für den globalen Datenverkehr prognostiziert wird.

Die visuelle Kommunikation wird zweifellos enorm an Bedeutung gewinnen. Allerdings wird auch von Seiten der User einiges mehr abverlangt als bei reiner Voice-Übertragung (Licht, Auftreten, “virtuelle Kompetenzen” ). Dies ist neben der Technik sicherlich ein weiterer Grund für die etwas länger dauernde Adaptierungsphase.

Aus aktuellem Anlass, habe ich mir wieder einmal Gedanken zum Thema “Warum SharePoint Projekte scheitern” gemacht.

Es gibt offensichtlich mehrere Gründe warum SharePoint-Projekte scheitern. Gelegentlich finden sich die Gründe außerhalb der Reichweite der beteiligten Parteien und sind nicht wirklich die Schuld von einer bestimmten Person, die an dem Projekt beteiligt ist. Meiner Erfahrung nach ist dies jedoch fast nie der Fall. Der Fehler ist in der Regel ein Fehler von einem oder mehreren Mitgliedern des Teams.

Der Grund liegt (meine Erfahrung) vielfach beim Management des Projektes. Der Projektmanager hat keine leichte Aufgabe. Er muss eine Balance finden zwischen über- und unter Koordinieren, Leiten und Managen. Je nach Symptomen die gerade während der Projektlaufzeit auftauchen. Diese Symptome sind auf den zweiten Blick nicht nur auf SharePoint Projekte anwendbar, sondern vermutlich auf die meisten IT-Projekte (die scheitern) anwendbar. Aber was sind diese Symptome?

1. Business-Ziele nicht genau definiert oder der vom Auftraggeber akzeptierte Vorschlag steht im Wiederspruch mit der tatsächlichen strategischen oder operativen Anforderungen. Dieser Punkt wird vielfach erst während dem Projekt realisiert. Wenn der Projektmanager dann probiert, einfach seine Linie weiter zu gehen, (Weg des geringsten Wiederstandes) sieht es logischerweise nicht gut für das Projekt und/oder den Erfolg der Realisierung aus.

2. Die Anforderungen wurden vom Kunden oder dem Lieferanten oder beiden nicht vollständig verstanden. Auch dieser Punkt bemerkt man oft, wenn das Projekt im Gange ist. Wenn man sich hier scheut offen und ehrlich noch einmal einen Schritt zurück zu gehen, wird das Projekt wohl kaum vom Erfolg gekrönt werden.

3. Der Kunde probiert mit dem Produkt Office SharePoint Server 2007 ein Web 2.0 Buzzword mit auf seine Intra/Extranet Seite, oder sogar auf das Internet zu bringen. Er ist sich aber über die Konsequenzen die sich dadurch in seiner eigenen Organisation ergeben nicht bewusst.

4. Die Erwartungshaltung in Bezug auf Lieferobjekte werden nicht geklärt. Dieser Punkt ist vermutlich der Wichtigste. Unterschiedliche Erwartungshaltung lösen während dem Projekt immer wieder Meinungsverschiedenheiten aus. Wird die gegenseitige Erwartungshaltung zu lange nicht geklärt, merkt eine Partei plötzlich (meist vor einem Meilenstein), dass aus ihrer Sicht ja alles völlig im argen liegt. Aussagen wie: “… dann hätte ich es ja gleich tun können”, oder “..ich dachte ihr seit Profis genug” werden dann über den Tisch hin uns her geschoben.

5. Falsche Schätzungen bei Kosten, Zeit, Ressourcen, Infrastruktur – Hardware-und Software-, Kapazitäts-Management usw.).

6. Umfangreiche Änderungen und/oder strategische Neupositionierung im laufenden Projekt. Wird von allen geliebt, insbesondere während der Endphase des Projekts.

7. Projekt-Prozesse wurden nicht definiert oder sie sind definiert, werden aber nicht konsequent eingehalten. Wir alle haben es während der Ausbildung gelernt: An einem Kickoff sollte man erläutern wie man gedenkt zu Dokumentieren, welche Kommunikations-Kanäle benutzt werden sollen (insbesondere wenn mit dezentralen Teams gearbeitet wird), wo man die Risiken heute schon sieht, welche Masstäbe man an die Qualität setzt und so weiter. Man hat uns das beigebracht, damit wir aus vergangen Fehlern lernen.

8. Fehlende Kommunikation und fehlende Aufrechterhaltung der Beziehungen mit allen Beteiligten (Kunde, Berater-, Infrastruktur-Anbieter, Geschäftspartner und alle anderen Beteiligten in dem Projekt). Ich glaube, das ist bei grossen und komplexen Projekten eines der Hauptprobleme. Vor allem externe und dezentrale Projektmitarbeiter tendieren bei fehlender Kommunikation dazu die “Begeisterung” für das Projekt zu zügeln.

Wie sieht es bei Euch aus? Habt Ihr Kommentare oder weiter wichtige Punkt hinzuzufügen?

Während wir, wegen der reinen Grösse der Lösung, für die Demo der Cisco TelePresence noch einen Termin mit dem Hersteller abmachen mussten, bin ich heute im vorbeigehen an eine Microsoft Roundtable Demo gekommen. Ein etwas ungleicher Vergleich. Aber hinter den beiden Produkten steckt ja bekanntlich ein ähnliches Konzept.

Auf meinem Rechner war bereits ein LiveMeeting Client installiert. USB-Kabel der Roundtable Kamera in den Laptop und bereit war ich für meine eigene kleine Demo.

Wie sich die Roundtable in LiveMeeting verhält kann man in unserem Screencast sehen.

(Wer genau hinsieht kann sogar Agent Kuper sehen)

Google, hat mal wieder in der Trickkiste gewühlt und eine neues Framework für Mobile Geräte entwickelt. Dies hört sich auf den ersten Blick nicht sehr spannend an. Jedoch ist Android ein Open Source Framework und somit für alle professionelle und hobby Softwareentwicker zugänglich um innovative Applikationen für die Mobilen Telefone von Morgen zu bauen.
Die Idee ist es die kreativen Köpfe rund um den Erdball in einer Android Community zu vereinen. Ideen auszutauschen und zusammen in der kollektiven Intelligenz jene Applikationen zu entwickeln, die den Bedürfnissen der Benutzer entsprechen. Google erhofft sich eine Virale Ausbreitung des Frameworks und plädiert an alle kreativen Köpfe der ganzen Welt, um die beste und innovativste Software für Mobile Geräte zu entwickeln. In meinen Augen ein simples und geniales Konzept. Etwas ähnliches haben wir mit Linux ja schon erlebt und es wurde schon bewiesen, dass dieses Konzept mehr als nur überlebensfähig ist.

Einige Facts:

• Um für Android entwickeln zu können, muss man die Java Programmiersprache beherrschen.
• Mit dem Android Grundpaket werden ein e-Mail Client, SMS Editor, eine Kalenderapplikation, Weltkarten, Internet Browser und Kontaktverwaltung mitgeliefert.
• Entwickler haben vollen Zugriff auf die gleichen Framework APIs welche von den Core Applikationen benutzt werden.
• Andoid basiert auf dem Linux Kernel der Version 2.6
• Optimierte Grafikbeschleuniger, 3D Grafiken basieren auf dem Open GL ES 1.0 Standard
• Media Support für gängige Medienformate wie: MPEG4, MP3, AAC, AMR, JPG, PNG, GIF
• uva.

Ehrlich gesagt, bin ich jetzt schon gespannt was sich die Welt für dieses Android Framework ausdenken wird. Ich bin sicher, dass Android wieder einen weiteren Schritt für eine moderne kollaborative, vernetzte Welt darstellt.
Warum ist das so? Warum ist Android eine echte Konkurenz zu Apples iPhone?
Um wirklich ein grosses Produkt zu erstellen, muss man zuerst mit dem Produkt leben. Wir leben damit, entwickeln Bedürfnisse und Anforderungen. Der Unterschied zum iPhone und Android besteht darin, dass ich mein Android-Phone exakt auf meine Bedürfnisse und Wünsche anpassen kann. Wenn ich nicht programmieren kann, dann kann ich die Community um Hilfe bitten, oder vielleicht hat ja ein Entwickler genau das gleiche Bedürfniss wie ich?
Es ist allgemein bekannt, dass 2 Köpfe mehr leisten, als nur einer. Man stelle sich vor, hundert tausende von innovativen Köpfen rund um den Erdball versuchen gemeinsam ein geniales Produkt zu entwickeln.
Mann stelle sich ein Google Earth vor, das als GPS Navigator funktionieren könnte und auf Wunsch die Sehenswürdigkeiten in der Nähe des aktuellen Standorts vorschlägt. Die Möglichkeiten mit Googles neuer mobilen Plattform sind enorm .
Man kann schon heute damit beginnen für Android zu entwickeln. Die SDK findet man hier.

Der Hauptunterschied zu Apples iPhone ist, dass die Community das Perfekte Produkt entwickeln wird. Es wird nicht nur ein Android phone geben, sondern tausend verschiedene. Apple glaubt das Perfekte Produkt selbst entwickeln zu können. Sehen wir, wer am Ende recht hat.

Nun ist scolab.ch ein Jahr online. Der Traffic auf der Seite stieg kontinuierlich an und gab unserer Idee recht. Eine Community die sich rund um das Thema Collaboration dreht ist entstanden. Unsere Job Hilfe Nummer 1 wurde kreuz und quer über den Globus verlinkt. Einige wollen diese Arbeit von uns abkaufen. So etwa der SharePoint Buch Autor Bill English. Die Job Hilfe Nummer 2 ist am entstehen. Hier darf man ein „Kochbuch“ zu STSADM.EXE erwarten.

Die Community, rund um Scolab, manifestiert sich vor allem in Aktivitäten auf dem Web. Wir möchten die Community aber erweitern und vor allem auch mit Euch in Kontakt treten. Zu diesem Zweck haben wir auf Facebook eine Gruppe eingerichtet. Also meldet Euch dort und kontaktiert uns direkt.

Zudem planen wir in Zürich Anlässe, zu aktuellen Themen der Collaboration durchzuführen. Nicht die grossen TechDays, sondern kleine, feine Anlässe unter IT-Pros. Wir stehen mit einigen Cracks zu unseren Themen in Kontakt die wir auf die eine oder andere Art nach Zürich bringen werden.

Weiter gilt wie immer: Wer nicht genau weiss was er mit seinem Freitagabend machen soll ist eingeladen sich bei uns zu melden. Wir haben vermutlich den richtigen Geist um diese Lücke mit IT, Collaboration und Pizzas oder anderen italienischen Köstlichkeiten zu füllen.

In diesem Sinne gratulieren wir uns selber zum ersten Online-Jahr und freuen uns darauf, dass wir mehr von Euch da draussen persönlich kennen lernen.

Scolab – Das Team