Managed hosting door True

Bij sturing op kwaliteit kan software wél op tijd af zijn

De deadline is heilig

 

'It-projecten lopen altijd uit' - hoe vaak horen we dat niet? De it-branche staat nog altijd niet te boek als een volwassen, professionele sector. Vooral software-ontwikkeltrajecten zijn moeilijk beheersbaar. Of het nu om grote of kleine projecten gaat, standaardsoftware of maatwerk, het overschrijden van de deadline wordt vaak vooraf al ingecalculeerd. Dat maakt het sowieso psychologisch al problematisch om hem te halen, terwijl het belang daarvan veelal groot is. Als je stuurt op kwaliteit, lukt het de deadline als heilig te beschouwen.

Vaak zijn andere trajecten afhankelijk van de afronding van een softwareproduct. Trainingen en opleidingen, organisatiewijzigingen, procesverbeteringen, marketingcampagnes - allemaal moeten ze wachten totdat de programmeurs klaar zijn. Toch kan de oplossing simpel zijn: beschouw de vooraf gestelde deadline als heilig en zet er alles voor opzij.
Als projectleider leer je te sturen op drie factoren: (doorloop-) tijd, geld (gewerkte uren) en kwaliteit. Daarvan mag je er twee kiezen. Dat laatste blijkt niet altijd op te gaan. In een software-ontwikkeltraject kan je niet onbeperkt veel programmeurs en testers laten opdraven zodat je in ieder geval op tijd klaar bent met het vooraf beschreven product (kwaliteit). Afhankelijk van het te bouwen product heb je een ideale grootte van de groep ontwikkelaars. Verdere groei van het team levert steeds minder toegevoegde waarde op, totdat deze door de toenemende noodzaak tot afstemming en begeleiding zelfs negatief wordt.
Bij een vooraf bepaalde kwaliteit zullen tegenslagen in het project zich dus al snel uiten in een langere doorlooptijd. Je kunt het echter ook omdraaien: als de eindtijd heilig is, moet je dus sturen op kwaliteit. Hoewel dat op dit moment vrijwel nooit gebeurt, kan het bijna altijd.

Leuke dingen

Bij de specificatie van een nieuw softwareproduct wordt bijna altijd een indeling gemaakt in 'vereiste zaken' (must-haves), 'leuke dingen' (nice-to-haves) en 'luxe' (pure-luxury). Gek genoeg wordt de beslissing over welke zaken mee moeten al in de ontwerpfase genomen en niet overgelaten aan de loop van het project. Dat zet het niveau van de kwaliteit vast, zodat er weinig te sturen overblijft.
De belangrijkste voorwaarde bij het gebruik van kwaliteit als stuurfactor in een software-ontwikkeltraject is het onderscheid tussen wat gebouwd móet worden en wat gebouwd mág worden. Je moet dit opnemen in het functioneel ontwerp in plaats van al in de ontwerpfase daarover beslissingen te nemen.
Voor het succesvol uitvoeren van een project op deze wijze moet je aan meer voorwaarden voldoen. De '80 procent is goed genoeg'-regel vat de tweede voorwaarde samen. Er valt alleen wat te sturen als de 'leuke dingen' ook een behoorlijk percentage van de totale specificaties behelzen. Dit is vaak lastig te accepteren voor de opdrachtgever of eindgebruiker, want die moet er rekening mee houden dat eventueel slechts de gespecificeerde 'vereiste zaken' in het eindproduct terugkomen. Daarom moet hij genoegen kunnen nemen met 80 procent. Hij heeft dan wel de waarborg dat die 80 procent op tijd af is.

Van uitstel tot afstel

De derde voorwaarde is: beperk de lengte van het project tot maximaal drie á vier maanden. De belangrijkste redenen voor de uitloop van projecten zijn onvolledigheid tijdens het specificatieproces, wisselingen in de samenstelling van het projectteam (aan de kant van zowel opdrachtnemer als opdrachtgever) en 'voortschrijdend inzicht'.
Projectleiders van software-ontwikkelprojecten (van de uitvoerende partij) letten altijd scherp op mogelijke nieuwe inzichten aan de kant van de opdrachtgever. Deze betekenen een extra opdracht (plus extra budget) die de opdrachtgever wel uit moet laten voeren. Bovendien geeft dit de bouwende partij de kans om af te komen van de in de offertefase afgesproken deadlines.
Wisselingen in het projectteam en voortschrijdend inzicht leiden niet alleen vaak tot uitstel, maar soms ook tot afstel. Dit is allebei grotendeels te voorkomen door de lengte van het project te beperken tot maximaal drie á vier maanden. Hiermee verklein je het risico dat projectleden gedurende het project een andere functie krijgen of hun betrokkenheid anderszins wijzigt. Daarnaast beperk je de kans dat nieuwe inzichten het project een heel andere richting geven en daarmee vertragen.
Voor een groot project betekent zo'n maximale lengte een opdeling in kleinere projecten, ieder met zijn eigen doelstelling en op te leveren eindproduct. Ieder deelproject moet een eigen resultaat opleveren dat niet alleen een voorwaarde is voor het vervolgproject, maar ook een positieve stap betekent als het vervolg onverhoopt geen succes blijkt te zijn. Ook zonder het vervolgproject moet een deelproject dus zélf wel een succes kunnen worden; ieder deel moet zijn eigen bedrijfstoepassing hebben.

