Eller sagt på en anden måde: Sikring af at projektet leverer kvalitet, er nøglen til en glad kunde.
Kvalitet er ikke omfang (scope)! Manglende omfang er ikke det samme som manglende kvalitet. Det er blot en kunde, der er skuffet over ikke at få det hele med i første omgang. I de fleste projekter er det sikrere at levere mindre end at slække på kvaliteten.
Men hvordan er det nu lige jeg får styr på kvaliteten?
Kvalitet er ikke omfang (scope)! Manglende omfang er ikke det samme som manglende kvalitet. Det er blot en kunde, der er skuffet over ikke at få det hele med i første omgang. I de fleste projekter er det sikrere at levere mindre end at slække på kvaliteten.
Men hvordan er det nu lige jeg får styr på kvaliteten?
Hvad er kvalitet egentlig?
Kvalitet er ikke er en fast størrelse. Er en Porche-sportsvogn et kvalitets køretøj? Hmm, det afhænger af, hvad vi skal bruge køretøjet til. Hvis det er til at flytte en kummefryser, så ”nej”. Men hvis det er for at kunne køre hurtigt så ”ja”.
Det afgørende er, hvad der af kunden og brugeren af produkterne betragtes som afgørende for, at produktet fungerer.
Ofte er det vanskeligt at skelne funktionalitet fra kvalitet. Det er på en måde også ”to alen ud af samme stykke”. Vi taler netop om kvalitetstolerancer, og dermed indikerer vi, at vi taler om den sidste lille snas, der skal være en del af produktet, for at kunden er tilfreds med produktet. Den del som kunden betragter som værende afgørende for, at produktet kan anvendes til sit formål.
Er vi ikke opmærksomme, og får vi ikke aftalt kvaliteten præcist med kunden, risikerer vi, at vi synes, vi har leveret tæt på 100 % af det krævede, men kunden er ikke tilfreds og mener måske nærmest, at produktet er ubrugeligt på grund af den ene procent, der mangler.
Spørger vi fx kunden om hvor mange fejl, der må være i et it-system, er svaret ofte ”ingen”. Vi må så skuffe med at svare ”det er umuligt at undgå” og så arbejde med at kvalificere fejl i it-systemet. Fx kan det være, at kunden kan acceptere, at der forekommer x antal stavefejl, men at der ikke må være beregningsfejl.
Lad os se lidt nøjere på, hvordan vi kan beskrive og styre kvalitet:
Kvalitetskriterier – Kvalitetstolerancer – Kvalitetsmetode
Vi har brug for kvalitetskriterier: De skal være eksplicitte og målbare.
Eksempel: ”Krav til overflade: Dørene skal leveres malet med blank hvid maling”.
Men ”blank” er et vidt begreb! Vi kan nemt ende med, at kunden ikke er tilfreds, selvom vi synes, at dørene ser blanke ud. Vi må være mere præcise:
Med kvalitetstolerancer kan vi kvalificere kvalitetskriterierne.
Eksempel fortsat: ”Kravet til overfladeglans / -blankhed: Der skal anvendes en maling med en glansgrad på mellem 85 og 100 i det, der måles i henhold til DIN 67 530”.
Vi kunne have valgt endnu mere snævre kvalitetstolerancer og sagt, at glansgraden skal være 90.
Vi bør nu udtænke, hvordan vi kan tjekke at kvalitetstolerancerne er nået:
Vi har behov for en kvalitetsmetode: Hvilken kvalitetskontrolmetode skal der anvendes? For eksempel: Review, måling, test, prøveudtagning, interview med brugere, etc.
Eksempel fortsat: ”Glansgraden for malingen kontrolleres ved visuel inspektion af de uåbnede malerdunke, hvor det af etiketten fremgår, hvilken glansgrad malingen har”.
- det behøver jo ikke at være kompliceret.
Dertil skal der tænkes over, hvilke kvalifikationer, der kræves af dem, der skal tjekke kvaliteten, og hvem der skal tage ansvaret for kvalitetskontrollen.
Vi skal også lige have aftalt med kunden, hvad kvalitetskriteriet for ”hvid” er. Farven ”hvid” er jo mange ting…
Disse retningslinjer for at beskrive kvalitet fremgår af PRINCE2’s ledelsesprodukter. Du kan hente ledelsesprodukter med indbygget vejledning her.
Hvad nu hvis vi arbejder agilt?
De overordnede kvalitetskrav vil normalt være fikseret i en agil sammenhæng. På det detaljerede niveau handler det om at give en passende tolerance (fleksibilitet) på kvalitet, så teamet kan arbejde agilt.
Det kræver kundeinvolvering, når kvalitetskriterier skal specificeres, prioriteres, ændres, eller når der skal korrigeres ved forsinkelser. Det kan projektlederen ikke, da kompetencer og mandat fra forretningen kan mangle - og styregruppen har sjældent tid. Derfor har man i den agile verden den supervigtige rolle ”Product Owner”.
Det er de samme diskussioner, og de samme beslutninger, der skal tages. Der er intet, der bliver nemmere i min optik, fordi det kræver, at vi har kundens repræsentant involveret tættere i selve udviklingsprocessen, og at kundens repræsentant fungerer og har mandatet.
Sådan kan du styre kvaliteten i dit projekt
Dybest set handler det hele om, at vi ender med en kunde, der kan godkende det leverede produkt. Selve godkendelsen kan i sig selv være forholdsvis enkel. Foreligger der en Produktbeskrivelse med kravene til kvaliteten, så skal den sammenlignes med det leverede produkt. Dette kan ske mere eller mindre formelt og der kan benyttes komplekse eller simple kvalitetsmetoder.
Inden vi kommer dertil – gerne længe inden – skal vi sikre os, at vi er på rette vej. Det kan kræve en del diskussioner med kunde og bruger samt dokumentation og planlægning. Jeg vil ikke komme yderligere ind på det her, men kan anbefale, at du besøger – eller genbesøger – PRINCE2’s tema om kvalitet.
Et par cases
Jeg hjalp en offentlig styrelse med at planlægge og herunder definere en række produkter. De havde meget vanskeligt ved at få styr på definitionen af kvalitet. En del af projektet handlede om at udarbejde bekendtgørelser. På et tidspunkt i forløbet havde vi styrelsens direktør på besøg i projektgruppen, idet vi havde bedt hende om at redegøre for sine forventninger. Hun sagde, at hun forventede ”Fleksible bekendtgørelser, der levede op til de politiske forventninger”. Det var kvalitetskrav hun fremkom med. Det man i PRINCE2 kalder ”Kundens Kvalitetsforventninger”.
Jeg hjalp et meget omfattende infrastruktur anlægsprojekt i energisektoren. De var i gang med planlægningen. I projektgruppen spottede jeg en medarbejder, der så godt sur og irriteret ud, og jeg undrede mig over hvorfor. Det viste sig, at han var ansvarlig for kvaliteten. Problemet var, at projektet ikke havde defineret deres produkter ordentligt, de lænede sig op ad: ”Vi har prøvet det før, så det er cirka som sidst”, og dertil en række branchestandarder. Den stakkels medarbejder havde ikke en chance for at få defineret eller styret kvalitet på ukendte eller ikke-eksisterende specifikationer af produkterne.
7 gode råd
Det er forhold, som dem jeg har nævnt i artiklen, vi arbejder med på kurset ”Lær PRINCE2 Ordentligt”. Teorien omkring kvalitet er i sig selv udfordrende nok i PRINCE2-metoden, men det er ikke nok at lære den, hvis man ikke har forståelse for de faktiske problemer, som man vil møde.
Kvalitet er ikke er en fast størrelse. Er en Porche-sportsvogn et kvalitets køretøj? Hmm, det afhænger af, hvad vi skal bruge køretøjet til. Hvis det er til at flytte en kummefryser, så ”nej”. Men hvis det er for at kunne køre hurtigt så ”ja”.
Det afgørende er, hvad der af kunden og brugeren af produkterne betragtes som afgørende for, at produktet fungerer.
Ofte er det vanskeligt at skelne funktionalitet fra kvalitet. Det er på en måde også ”to alen ud af samme stykke”. Vi taler netop om kvalitetstolerancer, og dermed indikerer vi, at vi taler om den sidste lille snas, der skal være en del af produktet, for at kunden er tilfreds med produktet. Den del som kunden betragter som værende afgørende for, at produktet kan anvendes til sit formål.
Er vi ikke opmærksomme, og får vi ikke aftalt kvaliteten præcist med kunden, risikerer vi, at vi synes, vi har leveret tæt på 100 % af det krævede, men kunden er ikke tilfreds og mener måske nærmest, at produktet er ubrugeligt på grund af den ene procent, der mangler.
Spørger vi fx kunden om hvor mange fejl, der må være i et it-system, er svaret ofte ”ingen”. Vi må så skuffe med at svare ”det er umuligt at undgå” og så arbejde med at kvalificere fejl i it-systemet. Fx kan det være, at kunden kan acceptere, at der forekommer x antal stavefejl, men at der ikke må være beregningsfejl.
Lad os se lidt nøjere på, hvordan vi kan beskrive og styre kvalitet:
Kvalitetskriterier – Kvalitetstolerancer – Kvalitetsmetode
Vi har brug for kvalitetskriterier: De skal være eksplicitte og målbare.
Eksempel: ”Krav til overflade: Dørene skal leveres malet med blank hvid maling”.
Men ”blank” er et vidt begreb! Vi kan nemt ende med, at kunden ikke er tilfreds, selvom vi synes, at dørene ser blanke ud. Vi må være mere præcise:
Med kvalitetstolerancer kan vi kvalificere kvalitetskriterierne.
Eksempel fortsat: ”Kravet til overfladeglans / -blankhed: Der skal anvendes en maling med en glansgrad på mellem 85 og 100 i det, der måles i henhold til DIN 67 530”.
Vi kunne have valgt endnu mere snævre kvalitetstolerancer og sagt, at glansgraden skal være 90.
Vi bør nu udtænke, hvordan vi kan tjekke at kvalitetstolerancerne er nået:
Vi har behov for en kvalitetsmetode: Hvilken kvalitetskontrolmetode skal der anvendes? For eksempel: Review, måling, test, prøveudtagning, interview med brugere, etc.
Eksempel fortsat: ”Glansgraden for malingen kontrolleres ved visuel inspektion af de uåbnede malerdunke, hvor det af etiketten fremgår, hvilken glansgrad malingen har”.
- det behøver jo ikke at være kompliceret.
Dertil skal der tænkes over, hvilke kvalifikationer, der kræves af dem, der skal tjekke kvaliteten, og hvem der skal tage ansvaret for kvalitetskontrollen.
Vi skal også lige have aftalt med kunden, hvad kvalitetskriteriet for ”hvid” er. Farven ”hvid” er jo mange ting…
Disse retningslinjer for at beskrive kvalitet fremgår af PRINCE2’s ledelsesprodukter. Du kan hente ledelsesprodukter med indbygget vejledning her.
Hvad nu hvis vi arbejder agilt?
De overordnede kvalitetskrav vil normalt være fikseret i en agil sammenhæng. På det detaljerede niveau handler det om at give en passende tolerance (fleksibilitet) på kvalitet, så teamet kan arbejde agilt.
Det kræver kundeinvolvering, når kvalitetskriterier skal specificeres, prioriteres, ændres, eller når der skal korrigeres ved forsinkelser. Det kan projektlederen ikke, da kompetencer og mandat fra forretningen kan mangle - og styregruppen har sjældent tid. Derfor har man i den agile verden den supervigtige rolle ”Product Owner”.
Det er de samme diskussioner, og de samme beslutninger, der skal tages. Der er intet, der bliver nemmere i min optik, fordi det kræver, at vi har kundens repræsentant involveret tættere i selve udviklingsprocessen, og at kundens repræsentant fungerer og har mandatet.
Sådan kan du styre kvaliteten i dit projekt
Dybest set handler det hele om, at vi ender med en kunde, der kan godkende det leverede produkt. Selve godkendelsen kan i sig selv være forholdsvis enkel. Foreligger der en Produktbeskrivelse med kravene til kvaliteten, så skal den sammenlignes med det leverede produkt. Dette kan ske mere eller mindre formelt og der kan benyttes komplekse eller simple kvalitetsmetoder.
Inden vi kommer dertil – gerne længe inden – skal vi sikre os, at vi er på rette vej. Det kan kræve en del diskussioner med kunde og bruger samt dokumentation og planlægning. Jeg vil ikke komme yderligere ind på det her, men kan anbefale, at du besøger – eller genbesøger – PRINCE2’s tema om kvalitet.
Et par cases
Jeg hjalp en offentlig styrelse med at planlægge og herunder definere en række produkter. De havde meget vanskeligt ved at få styr på definitionen af kvalitet. En del af projektet handlede om at udarbejde bekendtgørelser. På et tidspunkt i forløbet havde vi styrelsens direktør på besøg i projektgruppen, idet vi havde bedt hende om at redegøre for sine forventninger. Hun sagde, at hun forventede ”Fleksible bekendtgørelser, der levede op til de politiske forventninger”. Det var kvalitetskrav hun fremkom med. Det man i PRINCE2 kalder ”Kundens Kvalitetsforventninger”.
Jeg hjalp et meget omfattende infrastruktur anlægsprojekt i energisektoren. De var i gang med planlægningen. I projektgruppen spottede jeg en medarbejder, der så godt sur og irriteret ud, og jeg undrede mig over hvorfor. Det viste sig, at han var ansvarlig for kvaliteten. Problemet var, at projektet ikke havde defineret deres produkter ordentligt, de lænede sig op ad: ”Vi har prøvet det før, så det er cirka som sidst”, og dertil en række branchestandarder. Den stakkels medarbejder havde ikke en chance for at få defineret eller styret kvalitet på ukendte eller ikke-eksisterende specifikationer af produkterne.
7 gode råd
- Få projektets kunde(r) til at udtrykke, hvad de forventer i forhold til kvalitet. Sørg for at du har dialogen med den eller de rigtige interessent(er)
- Beskriv eksplicit kvalitetskriterier og tolerancer fx som en del af produktbeskrivelsen
Husk at få kundens godkendelse heraf - Fastlæg hvilken kvalitetsmetode, der skal anvendes.
Husk at få kundens godkendelse heraf - Fastlæg i første omgang, hvilke krav, der er til kvalifikationer til dem, der skal kontrollere kvaliteten.
Husk at få kundens godkendelse heraf - Indgå klare aftaler med kunden om, hvem der kan godkende beskrivelserne af kvalitet, pkt. 1-4 ovenfor!
- Beskyt kvaliteten af dine produkter ved at baseline dine produktbeskrivelser, så kvaliteten ikke sænkes ubemærket, når projektorganisationer bliver presset på tid og økonomi
- Hvis du arbejder agilt, bør du beskytte det overordnede niveau (typisk produktbeskrivelsen) mens teamet gives fleksibilitet via prioritering af kvalitetskrav (tolerancer) på det detaljerede niveau
Det er forhold, som dem jeg har nævnt i artiklen, vi arbejder med på kurset ”Lær PRINCE2 Ordentligt”. Teorien omkring kvalitet er i sig selv udfordrende nok i PRINCE2-metoden, men det er ikke nok at lære den, hvis man ikke har forståelse for de faktiske problemer, som man vil møde.
