Jeroen van de Rijt, Sicco Santema: Prestatieinkoop

“Wie steekt er boven het maaiveld uit?”

Prestatie-inkoop (best value procurement) is een “nieuwe” manier van inkopen, die zich afzet tegen het traditionele aanbesteden, waarbij je minitieus beschrijft wat je wil, op welk kwaliteitsniveau, wanneer, met welke mensen etc. In plaats daarvan geef je globaler aan wat je wilt en leg je een veel grotere accountability bij de opdrachtnemer.

Het boek begint dan ook de aannames onder het “traditionele” aanbesteden onder uit te halen en te wijzen op waar die controledrift toe leidt. Dat was zo enorm herkenbaar voor mij dat het bijna eng was..

Een citaat:
“Vaak bemoeit de opdrachtgever zich in hoge mate met de opdrachtnemer. Hij wil hem controleren, aansturen en eigenlijk vertrouwt hij hem niet zo. Deze activiteiten zorgen voor bureaucratie tussen opdrachtgever en opdrachtnemer en daarmee inefficiëntie in de keten waar vooral de matige aanbieders van profiteren.”

In “traditionele” aanbestedingen leg je vervolgens allerlei prestatienormen vast als minimumnormen (in ICT projecten: minimaal 98% uptime, binnen 2 uur reageren op incidenten, etc.). Daarover zeggen de auteurs het volgende: “Het definieren van minimum-standaarden zorgt voor een “u-vraagt-wij-draaien”-houding van aanbieders. Dit is de aanbieders niet aan te rekenen; het is de opdrachtgever aan te rekenen die pro-activiteit en accountability wegneemt van de aanbieders. De opdrachtgever zorgt ervoor dat geen enkele aanbieder zich “boven het maaiveld” kan uitsteken. Het is niet de bedoeling dat de opdrachgever “de hoogte van het maaiveld” definieert; het gaat erom dat de verschillende aanbieders kunnen aantonen waar zij zich in het maaiveld begeven!

Bij prestatie-inkoop daarentegen zijn er een aantal andere aannames:
– de opdrachtgever heeft niet de meest accurate kijk op de werkelijkheid in de keten;
– de opdrachtgever heeft vaak verwachtingen die niet realistisch zijn
– de opdrachtgever is niet de expert bij het inhuren van de expert
– de opdrachtgever weet niet wat hij niet weet

Andersom kun je ook stellen: een goede opdrachtnemer kan de wensen van zijn opdrachtgever vertalen naar een goede oplossing en zijn opdrachtgever adviseren over te maken keuzes. Hij is zelf de expert op zijn vakgebied en neemt daarvoor de verantwoordelijkheid in termen van verwachtingsmanagement, kwaliteitsnormen en planning. Daarvoor heeft hij vrijheid nodig en een opdrachtgever die hem als gelijkwaardige partner beschouwt.

Ik kwam met prestatie-inkoop in aanraking op een bijeenkomst van Agile Overheid waar Sjoerd Posthuma er iets over vertelde en via collega Anja Smorenburg, die er ervaring mee opdeed bij de Landelijke Voorziening WOZ.

