Opdrachtgeverschap tot in de puntjes…

Één van de opmerkingen die ik kreeg op mijn blog over korte sprints als succesfactor bij IT-projecten was dat de business goed moet weten wat zij willen. Als dat niet het geval is en de IT-afdeling dit niet goed scherp krijgt, is dat een groot risico voor de uitvoering en goede afronding van een IT-project. Maar hoe kunnen zij dat nu goed invullen? En welke rol kan de IT-afdeling hier zelf in pakken?

Goed opdrachtGEVERschap vanuit de business en goed opdrachtNEMERschap vanuit de IT is allereerst een kwestie van met elkaar bespreken wat de opdrachtomschrijving is en welke rolverdeling er gekozen wordt. We kennen de stappen business case, globaal, functioneel en technisch ontwerp, plan van aanpak en de uitvoering waarbij beide partijen een rol spelen. Die stappen moeten in elk project opnieuw gezet worden. “Maar dat kost weer extra tijd en dat doen we altijd zo…”. Ja, cliché misschien, maar het is knap vervelend om halverwege bij te moeten sturen (in het gunstigste geval) of achteraf te concluderen dat de rolverdeling niet duidelijk was.

 

IT_Project

 

Ieder mens heeft zijn eigen belevingswereld. Zo is in bovenstaande cartoon heel duidelijk te zien wat 10 verschillende mensen voor verwachtingen kunnen hebben. Des te belangrijker is het dat de neuzen dezelfde kant op komen te staan… maar hoe?

De IT-afdeling ondersteunt de business, dat is regel één! Zij vertelt de business dus niet wat zij moeten doen, maar denkt wél mee in hoe het beter kan. Daarnaast is het voor de IT-afdeling de taak om uit te leggen hoe de software gebruikt kan worden, maar wil dit in de praktijk nog wel eens doorslaan naar het uitleggen hoe de business zijn werk moet doen. Niet doen! Dat weten zij zelf veel beter, maar toch zien we een aanzienlijk verschil tussen plaatje 1 en 10.

“Communiceren is zo dicht mogelijk langs elkaar heen praten” is mij wel eens verteld, en zo is het. Het is héél verstandig om dié personen bij elkaar te zetten die elkaar begrijpen en inhoudelijk met elkaar kunnen sparren. Als opdrachtgever is het zaak om iemand naar voren te schuiven die de IT begrijpt, de nukken kent en er mee om kan gaan dat het een spelletje van 1-en en 0-en is. Aan de andere kant, is het als opdrachtnemer van belang daar afstand van te kunnen doen. De business wil snel veranderen, alles moet mogelijk zijn, maar wees realistisch over het afgeven van een prijs, tijd en planning.

Hoe meer details vooraf bekend zijn, hoe dichter bij het gewenste resultaat gekomen kan worden. Dan zit er misschien geen profiel op de band, maar hangt deze wel netjes aan een touw aan de boom in plaats van die ruwe houten planken waar je op de splinters mag zitten…

Korte sprints: de sleutel tot succes

Elke software-ontwikkelaar krijgt er mee te maken: een veranderende omgeving waarbij aanpassingen gedaan moeten worden in het project. Aanpassingen die niet voorzien waren, aanpassingen die geld en tijd kosten en dat willen we niet.

In elk project zijn er onvoorziene acties nodig, omdat niemand een volledig beeld heeft van wat er allemaal op het project afkomt. Software is complex en ‘onder water’ gebeurt veel meer dan wat er opgeschreven staat of wat er bij de projectleden bekend is. Daarom wordt er (als het goed is) ook rekening gehouden met onvoorziene werkzaamheden. De projectleider houdt hier rekening mee en ziet er op toe dat dit het resultaat van het project niet in gevaar brengt.

Te vaak gebeurt het dat er projecten over tijd en budget heen gaan. Dat er meer onvoorzien werk is, kan voorkomen. Maar vaker gebeurt het dat er door voortschreidend inzicht wijzigingen in de oorspronkelijke projectscope gedaan moeten worden. Langer lopende projecten willen nog wel eens tegen issues aanlopen als wijzigingen in software-versies, beschikbare mensen en/of tools en wijzigende infrastructuur. Het gevolg laat zich raden: extra kosten, meer tijd en dus: “wéér een mislukt IT-project”.

Om projecten succesvol te laten verlopen, is het aan te raden om met korte sprints (deelprojecten) te werken. De organisatie stelt de business case vast en hieruit rollen vaak meerdere wijzigingen die door IT doorgevoerd moeten worden. Door deze wijzigingen te verdelen in sprints, wordt voor iedereen duidelijk wat er wanneer opgeleverd moet worden en weet iedereen waar hij/zij aan toe is. Doordat de projectomvang beperkt is, kan de business case beter uitgewerkt worden en is er een beter beeld wat er allemaal bij komt kijken.

Oh ja, de business case moest eigenlijk gisteren al af zijn en daarom staat van meet af aan het project onder druk. Hoe sneller er opgeleverd kan worden, hoe beter het is. Doe de meest complexe onderdelen of onderdelen die door meerdere partijen gebruikt kunnen worden als eerste en de IT-afdeling krijgt meer grip en meer kans op succes. Door regelmatig op te leveren, krijgen zowel de organisatie die de business case oplevert als de IT-afdeling het gevoel dat het dus wel kan! Natuurlijk zijn er tegenvallers, maar als er in korte sprints gewerkt wordt, krijgt de business niet de kans om de scope van het lopende project te wijzigen. Hiervoor zijn er wijzigingsverzoeken of worden nieuwe sprints gestart. IT-projecten worden zo een stuk beheersbaarder en de samenwerking tussen IT en business verloopt een stuk soepeler.

Lees hier meer over een praktijk case bij de gemeente Rijswijk