Artikel top billede

Kvalitetsledelse betaler sig til software- og it-udvikling: Nogle vigtige råd til at få styr på dit arbejde

Klumme: Inddrag medarbejderne. Definer processerne. Brug ressourcer på procesforbedring under agil så vel som plandreven udvikling. Det kan da ikke være så svært.

Kvalitetsledelse betaler sig. Dette postulat forudsætter dog, at udviklere af software og it definerer, vedligeholder og forbedrer udviklingsprocesserne.

Over en årrække arbejdede jeg med at underbygge mit postulat om, at kvalitetsledelse betaler sig. Den dokumentation, jeg kan skaffe, er fremlagt i bogen "Kvalitetsledelse betaler sig" udgivet på Aalborg Universitetsforlag i november 2015.

Læs tidligere klumme og anmeldelse af bogen via dette link: Sådan får du styr på kvaliteten og øger din indtjening.

Der er dog hindringer, der skal fjernes, hvis man skal have udbytte af investeringen i kvalitetssystemer.

Ovennævnte studium identificerer syv hindringer.

De tæller blandt andet disse to:

1) Få ressourcer til planlægning af kvalitetssystemet.

2) Lav grad af inddragelse af medarbejdere.

Nul effektivitet og motivation

Få ressourcer og lav inddragelse hindrer effektivitet og motivation. De er hindringer for implementering af et effektivt kvalitetssystem.

Virksomheder bestræber sig på det modsatte, nemlig et effektivt system. Men faren lurer lige om hjørnet.

En af casene i ovennævnte bog handler om et lille, ungt og innovativt software- og it-udviklingsfirma.

Langt de fleste medarbejdere i dette firmas udviklingsafdeling har videregående uddannelser som ingeniører, dataloger og lignende.

Ejeren, som også er direktør, ermest optaget af innovation og produktudvikling, og evne og ressourcer til disse formål er sat i højsædet.

Derfor er firmaets systemer oprindeligt meget løse, hvilket bevirker, at kvalitetsledelse har haft sporadisk karakter i firmaets første år.

Firmaet beslutter sig for at fremstille og sælge fysiske produkter, som man selv har udviklet.

På det tidspunkt behersker firmaet ikke kompetencer til produktion. Derfor bliver et udviklingstiltag gennemført, som resulterer i certificering af kvalitetssystemet angående produktion (produktudvikling er ikke omfattet).

Formålet er at højne firmaets troværdighed som en kvalificeret samarbejdspartner for kunder, leverandører og andre samarbejdspartnere gennem kvalitetsstyring.

Bliver et hjælpemiddel

Kvalitetssystemet bliver et hjælpemiddel under firmaets udvikling fra lille udviklingshus til produktionsvirksomhed. Systemet tilfører både struktur og forretningsgang til støtte for driften. For eksempel bliver der indført rutiner til systematisk at tjekke underleverandører, inspicere varer, udføre slutafprøvning og lignende.

Men virksomheden kan ikke opnå den budgetterede omsætning. Strategien om at sælge og producere egne produkter mislykkes.

Derfor opgiver firmaet for en tid sin certificering og vender tilbage til alene at udvikle løsninger.

Hensigten er at forøge fokus på innovationsevnen, men bibeholde gevinster fra kvalitetssystemet. Det lykkedes at skabe et højteknologisk og internationalt arbejdende udviklingscenter, som vokser sig større.

På bekostning af struktur og system

Mangelen på et certificeret kvalitetssystem i en periode hæmmer ikke skabelsen af et vellykket udviklingshus. Men tilbagevenden til udviklingshus sker på bekostning af struktur og system, dog med bedre innovationsevne som gevinst.

Medarbejderne bliver mere inddraget i denne omstilling, og det giver sig udslag i højere motivation end ved etablering af det certificerede kvalitetssystem.

Under omstillingen bliver fokus ændret fra kvalitetsstyring til forbedring af processer under produktudvikling.

Systemforbedringer bliver besluttet på en mere demokratisk måde - medarbejdere bliver inddraget i at ændre kvalitetssystem og værktøjer til softwareudvikling.

Medarbejderne ønsker et dynamisk konfigurationsstyringssystem til støtte for arbejdet, og som kan tilpasses forskelligartede krav og udviklingsmiljøer.

Derfor bliver der gjort et tiltag for selv at udvikle et sådant værktøj.

Det efterfølgende forløb viser, at virkelige forbedringer skabes af udviklerne selv, når udviklingsfolkene selv udvikler værktøjer og procedurer, som efter deres mening forbedrer konkurrenceevnen. Denne gode erfaring bliver gjort, selv om udviklerne i parallel arbejder med forretningsmæssig produktudvikling.

En slags cirkelbevægelse

