How to

Top 10 toepassingen voor projectblogs

0

[[image:projectblog200.jpg::left:0]]Het adviesbureau Cutting through heeft op haar weblog een uitstekend
artikel gepubliceerd met een opsomming van tien manieren om weblogs
voor projecten in te zetten. Je zou het bijna vergeten, blogs zijn niet
alleen voor marketing of entertainment, bedrijven kunnen blogs ook
inzetten om de informatievoorziening te verbeteren, informatie-overload
te voorkomen en voor eens en altijd een einde te maken aan het “daar
wist ik niets van” syndroom.

  1. Communiceren met stakeholders project: Het is belangrijk
    om de belangrijke stakeholders up-to-date te houden over de voortgang
    van een project. Maar het zijn vaak drukke mensen die geen omvangrijke
    dikke rapportages of uitgebreide e-mail gaan doornemen. Een
    alternatieve manier is om de mijlpalen via een weblog te publiceren.
    Dat kan wekelijks, dagelijks of zelfs meerdere keren per dag zonder ze
    te bombarderen met allerlei e-mails. Nog mooier is als je met een RSS
    werkt waarbij ze alleen de webfeed-samenvatting hoeven te scannen om te
    bepalen of ze al dan niet moeten reageren.
  2. Vervangen van papier: Iedereen die een projectmethodiek als PRINCE (Projects in Controlled
    Environments) of  PMBOK
    (Project Management Body of Knowledge) vraagt zich wel eens af of ze
    niet ontworpen zijn door mensen met aandelen in de papierindustrie.
    Kastplanken vol met papier waarvan de vraag is of ze later nog terug te
    vinden zijn. Maar met een goede categorie-indeling en enkele online
    templates op maat kan veel van dat papier vervangen worden door
    webpagina’s. Toegankelijk voor altijd en iedereen, met een afdoende
    versiebeheer en ingebouwde zoekfuncties.
  3. Werken met issue logs: Iedereen in een project zou gemakkelijk een issue moeten kunnen aanmelden. Of er nou een vraag is, een request for change of een off-specification,
    elk item zou in een project issue log vastgelegd moeten worden. Geen
    e-mail naar de projectmanager maar een open blog (of wiki) waar issues
    meteen op de goeie plek terechtkomen en voor iedereen ook zichtbaar
    zijn. Met de zoekfunctie kun je snel bepalen of issues al geadresseerd
    zijn, met de reactiemogelijkheid kan er een discussie gevoerd worden
    over hoe om te gaan met elk issue. Het (online) besluitvormingsproces
    wordt op deze manier bovendien meteen vastgelegd.
  4. Vasthouden van “informatiebrokjes”:
    Er wordt in de loop van het project een hoop informatie verzameld , van
    gezamenlijke wachtwoorden via nuttige url’s tot stukjes code. Er zijn
    altijd projectleden die zulke informatie op hun eigen pc verzamelen,
    maar hoe kun je dat aan het hele team ten goede laten komen? Door
    hiervoor een blog (of wiki) in te zetten, kan dit materiaal gemakkelijk
    verzameld, gecategoriseerd, doorzocht en gevonden worden. En, niet in
    de laatste plaats, er ontstaat al snel een waardevolle kennisbank voor
    latere projecten.
  5. Publiceren over projectvoortgang:
    Waarom zou je als een project goed gaat daar niet volop over
    communiceren? Door nieuws, updates en statusrapporten in een
    organisatiebrede blog te posten, kun je iedereen op de hoogte houden
    van de voortgang van een project. Dit kan heel nuttig zijn bij
    projecten die een grote impact hebben voor eindgebruikers en – maar dat
    is natuurlijk slechts bijzaak – kunnen het gebruik van webfeeds in een
    organisatie op gang brengen.
  6. Reduceren van e-mail overload:
    E-mail is zowel een zegen als een vloek. Het is natuurlijk geweldig
    voor snelle communicatie met collega’s of klanten maar soms is het
    verleidelijk om naar jan en alleman een cc te sturen. Waarom zou je
    niet in plaats van e-mails met lange cc-lijsten dit soort berichten
    niet gewoon in een blog posten? Er ontstaat niet alleen een centraal,
    doorzoekbaar en goed gearchiveerde verzameling, je kunt ook webfeeds
    gebruiken om nieuwe berichten razendsnel te scannen en te besluiten of
    je al dan niet actie moet nemen. Het kost je maar een fractie van de
    tijd die gemoeid zou zijn met het behandelen van nieuwe e-mail.
  7. Vastleggen van requirements: Hoe
    vaak gebeurt het niet dat de belangrijkste wensen en eisen van
    eindgebruikers pas aan het licht komen als de workshops al achter de
    rug zijn? Je kunt een open blog inzetten om nieuwe requirements te
    verzamelen en discussies over bestaande requirements te voeren. Dat kan
    zowel voor, tijdens als na de workshop-periode. Samen met een goed
    gebruik van categorie