Uiteraard overdreef ik met de automative om je uit de tent te lokken. Jij serveert de complete ICT en ICT-ers af vanwege arrogantie etc en scheert alles over één kam.
Overigens, er gaat buiten de ICT ook het nodige fout op het gebied van niet-ict projecten (haagse tramtunnel, betuwelijn, hsl-lijn, noord-zuid metro, etc), die ''strategisch noodzakelijke'' fusies (waar het bedrijf niet beter wordt, maar de bonus van de top wel), die fantastische financiele producten (o.a. beleggingsverzekeringen) en talloze commerciele initiatieven die het soms maken maar vaak ook niet. Daarover lees ik nooit zoveel kritiek over van van jou, maar dat terzijde.
Als het dan een mind-set of attidude is die bij ICT-ers ontbreekt hoe kan jij dan als HRM-er ''ons'' daarbij (wel) helpen? Je vakbroeders die ik bij een aantal multinationals ben tegen gekomen hielpen alles en iedereen met vacatures en opleidingen, behalve de ICT-afdelingen. Want dat konden / wilden ze er niet bij hebben. Hopelijk word jij onze rots in de branding en is er nog hoop!
Reactie: Er zijn 101 redenen en manieren (risico's) te bedenken waarop projecten mislukken. Dit zijn zeker niet de 5 belangrijkste. Als ik kijk naar mijn eigen ervaring als riskmanager of adviseur binnen projecten dan wordt als een belangrijk risico of succesfactor gezien:
1. Het al dan niet kunnen overzien en doorgronden van het gehele project of programma
2. Het al dan niet beschikken over deskundige en ervaren projectmanagement
3. De sterke afhankelijkheid van derden en het al dan niet adequaat managen van raakvlakken/interfaces met de bestaande organisatie of andere projecten
4. Het al dan niet goed weten wat we willen en het groot aantal tussentijdse wijzigingen of veranderingen waar weer rekening mee gehouden moet worden
5. De kwaliteit van de projectbeheering zoals quality assurance, integrale en risicogebaseerde planning en begroting, managementrapportages over status vs budget e.d.
Twee uitspraken die naar mijn idee aardig in conflict met elkaar zijn
''Ik denk niet zwart-wit, maar ....''
''Vakantie is vakantie, punt uit! ''
Ik check mijn mail in de vakantie en heb daarnaast voldoende tijd om te ontspannen. Gelukkig ben ik ook niet zo stellig en zwart wit. Ik denk dat ik daardoor ik minder vakantie nodig heb dan u. Relax en ga niet voor anderen voorschrijven hoe de wereld in elkaar zit. Spreek voor u zelf!
Ú doet niets op vakantie! Fijn dat dát voor u werkt. Mag het anders voor een ander zijn?
Reactie: U interpreteert een poll als ''gelijk hebben''.
De poll geeft aan, dat toch nog 40% mensen tijdens de vakantie bereikbaar voor hun werk zijn. Dat is in mijn visie fundamenteel verkeerd en heb dat kort en helder onderbouwd.
Uw reactie is hoogst merkwaardig.
Ik denk niet zwart-wit maar vanuit een basale oorzaak- en gevolgenreeks, en dat dan als uitgangspunt en bijdrage aan de stelling. Merkwaardig, dat u verder opmerkt dat ''anderen mijn statement niet delen''.. dat mag, maar is feitelijk en inhoudelijk absoluut niet relevant.
Vakantie is vakantie, punt uit!
Reactie: Ik denk dat je in je eerste alinea precies aangeeft waar de schoen wringt.
ICT is lineair en de wereld is tenminste 3 dimensioneel. Met een lineair systeem kun je de problemen van bedrijven niet oplossen, zo simpel is het.
Vergelijk het met modelbouw, een van mijn hobbies.
ICT is te vergelijken met een radiografisch bestuurbare auto. Hij gaat altijd vooruit, je kunt de snelheid regelen en ook de richting.
Een bootje wordt wat moeilijker, omdat de ondergrond beweegt op een moeilijk voorspelbare manier. Vliegtuigen gaan nog steeds hun neus achterna, maar kunnen ook in hoogte veranderen, tweedimensioneel dus.
Helicopters kunnen alle kanten op en doen dat ook op de meest onverwachte en onvoorspelbare momenten. Ze vereisen een continue concentratie. Dat is het bedrijfsleven en in mindere mate de overheid ook.
Met lineair denken is het onmogelijk een driedimensioneel schaakspel te spelen.
Het grote probleem van bedrijven is ook dat de managers veelal zijn opgeleid in een lineaire tak van sport, techniek of financien. Daardoor wordt te veel lineair gedacht en worden de problemen alleen maar groter.
Reactie: Punt 4 is mede ook een belangrijk punt. Ik zou er nog aan toe willen voegen dat belangrijk is dat iedereen gedurende het traject positief blijft denken. Belangrijk zaken als een maandelijkse update van de stand van zaken en de kernpunten blijven benoemen.
Als u naar het door mij gebruikte voorbeeld verwijst, dan is het prettig als u ook begrijpt wat ik heb bedoeld.
In het voorbeeld (en in de rapporten van de Rekenkamer) wordt immers aangegeven dat de starre functie-eisen worden veroorzaakt door de regels voor Europese aanbesteding.
Die vereisen dat iedere aanbieder een prijs etc afgeeft op basis van dezelfde informatie.
Die vereisen dat je daar achteraf niets meer aan mag veranderen, want dat ondergraaft de eerlijkheid van die aanbesteding (of leidt tot juridische gevechten met aanbieders die de opdracht niet hebben gekregen).
Die gaan volledig voorbij aan het feit dat de wereld (mede op basis van politieke besluitvorming) voortdurend verandert en dat daarmee juist een softwareproject zelden of nooit tevoren is vast te pinnen op strakke functie-eisen.
Die zijn dus gemaakt voor simpele overheidsaankopen, zoals de auto's waar u kennelijk verstand van heeft.
Hoe u dit voorbeeld nou weer kunt verdraaien naar arrogant gedrag van ICTers is me echt een raadsel.
Reactie: Natuurlijk wordt banenverlies reeler. Het is elke keer hetzelfde liedje: bij hoogconjunctuur denkt alles en iedereen dat deze omstandigheid eindeloos zal voortduren. Komt er dan weer een daling in de conjunctuur, dan is paniek weer de leidsman.
Banen bestaan bij de gratie van een succesvol opererend bedrijf en daar zit hem de kneep. Bedrijven in NL zijn helaas te weinig innovatief en onvoldoende in staat om andere wegen in te slaan. Altijd wordt weer gekozen voor (massa)ontslagen, waar verbeterde, nieuwe, aansprekende baanbrekende producten en diensten minstens zo vaak een antwoord zijn. In een door mij uitgevoerd onderzoek blijkt dat 70% (!) van de bedrijven een dikke onvoldoende scoort op innovatie (producten/diensten/customer value) en beweeglijkheid (organisatie en bezetting aanpassen aan onstandigheden).
Reactie: We kennen de frustratie van Ad de Beer inmiddels wel, dus laten we maar niet meer op hem reageren.
Het onderwerp: Testen, is wezenlijk. Alle suggesties, zoals die uit het artikeltje en de aanvullingen van Willem, Teun en Marcel zijn waardevol.
Ik voeg daar graag aan toe, dat het ook verstandig is om eerst de basisfunctionaliteit van de toepassing te testen en dan in een 2e tesfase pas naar uitzonderingen te kijken. Dat scheelt veel ontwikkeltijd en energie.
Reactie: Zeer herkenbare aspecten.
Ik zou er nog een zesde aspect aan toe willen voegen, namelijk het ontbreken van het gevoel van urgentie. Waarom is dit project noodzakelijk, wat is het gevolg van het niet uitvoeren cq niet slagen van het project. Door het creëren van een urgentiegevoel onstaat er binnen het projectteam ook een gemeenschappelijk doel.
Reactie: De vijf punten waarop een plan kan struikelen zijn helder en welbekend. Er is een zesde punt en dat is het niet kunnen aanpassen van de planning aan veranderende omstandigheden, waarbij het doel gelijk blijft of herijkt wordt. Net als een kano in woelig water verandert de positie van een project voortdurend. Je kunt dan ijzerenheinig dezelfde kant op blijven roeien, maar misschien kom je dan midden tussen de rotsen terecht. Veel projecten zijn dus te star opgezet en kunnen, eenmaal op gang, nauwelijks nog een kant uit.
Reactie: De aangegeven 5 manieren waarop een project mislukken zijn zeker waar. Het zal veel mensen die in projecten zitten en hiermee te maken krijgen veel beter helpen als item 4 hier niet meteen geweld werd aangedaan. Beschrijf i.p.v. redenen waarom projecten niet lukken nu eens de voorwaarden die er voor zorgen dat de kans groot is dat het project wel goed wordt opgeleverd.
Daarnaast mis ik een aantal belangrijke items, waar het mijns inziens juist vaak al direct bij de start mis gaat. De drie belangrijkste zijn volgens mij: start een project altijd met een Business Case en blijf die gedurende het project toetsen of ze nog geldt (punt 3 geeft enkele facetten hiervan aan). De tweede : zorg voor duidelijk en helder opdrachtgeverschap.
De laatste : zorg voor goede, duidelijke communicatie. Zowel binnen de projectorganisatie als naar stakeholders.