Terechtwijzing

Sturen op kwaliteit tijdens de bouw kan alleen als er een groot vertrouwen is bij de opdrachtgever in de integriteit van de bouwende partij. Wie neemt de beslissing bepaalde 'leuke dingen' te laten vallen zodat de deadline gehaald kan worden? Dat kan alleen de bouwende partij zijn. Dit vraagt veel vertrouwen van de opdrachtgever, want het is nooit precies te controleren wat de precieze reden is van het inkrimpen van het resultaat.
Fouten tijdens de bouw, onvolledigheid tijdens het ontwerp of een verkeerde inschatting van de werkzaamheden? Een terechtwijzing bij ieder onderdeel dat niet gehaald wordt, komt de samenwerking en dus het projectresultaat niet ten goede. Je moet als opdrachtgever en -nemer duidelijk toe zijn aan een dergelijke werkwijze.
Verder vraagt het heilig verklaren van de einddatum om snelle beslissingen van de opdrachtgever. De praktijk leert dat het nagenoeg onmogelijk is om van tevoren alle specificaties op te schrijven zonder er één te vergeten. Het is dus vrijwel zeker dat tijdens de bouw nog enkele niet volledig gespecificeerde zaken naar boven komen. Dit vraagt om snelle beslissingen van de opdrachtgever, wil je de deadline nog halen. Niet alleen moet hij (of zijn gedelegeerde) beslissen of iets een 'vereiste' of 'leuk' is, vaak ook moeten nog echte (ontwerp-) beslissingen worden genomen. Hoe zit die berekening precies in elkaar, welke gegevens hebben we nodig, waar in het proces voeren we een en ander uit, met welke systemen moeten we een interface ontwikkelen enzovoort.
Daarvoor is een grote betrokkenheid van de opdrachtgever in het project nodig. Het laatste wat je wilt is dat het dagen- of zelfs wekenlang duurt voordat iets is uitgewerkt. Een puur it-project waarbij bepaalde fasen het moeten doen zonder betrokkenheid van de bedrijfskant of een beslissingsbevoegde eindgebruiker zal bijna nooit aan deze eisen kunnen voldoen.

Niet efficiënt

De volgende voorwaarde lijkt vanzelfsprekend: bezuinig niet op het testproces. De testfase is nu nog te vaak het kind van de rekening als eerdere fases zijn uitgelopen, in een laatste poging toch nog de deadline te halen. Iedereen weet dat testen belangrijk is en dat je daarop niet mag bezuinigen, maar toch gebeurt het. Ook in zo'n geval is de kwaliteit van het product de dupe, met dit verschil dat een niet volledig uitgevoerd testproces betekent dat je niet weet welke kwaliteit je product heeft.
De kwaliteit zou dus goed genoeg kunnen zijn, maar het kan ook betekenen dat zelfs de 'vereisten' niet gehaald zijn. Daarmee bereik je niet wat je juist in een testproces wilt bereiken: beperking van de risico's van de implementatie. Als je kwaliteit als stuurfactor gebruikt, moet je er op zijn minst zeker van zijn dat de kwaliteit die je tijdens het project al sturend hebt bepaald echt wordt gehaald. Een dergelijke projectopzet vraagt juist een grotere betrokkenheid van de testers bij de bouw. Tenslotte wordt tijdens de bouw nog bepaald welke 'leuke dingen' afvallen. Testers moeten dit weten.
Het uitvoeren van een project op deze wijze heeft ook invloed op het ontwikkelproces. Je begint met de bouw van de 'vereisten'. Daarna ga je verder met de 'leuke dingen'. Dit kan betekenen dat je misschien niet de efficiëntste wijze van programmeren kiest. Het liefst zou je één ontwikkelaar een bepaalde module helemaal laten afmaken (vereist, leuk én luxe) om daarna te starten met de volgende. Nu moet je beginnen met de 'vereisten' van een bepaalde module en keer je later eventueel terug om aan de 'leuke dingen' te werken.
Ook hier is het van belang de risico's in het project zoveel mogelijk naar voren te halen. Hoe sneller tegenvallers worden opgemerkt, hoe meer er valt bij te sturen.

Klaar

Als je aan al deze voorwaarden kunt voldoen en je hebt als opdrachtgever en -nemer een klimaat geschapen waarin een goede samenwerking voorop staat, kan je keer op keer de gestelde deadlines te halen, met alle positieve gevolgen van dien. Je kan de trainingen van de eindgebruikers op tijd starten, eventuele reclamecampagnes (in- of extern) uitvoeren, voorbereide organisatiewijzigingen in gang zetten, licenties op vorige programmatuur stopzetten enzovoort. Bovendien is het projectteam zelf ook klaar voor zijn volgende opdracht. Dat volgende project kan op tijd beginnen en, mits op dezelfde wijze aangepakt, ook op tijd gereed zijn. < BR>

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/1329218). © Jaarbeurs IT Media.

?


Lees meer over


 
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×