Om tot een goede samenwerking te komen moeten zowel de leden van de IT afdeling als de ontvangende organisatie kennis van elkaars werkzaamheden hebben. Er moet ‘begrip’ en ‘respect’ en daardoor ‘vertrouwen’ voor elkaar ontstaan.
Tijdens mijn projecten ben ik vele projectleden uit IT afdelingen tegengekomen die hier echt alle moeite voor deden. Velen hebben hier dan ook mooie successen mee geboekt. Toch heb ik ook valkuilen gezien, waar men later wel verbeteringen op toepasten.
Valkuilen
- Informatiebijeenkomsten met de business. Echter georganiseerd door het project en het project bepaald de agenda. De opdrachtgever geeft aftrap, hierna enkel projectteam aan het woord.
- Tijdens bijeenkomsten worden presentaties gebruikt die zwaar op de technische inhoud van het project ingaan. Het tonen van een balken planning met daarin ‘initiatiefase’ – ‘definitiefase’ – ´ontwerpfase´ ‘bouwfase’ etc. Dit zijn termen die de organisatie veelal nog niet begrijpen.
- Bij participatie in de communicatiemiddelen van de organisatie meldt het project over requirements die beschreven worden, issues die nog openstaan, de functionele testen die nog lopen etc. Voor de leden van het projectteam en de IT afdeling herkenbare informatie, voor de organisatie vaak acabadabra waar men geen chocola van kan maken.
- Bij aanvang van projecten worden sessies als begin van de werkzaamheden (kick off) georganiseerd met zowel het projectteam als key users die vanuit de business betrokken worden bij het project. Hier wordt gemeld dat men van alles verwacht van de mensen, echter concreet wordt het vaak niet. Niet op inhoud en niet op tijdsbesteding. Gevolg is een groep mensen die voorlopig de eigen werkzaamheden blijft doen en wacht tot ze meer informatie ontvangen. Niet echt een betrokken groep dus.
De hierboven beschreven valkuilen behoeven niet heel veel aanpassing. Het gaat om een verschuiving in gedrag en opzet van andere presentaties. Dus eenvoudig op te lossen en kunnen een enorme verbeterslag creëren.
Bij aanvang van een IT project lijkt het zo goed voorbereid. Er hebben verschillende gesprekken met de opdrachtgever en het
management plaatsgevonden. Iedereen binnen het management vind de IT implementatie van groot belang en staat erachter. Dan vind het IT project aanvang en ineens lijkt de business niet thuis te geven. IT implementatie hoort gezamenlijk met business te lopen, maar de business heeft geen tijd voor de leden van het project.
Een veel voorkomend fenomeen waar leden van een IT project vaak niet goed weten op welke wijze op te reageren. Want, de
planning loopt voort en we moeten toch op tijd leveren. Toch? Echter op dat moment lijkt de planning, dus de kwantiteit van de IT implementatie van groter belang dan de kwaliteit. Want voor wie vindt deze implementatie nu plaats? Wie heeft er groter belang bij dat de juiste besluiten worden genomen, passend bij de organisatie?
Wanneer deze situatie voorkomt is tot op heden zo’n 70% van de IT projecten die gewoon voort gaan met de technische
voorbereidingen. De definitiefase gaat over op de ontwerpfase, de bouwfase en voordat we het weten zijn we aan het testen. Echter, is het IT product waar aan wordt gewerkt ook nog het product zoals de organisatie dit verwacht? Weet het projectteam nog steeds zeker dat de organisatie hetzelfde beeld voor ogen heeft als het team?
Een mooi ding van het geheugen van de mens is dat het trucjes met je uithaalt. Want aan het begin van de IT implementatie
heeft project en organisatie samen gezeten. Op basis van diverse gesprekken zijn de business requirements vastgesteld. Het project gaat nu aan de gang. Ondertussen gaat de organisatie ook verder met het eigen werk en in het achterhoofd leeft
nog het idee van het nieuwe systeem dat er aankomt. Het geheugen ontwikkelt het systeem ondertussen steeds verder. Wanneer er door het project geen verwachtingen worden gemanaged over het systeem, kan de organisatie steeds meer gaan verwachten.
Wanneer tijdens het testen het systeem dan voor het eerst zichtbaar wordt bij de organisatie, is de teleurstelling groot en zijn er discussies alom. Noodzaak om hier in het vervolg de implementatie op in te richten!
Mensen uit een IT project en de ontvangende organisatie hebben meestal een totaal verschillend DNA. Dit wordt vaak als excuus gebruikt waardoor men elkaar minder begrijpt en naast elkaar een project doorloopt. Terwijl een IT implementatie een grotere kans op succes heeft wanneer er wordt samengewerkt! Een verschillend DNA is hierbij eerder een voordeel dan een nadeel. Het betekend dat de samenwerking met elkaar aanvullend kan werken. Het kan de IT implementatie tot een compleet geheel maken.
Wanneer je het voordeel van verschillende DNA’s en daardoor verschillende karakters binnen een compleet IT project inziet, is het niet meer dan logisch dat het verder uitgebuit wordt. Naast de standaard project aanpak die inmiddels bij diverse projectimplementaties gewoonte is geworden, is het noodzakelijk om een aantal ‘zachtere’ gewoontes in de uitvoering van het project op te nemen. Zie dit niet als de spreekwoordelijke checklist, maar als iets wat standaard in het ‘bloed’ van de projectaanpak hoort te zitten.
Standaard gewoontes die tegenwoordig ook binnen de projectaanpak behoren te zitten:
- Stel gezamenlijke doelen met de opdrachtgever vast
- Zet gezamenlijke mijlpalen die de ontwikkeling richting het gezamenlijke doel volgen
- Neem de opdrachtgever standaard op in het implementatieteam
- Evalueer de mijlpalen samen met de opdrachtgever, stel hiervoor punten op die zowel voor organisatie als IT project noodzakelijk zijn
- Loop minimaal 1x per maand een dag mee met iemand binnen de organisatie waar het project betrekking op heeft
- Etc. eigenlijk zijn de mogelijkheden legio
Voor de mensen die in Bits & Bites denken kan het lastiger zijn om deze activiteiten te verzinnen. Let op: ook dit hoeven de projectleden niet zelf te verzinnen. Ontwikkel gezamenlijk met de opdrachtgever een aantal activiteiten waarvan jullie over en
weer van mening zijn dat ze essentieel zijn voor het wederzijdse begrip. Wanneer je er zelf als projectleider niet toe komt, kun je er voor zorgen dat iemand aan het project wordt toegevoegd die de projectleden hierin kan coachen en sturen. Dit betekent niet dat deze persoon (vaak een verandermanager of een communicatie adviseur) de gesprekken met opdrachtgever en organisatie zelf zal
uitvoeren, maar de projectleden en zelfs de projectleider kan hier wel mee geholpen worden.
Valkuilen van een checklist
Op de werkvloer is het algemeen bekend. De IT afdeling of een IT’er praat in bits & bytes. Daarentegen hanteert de organisatie meer en meer strategische termen. Er lijkt een ontwikkeling te ontstaan waarin men elkaar niet meer begrijpt en het gat van onbegrip wordt steeds groter. Een lastig fenomeen bij de implementatie van een IT systeem in een organisatie.
Een oplossing kan gevonden worden door tijdens elk IT project een checklist te hanteren. Met deze checklist zet je een eerste stap voor het verkrijgen van wederzijds begrijp bij een IT project. Echter, het is niet zaligmakend! Mensen die een neiging hebben om alles te standaardiseren moeten nu opletten.
Bij het bestaan van een checklist is de aanwezige valkuil nog enkel gebruik wordt gemaakt van de ‘standaard’ vragen en niet verder wordt gekeken. Het is belangrijk om hier je eigen gedrag te herkennen en te waken voor het doordenderen zoals altijd de manier was. Want veelal willen projectleden de aanpak standaardiseren en een checklist als standaard onderdeel in de project activiteiten opnemen. Sommige mensen noemen het cynisch het plaatsen van ‘vinkjes’ in het totaal van blauwe activiteiten.
Op welke wijze voorkom je dat je elke keer weer in dezelfde valkuil stapt? Benoem aan het begin van het project een activiteit waarbij je de checklist doorneemt met je opdrachtgever. Vraag aan de opdrachtgever wat deze van de checklist vindt en vraag een aanvulling. Denk hierbij niet dat je opdrachtgever op dit soort vragen niet zit te wachten. Want ieder mens zowel zakelijk als persoonlijk, vind het fijn als interesse wordt getoond in de eigen situatie en wanneer een mening wordt gevraagd.
Door veel door te vragen over de eigen organisatie en een opdrachtgever of sponsor daarna om advies te vragen zal deze vanaf het begin sneller het gevoel hebben dat alle moeite wordt gedaan om de organisatie te begrijpen. Want een begrip voor de organisatie, leidt tot producten die beter aansluiten op de bestaande organisatie.
Conclusie: Stap niet te vaak in de valkuil van standaardisatie, ga in gesprek met je opdrachtgever.