De top 3 overwegingen voor het starten van een Pega-project

“Ik ga op reis en ik neem mee …”

Iedereen zal zich dit bekende geheugenspelletje uit hun jeugd herinneren. Ik ga op reis en neem mee …, de volgende persoon herhaalt dat en voegt iets toe. Dat gaat zo door tot iemand iets vergeet op te noemen dat gezegd is en daarmee uit het spel ligt. Als je een Pega project start kun je de analogie met dit spelletje trekken. Er is zo veel om aan te denken en als je iets cruciaals vergeet of negeert, kun je later geconfronteerd worden met grote uitdagingen of hoge herstelkosten. In mijn zeven jaar ervaring als Pega project-/delivery manager heb ik de volgende top drie van belangrijkste zaken om te adresseren als je een Pega project start.

–

1 – “Eerst wie, dan wat”

Dit welbekende principe van management goeroe Jim Collins is ook van toepassing op Pega projecten. De meeste grote bedrijven hebben outsourcing contracten met grote system integrators. Meestal zijn zij alleen in staat één type experts, namelijk technische, te leveren. Hoewel technisch vaardig, missen zij vaak andere competenties als het goed begrijpen van de business en ontwerpen. Sommige projecten starten zelfs meteen met offshoring. Hoewel dit in het begin goedkoop lijkt, komt dit vaak als boemerang terug doordat samenwerking moeilijk is, weinig business begrip en gebrek aan betrokkenheid. Vervolgens is veel tijd en geld nodig van onsite resources om dit werk in goede banen te leiden en te verbeteren.

Mijn ervaring is dat het beste team om mee te starten een on site team van interne medewerkers en externe experts van diverse implementatie partners met de juiste combinatie van ervaringen. Deze combinatie van de benodigde rollen en ervaringen bij één leverancier vinden is vaak lastig. Sommige leveranciers zijn uitstekend in het opstarten van een Pega project, maar hebben niet de omvang om snel op te schalen als het project succesvol is en er veel meer met Pega gedaan wordt. Andere leveranciers kunnen snel opschalen, maar hebben geen business kennis en weinig ervaring in het goed opzetten van de juiste delivery aanpak en architectuur. Mijn advies aan grotere organisaties is om met minstens twee leveranciers te werken om het beste resultaat te halen door elkaar aan te vullen en (minstens zo belangrijk) elkaar scherp te houden. In het begin is het tevens cruciaal om Pega zelf bij het project te betrekken.

Naast de IT rollen, is de rol van Product Owner cruciaal in agile projecten, dus het selecteren van de juiste PO met het juiste mandaat is cruciaal voor succes. Wat een juiste PO is uitgebreid beschreven door veel anderen, dus daar ga ik in dit blog verder niet op in.

2 – “Denk na voor gij begint”

Bijna alle IT projecten worden tegenwoordig op een agile manier uitgevoerd. Met agile projecten schieten mensen vaak meteen in de actiemodus en gaan snel bouwen. Hoewel dit in het begin snel lijkt te gaan, is de valkuil dat onvoldoende is doordacht wat en hoe je moet ontwikkelen, wat resulteert in veel rework in een later stadium. Dus neem je tijd om een goede (business) analyse te maken en stel je start architectuur goed op. De bekende Project Start Architectuur is cruciaal voor succes. Maak duidelijke keuzes in wat je wel én niet in Pega doet. Ontwerp hierna een goede applicatie architectuur voordat je met bouwen begint. Juist met een platform als Pega is dit ontzettend belangrijk. En met een goede applicatie architectuur bedoel ik meer dan de Enterprise Class Structure.

3 – “Denk groot, start klein en laat succes zien”

Met het Pega platform heb je zoveel mogelijkheden, dat je voor je het weet de wereld in één big bang wil veranderen. Maar dit leidt tot een lange doorlooptijd en daarmee gaat het momentum verloren. Je kunt beter klein beginnen, snel resultaat laten zien en van daaruit het succes uitbouwen. Pega is ‘build for change’, dus focus op het Minimum Lovable Product (MLP) en bouw dit uit.

De rol van de product owner is hierbij essentieel, hij of zij is verantwoordelijk voor het maken van de juiste keuzes wat er gebouwd moet worden. Maar het implementatie team moet de product owner hierop wel challengen en gezamenlijk het MLP definiëren en daarmee acceptabele delivery tijdslijnen. Ga dus niet voor een big bang scenario, aangezien ook de organisatie moet veranderen en dit vermogen vaak beperkt is. Neem dit dus mee bij het selecteren van het eerste project/proces en vertaal dit naar een goed ontwerp zoals hierboven beschreven.

Conclusie

Als je bovenstaande punten meeneemt, zou je Pega journey tot succes moeten leiden. Het zal soms pijnlijk en moeilijk zijn, maar als je goede dingen op de goede manier doet ben je uiteindelijk succesvol. Onthoud dat wanneer succes in een IT project uitblijft mensen de technologie de schuld gaan geven, maar in bijna alle gevallen is het niet de technologie, maar business en IT management dat gefaald heeft de zaken op de juiste manier aan te pakken. Mocht je vragen hebben over het opstarten van je Pega project of heb je het gevoel dat je vastzit, aarzel niet om contact met ons op te nemen.

Wij delen daarnaast graag onze kennis en ervaring met de markt. In onze whitepaper ‘De zeven stappen voor een goede start van je Pega-project’ beschrijven we welke kernactiviteiten uitgevoerd moeten worden om een goede start van je Pega-project te borgen en welke aandachtspunten daarbij horen.

[whitepaper-1]