There are two possible outcomes: if the result confirms the hypothesis, then you've made a measurement. If the result is contrary to the hypothesis, then you've made a discovery.

Enrico Fermi

De essentie van High Performance
Praktijklessen van Agile, leiderschap en cultuur die het verschil maken tussen goed en excellent
Peter Stoppelenburg

Bij Bol.com | Managementboek

Motion does not equal action. Busyness does not equal effectiveness.

James Clear

Het groot online werkvormenboek
Dé inspiratiebron voor online vergaderingen, opleidingen en andere bijeenkomsten
Sasja Dirkse, Angela Talen, Annemarieke van Rumpt & Lotte Bons

Bij Bol.com | Managementboek | Amazon.nl

Haal je kop uit het zand!
Leren met zichtbaar resultaat
Stephan Obdeijn, Metteke Lubberts

Bij Bol.com | Managementboek

Sander van der Geest geeft in het artikel "Beter besturen met businesscases" (Informatie, april 2010) onderstaande top tien met succes- en faalfactoren voor ICT-projecten:

Succesfactoren

1. Heb het lef om een project te stoppen: “Door projecten te stoppen waarvan de business case gedurende de realisatiefase minder rooskleurig blijkt, maak je geld en resources vrij voor kansrijkere projecten."

2. Zorg voor betrokkenheid van de lijnorganisatie bij het inschatten van de baten: “De lijnmanager die aan de slag moet met het projectresultaat, kan een reëel tegenwicht geven aan de natuurlijke drang van de geestelijk vaders van ideëen om de baten te overschatten.”

3. Veranker batenmanagement in de controlcyclus: “Door het (gedeeltelijk) inboeken van geraamde baten in de doelstelling in de lijn kan batenmanagement verankerd worden in een organisatie."

4. Zorg voor vroegtijdige aandacht voor batenmanagement: "Aandacht binnen project en stuurgroep voor batenmanagement verhoogt de kans dat baten na afloop van het project geïncasseerd kunnen worden."

5. Hergebruik gegevens uit eerdere projecten: inschattingen van baten en lasten kunnen sterk verbeteren wanneer gebruik wordt gemaakt van realisatiecijfers uit eerdere projecten.”

Faalfactoren

1. Start het project zonder vastlegging van een minimale businesscase: “Het project zal snel van start kunnen, maar de kans is groot dat het na enige tijd stuurloos achter veranderende omgevingsfactoren aanloopt, waardoor de oorspronkelijke beoogde resultaten uit het zicht raken.”

2. Geef – ‘in de waan van het project’ – geen prioriteit aan het regelmatig actualiseren van de businesscase: “Het project zal de beoogde producten realiseren, maar de kans is groot dat de omgeving voor afronding veranderd is. Hierdoor kunnen de beoogde voordelen mogelijk niet (geheel) worden geïncasseerd.”

3. Zorg voor een matige structurering van het selectieproces voor projecten: “Helderheid over welke projecten wel en niet gestart worden en de motivatie van deze besluiten is essentieel voor een efficiënte inventarisatiefase. Bij onduidelijkheid over de besluitvorming wordt tot in het oneindige energie gestoken in stokpaardjes.”

4. Verwaarloos de niet-incasseerbare baten: een efficiencybesparing van 5 fte verspreid over 100 personen in de organisatie is zelden incasseerbaar.

5. Laat projecten lang lopen: naarmate een project langer duurt, stijgt het risico dat het project mislukt. “Grote projecten kunnen vaak worden opgedeeld in een aantal kleine projecten met elk een positieve businesscase door kritisch te kijken naar de relatie tussen de te verwachten baten en te realiseren functionaliteiten."

Zie ook: 7 kritieke succesfactoren voor IT-projecten

Bron: Beter besturen met businesscases, Sander van Geest, Informatie / april 2010

In 1532 publiceerde Machiavelli Il Principe (De Heerser, of misschien nu wel: De Manager), waarin hij al aangeeft waarom veranderen eng is:

Niets valt zo moeilijk te organiseren, niets maakt zo weinig kans op succes, niets is zo gevaarlijk bij het doorvoeren ervan, als vernieuwingen. Wie zich daarvoor inzet, maakt zich allen die van de oude situatie profiteerden tot vijanden – terwijl hij op weinig enthousiasme mag rekenen bij hen die uit de nieuwe toestand profijt zouden kunnen halen. Hun lauwheid spruit voort, enerzijds uit vrees voor de tegenstanders die zich op statuten en tradities kunnen beroepen; anderzijds uit het feit dat mensen over het algemeen achterdochtig zijn en nieuwigheden nooit echt vertrouwen voordat zij er beter van zijn geworden. Bijgevolg zullen allen die tegen veranderingen gekant zijn, bij elke gelegenheid fanatiek ten aanval blazen, en zullen de voorstanders liever de kat uit de boom kijken. Met als resultaat dat de positie van de vernieuwers en hun medestanders altijd gevaar loopt.

In dit Youtube-filmpje (4.17m) legt Jeff Monday helder uit wat de theorie van disruptieve innovatie (disruptive innovation) van innovatie-goeroe Clayton Christensen's inhoudt.

Ook Management Team geeft op haar website een bondige samenvatting van deze theorie:

