Tag Archive for Projectmanagement

Werner Vogels (Amazon)

Interview met Werner Vogels, werkzaam als CTO van Amazon, bij Top Names (fastmovingtargets). Inspirerend, verhelderend en leerzaam.

“Jeff Bezos, de baas, de leider van Amazon, wilde iets helemaal anders doen. Hij wilde online toegang tot alle boeken van de wereld bieden. Daar heb je techniek voor nodig. Alles van reviews tot recommendation is technologie gedreven. We happened to do retail. Iemand als Jeff kan fundamenteel anders dan anderen denken. Dat is de kracht. Hij is een leider met visie: Amazon wants to be the world’s most customer centric company. Daar wordt alles aan getoetst. Soms kannibaliseren we onze eigen business om uiteindelijk het beste voor de klant te doen.”

“Working from the customer backwards noemen wij dit principe. Wij werken heel hard met de klant samen. De klant bepaalt waar het product naartoe gaat. Je weet snel of een product succesvol wordt en als het dat niet wordt, kun je snel bijsturen.”

“Als jij als bedrijf plotseling groot wordt, hoef je niet naar de bank om veel geld te lenen om een compleet serverpark in te richten, maar kan jouw techniek via diensten van Amazon meegroeien met het succes. Vroeger was je grootste angst op een feestje dat niemand kwam opdagen, op internet is de grootse angst dat iedereen komt aanzetten.”

“Alle waist, alle extra’s, moeten worden uitgesloten. Die trend zie je overal. Ook ga je zien dat alle lange contracten uit de IT de deur uitgaan. Iedereen haat dat model. Het is niet meer nodig. Je gaat alleen nog die software kiezen voor de tijd die nodig is. Niet langer. Dan trek je de plug eruit.”

 

Share on TwitterShare via email

Estimations

Het inschatten van de projectwerkzaamheden is misschien wel een van de meest uitdagende onderdelen van het totale project. De wijze waarop de inschattingen tot stand zijn gekomen zal normaliter de uitkomst en het succes van een project grotendeels bepalen. Zonder onderbouwde inschattingen geen planning, zonder planning geen sturing en zonder sturing geen beheersing.

Gedurende het totale project kunnen er in ieder geval vijf verschillende fasen worden onderscheiden, beginnend bij de ballpark fase en eindigend bij de sign-off. Naarmate de kennis over de klant groter is, het einddoel gespecificeerd en afgebakend en deze kennis over een groter aantal teamleden is verspreid, zal de kwaliteit van inschatting beter zal worden. Het is de uitdaging om dit optimum zo snel mogelijk te bereiken zonder hierbij de kwaliteit van het resultaat te belemmeren. Kwaliteit is in dit geval een breed begrip. Het staat niet alleen voor de kwaliteit van bijvoorbeeld de code of de hoeveelheid bugs, maar eerder nog of het resultaat zal worden geaccepteerd door haar doelgroep als volwaardige oplossing voor een probleem en/of commerciele invulling. Mijn primaire uitgangspunt hierbij is dat het eindresultaat moet voldoen aan de verwachtingen op het moment van opleveren. De rode draad gedurende het gehele project zijn hierbij de minimaal benodigde requirements en het budget.

In de aanloop van een project zullen er een aantal kerntaken moeten worden uitgevoerd. Naast een functioneel- en technisch ontwerp, kan hierbij worden gedacht aan een testplan, risico inventarisatie en het invullen van de definitions of done. Verder zal er veelal, met name in een commercieel traject, een ballpark zijn afgegeven om een budgetindicatie af te kunnen geven.

  • Ballpark: Een high-level budgetindicatie op basis van de op dat moment aanwezige informatie. Dit kan een aangeleverd Functioneel Ontwerp zijn, maar het is belangrijk om te realiseren dat een dergelijke inschatting een beperkte waarde heeft. Er kan globaal rekening worden gehouden met aanwezige randvoorwaarden en/of eisen en het gewenst om hier al een MoSCoW-analyse toe te voegen, maar je mist hierbij de input van het development team bij de kwaliteit van bugettering. Een ballpark moet om die reden echt gezien worden als startpunt en niet meer dan dat.
  • Functioneel- en Technisch Ontwerp: Beide documenten zullen gedurende het project verder aangevuld en uitgewerkt moeten worden, maar de basis omvat in ieder geval voldoende afbakening voor de start van de eerste Iteratie. Daarnaast is het raadzaam om de resultaten uit de MoSCoW-analyse toe te voegen en de Must-haves in dit stadium al verder uit te werken.
  • Definition(s) of Done: Binnen een project zijn een aantal vaste fasen te onderscheiden: Story, Iteratie, Acceptatie en Productie. Voor elk van deze momenten kun je een Defintion of Done bepalen. In principe geeft dit een vertaling van de kwaliteitseisen waar elke fase aan moet voldoen. Hierbij kun je denken aan de vastgestelde kwaliteitseisen, zoals code coverage, bugfixing, e.d., en werkzaamheden uit het Testplan.
  • Budgetteren Iteratie(s): Vanuit enerzijds een opsomming van uitgewerkte stories en anderzijds eenduidigheid over de kwaliteitseisen en activiteiten per story (definition of done), kan er gestart worden met het inschatten van de werkzaamheden voor een Iteratie. Belangrijk hierbij is om discussie en concensus te bereiken. Hiervoor is het noodzakelijk dat alle teamleden afzonderlijk van elkaar een inschatting geven en zij voldoende ruimte krijgen om zijn/haar inschatting te verdedigen.