Firmaets kvalitetsforståelse gennemgik en bemærkelsesværdig ændring i en slags cirkelbevægelse - firmaet vendte tilbage til sin oprindelige forståelse, men var blevet klogere undervejs.

Det er min vurdering, at firmaets struktur var organisk og kultur var selvigangsættende ved begyndelsen af tiltaget.

Opbygning af et kvalitetssystem medførte mere fast struktur, som umiddelbart stod i vejen for firmaets innovative kultur.

Kvalitetsstyring blev indført med certificering af kvalitetssystemet, og den var gavnlig i firmaets drift, som stod for produktion af produkter.

Certificeringen blev lagt på hylden på grund af firmaets strategiændring.

Det bevirkede, at firmaet gik i retning af sin oprindelige organiske struktur og selvigangsættende kultur.

Belært af sine erfaringer fra før kvalitetsstyring blev indført påbegyndte firmaet et nyt kvalitetsinitiativ med formålet at bringe struktur ind i projekterne med væsentlig deltagelse af medarbejdere fra udviklingsafdelingen.

Dette var udtryk for, at kvalitetsstyring ikke var tilsidesat, men under udvikling med nye spillere for bordenden.

Strukturen i virksomheden var løs og ubureaukratisk.

Derved skulle organisationen let kunne orientere sig mod de stadige ændringer og nye udfordringer. Det var medarbejderne efter min vurdering også interesseret i.

Men da organisationen voksede meget, i kølvandet på tilbagevenden til alene at være udviklingshus, begyndte den at lide under manglende styring og normer, fordi den blev stor. Firmaets produktudvikling led under mangel på procedurer for planlægning, vedligeholdelse af specifikationer, konfigurationsstyring mv.

Da certificering blev sat på hold, og firmaet vendte tilbage til en mere organisk struktur, blev organisationen ganske vist fleksibel, men den sprang fasen over at afklare regler for projektstyring, normer for kvalitet og metoder til procesforbedring.

Det gik ud over effektivitet i projekter, og nye folk havde sværere ved at komme i gang. Derfor savnedes strukturer, som kunne støtte udviklingsfolkene.

Medarbejderne var motiverede for selv at bidrage med løsninger, men de var ikke kompetente til at løfte opgaven, fordi virksomheden savnede den struktur under udvikling og projektledelse, som kunne gøre det muligt. Problemet var ikke af teknologisk karakter, tværtimod var firmaet teknologisk førende på sit felt.

Problemet var at styre de mange udviklingsopgaver med det store mandskab, man havde og samtidigt bevare det teknologiske forspring med et profitabelt resultat.

Mange grupper af designere udviklede software, som typisk var specificeret af udenlandske kunder.

Udfordringen var at styre udviklingsopgaverne således, at kundens specifikationer og behov blev afdækket og udviklingsarbejdet effektivt organiseret og styret. Det fordrede, at firmaet var bevidst om sine standarder, designmetoder, testprocedurer etc.

For at kunne alt dette skulle firmaet afklare sin best practice, træne medarbejderne i at bruge den, give dem værktøjer, så de kunne kommunikere om denne praksis, så de sammen med ledelsen kunne videreudvikle og forbedre den.

Motivationen for at udføre systematisk konfigurationsstyring på udviklet software steg betragteligt hos designerne i dette firma, da de kunne anvende deres egen løsning, udviklet af egne folk (designere).

Dette var et eksempel på, at det var en styrke, når designerne selv fandt deres egen udvej til at løse egne problemer.

Det var vigtigt at lade de folk, der dagligt var involveret i udviklingsarbejdet, selv udvikle værktøjer og procedurer, som efter deres mening ville forbedre processer og konkurrenceevne.

Det var vanskeligt at skabe en afdelingskultur. Designerne arbejdede gerne som individualister med egne metoder. Der er på en og samme tid behov for både styring og fleksibel organisation.

Dette dilemma skal løses af ledelsen sammen med medarbejderne.

Min lære om dette forløb samler jeg i nogle få råd til virksomheder, der udvikler software og it:

• Kvalitetsledelse er en god ting, men forudsætter, at medarbejderne inddrages i kvalitetsledelsen.

• Inddrag de ledere og udviklere, der planlægger og udfører produktudvikling.

• Udviklere og ledere skal sørge for at afklare, definere, vedligeholde og forbedre processerne til produktudvikling.

• Dette gælder uanset, de anvender en plandreven eller agil tilgang under produktudvikling*

• Gør disse processer til fælles gods for alle udviklere tilpasset det enkelte projekt. Dette er kun muligt, hvis software- og it-udviklerne selv deltager i arbejdet.

• Behovet for værktøjer, procedurer, processer og træning afhænger af firmaets størrelse og modenhed

* Mange virksomheder benytter både plandreven og agil tilgang eller kombinerer dem.