Monday, September 15, 2008
Top Down of Bottum Up of The best of Two Worlds
Bottum up is een probleem of uitdaging creatief aanpakken. Er is een idee van een oplossingsrichting. Die wordt getest, het werkt maar half. Een nieuwe richting ontstaat. Kortom de oplossing wordt gevonden door het te proberen en ontstaat tijdens het werk. Dit is de wereld van de doeners. Ook Agile software ontwikkeling en RUP werken zo. Net als veel kunstenaars. Zij kunnen producten maken.
Als je slechts een van de twee werelden toepast mis je veel. Niet alles is te top down plannen. Doe dit alleen op hoofdlijnen. Laat de makers de ruimte op hun manier de problemen aan te pakken. Beperkt hun tijd zodat de resultaten binnen de grenzen worden opgeleverd.
Geef beide werelden de ruimte en gebruik hun kracht: ratio en creativiteit.
Monday, April 21, 2008
Droom of Nachtmerrie
Ik kom ze nog steeds tegen. Projecten met requirements die op zichzelf allemaal heel valide zijn en een mooi doel nastreven. Het is bijna als een droom als het allemaal voor elkaar komt.
De praktijk is een stuk weerbarstiger. Na een lange tijd, soms meer dan een of twee jaar, blijkt dat de droom te hoog gegrepen is. De droom lijkt een nachtmerrie te worden.
Hoe kunnen we nu voorkomen dat dit gebeurd?
Inmon zie het al: groot denken en vooral klein starten. Dat is waar, maar hoe doe je dat dan.
De volgende 3 stappen kunnen helpen om een droom waar te maken.
1 Bedenkt je droom. Ga na wat je wilt bereiken en gebruik je fantasie.
2 Bedenk een plan. Ga na wat nodig is om je droom te bereiken, maakt een realistisch plan van aanpak. Hierbij zijn kleine stappen in de richting essentieel.
3 Ben kritisch. Doe een risico analyse, bedenk wat er allemaal fout kan gaan
Pas je plan van aanpak en/of je droom aan. Blijf de stappen doorlopen totdat je tevreden bent. Vaak helpt het om andere hieraan mee te laten doen. Op deze manier kan je een droom realiseren en wordt je droom geen nachtmerrie.
Friday, April 4, 2008
Doen wat je wilt
Doe wat u wilt,Niet alleen wat u kunt.
Met dit soort advertenties worden mensen geworven. Deze is van CAP.
Het lijkt leuk, maar wat kunnen ze er van waarmaken? In mijn ogen zijn het valse beloften.
Als ik een medewerker krijg die niet doet wat ie voor staat opgesteld (een boom omzagen) en als dat dan ook nog 10x zoveel tijd kost gaat ie er uit. Ongeacht hoe mooi het resultaat is.
Als je veel kan en wil doen wat je wilt, ga je niet in dienst bij een van de grote mensleveranciers!
Als je een kunstenaar bent, ga je toch geen hout hakken!
Sunday, March 9, 2008
Kennis en ervaring
Vorige week las ik een interessant artikel in het Brabants Dagblad. Het ging over de herbouw van een oude molen. Bij de werkplaats die dat uitvoerde was een korte schets voldoende om een ingewikkeld houten rader gestel te bouwen. Volgens de directeur kwam dit omdat de medewerkers veel kennis en ervaring hadden. Nieuwe medewerkers recht van school kunnen alleen van heel gedetailleerde tekeningen werken en het kost veel tijd die te maken.
Dat is herkenbaar. Gisteren had ik kennissen te eten. Ik ging op een gegeven ogenblik uitleggen hoe ik een onderdeel van een houten hekje wilde monteren. De tijd die het kost om het uit leggen is bijna net zo veel als om het uit te voeren.
Daar ligt de link met ICT. Het uitleggen van ingewikkelde zaken zoals DW en BI aan verschillende partijen kost veel tijd, zeker als het publiek niet echt geschoold is in het vak. Ook de ICT’ers hebben vaak hun eigen jargon en ideeën en het kost veel tijd nieuwe ideeën en best practices uit te leggen. Op zich is het een goede investering. Alleen vaak jammer dat de mensen na een tijd weer wat anders gaan doen.
In praktijk merk je dat het uitleggen van complexe zaken aan mensen met kennis en ervaring een stuk eenvoudiger is. Dat scheelt veel tijd en geld. Wel is het dan zaak goed te documenteren zodat anderen (beheer) het later op kunnen pakken.
Friday, February 22, 2008
Cobb’s Paradox (2)
In praktijk is het eenvoudig. Slechte projectleiders zijn er nog steeds. Laatst was ik adviseur bij een project en daar bleek de projectleider geen PID (of PvA) te kunnen schrijven, daar "had" hij mensen voor, ik dus. Zelfs naar het voorkauwen, ik heb een concept geschreven, maakte hij er niets van.
Nadat ik had aangegeven dat ik niet tevreden was over zijn kwaliteiten en houding (hij stond ook niet open voor constructieve feedback) heb ik de zaak overgedragen aan een andere collega.
Een paar maanden later zag ik zijn eindresultaat, niet om aan te zien! Het project zit nu, na een half jaar, nog steeds in onduidelijk vaarwater.
Aan dit soort praktijken kan ik behoorlijk ergeren! Maar het is wel duidelijk waarom projecten fout blijven gaan.
Friday, July 20, 2007
Cobb’s Paradox
"We know why projects fail, we know how to prevent failure—so why do they still fail?" Martin Cobb, Treasury board of Canada Secretariat, Ottawa, Canada
We weten welke factoren belangrijk zijn bij het falen van projecten. Deze zijn uitgebreid in kaart gebracht. Tevens zijn processen, methoden, technieken, tools en volwassenheidsmodellen ontworpen om dat falen te voorkomen. Toolkits te over, alsof een project met procedures naar succes te managen is. Ook de menselijke aspecten hebben de aandacht gekregen. Communicatieplannen, management technieken, teambuilding, kernkwadranten en zelfs enneagrammen zitten in de tas van projectmanagers.
Punt een, weten is niet voldoende. Het gaat erom dat je de kennis toepast en wel op het moment dat het nodig is. Voor velen is kennis een en doe het andere. Alleen als je kennis doorleeft is en je kunt het toepassen in stressvolle situaties wordt het effectief.
Punt twee, projecten zijn complex. In een bewegende omgeving iets nieuws neerzetten met een nieuw team en inspelen op steeds veranderende behoeftes heeft meer weg van een organisch systeem dan van een mechanisch systeem. De boven genoemde processen, methoden en technieken zijn mechanisch van aard. Ze zijn procedureel beschreven en “iedereen” kan het volgen.
De werkelijkheid is veel complexer. Zoals gezegd die is organisch, er is wederzijdse beïnvloeding tussen project en omgeving en de succesfactoren zijn steeds anders en veranderen tijdens het traject. Hier past geen methode. Wel kan je onderdelen van methoden gebruiken.
Wat telt is persoonlijk leiderschap. Vanuit je eigen kwaliteiten een bijdrage leveren aan de tot stand komen van een resultaat. Met een open geest de anderen tegemoet treden en samen naar oplossingen zoeken. Vanuit leiderschap kies je elementen uit de methoden die op dat moment nodig zijn. Je geeft zelf het goede voorbeeld en bent een inspiratiebron voor de anderen.
Teun van Aken heeft aspecten hiervan al een keer duidelijk beschreven in zijn boek “De weg naar projectsucces”. Dit werk is wetenschappelijk onderbouwd, maar zijn boodschap lijkt niet aan te slaan.
Tuesday, April 17, 2007
Doe het zelf of uitbesteding in BIDW
Van oudsher is BIDW het terrein van de business. Het credo is “give us the tools and we will finish the job”. Prima als mensen met verstand van de inhoud met behulp van intelligente (rapportage)tools zelf toepassingen kunnen maken.
Het onderliggende probleem is vaak dat de grondstof (gegevens) voor de rapportages niet zo eenvoudig te verkrijgen is en dat de kwaliteit ervan vaak niet voldoende is. Het standaard leveren van geïntegreerde gegevens van hoge kwaliteit is werk voor ICT professionals.
Ieder zijn vak denk ik dan. Doe het zelven van de business op het gebied van gegevens is vaak peny wise, pound foolish. Bezuinigen op gegevens levert op korte termijn besparing op, maar kost op duur veel geld. Rapporten maken kan de business vaak veel beter dan de ICT’ers, doe dat dus vooral zelf.
Professionalisering ontstaat door specialisatie en vooral door ervaring. Die ervaring is binnen BIDW een probleem. Binnen een (half) jaar ben je senior in je rol en binnen een jaar krijg je een andere rol, een ander aandachtsgebied of een andere toolset. Hoe kan je dan ervaring op doen en leren? Zo blijft het “doe het zelf” niveau in stand en worden keer de zelfde fouten gemaakt.