Al lezend bekruipt me het een en ander aan schijnbare tegenstrijdigheden:
1. het lijkt een methodologie die heel erg op vertrouwen is gebaseerd, waarbij de verantwoordelijkheden op de juiste plek worden gelegd. Er zijn allerlei zaken die je als opdrachtgever niet meer specificeert, dat leg je immers bij de aanbieder. Tegelijkertijd zijn de stappen in het proces dan weer heel strikt. De Risks assessed mogen maximaal op één a4, de aanbieder krijgt alle risico’s van zijn niet geselecteerde collega’s er ook bij, de interviews moeten per se met één persoon en er zijn allemaal formatjes voor de verschillende stappen in het inkoopproces. Eigenlijk werken deze formats bevrijdend; door je op dat punt strikt aan het proces te houden, krijg je vrijheid op andere aspecten: de specifieke invulling van de vraag, hoe je bepaalde risico’s oplost en niet in het minst de pre-awardfase, waarin een gedetailleerd plan voor het uitvoeren van de opdracht wordt uitgewerkt;
2. als er ten hoogste drie of vier interviews gehouden mogen worden, dan lijkt het alsof het project dan dat wordt nooit te groot kan zijn; hoe kun je anders alle sleutelfiguren spreken? Bij de gemiddelde IT-aanbesteding zou ik tenminste met de projectleider, de technisch projectleider, de architect en de kwaliteitsmanager (en eventueel de infrabeheerder) willen spreken. Maar tegelijkertijd, als het een heel groot turnkey project zou zijn met beheer en implementatie er bij geleverd, dan ga je op een andere manier sturen en ontstaan er dus ook andere sleutelfiguren: de verantwoordelijken voor respectievelijk ontwikkeling, beheer en implementatie bijvoorbeeld. Ik vraag me wel af of bij dat soort projecten de risico’s op één a4 passen en of je van tevoren je budget kan vaststellen;
3. mensen maken het verschil, daarom zijn de interviews zo bepalend. Bij sommige inkooptrajecten is echter de kwaliteit van ingekochte onderdelen of de continuiteit van levering belangrijk, en dat zit meer in fabricageprocessen of in de structuur van eenorganisatie; zou je daar dan niet veel meer op moeten meten in plaats van de interviews? Dat kun je echter vastleggen in je gewenste kader en in de interviews kun je ingaan op hoe dat kwaliteitsniveau gehaald kan worden of die continuïteit verzekerd;
4. IT-aanbestedingen van de overheid zijn in toenemende mate sterk ingekaderd door bestaande standaarden en architecturen. Dat beperkt de vrijheid van de aanbieder nogal bij het kiezen van een optimale oplossing. Andersom zou de aanbieder die “boven het maaiveld uitsteekt”, dan weer optimaal gebruik kunnen maken van die al bestaande omgeving en juist daarop uitblinken.

Er zitten een aantal aannames onder prestatie-inkoop die niet zo expliciet worden gemaakt als degenen boven:
– het traject moet goed te plannen zijn van tevoren, je moet immers in de pre-award fase tot een volledig plan komen;
– het traject moet überhaupt te overzien zijn, want je moet immers van tevoren je budget aangeven;
– de (voorbeelden van) trajecten zijn met name gericht op de interactie tussen opdrachtgever en opdrachtnemer, in plaats van een multi-actor omgeving.

De trajecten waar ik zelf in werk zijn altijd meerjarig, met veel ketenpartners en nog niet veel meer duidelijkheid dan een politieke doelstelling aan het begin. Dat wil niet zeggen dat de methodiek onbruikbaar is, maar je gaat dan meer naar een metaplanning kijken, ordegroottes van budgetten en afhankelijkheden van elkaar. Ik kan me goed voorstellen dat een aanbieder “die boven het maaiveld uitsteekt” komt met voorstellen voor overlegstructuren of monitormechanismen voor de afhankelijkheden. Mantelovereenkomsten zijn ook een optie, zoals die van mGBA.

Ik kan het boek in ieder geval aanraden voor een frisse kijk op de relatie opdrachtgever/opdrachtnemer en de mechanismen om die gewenste relatie te bewerkstelligen.

www.prestatieinkoop.com
http://www.managementboek.nl/boek/9789077951002/prestatieinkoop-jeroen-van-de-rijt
http://pbsrg.com/

John Whitmore: Succesvol coachen

Whitmore is één van de grondleggers van het “moderne” coachen. Ik las het boek in het kader van de leergang Intercoach die ik mag volgen.

Coachen, ten opzichte van andere “beïnvloedingsstijlen”, richt zich op de zelfwerkzaamheid van de gecoachte. Er zit een geloof achter dat mensen hun eigen pad moeten vinden. Coachen als stijl richt zich dus op het helpen van mensen om hun eigen pad te vinden, in plaats van (bijvoorbeeld) ze te adviseren wat ze moeten doen. Daarbij zijn twee begrippen in samenhang van belang: bewustzijn en verantwoordelijkheid. Iemand die zich niet bewust is van zijn eigen gedrag kan het ook niet veranderen. En iemand die zich niet verantwoordelijk voelt voor een verandering zal er ook niets mee gaan doen. Wat mij enorm helpt is die twee termen continu in beeld houden als ik coaching als stijl wil toepassen. En tegelijkertijd, als ik vanuit die optiek kijk, zie ik ook hoe vaak ze niet gebruikt worden (en ook dat ik ze niet gebruik).

Whitmore gaat vrij uitgebreid op de achtergrond van coaching in en de mentaliteitsverandering van het moderne coachen versus het oude coachen (met name in de sport), waarbij je iemand de techniekjes aanleert en continue feedback geeft op de techniek. Whitmore en consorten kwamen uit op het concept “inner game”: wat gebeurt er binnen je op het moment dat je dat tennisracket, die hockeystick of die golfclub ter hand neemt.

