Het resultaat van ict-projecten stelt de opdrachtgever vaak teleur. ‘Te laat’, ’te duur’, ‘onvoldoende kwaliteit’; het eindresultaat voldoet niet aan de verwachtingen. Als de projectmanager kan samenwerken met een goede stuurgroep, hij de elementen waarop hij kan sturen onderling in balans houdt en het testen niet de dupe wordt van vertraging in eerdere fases is de kans op een goede afronding groot.
| Volwassen Bij het artikel De deadline is heilig (5 september 2003) van Nils Keuning vallen vanuit projectmanagement enkele kanttekeningen te maken, meent John Roos. Keuning stelt onder meer dat een projectleider stuurt op drie factoren: tijd, geld en kwaliteit. Er is een vierde stuurelement, ‘scope’, waarmee de projectmanager de opdrachtgever duidelijk maakt wat hij wel en niet oplevert aan producten. Verder stelt Keuning de programmeurs centraal. Trainingen, marketing, organisatiewijzigingen, procesverbeteringen; alles moet wachten tot zij klaar zijn. Vooraf gestelde ‘heilige’ kwaliteitsdeadlines zouden soelaas bieden. Softwareontwikkeling en projectmanagement zouden onvolwassen zijn en uitloop op projecten wordt nog steeds ingecalculeerd. Projectmanagement is de laatste jaren juist volwassen geworden. Het wordt gekwalificeerd volgens internationale standaarden (Prince2, Ipma). Deze professionaliteit zorgt ervoor dat veel aandachtspunten in ‘De deadline is heilig’ oplosbaar of gedateerd zijn en de aangedragen oplossingen deels achterhaald zijn. Opdrachtgevers stellen tegenwoordig hoge eisen aan projectmanagers en accepteren geen duurbetaald mismanagement meer. Dit is één van de redenen dat de vraag naar gecertificeerde projectmanagers groeit. Hoe lossen we de in ‘De deadline is heilig’ geschetste problemen op via projectmanagement? |
Met de vier stuurelementen moet de projectmanager het project in balans houden. Afhankelijk van de opdracht en de projectsituatie legt de stuurgroep met de projectmanager accenten op deze elementen, zonder dat de laatste de consequenties daarvan uit het oog verliest. De consequenties kunnen verstrekkend zijn en tot risico’s voor het project en het bedrijf leiden. Door vakmanschap in combinatie met projectprocessen, technieken en componenten moet de projectmanager dit in de hand kunnen houden.
Sturen op tijd alleen veroorzaakt tijdsdruk en kan leiden tot het afraffelen van werk of minder testen. Daardoor kan de kwaliteit onder druk komen te staan. Sturen op scope (een starre minimale en maximale grens) leidt tot beperkingen wat betreft geld, kwaliteit en tijd. De grenzen van het toelaatbare zijn rigide. Sturen op geld betekent dat je binnen de scope, kwaliteit en tijd alles moet realiseren volgens de gestelde criteria. Sturen op kwaliteit is ‘mooi’ maar kost tijd en geld, en kan de scope beïnvloeden.
Opdelen
Over de vraag of kwaliteit een voorgeschreven product is bestaan veel meningen. In dit artikel beschouwen we kwaliteit als meetbare criteria die aan een product gesteld zijn door de opdrachtgever en wettelijke regelgeving. Op basis van deze kwaliteitscriteria wordt in het project geproduceerd. Kwaliteitsdeskundigen controleren aan de hand van die criteria de producten.
In beginsel bepaalt kwaliteit niet de voor het project beschikbare middelen; deze vloeien voort uit de op te leveren producten en activiteiten en de daaraan gekoppelde middelen. De stuurelementen en de projectomstandigheden kunnen een en ander wel beïnvloeden. Deze beïnvloeding moet in balans zijn; overvloed schaadt. Er bestaan overigens rekenmethodes om een optimum te bereken, zoals fpa (functiepuntanalyse).
Kwaliteit moet in de denk- of voorlaatste fase van een nieuwe projectfase bekendgemaakt en vastgelegd zijn. De projectmanager wil graag alles weten voordat het project start. Soms is het echter onmogelijk om alles van te voren te weten en te plannen. Door fasegewijze projectsturing met stappenplannen is het mogelijk om in iedere voorlaatste fase de gegevens van de toekomstige in te vullen. Kennis en inzichten groeien vaak tijdens het project. Een bijkomend voordeel is dat de (kwaliteits-) planning een betrouwbaar gegeven wordt. Hierbij kan de projectmanager de pbs-techniek gebruiken (product breakdown structure).
Vergelijk pbs met Ikea-meubels. We kopen een boekenkast (eindproduct). De bijgevoegde tekening is de product breakdown structuur met productcodes en beschrijvingen. De losse genummerde en geproduceerde onderdelen vinden we per zakje in de doos. De montagevolgorde is de productiestroom; dit geeft de fases van ons project aan. Vervolgens bespreken we met onze huisgenoten (projectteam) het (project-) plan en starten we ons project.
Elk los onderdeel is in de fabriek beschreven met de daaraan gestelde kwaliteitscriteria en levertijden. Het projectmanagement kan hiermee exact het productieproces plannen, de levertijd per fase aangeven en alle productie-eenheden (projectteams) aansturen en controleren (kwaliteit). Deze simpele techniek geeft je als projectmanager structuur met de garantie dat het project op deze wijze te beheersen valt. Dit geldt ook voor softwareprojecten, hoewel daarbij niet alles meetbaar is.
Een project opdelen in meerdere kleine projecten lijkt een goed alternatief voor pbs. Losse projecten zijn echter moeilijker in hun onderlinge samenhang te managen. Fasering binnen projecten lost het probleem van de beheerbaarheid beter op en bewaart de onderlinge eenheid.
Veranderingen opvangen
Zaken als ‘vereisten’, ‘leuke dingen’ en ‘luxe’ worden in samenhang met de scope (wat doen we wel en niet) toegevoegd of uitgesloten. Veranderingen na het vastleggen van het projectcontract en het stappenplan worden beschouwd als een ‘verzoek om wijzigingen’. Uitgangspunt van deze aparte procedure is dat zonder goedkeuring van de stuurgroep en het overzien van de consequenties er geen wijzigingen plaatsvinden.
De afgesproken (kwaliteits-) criteria uit de denkfase of het stappenplan blijven leidend en zullen geen verrassingen of druk opleveren. Het project blijft bestuurbaar voor de projectmanager. De programmeur heeft hierin geen zeggenschap en voert alleen de werkorders van de projectmanager uit. Het enige wat een programmeur mag doen is verzoeken om wijzigingen melden bij zijn projectmanager of projectbureau. Dit noemen we ook wel een ‘projectissue’.
Wisselende projectteams en veranderde inzichten zijn risico’s als je ze niet analyseert en beheert. Veranderingen zijn op te vangen door een wijzigingsprocedure in het project. Een senior projectmanager heeft de kennis en ervaring om daarmee om te gaan. Een gecertificeerde projectmanager heeft daarnaast een theoretisch proceskader.
De stuurgroep is een cruciaal startpunt na het krijgen van het mandaat voor het project. Zonder goede stuurgroep met voldoende sponsorschap van alle vertegenwoordigde partijen is een project per definitie mislukt. Zij moeten zich eigenaar voelen en de gedelegeerde projectmanager alle middelen en gereedschappen voor de dagelijkse projectleiding ter beschikking stellen. Zonder overeenstemming en steun heeft de projectmanager onvoldoende macht en hulp om zijn project op te bouwen en uit te voeren. In de stuurgroep moeten minimaal een opdrachtgever (met een ‘business case’), een eindverantwoordelijke voor de gebruikers en een senior leverancier zitten. Zij leiden en sturen samen met de projectmanager de tijdelijke projectorganisatie. Dit is integraal projectmanagement.
Let wel: de stuurgroepleden zijn vaak niet opgeleid voor deze rol. Dit leidt meestal tot slecht management, tekortkomingen en het oneigenlijk afschuiven van taken op de projectmanager. Die moet dan het project managen zonder echte projecteigenaars; hij moet alles op eigen titel regelen, soms door manipulatie.
Angel eruit
Testen is vaak het kind van de rekening. Als alle projectfases uitlopen, moeten de testers dan in de slotfase opvangen. Deze situatie is vergelijkbaar met een omgekeerde piramide; alles rust op dat ene puntje.
Het tijdstekort in de laatste projectfase legt misplaatste druk op de testers en veroorzaakt daardoor stress. De verleiding om delen van de tests over te slaan is groot. Dit leidt tot kwaliteitsverlies en risico’s bij het in productie nemen, onnodig overwerk met als gevolg meer kosten en risico’s op deadlines.
De klant bepaalt vaak het in productie nemen. Hij staat onder druk van zijn achterban, die op een bepaalde datum over het systeem wil beschikken. Als het fout gaat wordt de leverancier geslachtofferd, wat slecht is voor zijn image. Dit alles is op verschillende manieren te voorkomen, waaronder ‘managing product delivery’ (mpd) en ‘stageplanning’.
Bij mpd geeft de projectmanager eerst in de desbetreffende stap (via werkpakketten voor de teamleiders) de producten vrij die ontwikkeld moeten worden. Vervolgens accepteert de teamleider het werkpakket en gaat hij met zijn team aan de slag. Tijdens de ontwikkeling bespreken de projectmanager en de opdrachtgever de voortgang. De opdrachtgever moet vanaf de eerste projectfase betrokken zijn bij het productieproces. Dit geeft hem betrokkenheid bij en inzicht in het project. Hij ziet iets ontstaan en krijgt verantwoordelijkheidsgevoel. Verder wordt bij het opleveren van een deelproduct in een projectstap al getest of het (tussen)product voldoet aan de kwaliteitscriteria. De klant woont deze test bij en accordeert het resultaat. Wijzigingen of ‘off’-specificaties worden in een vroeg stadium ontdekt en via een procedure hersteld. Dit betekent dat problemen al in die stap (dit kan zelfs de eerste projectfase zijn) worden opgevangen en opgelost, en dat de producttests gedurende het gehele project iteratief plaatsvinden. Zo’n aanpak in combinatie met een stappenplanning voorkomt dat de laatste testfase van het project het kind van de rekening wordt.
Als de projectmanager een stappenplan maakt, kent de stuurgroep exact de planning en de op te leveren eindproducten. Ook hier zijn wat variaties mogelijk. Het risico- en verassinggehalte is een stuk lager. Door de opdrachtgever vanaf het begin te betrekken bij het testen zal hij bovendien niet verrast zijn als het wat langer duurt dan afgesproken. Als het goed is kent de opdrachtgever de redenen voor tegenslag of uitstel al, zonder de uitleg van de projectmanager. De angel van het verrassingselement is zo geëlimineerd. < BR>
John Roos, Roos Projectmanagement
