Projektledelse

Ups, jeg missede sidste uge i min Post a week udfordfring af mig selv. Derfor kommer er et lidt længere indlæg. Det har rumlet i min kladdekasse længe, men nu skal det altså afsted. Here goes…

Gennem tiden har jeg været del af flere projekter, der har bygget websites, digitale tjenester til bibliotekerne mm. Oven i det kommer ganske almindelig arbejde med it-relateret behovsafklaring og lignende.

Noget der gang på gang er tydeligt er, at det brugeren siger, ikke er det udvikleren eller teknikeren nødvendigvis hører. Der er helt tydeligt en sprogbarrierer mellem it-folk og ikke-it-folk. Pointen er, at ofte taler it-teknikere/administratorer/udviklere og lign. et sprog, der er uforståeligt for den almindelige bruger. Det samme gør sig også gældende fra brugerens (kundens) side. Begge parter bruger et væld af udtryk fra eget fagområde, som ikke nødvendigvis forstås af modparten. Hertil kan lægges indforståethed.

Et eksempel fra projektverdenen

Jeg var på et tidspunkt tæt på et projekt, der skulle udvikle en email- og webbaseret løsning til litteraturformidling. Projektlederen stod for kontakten til udviklerne (et eksterne firma) og sammen med andre projektdeltagere (med baggrund inden for litteratur og formidling) stod han også for at beskrive ønsker til ny funktionalitet mm. Problemet bestod i, at projektlederen og chefudvikleren på ingen måde forstod hinanden. Det der for projektlederen var en selvfølge fx i forhold til usability, ikke var  for udvikleren. Og når de, hver især skulle forklare et ønske, en fejl eller andet, blev det aldrig præcist nok for modparten til, at det kunne omsættes til kode uden en tidskrævende proces omkring beskrivelse og kravspecifikation. Når man kende begge verderer, er der ikke de store problemer, og det er rimeligt let at stille forståelige, opklarende spørgsmål. Men bevæger man sig næsten udelukkende i den ene verden, er det tydeligvist svært at forstå den anden.

Et eksempel fra supportens verden

Brugerens sprog omkring brugen af pc, systemer mm er tit upræcist (set med teknikerens øjne) og mange sammenhæge i funktionalitet og mellem systemer er uklare for brugeren. Samtidig kan den samme tekniker have svært ved at stille de spørgsmål, der får brugeren til at give den nødvendige information – og er samtalen pr telefon er problemet bestemt ikke mindre. Min erfaring er, at jo flere systemer supporterne i servicedesken skal kende til, jo sværere har de ved at løse et problem her og nu og jo sværere har de også med at visitere sagen til at andet led i driftorganisationen. Undtaget herfra er de fællessystemer som alle i organisationen benytter, fx office og esdh. Samtidig kan det være svært for brugeren at se årsagen til, at et system hænger. Er det systemet i sig selv? Er det et system, det første system er afhængigt af? Eller er det netværket, der har lange svartider?

Findes der en løsning?

Måske, men det kommer an på organisationens modenhed og måden den vælger at yde support på. Mit bud er, at finde de medarbejdere, der har teknisk forståelse i en eller anden form. De vil som regel gerne bruge lidt tid på at hjælpe deres kollegaer med at få beskrevet et problem. At tro servicedesken kan gøre det i telefonen er en utopi, uanset hvor stor indsats deres gøres derfra. IT er i dag et værktøj langt de fleste medarbejdere bruger, og derfor skal medarbejderne have kendskab til IT på et generelt plan, og ikke kun på deres fagsystemer. Det tror jeg, er en udfordring for mange organisationen, hvor mantraet længe har været, at it-viden og support centraliseres, så den enkelte medarbejder kan fokusere på sit fagområde. Min pointe er, at faglighed også omfatter it-kendskab.