• 11 jan, 2016
  • Agenda, Nieuws, Tips

 

De Management of Change Community, waaronder PRIOM,  organiseert een VeranderWeekend van vrijdagavond 18 maart 2016 tot zondagnamiddag 20 maart 2016. Deze keer belichten we “Business Process Management” vanuit een viertal invalshoeken:

  1. Veilig en technologisch innoveren
  2. Resultaat en kwaliteit in de keten
  3. Duurzame en klantgerichte processen
  4. Spelen en leren in processen

Het VeranderWeekend is een interactieve dialoog en beoogt geen Business Process Management opleiding te zijn, maar juist de blik op dit vakgebied te verrijken met hedendaagse inzichten vanuit resultaatgericht verbeteren, innoveren en veranderen.

Professionals uit onze community delen in het VeranderWeekend met elkaar hun inzichten. Dit wordt ondersteund door onze sprekers en de leeromgeving waarin materiaal gedeeld kan worden om de mate van interactiviteit in de bijeenkomst zo hoog mogelijk te krijgen.

Voor wie?

Voor iedere professional die betrokken is of gaat worden bij Business Process Management.

Wanneer en waar is het?

Het VeranderWeekend vindt plaats in het weekend van 18, 19 en 20 maart 2016. Startend op vrijdagavond 18 maart en eindigend op zondagnamiddag 20 maart. De locatie is Conferentiehotel Mennorode.

Wat kost het?

Je betaalt slechts kostenvergoeding voor de out-of-pocket kosten voor de opleiding en het verblijf (twee nachten met natje en droogje) in het conferentieoord. Dit is €298,= (vrijgesteld van btw). Heb je een coupon van je werkgever ontvangen, dan kan de prijs gereduceerd zijn tot maar €50,= . Kijk op de aanmeldtab of je werkgever dit sponsort.

Ervaringen

Dit is de vierde editie. Eerdere edities van het VeranderWeekend trokken 35 tot 50 enthousiaste deelnemers die het een waardering gaven van meer dan 4 sterren (van de 5).

Lees verder...

scrum, priom, vastgoedsector, stakeholders
  • 09 jan, 2016
  • Scrum, Tips

 

Hoe overtuig ik de stakeholders van de voordelen die scrum hen kan bieden?

De scrummethode is verre van nieuw. Toch is het verbazingwekkend dat veel gevestigde, grote organisaties nog geen kennis hebben van de methode, laat staan dat ze er ooit mee gewerkt hebben. Voor leveranciers is het vaak lastig om de klant te overtuigen van de toegevoegde waarde van het gebruik van de scrummethode. Voor een leverancier is het vaak al prettig als er bij een organisatie één ambassadeur van de scrummethode aanwezig is, die ook overtuigd is van de scrummethodiek en er graag mee zou willen werken. De grote vraag is dan: ‘Hoe kunnen we samen de stakeholders overtuigen?’ Het is vooral een strategisch vraagstuk en een gezamenlijk belang om in dit geval de DMU’s van een organisatie te overtuigen van de toegevoegde waarde van de scrummethode.

scrum elshof afb0

In dit artikel wil ik mij niet per se focussen op de voordelen die de scrummethodiek voor een project kan bieden, maar vooral de voordelen die de methodiek heeft voor de stakeholders/DMU’s. Zo kan ik hen misschien overtuigen om de methodiek in te zetten. Uiteraard gelden deze ‘tips’ zowel met als zonder een ambassadeur binnen een organisatie. Ik merk in de praktijk vaak dat dit een gezamenlijke uitdaging is en daarom heb ik het gevoel dat deze tips voor beide partijen toegevoegde waarde kunnen hebben.

Schijnzekerheid weerleggen

De stakeholders van een organisatie zijn gewend opdrachten aan te nemen op een bepaalde, geboden zekerheid. Alle mogelijke voorbereidingen zijn getroffen om risico’s binnen het project te vermijden… Althans, dat denken ze. Eerlijk gezegd is dat natuurlijk ‘wishful thinking’; stakeholders weten over het algemeen ook wel beter, of zouden in ieder geval beter moeten weten. De ‘schijnzekerheid’ die door een fixed scope, fixed price offerte en een planning met keiharde deadline gecreëerd wordt, blijkt in veel gevallen een wassen neus te zijn.

Er is een leuk voorbeeld die deze stelling kan bekrachtigen. Voer de term ‘hier komt binnenkort’ maar eens in Google in. Op het moment van het schrijven van deze blog zijn er 350.000 resultaten op deze term. Een groot aantal van deze aankondigingen dateert uit een ver verleden.

scrum elshof afb1

Met andere woorden: kijk de stakeholders recht in de ogen en vraag of ze altijd precies gekregen hebben wat ze wilden, binnen het gestelde budget en op de gestelde deadline. Stakeholders zitten ook niet te wachten op oeverloze discussies over scope, budget en planning. Zij willen aan de slag en snel resultaat zien!

Je kunt niet alles weten

