Fallstudie 2: När det inte går att skilja på projekt och verksamhet – del 1

Fallstudie nummer två är inte så specifik som fallstudie ett var, utan får kanske mer betraktas som en mer allmän betraktelse över moderna kunskapsintensiva organisationers utmaningar vad gäller förutsättningarna att skapa väldefinierade och tidsavgränsade projekt.

Jag var verksam i en organisation som drev sin utvecklingsverksamhet genom att skapa projekt.

Oftast innebar arbetet att vi gjorde kundanpassningar med en befintlig produkt som grund, och den nya anpassade produkten skulle införlivas i produktportföljen när projektet var avslutat.

Det innebar att en stor del av arbetet redan från början var uppstyrt av historiska beslut kring produkten vi hade som bas och vår organisation som vidmakthöll våra produkter, samtidigt som en rad processer och verktyg för exempelvis produktdata, provning, certifiering och konfigurationsstyrning också var av gud givna.

Det här gjorde att projekten hade en stor andel arbete som, även om det ekonomiskt var arbete i projekten för den specifika kunden, genomfördes som en form av kontinuerligt linjearbete.

Det i sin tur innebar att projekten i sig inte var så synliga och inte heller alltid involverade i daglig arbetsledning av verksamheten.

I organisationen fanns naturligtvis också ett behov av att underhålla befintliga produkter och stödja mer- och nyförsäljning.

Ett av företagets stora styrkor var den affärsorienterade attityd stora delar av företaget hade, vilket innebar att man fokuserade mycket tid och kraft på att vinna nya affärer och alltid var redo för nya kunder.

Det tydliga projekttänket stödde detta, men lurade oss också, då det alltid gick att starta nya projekt och bemanna upp ny verksamhet för att stödja en ny affär, detta trots att vi egentligen inte kunde driva mer än en viss verksamhet, givet vår kompetensbas, effektivt.

Ofta innehöll också våra kundavtal en rad öppna punkter och en hög nivå av kunddialog, vilket innebar att mycket arbete återstod när det gällde att definiera arbetsinnehållet i projekten även efter projektstart.

I praktiken innebar beskrivningen ovan att organisationen utsattes för flera utmaningar:

1. Oklarheter vem som drev verksamheten; köpte projektledaren ett uppdrag av linjechefen eller var hen ansvarig för aktiv arbetsledning av samtliga delar i projektet.
2. Prioritering mellan projekt, produktunderhåll och stöd till nyförsäljning var en ständigt pågående process som ibland skedde på enskild ingenjörsnivå utan att någon uttalad prioritet fanns från ledningen.
3. Projektens innehåll ändrades ofta och osäkerheter kring faktiskt innehåll kunde finnas under långa perioder.
4. Kritiska kompetenser som inte lätt gick att skala upp fick en tuff arbetssituation då nya projekt skapades för att möta nya affärer, utan att tillgängligheten på kritiska resurser beaktades nämnvärt.

Delar av de problem som driftsformen skapade är problem som inte är lämpliga att lösa på arbetande nivå, men de ”sköts” så att säga ner i organisationen och blev i stället ständiga orosmoment och tvisteämnen.

För en renlärig projektledare så skapar detta en mardrömssituation där det är oklart vem som styr; vilken personal man har i projektet; vilken tidplan och vilka mål som faktiskt gäller och vilken omfattning projektet har.

Det gör också att det finns en ständig kamp mellan individer som agerar utifrån att säkra just sin verksamhet, sina leveranser och sin tidplan i organisationen.

Utifrån ett renlärigt projektledarperspektiv är det ganska rättframt att skissa på en lösning.

Den ser ut ungefär så här:

1. Inför någon form av portföljhantering som gör att projektens prioritering och bemanningssituation kan hanteras på en mer övergripande nivå. Ibland är det rimligt att stoppa viss verksamhet för att andra ska få göra klart.
2. Arbeta igenom projektifieringsfasen mer. Definiera tydligare omfattning och tillgång till resurs innan projektverksamheten startas.
3. Släpp endast ut tydligt definierade arbetspaket i organisationen.
4. Resurser ska vara heltidsdeltagare i projekten och ”annan verksamhet” som produktunderhåll och affärsstödjande verksamhet ska planläggas och hanteras strukturerat.

Det finns säkert mer att göra som är naturligt för att skapa bättre ordning och struktur som leder till väldefinierade projekt som effektivt kan ledas.

I praktiken har vi en trend sedan 1980-talet som gör att de enkla fixarna ovan är betydligt svårare att införa och få bra än vad vi kan tro.

I USA så noterade man under 1980-talet att mycket av den overhead man hade i verksamheten motiverades av att företaget skulle kunna vinna affärer och vara effektivt och lönsamt.

Vi har diskuterat det transaktionella ledarskapet här tidigare och det bygger på ett antagande om att chefen vet bäst och det speglade också företagsorganisationerna.

De som skulle veta bäst var tvungna att sitta någonstans och de gjorde ofta det som chefer, i staber eller som ganska fria men väl förankrade spelare högre upp i organisationen.

Men i takt med att förändringstakten ökade i företagen så var detta inte längre en sanning att chefen eller den seniora medarbetaren visste bäst.

I själva verket pekade trenden på att företagets anställda på lägsta nivå var tvungna att vara delaktiga i alla verksamhetssteg för att få tillgång till rätt och relevant kompetens och den innovationskraft man önskade.

Det är inte bara för att spara kostnad overheaden i företagen försvunnit, det är snarast för att det är svårt att upprätthålla den kompetens och förmåga som är relevant för företaget högre upp i organisationen som gör att hierarkierna blir allt grundare.

Det här gör att väldigt få företag idag har någon organisation utöver utförarnivån i företagen som kan skapa väldefinierade projekt.

För att projekten ska kunna beskrivas så krävs att ingenjörer, produktledare, inköpare, projektledare och många fler är delaktiga.

Att skapa projekt för att skapa projekt är avigt och projektstarten åker i tid. Det gör att projekten rullar igång trots att det kanske är oklara grunder med oklara mål.

Dessutom är bemanningssituationen och driftsformen oftast helt ohanterad. Budgeten är oftast det som är enklast att definiera, men den får sällan någon prioritet om produkten faktiskt måste ut på marknaden.

Hur hanterar man att det bara i teorin går att ge projekt de grundförutsättningar de ska ha enligt skolboken?