Een zeer bruikbaar model om toe te passen in coachingssituaties is het “GROW-model”, waarbij je eigenlijk een volgorde van vragen doorloopt om uiteindelijk te komen tot concrete vervolgacties.
G: Goals: wat zijn je doelen?
R: Reality: wat is nu de werkelijkheid?
O: Options/Obstacles: wat zijn de opties en de obstakels om vanuit de werkelijkheid de doelen te bereiken
W: Way forward: wat zijn de stappen om te nemen

De auteur neemt veel ruimte om zijn kijk op de wereld over te dragen (milieu, economie, bankensector, kapitalisme), zogenaamd als context voor het belang van coaching. Wat mij betreft had het boek ook wel zonder die context gekund, maar je kunt hem vergeven dat hij het boek als platform gebruikt om zijn zorgen over de wereld te uiten.

http://www.performanceconsultants.com/sir-john-whitmore

http://www.bol.com/nl/p/succesvol-coachen/1001004010609021/

Jeff P. Howe: Crowdsourcing

“The coming big bang of business”

Steve Howe was als journalist een van de eersten die op crowdsourcing insprong (toegegeven, wel na Wisdom of Crowds uit 2004), en wel in Wired van juni 2006. In 2008 schreef hij er een boek over, toepasselijk genaamd: Crowdsourcing.

De waarde van het boek ligt niet zo zeer in een uitgebreide elaboratie op het begrip crowdsourcing, de toepassingsmogelijkheden of de do’s en don’ts. In plaats daarvan worden er heel veel voorbeelden uitgewerkt en dat in een schrijfstijl die “lekker wegleest”.

Howe gaat in op microfinanciering (Kiva.org), op onderzoek (Innocentive), op fotografie (iStockphoto), op het voorspellen van markten, het ontwikkelen van software (Linux) en nog meer. Het is een boel gejubel over crowdsourcing en het is moeilijk daar doorheen te kijken, maar het belangrijkste wat er door de voorbeelden heenschijnt is het “disruptive” gehalte van crowdsourcing initiatieven. Waarom zou je een fotograaf inhuren voor stockfotografie, als je foto’s voor 1 euro in licentie kan krijgen bij iStockphoto. Waarom een hele researchafdeling aan de gang houden als je iedere opdracht apart kan uitzetten als “wedstrijd”. En natuurlijk: waarom zou je een eigen encyclopedie gaan maken, als duizenden vrijwilligers het met veel plezier voor niks doen…

Dan nog maar eens de definitie:
“Crowdsourcing represents the act of a company or institution taking a function once performed by employees and outsourcing it to an undefined (and generally large) network of people in the form of an open call. This can take the form of peer-production (when the job is performed collaboratively), but is also often undertaken by sole individuals. The crucial prerequisite is the use of the open call format and the large network of potential laborers.”

Na het lezen van dit boek kun je moeilijk nieuwe initiatieven opstarten en dan niet nadenken hoe crowdsourcing er een rol in kan spelen…

http://crowdsourcing.typepad.com/

De kinderopvangketen; over het verbinden van beleid, uitvoering en ICT

De afgelopen anderhalf jaar was ik namens ICTU projectmanager van de ontwikkeling van het Landelijk Register en de Gemeenschappelijke InspectieRuimte Kinderopvang en Peuterspeelzalen (LR GIR KOP).

In de tweede helft van 2012 is LR GIR KOP overgedragen van programma naar een beheerfase en dat was een mooi moment om de lessons learned van het programma uit te werken. Dat resulteerde in een, mag ik wel zeggen, zeer fraai boekje waar vanuit verschillende invalshoeken geschreven is over de ontwikkeling, de implementatie en het beheer van LR GIR KOP. De hoofdstukken werden geschreven door DUO (beheer), KING (implementatie bij gemeenten en GGD’en), VNG en GGD (sturing vanuit hun respectievelijke landelijke organisaties), SZW (opdrachtgever en programmamanagement) èn door mij (vanuit ICTU over de ontwikkeling).

Het boekje werd als PBLQatie (vroeger HEC Papernote) gepubliceerd en is daarom te downloaden vanaf de site van PBLQ:
http://www.pblq.nl/publicaties/2013/papernote-40-de-kinderopvangketen

