At samle et flydende puslespil

En projektleder griber ofte en opgave an med drejebøger, som er baseret på, at man kan underopdele opgaverne i en tayloristisk arbejdsdeling og dermed skabe veldefinerede brikker i puslespillet, der skal samles, sådan som det faktisk foregår i industri-produktion.

Vores forskning inden for videnledelse, udvikling og læring i it-virksomheder viser, at en sådan drejebog er et dilemma, når man leder mindre og videntunge virksomheder. Her har man ikke mulighed for at kontrollere omverdenens foranderlighed, eller hvordan videnmedarbejderne beslutter og tager ansvar for deres brik af puslespillet undervejs.

Dette ændrer ledelsesrollen og stiller store krav til evnen til at lytte og i det hele taget til kommunikation og fortløbende organisering.

Men det skaber også øgede krav til fleksibilitet til kundernes ændringer undervejs, det vil sige hele rammen for puslespillet, og tidsgrænserne flyttes.

Ekstremt usikker verden
Vi har haft fokus på mindre multimedievirksomheder, og hvordan de udvikler nye produkter og håndterer udviklingsprocessen i en ekstremt usikker omverden. En række forskellige problemstillinger har vist sig:

1. Det er normalen snarere end en undtagelse, at vilkårene for udviklingsprojekter ændres undervejs. Enten forkortes projektet, der skal indarbejdes flere eller helt andre funktioner, eller ressourcerne mindskes. Det betyder, at drejebogen for det næste projekt også ændres, og at man som leder med en drejebog for projektet hele tiden skal være i stand til at ændre den. Magtforholdet mellem en lille itvirksomhed og en stor kunde betyder, at den lille leverandør er afhængig af storkundens senere ordrer og derfor er nødt til at løse opgaverne under stort set umulige vilkår.
2. De enkelte programmører bliver optaget af spændende og æstetiske koder, som betyder, at de løber ud ad en tangent i forhold til den fællesopgave, der skal løses. Det kan være udtryk for relevant udvikling, men det kan også være udtryk for særinteresser. Det stiller særlige krav til lederen om at »af-kode« medarbejderne, så lederen stadig kan forsøge at skabe overblik over puslespillets helhed og tilpasse de brikker, som er afhængige af en ny udvikling.
3. Det er ikke nødvendigvis lederen, som ved mest om projektets udviklingsdele. Dvs. at projektlederen skal holde de andre fast på den fælles mening i det fælles puslespil, men skal selv få viden om de enkelte dele og konsekvenserne for de andre brikker. Det er mere en koordinering end en tayloristisk styring, fordi ekspertisen er decentral.
4. Behovet for videndeling eller kommunikation mellem medarbejderne øges, fordi kompleksiteten øges, og tidspresset bliver større. Når man forsøger at komprimere eller »folde tiden«, bliver det helt nødvendigt med en meget åben kommunikation, så man ikke fremstiller brikker til helt forskellige puslespil.

Der er en række af forholdene, som måske mest har med branchen at gøre. Her kunne forsøget på en arbejdsdeling i et projekt, der flyder, og hvor puslespillets dele udvikler sig, være en særlig problemstilling.

Der er nogle stramme vilkår for projektledelse i denne branche: Når kunderne ikke rigtig ved, hvad de vil, bl.a. fordi forskellige interessenter og grupper har forskellige krav til produktet, og de ændrer vilkårene sent i forløbet uden at give bedre tidsrammer.

Det skaber gnidninger og problemer med, hvad man skal gøre, hvad der er viden, og hvem der har besluttet om denne viden. Internt hos kunden kan det være et problem, hvem multimedievirksomhedens ledelse forhandler med, og hvem der dernæst sætter dagsordenen for de følgende beslutninger.

Det bliver hurtigt en problemstilling om ledelseskommunikation både internt og eksternt.

Videndeling i komplekse projekter
En anden problemstilling handler om at skabe videndeling, så nye medarbejdere kan rekrutteres og sættes i gang.
Vi har fulgt nogle virksomheder og haft fokus på videndeling. I projektet har vi set en række eksempler på, at virksomheder udvikler komplekse it-projekter og har problemer med at skabe en klar arbejdsdeling og aflastning af kerneprogrammører.

Vi er vant til arbejdsdeling som en metode til at underopdele opgaver i delopgaver og på den måde uddelegere og få flere til at arbejde på samme tid, så man bliver hurtigere færdig.
Som vi alle har lært i de tidlige regneopgaver: Når 2 mand graver en grøft på 2 dage, hvor længe er så 4 mand om det? Vidunderligt simpelt; de går ikke i vejen for hinanden, og de ved, hvad de skal lave.

Men hvis det nu er komplekse it-projekter, ser det anderledes ud. Den store udfordring er her, hvor kurven knækker, dvs. man bruger længere tid på at instruere de nye medarbejdere, end man får udbytte af dem. Når opgaverne er komplekse, er arbejdsdeling meget mere kompleks, og det er små virksomheder nødt til at håndtere og ofte håndtere i forhold til andre virksomheder, fordi de arbejder sammen i netværksbaserede organiseringer.

I forhold til casene udviklede en af virksomhederne et xml-værktøj, samtidig med at andre dele af virksomheden arbejdede med anvendelsen til et program. Dvs. man arbejdede parallelt med fænomener, som burde følge efter hinanden.

Denne form for næsten »foldede« tid giver en meget vanskelig videndeling, og da man rekrutterede to programmører, viste det sig, at de ikke kunne gå direkte ind og arbejde med indholdet, men var nødt til at bremse op for at blive briefet ordentligt og få viden nok til at sætte deres viden og kompetence i spil.

Udviklingsprojekter og komplekse it-projekter har alle den karakter, at arbejdsdelingen er baseret på, at man skal udvikle enkelte brikker i puslespillet, og der er en forestilling om, at man kender billedet i spillet.

Men både brikkerne og billedet og rammen ændrer sig i forløbet. Det er en meget spændende problemstilling i projektledelse og nogle vanskelige vilkår for ledelse. Men det er praksis og stiller meget store krav til kommunikation for at finde ud af, hvordan meningen eller »billedet« kan skabes gennem de ændrede brikker i spillet.

Referencer

Sisse Siggaard Jensen, Mette Mønsted, Sanne Fejfer Olsen: Viden, Ledelse og Kommunikation. Samfundslitteratur 2004.