Naarmate het project verder gestalte krijgt, zal het team beter in staat zijn om kwalitatief betere oplossingen en inschattingen te maken. Dit is een combinatie van in een ‘flow’ raken en individuele kwaliteit binnen het team. Aan de individuele kwaliteit binnen het team zal ook een beperking gelden. Het vermogen om vanuit een bepaalde afstandelijkheid naar een functionele eis te kijken en hierbij geen aannames te doen heeft een beperking in de tijd. Het is belangrijk om hier scherp op te blijven en niet vanuit een ‘comfortzone’ het project te managen. Verse inzichten binnen het team betrekken, het organiseren van een klankbord sessie of het laten rouleren van verantwoordelijkheden kan hierbij helpen.

Share on TwitterShare via email

Communicatie

Elk project start met een fase van wederzijds aftasten. Wie zijn de contactpersonen, wat zijn hun persoonlijke doelen en welke onuitgesproken belangen hebben zij. De doelstelling van dit eerste contactmoment is het vaststellen van een gezamenlijke ambitie. Gedurende het verdere verloop van het project is het zaak deze gezamenlijke ambitie te bewaken en vast te houden.

Een project manager moet zich houden aan de drie bouwstenen van project management, namelijk: faseren, beheersen en beslissen. Daarnaast moet het doel: sturen op resultaat, centraal staan in het project. In de praktijk zal dit inhouden dat er na een formeel akkoord op de projectovereenkomst een stapje terug zal worden gedaan. Akkoord op de projectovereenkomst hoeft in de praktijk nog geen akkoord te betekenen op de projectopdracht. Eensgezindheid hierin is van essentieel belang voor het gemeenschappelijke projectresultaat en dus het welslagen van de projectopdracht.

Ten behoeve van de afbakening, zal een project manager gebruik maken van het toekennen van rollen en de hierbij samenhangende bevoegdheden en verantwoordelijkheden. Hierbij kun je denken aan de rol van Product Owner en de invulling van Stuurgroep. Daarnaast zal er ook oog moeten zijn voor de meer onuitgesproken verwachtingen. Projecten ontstaan veelal vanuit een Programma. Bij de totstandkoming van Programma’s zijn vaak veel stakeholders betrokken of raken in een later stadium betrokken. Het aantal gesprekspartners kan dus een veelvoud zijn van de personen waarmee de Project Manager daadwerkelijk contact heeft. Het is belangrijk om dit te signaleren en te onderkennen.

Er zijn verschillende tools om de communicatie met de opdrachtgever gestalte te geven. Hierbij valt te denken aan diverse word- en excel templates, maar ook aan tools als skype en mail voor de communicatie en Greenhopper, Pivotal, Omniplan en MSProjects om de voortgang en status te delen. Uiteindelijk zijn dit, naast het benoemen van rollen, hele mooie en goede hulpmiddelen, maar dienen zij ter ondersteuning van de dialoog.

Vanuit de gedachte dat de eerder genoemde middelen een ondersteunende functie hebben, dient de feitelijke dialoog te voldoen aan een aantal randvoorwaarden. Niet het verdedigen van standpunten, maar het behartigen van belangen dient hierin centraal te staan. Hierbij dienen uiteraard wel de rollen en hierbij horende bevoegdheden te worden gerespecteerd. Daarnaast kan het gereserveerde Project Management budget een rol spelen. Uitgangspunt hierbij moet zijn dat er zal worden getoetst in hoeverre het gereserveerde budget voldoende is om het gewenste projectresultaat te realiseren. Indien dit niet het geval is, dient hiervoor op een passende manier actie te worden ondernomen.

Een tool welke kan worden ingezet ten behoeve van de dialoog, is de Mutual Gains Approach. Alhoewel deze methode zich met name richt op het onderhandelingsproces, kunnen bepaalde onderdelen zeer goed projectbreed worden toegepast. Met projectbreed doel ik op alle facetten van het project en niet alleen het deel van het project wat alleen van toepassing is op de Project Manager.

De Mutual Gains Approach is van oorsprong een Amerikaanse aanpak (Harvard, MIT). De deelnemers creeren samen een oplossing die niemand op basis van louter het uitwisselen van standpunten zou verzinnen. De gezamenlijk gevonden oplossing heeft meerwaarde omdat het resultaat tegemoet komt aan de meeste individuele belangen. In tegenstelling tot het poldermodel (compromissen sluiten) of de traditionele aanpak (meeste stemmen gelden), wint bij MGA het collectief omdat afzonderlijke partijen hun belangen gediend zien en ze dus tevreden zijn met het eindresultaat.

Share on TwitterShare via email