Enterprise social software

Definition von Enterprise 2.0 Software auf Wikipedia:

In contrast to traditional enterprise software, which imposes structure prior to use, this generation of software tends to encourage use prior to providing structure.

Dies deckt sich mit meinen Beobachtungen aus unserer internen Verwendung eines Wikis als zentrales Projektbegleitungstool und den oftmals in Kundenprojekten angetroffenen Intranets mit laaaangen Planungs-, Implementierungs- und Einführungsphasen. Das Wiki bei uns war bereits in starker Verwendung noch lange bevor wir das erste mal über ein Regelwerk für den konkreten Umgang nachgedacht haben. Jetzt verwendet es die gesamte Firma, um gemeinsam mit dem Kunden Projekte zu planen. Das ganze ohne eine Zeile Code- oder Designanpassung zu machen. Auch aus einem Kundenprojekt kenne ich dieses Feedback: Parallel zum langlaufenden Relaunchprojekt eines Intranets wurde in wenigen Wochen ein Wiki aufgesetzt und gewann ohne grosse interne Werbung schnell Akzeptanz.

Enterprise 2.0 im täglichen Arbeitseinsatz

Enterprise 2.0 Präsentation von Scott Gavin: Einsatz von Web2.0 Tools in der Firma. Im Grunde nichts neues, aber gut komprimiert

Grundsätzlich setzen wir bei meiner Firma dieselben Tools ein (Confluence Wiki, JIRA, Social Bookmarking, Blogs, Feeds), mal schauen wann wir die Durchdringung durch alle Teammitglieder schaffen

Project Management based on Confluence Wiki

A year ago i started a project for my employer to setup a project platform to keep all project relevant information together at one place. I had a 2-year experience with Atlassian Confluence from an EU funded research project. Atlassian Confluence is a so called collaborative Wiki, we used it in the past for a knowledge Platform for scientists to collect all information specific to neanderthal sites and finds (see NESPOS).

Before that, i experimented a year with a „collaborative UML Case Tool“ called Sparx Systems Enterprise Architect, tried to get the developers and project managers involved to share information and collaborate using this platform. Although it provides some nice collaborative features, it was as effective as using a screwdriver for driving nails into wood, it was simply the wrong tool for this kind of work.

Thats the reason i gave Confluence a try. We started to use it in a small team, made a lot of mistakes first(see WikiPatterns), learned a lot, got it growing in quality and substance from project to project.

The project is still ongoing and still needs adaption, but the cost-benefit ratio is amazing. The flexibility of a wiki (most of all, of Confluence) gives the freedom to simply learn by trial and error without huge costs of development. The WYSIWYG Editor of Confluence reduces the barrier for business users (e.g. project managers, designers) to do „edits“ in the wiki.

The important issues in my point of view:

• The tool matters: The tool isn’t everything, but you will never get the project fly with the wrong tool. My opinion: Use a wiki, and at least evaluate Atlassian Confluence.
• Its easy to attract the developers, but its hard to get the PMs and Designers onboard: Some people won’t use wiki syntax. Believe it or fail.
• From an agile aspect, the customer should have the same rights in the wiki as a developer has. The customer is willing to collaborate, at least some of them. Let them create, view and edit. Everything
• You might need Templates: Or, who is afraid of white and empty pages. The freedom of doing everything is the fear of others. Provide some usefull templates, best is to use the zone plugin for Confluence
• The point we are at now – Support Quality: As soon as most of the employees start working with the wiki, the quality rapidly decreases. The reasons are manifold: some people think they are forced to use the wiki, others make the same beginner’s mistake as we did first. Business Users tend to upload tons of Powerpoint, Wordfiles and PDFs, copy and paste emails and forget to keep the information up-to-date.