Ook ICTU schreef er een nieuwsbericht over.

Managing Successful Programmes

Ik mocht weer een diploma in ontvangst nemen, en wel dat van MSP foundation. MSP staat voor Managing Successful Programs en is een methodiek om programma’s te organiseren.

Een paar dingen bleven me erg bij:
– programma’s versus projecten
Voor de mensen en organisaties die heen en weer laveren tussen programma’s en projecten (en waar functietitels als programma- en projectmanager alom aanwezig zijn) is het goed om het onderscheid tussen projecten en programma’s scherp te houden. Projecten hebben een vastomschreven doel en resultaat. In Prince2 zie je dat die scope ook sterk wordt bewaakt in de fasering, in exception reports en in minimale rapportagevormen. Programma’s zijn vaak meer visiegedreven waarbij het eindpunt minder strak omschreven wordt. De sturing van programma’s en projecten is daarom anders. Programma’s worden veel meer gestuurd middels stakeholder management, visie en communicaties en projecten worden veel meer gestuurd op resultaten en planning. Als je een project aanstuurt als programma, dan gaan doelstellingen schuiven en worden resultaten vaag. Als je een programma aanstuurt als project doe je geen recht aan de vaak complexe omgeving en lever je een heel concreet resultaat op wat niet meer aansluit bij de omgeving.

– programma’s opzetten
In navolging daarop: je kunt niet “even een programma opzetten”. Bij een project lukt dat nog wel eens (mits mits mits), maar als je een vraagstuk serieus als programma wil definiëren, dan hoort daar een behoorlijke voorbereiding bij en een opdrachtgever die de samenhang ziet en ook haar omgeving kan organiseren.

– business change management
In MSP wordt vrij duidelijk een scheiding gehanteerd tussen de business (de operatie, vallend onder lijnmanagement) en het programma. Het programma moet “capabilities” (zie het als geïmplementeerde projectresultaten) opleveren waar vervolgens in de business “benefits” (zoals kostendaling, winstverhoging) mee worden gerealiseerd. Ik zal vast de enige zijn, maar ik maak nogal eens mee dat er een programma wordt opgezet, dat op zich mooie resultaten oplevert, maar die resultaten vallen op de grond omdat niemand er iets mee doet. In MSP wordt de verantwoordelijkheid voor het realiseren van de benefits bij een Business Change Manager gelegd. Deze staat naast de programmamanager, beide werken dus nauw samen en leggen verantwoording af aan de Senior Responsible Owner (de opdrachtgever). Terugkijkend heb ik deze situatie in de praktijk wel gezien, maar nooit zo formeel benoemd.

http://www.msp-officialsite.com/

Rini van Solingen, Eelco Rustenburg: De kracht van Scrum

“Een inspirerend verhaal over een revolutionaire projectmanagementmethode”

Hmm kennen we “The goal” en “The race” nog van Eli Goldratt? Daar deed het me enorm aan denken: een roman waarin een bedrijfskundig concept op verhalende wijze wordt toegelicht, rijkelijk geïllustreerd door een mysterieuze goeroe en toegepast in een probleemsituatie..

Dat gezegd hebbende is “De kracht van Scrum” een hartstikke leuk boekje, dat je in een paar uur uit hebt. Ok, misschien moet je het twee keer lezen om de termen een beetje tot je te laten doordringen..
Maar, anders dan gewoon met Scrum beginnen en werken, of Jeff Sutherland langs laten komen, is het boekje wel een hele goede manier om kennis te maken met Scrum.

Het verhaal: Pekka, een mysterieuze Finse software-ontwikkelingsgoeroe ontmoet bij toeval Mart, een getergde CTO met deadlineproblematiek en leert hem een nieuwe ontwikkelmethode: Scrum. De rest van het boek is gejubel over hoe het ontwikkelteam, na enig zuchten, de methode omarmt, hoe de productiviteit van het team toeneemt, hoe de kwaliteit en stabiliteit van de software verbetert, de klant blijer wordt, de CTO beter slaapt en hoe er alleen nog maar zaken worden ontwikkeld die echt toegevoegde waarde geven. Gelukkig zijn de auteurs zelf ook niet te beroerd om hun eigen kwaliteiten in het fictiegenre ter discussie te stellen.

