Na een periode van stagnatie in wat ooit de spil was in it, bewegen organisaties zich momenteel met enige terughoudendheid richting een nieuwe werkwijze voor systeemontwikkeling. De laatste jaren heeft de focus vooral gelegen op kostenbesparing: it werd benaderd als een kostenpost en nieuwe ontwikkelingen zijn beperkt gehouden.
Nu het besef en de noodzaak ontstaan dat de it aan renovatie toe is, houden veel organisaties de vinger nog steeds stevig op de knip en kiezen voor een avontuur in de oriënt. Echter, zelfs als offshore een haalbare route is (maar nog meer als men niet blijkt te kunnen kiezen voor een dergelijke route vanwege de kritische inbreng van lokale gebruikerskennis) wordt het alsnog tijd om over te stappen naar de moderne ontwikkelaanpak.
Deze overstap betekent doorgaans de eerste kennismaking met het Rational Unified Process (RUP) van IBM en een aarzelende poging om een systeem te modelleren in UML. Hierbij wordt vaak voorbijgegaan aan de implicaties van de overstap van lineaire ontwikkeling naar iteratief. De twee voornaamste implicaties zijn de veranderde samenwerking tussen it en business en het feit dat organisaties verticaal ingericht zijn (i.e. aansluiten bij lineair).
Hokjesorganisatie
Veel organisaties zijn zo ingericht dat procesdisciplines zijn verenigd in organisatieonderdelen. Een dergelijke organisatiestructuur, met een indeling in naar competentie geoptimaliseerde hokjes, is ontstaan vanuit het gebruik van de klassieke lineaire procesfasering en deze sluit hier prima bij aan.
Vooral bij het toepassen van iteratieve systeemontwikkeling, maar ook in lineaire trajecten, loopt de projectmanager vast in de wirwar van deze interne leveranciers met elk hun eigen aanpak. Bovendien is er vaak sprake van verschillende belangen: het korte-termijnprojectresultaat versus de kwaliteitseisen van de leverancier. Er gaat veel tijd en energie verloren aan het schakelen tussen de afzonderlijke afdelingen. Hierdoor komen projectresultaten onder druk te staan.
Goed, de organisatie wordt nu verticaal gestuurd op procesdisciplines, maar is het advies nu dat dit moeten worden gekanteld in een projectenorganisatie die wordt onderverdeeld in functionele domeinen? Nee, dat is zeker niet het advies; de organisatorische ingreep zou kolossaal zijn en een klassieke indeling heeft voordelen zoals versterking van competenties en groeimogelijkheden. Hier geldt de wet van ‘behoud van ellende’; de voor- en nadelen van het ene model wegen omgekeerd op tegen die van het andere model.
Het realiseren van een nieuw systeem betekent tegenwoordig de directe inbreng van een legioen deskundigen vanuit de gebruikersorganisatie. Die betrokkenheid is essentieel vanwege de aard van de toepassingen die we maken en het besef dat de gebruiker meer dan ooit bepalend is voor het succes van een systeem. ‘Maar die gebruiker weet niet wat hij wil’ is een veel gehoorde klacht van menig systeemontwerper. ‘Laat mij het maar voor hen bepalen, dat deden we vroeger ook’. Door het verschil in opvattingen lopen nieuwe initiatieven niet zoals gepland.
Het MIRA-principe
Het concept dat in de praktijk tot succes heeft geleid bij genoemde problematiek hebben we MIRA genoemd en bestaat uit 4 kernprocessen die de eerdergenoemde wet van behoud van ellende kan doorbreken.
Waar het in essentie om gaat is dat bij een ‘in hokjes ingedeelde’ organisatie de verbindingen naar de projectmanager niet procesmatig zijn ingericht. Het MIRA-principe vangt dit op door een ontkoppelpunt te zijn tussen het projectenproces en de haaks daarop staande organisatiestructuur.
Zonder een dergelijk ontkoppelpunt ontdekt de projectleider uitsluitend nadelen van een iteratieve aanpak. Zijn op het ene moment de business requirements aan de orde, dan moet weer worden gewacht op de afdeling ontwerp. Om maar niet te spreken van die financiële controllers die een budgetschatting vragen, terwijl de scope van het te ontwikkelen systeem nog niet helder is.
In feite is MIRA de analogie van het objectgeoriënteerde compromis in de klassieke strijd tussen procesgericht en datagericht ontwikkelen. Dit is nu toegepast op organisatieniveau. In een grote organisatie heeft MIRA de problematiek geïsoleerd door de koppelingen met de bestaande organisatie te beperken, te expliciteren en daardoor te beheersen.
Het MIRA-principe behelst in eerste instantie de implementatie van een viertal procesgroepen: Management, Intern, het proces dat RUP aanreikt en Alignment. Zie voor een beschrijving van de groepen het kader bij dit artikel. Door deze vier procesgroepen integraal te beschouwen in het licht van het implementeren van een iteratieve methode als RUP is succes binnen handbereik. RUP-processen alleen zijn geen garantie voor een naadloze integratie in een verticale, sterk competentiegeoriënteerde organisatie.
MIRA is een bewezen concept: het werkt. Het concept kan gemakkelijk op een olievlek manier worden geïmplementeerd en goed onder de aandacht worden gebracht van het management. Door de implementatie klein te starten is de doorlooptijd kort, de investering minimaal en de risico’s op organisatieverstoring extreem gering.
In de praktijk blijken implementaties van een dergelijk projectenhuis voor systeemontwikkeling erg succesvol. Het succes komt niet alleen voort uit het inrichten van de processen, infrastructuur, methoden en technieken. Bij alle implementaties ontwikkelt de organisatie tevens voor een nieuwe cultuur rondom systeemontwikkeling. Door een ‘bit of magic’ ontstaat een inspirerende en professionele organisatie die softwareprofessionals waarderen. Hier komen de aspecten implementatie en verandering aan bod, onderwerpen die in een tweede artikel over MIRA aan de orde zullen komen.
MIRA
Managementprocessen
De doelstelling en toegevoegde waarde van deze procesgroep is het managen van MIRA als ontkoppelpunt tussen de horizontale projectgerichte organisatie en de verticale competentiegerichte staande organisatie.
De resultaatdoelstelling vanuit de projecten is minimaal energieverlies en maximale focus op en facilitering voor het bereiken van het projectresultaat. Deze verticale organisatie stelt de resultaatdoelstellingen in termen van een business case met als oogmerk transparantie van de voortbrengingsketen, productiviteit en kwaliteit. Op deze manier acteert de verticale organisatie als een sponsor van het ontkoppelpunt.
Interne processen
Het succes van de implementatie van een iteratieve methode als RUP wordt niet volledig afgedekt door de elementen van RUP zelf. Er is meer nodig.
Zo dient kennismanagement een plek te krijgen, zodat kennis kan worden vastgehouden in een organisatie die lerende is.
Verder is het aanbevelenswaardig om een proces in te richten voor measurement en estimation. Hierdoor wordt een projectoverstijgende discipline ingericht waardoor kwantitatieve rapportage over voortgang, productiviteit en volwassenheid beschikbaar komt op één plek; het projectendashboard. Van hieruit kan deze informatie goed worden benut om project-estimates te kunnen onderbouwen.
Een ander intern proces is het aanbieden van coaching en collaboration techniques. RUP doet dit weliswaar methodisch, maar MIRA geeft het een concrete praktische invulling. Het ontkoppelpunt vormt tevens de centrale fysieke kantoorlocatie waar de projectwerkzaamheden plaatsvinden en voorziet optioneel tevens in een centrale infrastructuur die specifiek wordt ingericht en ondersteund voor het projectenwerk.
Rational Unified Process
De R in MIRA staat voor het proces dat RUP aanreikt. RUP is zelf eigenlijk een procesraamwerk. De daadwerkelijk gehanteerde processen in de implementatie volgen uit een activiteit van tailoring en afbakening, maar het blijft hierbij binnen de scope van RUP zelf. Daaraan toegevoegd worden coaching en begeleiding, alsook training en optioneel certificering van de betrokkenen. Verder wordt het gebruik van RUP proactief aangespoord; een grote valkuil bij implementatie is dat men na verloop van tijd terugvalt op de oude werkwijze.
Alignment Processen
De vierde procesgroep binnen MIRA betreft processen die de alignment bewerkstelligen met zowel de buitenwereld voor zowel het project gebeuren als de verticale organisatie.
Voorbeeld: aansluiting van RUP op standaard projectmanagement aanpak (PMI of PrinceII) van een organisatie, of de rapportage aan de centrale PMO. We voorkomen hiermee dat elke projectleider die RUP toepast een ontdekkingsreis maakt hoe dit te bewerkstelligen.
Belangrijkste raakvlakken met de verticale organisatie worden geëxpliciteerd en afspraken gemaakt. Voorbeelden zijn release kalender van de (lineaire denkende organisatie op macroniveau) en het maken van estimates gerelateerd aan budgeting. Andere zaken zijn bijvoorbeeld staffing, competenties, transition points, QA en het projectmanagement laten aansluiten op dit principe.
Freddy Withagels, Martin Piller