“Simon en Sting, da’s toch geen combinatie!”

Zondagavond speelden Sting en Paul Simon in de Ziggo Dome en dat was boven verwachting goed! Nu zijn het natuurlijk grootheden in de muziekwereld, maar of dat samen gaat qua muziekstijl? En na North Sea Jazz vorig jaar had ik er eerlijk gezegd een hard hoofd in of Paul Simon dát kon brengen wat hij en zijn Afrikaanse drumband ooit in New York Central Park ten gehore brachten in 1990 of aan het niveau van Sting kon tippen wat hij live op het podium brengt.

Op North Sea stonden Sting en Paul Simon na elkaar op het podium en was er een wereld van verschil. Paul Simon die gewoon zijn ding deed, speelde zijn hits, maar om nu te zeggen dat er erg veel swung in zat en de zaal er warm voor liep? Nee, dat niet. Sting daarentegen gaf een goede show, muzikaal sterk en vrijwel foutloos spel. Dat was bij Paul Simon dus anders, maar gisteravond brachten zij allebei het beste in elkaar naar boven. De show, die maarliefst 3 uur duurde, was van begin tot eind boeiend en van hoog niveau.

Ze speelden hun klassiekers, samen en alleen, zongen duetten en om en om, en alles met een gemixte band van 16 man sterk. Alle muzikanten bij elkaar was een bont gezelschap van heel goede muzikanten, waarvan sommigen zelfs meerdere instrumenten bespeelden. Centraal stonden natuurlijk Sting en Paul Simon zelf, maar zij lieten hun muzikanten hun moment of fame. Die kans pakten ze met beide handen aan, want de solo’s waren goed, heel goed. De uithalen van Jo Lawry (achtergrond-zangeres) waren heel indrukwekkend tijdens Mercury Falling, maar ook de solo’s van Jamey Haddad (Simon’s percussionist) en de gitaristen en toetsenisten waren een knap staaltje muziek.

Doordat ze elkaars nummers afwisselden, maar ook sommige stukken hun eigen nummers speelden, vond ik Sting muzikaal toch sterker, creatiever en met meer gevoel. Paul Simon vond ik wat aan de zoetsappige kant en van de makkelijke, losse meezingnummers. Maar al met al zeker een geslaagd concert, want wat Paul Simon aan energie miste op het podium in North Sea Jazz afgelopen jaar, maakte hij hier ruimschoots goed. Hij nam zijn band en publiek mee in zijn enthousiasme en dat maakte veel goed. Muzikaal staat hij alleen 2-0 achter tegen het fenomeen Sting. Fragile, zo zuiver, Fields of Gold, nostalgisch, Mercury Falling, kippenvel…

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

Bijna klaar…

Zo, bijna klaar… Nog een plaatje hierboven en dan verder met vullen. Waarover? Mijn passies: werken in de software business (sorry voor de digibeten 😉 ), muziek, eten, drinken en golf.

En ja, het blijft een verrassing of er in het nederlands of engels geschreven wordt 🙂