Mocht ik te negatief klinken: het is een aanrader! In Scrum zit een aantal “zelfreinigende” psychologische mechanismen verborgen die ik nou precies belangrijk vind in management: de mensen in het team zelf verantwoordelijkheden en bevoegdheden geven, een transparant proces inrichten met natuurlijke meetmomenten, je opdrachtgever dicht bij je houden en in zijn rol duwen en focussen op zichtbare toegevoegde waarde die in reële stappen wordt gehaald.

http://www.bol.com/nl/p/de-kracht-van-scrum/1001004008563933/

Agile en contracten

Op maandag 17 september was er een bijeenkomst van Agile Overheid, een groepje gelijkgezinden die zich bezig houden met, je raadt het al, Agile in de Overheid. Niet per sé beperkt tot Agile ontwikkeling overigens, er zijn er ook die zich met Agile beleid, Agile beheer en Agile architectuur bezig houden om maar iets te noemen.

Op maandag ging de bijeenkomst over “Agile en contracten” en ik was er bij. Na een introductie op wat Agile en Scrum ook al weer is (nog een keer?), waren er twee presentaties. De eerste van Edwin de Vries van Concretor, die heel veel ervaring (aan overheid en aan leverancierskant) heeft met aanbestedingen. Hij beschreef eigenlijk een aantal stadia die veel van zijn klanten meemaakten, die buitengewoon herkenbaar waren:
1. fixed price, fixed date inkopen op basis van vastgesteld functioneel ontwerp: je loopt daar aan tegen het feit dat gebruikers van te voren moeilijk kunnen definiëren wat ze precies willen en dat er vrijwel altijd voortschrijdend inzicht is tijdens de ontwikkelfase. Het blijkt moeilijk om de vraag vooraf zo helder te maken dat de aanbesteding binnen de gestelde voorwaarden tot een succes leidt. Bovendien koop je altijd 1 “ding” in, waarbij de afstemming met de omgeving weer moeilijk wordt
2. Organisaties die veel (ICT) inkopen gaan vaak over naar het inkopen van een proces, in de vorm van mantels of een ontwikkelstraat: daarmee is beter geborgd dat bestaande en nieuwe ontwikkelingen op elkaar kunnen worden afgestemd, maar de grip op een ‘vast resultaat voor een vaste prijs’ valt deels weg. We werken nog steeds waterval en het blijft moeilijk om van te voren goed aan te geven wat je wil; het voortschrijdend inzicht kan nog steeds moeilijk worden verwerkt.

Belangrijk is ook de mentaliteit van de gebruiker bij bovenstaande stadia: die heeft de neiging om alles te vragen, want “misschien hebben we het nog eens nodig en als ik het nu niet vraag krijg ik het nooit”. Maar: inkooptechnisch is het goed te doen, binnen de geldende regels.

Langzamerhand beginnen steeds meer “demand” organisaties en gebruikers te vragen om Agile, omdat ze daar goede verhalen over hebben gehoord. De inkoper vraagt zich dan af: hoe kan ik dit inkopen, waarbij er ook weer stadia volgen:
1. mensen inhuren: via mantels of andere constructies huur je individuele mensen in, of een team. Inkooptechnisch goed mogelijk, maar je moet wel zelf de regie houden over het proces en de randvoorwaarden om dat proces te laten lopen. Bij LRK zitten we eigenlijk in die situatie, waarbij we heel veel grip hebben op het proces, maar tegelijkertijd ook zelf de verantwoordelijkheid overal over houden, tot en met de werkplekken toe.
Kenmerk van Agile is dan dat je veel meer samenwerkt tussen opdrachtgever en project en daardoor in de “co-creatie” samen verantwoordelijk bent. Inkooptechnisch al weer moeilijker.

2. een proces inhuren: dit is waar veel overheidsorganisaties nu mee bezig zijn: hoe kan ik Agile werken, daarbij een groot deel van de verantwoordelijkheid en regie bij de markt neerleggen, maar toch nog enige grip houden op het resultaat.

Hier ontstond (natuurlijk) veel discussie. Want als je van tevoren geen vast functioneel ontwerp vastlegt en je geeft zelfs toe dat dat nog wel eens kan veranderen in het traject; wat kun je dan wel vast leggen?
De antwoorden wisselden; een aantal dingen kun je zeker van tevoren vastleggen:
– een projectstartarchitectuur, waarin in ieder geval de richting van een oplossing duidelijk is
– randvoorwaarden voor het “agile proces” dat je gaat doorlopen met de leverancier
– de kwaliteit van de code (bijvoorbeeld in de aanbesteding van DigiD: minimaal 4 sterren SIG)
– een timebox van tijd en geld
– non-functionele eisen (bijvoorbeeld performance of beveiliging)
– èn: de uitkomst van de sprints. Alhoewel je niet weet wat of hoeveel je precies kan realiseren in een sprint kun je wel garanderen dat je aan het einde van de sprint werkende en geteste software hebt.