Het vorige punt focust zich op het negatieve aspect van de watervalmethode. Dit is nodig om de stakeholders te kunnen overtuigen van de voordelen die de scrummethode hen en de organisatie biedt. Maar waarom is het dan niet nodig om die (schijn)veiligheid in te bouwen voordat je met een leverancier in zee gaat? De eerste vraag die vaak wordt gesteld is luidt namelijk ‘Ja, maar wat krijgen we dan precies en wanneer is het af?’ Deze vragen zijn relatief makkelijk te beantwoorden.

Wat krijgen we precies?
Voordat ik deze vraag ga beantwoorden, is het noodzakelijk om een belangrijke misvatting van scrum te weerleggen. In de scrummethodiek wordt er altijd uitgegaan van een MVP. Het MVP (Minimal Viable Product) is het product dat het project minimaal moet opleveren. De opvatting dat dit een halffabricaat is dat niet mooi is, is niet waar! Een MVP is een minimaal acceptabel product, dat voldoet aan de eisen van de eindgebruiker. Een MVP kan dus prima een ‘Rolls Royce’ zijn. Een MVP geeft vooral richting aan het project en geeft een gevoel bij het eindproduct dat er moet komen. Budget en doorlooptijd worden beide bepaald op basis van het MVP. Echter is een MVP nog niet volledig en tot in detail uitgewerkt.

Dit gezegd hebbende weten de stakeholders dus wel wat ze aan het einde van het project krijgen, maar is er nog flexibiliteit om de details gedurende het project in te vullen. Je kunt van tevoren niet alles weten en dus ook niet bepalen, sterker nog, je wilt niet alles van te voren bepalen! Niet alleen de organisatie en de randvoorwaarden van een project kunnen gedurende de rit veranderen, maar ook de wereld om ons heen. Het is in deze tijd van belang om snel in te kunnen spelen op veranderingen. De stakeholders zijn er dus juist bij gebaat om niet met een fixed scope te werken, maar met een MVP, waar zowel de organisatie als de leverancier naartoe gaan werken.

Wanneer is het af?
Nu we de MVP weten, willen de stakeholders natuurlijk ook weten wanneer ‘alles’ af is. Het meest eenvoudige antwoord is: ‘Het is af wanneer wij als organisatie vinden dat het af is’. Helaas is dat over het algemeen niet het antwoord waar de stakeholders op zitten te wachten. Een veelgehoorde opvatting is dat er ‘een pot geld wordt overhandigd’ en dat het scrumteam ‘er maar mee doet wat ze wil’. De stakeholders hebben het gevoel dat ze maar moeten afwachten wanneer het af is. Het tegenovergestelde is waar en er is een aantal mogelijkheden om dit af te kaderen, zodat de stakeholders het project met een gerust hart kunnen starten.

Voordat de eerste sprint wordt gestart is de samenstelling van het scrumteam bekend en is er een inschatting van hoeveel sprints er nodig zijn om het MVP te kunnen realiseren. Er is dus wel degelijk een planning, met een deadline. De stakeholders mogen verwachten dat er na het aantal afgesproken sprints, een MVP gereed is. Het is dus ook van belang voor de stakeholders om te weten dat zij nog steeds flexibel zijn in de onderdelen die opgepakt worden in de sprints, maar dat dit altijd ten koste gaat van andere onderdelen die in het MVP waren opgenomen. Het is in dat geval ook mogelijk om een extra sprint af te spreken en dus de deadline op te schuiven; de stakeholders zitten achter het stuur.

Aan het einde van een sprint (gemiddeld 2 à 3 weken) is er ook nog eens een onderdeel gereed, dat potentieel naar productie zou kunnen. De voorwaarde voor een sprint is namelijk dat alle gebouwde functionaliteiten productie gereed zijn. Uiteindelijk zijn het dus toch de stakeholders die bepalen ‘wanneer het af is’. De time to market kan korter zijn als de stakeholders het erover eens zijn dat het product wat er op een X moment staat, voldoende is om naar productie te brengen. Een bekende uitspraak om dit kracht bij te zetten is “done, is better than perfect”.

Het belangrijkste argument om via de scrummethode te werken binnen dit vraagstuk is dat een omgeving nooit af is. Je wilt als organisatie met de tijd meegaan en de concurrentie altijd één stap voorblijven om te kunnen streven naar succes. Het is dus belangrijk om snel live te gaan met het MVP, zodat je ook snel kunt beginnen met de doorontwikkeling en het verbeteren van de omgeving op basis van de ervaringen van de eindgebruiker. Dit kan alleen als de omgeving beschikbaar is voor de klanten en daar wil je dus niet te lang mee wachten. Stakeholders zijn nu nog vaak op zoek naar ‘het perfecte product’ dat in één keer klaar moet zijn. Deze utopie is volgens mij niet de moeite waard om te weerleggen, maar wellicht is de onderstaande afbeelding een mooi voorbeeld hoe het werken met een MVP gaat.

^BC44D012491CE129E385F386737FB42367538A54EF93E201F4^pimgpsh_fullsize_distr