Disruptive innovation beschrijft een proces waarbij een dienst of product ‘onderin’ de markt, met simpele applicaties begint, waarna het schijnbaar ongemerkt naar boven in de markt beweegt, waarbij het uiteindelijk de gevestigde orde opzijzet. Een ‘disruptive innovation’ geeft een heel nieuwe populatie toegang tot een techniek die voorheen was voorbehouden aan mensen met veel geld of met veel vaardigheden. Kenmerken van disruptive businesses, zeker in hun begindagen: kleine marges, kleine doelgroepen, simpele producten en diensten die aanvankelijk nog niet zo aantrekkelijk lijken als de bestaande producten. Volgens Christensen letten de meeste bedrijven te veel op innovaties die hun huidige positie beschermen, in plaats van goed te kijken naar wat het was waardoor ze historisch ooit succesvol zijn geworden. Dat opent als vanzelf de deur voor disruptive innovators, zegt hij. De mobiele telefoon, die in recordtempo de vaste lijn verdwong, is daarvan het meest pregnante voorbeeld.

Zie ook: Disruptief innoveren volgens Clayton Christensen (2)

Bron: http://www.mt.nl/90/30821/management/clayton-christensen-universiteit-in-crisis.html

Make It Stick
The Science of Successful Learning
Peter C. Brown, Henry L. Roediger II, Mark A. McDaniel

Bij Bol.com | Managementboek

In een interview in De Volkskrant (6/12/2011) gaat Chris Verhoef, hoogleraar informatica aan de VU, in op de rol van de (overheids als) opdrachtgever bij het mislukken van ict-projecten. Verhoef spreekt over echecs 'die iedereen met kennis van zaken van verre ziet aankomen'.

Verhoef gaat in op het belang van de Amerikaanse Clinger-Cohen Act; een harde wet op de financiering en ontwikkeling van ict-systemen uit 1996 die de boel vooral wakker heeft geschud: "De echte betekenis van de Clinger Cohen wet is dat het de voorwaarden opsomt waaraan een ict-project moet voldoen. Als we in Nederland zo'n regelgeving hadden gekend, had dat veel zeperds gescheeld.'

De reden waarom we in Nederland dergelijke regels (nog) niet hebben is - aldus Verhoef - '[o]mdat bij ons de bom nog niet gebarsten is en we de politieke discipline ontberen die nodig is om debacles te vermijden.' Met deze politieke discipline bedoelt hij '[d]at je als opdrachtgever niet elke dag iets anders zegt over wat je verlangt van je nieuwe systeem.'

Verhoef stelt dan ook dat de eerste vraag aan een opdrachtgever zijn: "Wat wilt u precies? Maar de politiek is volgens hem vaak (te) opportunistisch: "Ict'ers moeten meer weerstand bieden. Politici moeten zich beperken tot de wat-vraag en de hoe-vraag overlaten aan de lui die kennis hebben van creatieve problemen." "Verder waarschuwt hij voor een te hoog ambitieniveau: "We moeten niet meteen voor 100 procent gaat, 80 procent is al geweldig. Daarvoor kiezen, vergt politieke discipline. En die is ver te zoeken. Zo blijven we mislukkingen genereren."

Verhoef noemt als voorbeeld het rekeningrijden. "Er zijn files in het land. De vraag voor de politiek moet zijn: wat kan gedaan worden om doorstroming te bevorderen? Goeie vraag. Maar dan voegt de politiek er meteen aan toe dat er kastjes moeten komen in auto's, en dat het ons 3,5 miljard gaat kosten en een half miljard aan jaarlijks onderhoud. Dan kunnen we rekeningrijden. 'Maar wat is nodig voor rekeningrijden? Je moet weten wie wanneer waar op de weg is. Zo iemand moet je een rekening kunnen sturen. Je hebt dus een klantrelatie nodig. 'Nou, zo'n systeem hebben we al. Het heet trajectcontrole. Het stelt de overheid in staat te zien of jij te hard hebt gereden op een bepaald stuk weg. Zo ja, dan krijg je de rekening thuis gestuurd. Er is dus een klantrelatie. Ik zeg: stuur altijd een rekening, namelijk voor het gebruik van de weg in spitsuren. Rekeningrijden ingevoerd! Wat is nog het probleem'"

Ook het Electronisch Patiëntendossier noemt Verhoef als voorbeeld van een overbodig systeem. "Wat wilde men? Geautomatiseerde uitwisseling van gegevens tussen artsen om medische missers te voorkomen. Prima. Het draaide uit op enorm geharrewar. 'Het ergste is: we hebben al een geautomatiseerd systeem van medische informatie. het heet Vecozo, Veilige Communicatie in de Zorg en is een portaal van de vereniging van zorgverzekeraars. Ik denk dat 90 procent van alle declaraties van dokters via dat portaal loopt. (...) Het is een systeem waarvan ik zeg: petje af. En weer blijkt dat het probleem is opgelost en met bestaande middelen kan worden gerealiseerd."

In de Clinger-Cohen Act is geregeld dat het Office of Management and Budget (OMB) gaat over de spelregels voor nieuwe ict-projecten. Het OMB kwam met een set van zgn Raines Rules (genoemd naar de auteur), "een setje van acht regels; zo helder als glas en zo hard als staal. Regels als: kijk eerst of er een alternatief is. Lever een businesscase, een financieel-economische onderbouwing. Ontwikkel het project in kleine stapjes, zodat je tussentijds kunt bijstellen. Wie niet aan alle acht regels kan voldoen, krijgt geen geld en kan fluiten naar zijn project."

"Verhoef: 'Waar de kromming van een banaan gespecificeerd is in een Europese richtlijn is er voor ict gewoon niks in Nederland. Dat is echt te weining. Zo'n lijstje als dat van Raines inspireert: acht of tien harde heldere regels. Ik zou er meteen al een van Raines invoeren: ga niet een systeem bouwen dat al bestaat."

Zie ook: 8 gouden regels bij IT-investeringen: Raines Rules

Bron: interview met Chris Verhoef in De Volkskrant (6/12/2011) "Mijn eerste regel zou zijn: bouw geen ict-systeem dat al bestaat"; Jan Tromp