De discussie ging nog wat verder maar ik bleef met de vraag zitten: Wat koop ik precies in als ik Agile wil uitbesteden:
– een aantal mensen of zelfs een heel team?
– een ontwikkelproces?
– een aantal functiepunten die nader ingevuld mogen worden?
Het staat of valt met goede mensen en vertrouwen onderling, zie dat maar eens in een contract vast te leggen.

Misschien is “Prestatie-inkoop” daar wel een antwoord op. Collega Anja Smorenburg vertelde daar laatst over en op de Agile Overheid bijeenkomst was daar Sjoerd Posthuma, die het ook ter sprake bracht. Prestatie-inkoop, ook wel best value procurement, is een (aanbestedings-)proces, waarin je in een aantal stappen tot gunning komt. Dat is op zich normaal, maar in dit proces krijgt de leverancier de kans om een groot deel van de aanpak in te vullen en mee te denken over het resultaat. Dat is een hele andere benadering dan een dik Pakket van Eisen maken, waar alle leveranciers dan braaf exact mogen doen wat er staat en niet de kans krijgen hun eigen kennis in te brengen (totdat er voortschrijdend inzicht is of tegenstrijdige functionaliteiten boven komen..). Er is net een boek over verschenen, toepasselijk genaamd “Prestatieinkoop“. Maar eens lezen!

Er was overigens ook een uitstekend verhaal van Rini van Solingen en Paul Weghorst van Prowareness, die op zeer enthousiaste wijze het hoe en waarom van Agile werken nog eens toelichtten en dat zeer deskundig ook afzetten tegen de klassieke waterval-aanbesteding. Dat mocht ook wel trouwens want Rini is deeltijds verbonden aan de TU Delft voor een leerstoel over software-ontwikkeling en Paul Weghorst was jarenlang verantwoordelijk voor aanbestedingen bij Ordina.

Adam Lashinsky: Inside Apple

How America’s Most Admired – and secretive – company really works

Tsja. Het boek maakt de (onder-)titel niet waar.
Het mag inmiddels duidelijk zijn dat Apple wat onorthodoxe methoden van zaken doen heeft en ik kon niet wachten om daar eens meer over te lezen. Ik had het boek al besteld voordat het uitkwam en had nog even gewacht met het beginnen te lezen om de spanning er in te houden.

Wat volgde was een hartstikke interessant boek met allemaal leuke anekdotes van ex-Apple mensen en betrokkenen, maar… het geeft geen echt inzicht in Apple’s werkwijze. Natuurlijk wordt er bij Apple ontzettend veel gevraagd van de mensen, wat in allerlei voorbeelden wordt toegelicht. Apple gaat op een bijzondere wijze met de pers om, met marktonderzoek, met ontwerp van producten, maar: hoe doen ze dat nou?

Het komt er gewoon niet uit. Wat ik elders wel eens heb gelezen is dat van nieuwe applicaties de demoschermen helemaal tot op de laatste pixel worden uitgetekend, in plaats van de gangbare schetsen met “lorem ipsum” teksten. Vond ik niet terug. Hoeveel mensen werkten er aan het ontwerp van de iPod? Er wordt gesproken over een draaiboek voor product launches. Maar wat staat daar dan in? Allemaal vragen waar Lashinsky geen antwoord op geeft.

Een paar concepten die wel goed worden toegelicht zijn de DRI (Directly Responsible Individual), het feit dat ze bij nieuwe geheime producten een deel van het kantoor afzetten met nieuwe wanden en afsluiten voor iedereen die niet direct betrokken is, een aantal methoden om geheimhouding te betrachten. Het is dus echt wel een interessant boek, maar het heeft zeker niet de diepgang die ik ervan had verwacht… Ethan Rasiel’s The McKinsey Way had dat bijvoorbeeld weer wel.

En: er werd iets teveel informatie geleend uit de Steve Jobs biografie van Walter Isaacson.

http://adamlashinsky.net/

http://www.amazon.com/Inside-Apple-Americas-Admired-Secretive-Company/dp/1611130956