Het MVP in dit voorbeeld zou ‘een vervoersmiddel’ kunnen zijn. In het eerste voorbeeld moet er vier sprints gewacht worden totdat er een werkbaar product is, terwijl er bij het tweede voorbeeld al na één sprint een MVP is. Het voordeel is dat er in sprint vier nog steeds gekozen kan worden om het bij een motor te houden, omdat blijkt dat de eindgebruiker helemaal geen behoefte heeft aan een vervoersmiddel met vier wielen en een dak. De focus kan dan gelegd worden op andere doorontwikkelingen. In het eerste voorbeeld is dat niet te realiseren, omdat alle voorbereidingen voor een auto al zijn gedaan, dus zou er opnieuw moeten worden begonnen om er alsnog een motor van te maken.

Tada… huh?

In mijn jaren als projectmanager heb ik gemerkt dat één van de meest lastige aspecten van een project managen het verwachtingsmanagement is. Hoe je ook probeert om van te voren alles in documentatie vast te leggen, in de meeste watervalprojecten loop je toch tegen een verschil van verwachtingen op en is er sprake van escalatie binnen het project. Ieder oplevermoment is weer spannend, omdat je hoopt dat een klant het goed vindt. Als je iets niet wilt, dan is dat onzekerheid over hetgeen je gaat opleveren richting de klant.

In gesprekken met klanten ben ik erachter gekomen dat klanten hetzelfde ‘unheimliche’ gevoel hebben tijdens een project. Een vaak gehoorde kreet is ‘ze zitten vier maanden in hun donkere kelders en ik heb geen idee waar ze mee bezig zijn’ In de basis is dat ook eigenlijk wat er bij waterval projecten gebeurt. Zowel de klant als de leverancier hebben baat bij grip op het project.

Een voordeel bij de scrummethode is dat er na iedere sprint (dus om de 2 à 3 weken) een demo is van de werkzaamheden die in de afgelopen sprint door het team zijn gerealiseerd. Alle stakeholders zijn welkom om bij de demo’s aanwezig te zijn. Zonder uitzondering merk ik dat stakeholders het erg prettig vinden om te zien wat er gerealiseerd is en dat ze ook nog de flexibiliteit hebben om sturing te geven aan het project. De stakeholders kunnen dus nog wel verrast worden, maar het gaat dan om beperkte onderdelen of functionaliteit, in plaats van een volledige omgeving wat grote gevolgen kan hebben voor planning, budget en uiteraard klantbeleving. In het geval van scrum kan het na twee weken alweer helemaal naar verwachting zijn bij de volgende demo. De stakeholders (van welk niveau dan ook) hebben, meer dan ooit, grip op het project.

Wie is de mol?

De stakeholders missen niet alleen grip op het project omdat ze pas aan het einde van de werkzaamheden te zien krijgen wat er gereed is, maar ook omdat er niemand is die de leverancier tijdens de werkzaamheden ‘in de gaten kan houden’. Stakeholders moeten erop vertrouwen dat de leverancier doet wat er gevraagd wordt en dat ze waar gaan maken wat er afgesproken is. In watervalprojecten worden alle ‘battles’ uitgevochten tussen de projectmanager van de organisatie en die van de leverancier. Beide proberen alles zo goed mogelijk (weg) te managen en stakeholders hebben daarbij vaak het gevoel dat zij niet alle belangrijke ontwikkelingen binnen een project meekrijgen.

Het grote voordeel van scrum en in dit geval voor de stakeholders/klant is dat er een afgevaardigde van de klant in het scrumteam plaatsneemt. De product owner, zoals deze genoemd wordt, is meerdere dagen per sprint aanwezig binnen het scrumteam. De product owner is verantwoordelijk voor het succes van het product en het maximaliseren van de return on investment (ROI). Hij bepaalt welk product gebouwd wordt en waar de prioriteiten liggen. De product owner heeft dus het stuur in handen. Een goed functionerende product owner is essentieel voor het succes van het project. De klant heeft hiermee dus maximale invloed op de uitvoer van het project.

De product owner bepaalt samen met de stakeholders wat er gebouwd moet worden en waar de prioriteiten liggen, voordat dit bij het scrumteam wordt ingepland. De stakeholders moeten er dus wel voor zorgen dat zij iemand aanstellen die voldoende capabel is, voldoende kennis heeft en ook voldoende mandaat en vertrouwen krijgt om deze rol goed te kunnen vervullen.

Conclusie

Er zijn nog veel meer argumenten om de stakeholders te overtuigen van de voordelen van het gebruik van de scrummethodiek. Maar ik hoop dat ze door dit verhaal overtuigd genoeg zijn om het gewoon te gaan doen. Ik ben er in ieder geval van overtuigd dat ze daarna geen overtuiging meer nodig hebben!

scrum elshof afb3

Lees verder...

Interessante blog van Jeroen Elshof. Jeroen is E-commerce Consultant en Scrummaster binnen De Nieuwe Zaak. Hij helpt dagelijks retailers, groothandels en A-merk fabrikanten met diverse e-commerce en omnichannel vraagstukken.


vastgoedsturing, PRIOM
  • 05 jan, 2016
  • Tips

 

We delen graag dit overzichtelijk schema, waarin u de producten en acties lezen kunt om het jaar rond te gaan wat betreft integrale vastgoedsturing.

 

Een cadeautje