We lezen dagelijks over het slechte economische klimaat en de dalende aandelenmarkten. Deze moeilijke tijden kunnen organisaties dwingen tot drastische wijzigingen in de vorm van bezuinigingen, kantoorsluitingen en personeelreductie. Toch is het belangrijk dat bedrijven juist nu voor de goede investeringen kiezen om de crisis het hoofd te bieden en sterker uit de strijd te komen. De ict-afdeling kan daarbij een belangrijke rol spelen in het leveren van toegevoegde waarde ondanks de organisatorische veranderingen.
Het rechtvaardigen van de nodige investeringen komt voor het management vaak op de eerste plaats. Net zoals elke andere afdeling binnen een bedrijf, moet ook de ict-afdeling met een goed businessplan komen om budget los te krijgen. Application development zal zich dus moeten concentreren op die features te ontwikkelen die de hoogste business value hebben. Daarom is het zeer belangrijk dat de looptijd en kosten van een project goed op voorhand kunnen worden vastgelegd. Het opleveren van de juiste features tegen het afgesproken budget (tijd en geld) zal een maatstaf worden voor de slaagkans van een project.
Om een project efficiënter uit te kunnen voeren moeten we een aantal zaken in projectuitvoering veranderen. Tot nu toe was het zo dat de business geen onderscheid maakte tussen nice-to-have’s en need-to-have’s. Dit komt voornamelijk omdat de business weet dat het moment dat de requirements vastgesteld worden ook het laatste moment is voor deze gebruikers om inspraak te hebben in de de scope. Daarnaast weet de business vaak nog niet precies wat er nodig is en weten ze ook dat als ze iets bestempelen als geschikt voor een volgende release dat het er nooit gaat komen. Het resultaat is een 'bloated scope' met te veel features die aan het einde vaak niet nodig blijken of anders uitgevoerd moeten worden. Helaas is dan vaak het moment van oplevering al geweest en is er geen tijd meer voor ingrijpende aanpassingen aan het systeem zonder het te vertragen. Gevolg is een project dat vertraagd is en niet de maximale business value levert met een groot risico dat het niet slaagt.
Door een project agile uit te voeren, terwijl rekening gehouden wordt met een vastgesteld aantal sprints oftewel een vast budget, kan een organisatie er voor zorgdragen dat het resultaat van het project altijd de maximale business value oplevert omdat de organisatie iedere iteratie opnieuw zijn prioriteiten stelt. Dit voorkomt dat er onnodige features geïmplementeerd worden en dit verkleint ook het risico naarmate je dichter bij het einddoel komt. Wanneer na de oplevering blijkt dat het resultaat dusdanig verschilt van de originele scope heeft dit geen invloed gehad op de timing of op de kosten. Beter voorkomen dan genezen geldt dus ook hier, zeker in het huidige economische klimaat.
Er wordt door Tony eerst gesteld dat de business geen onderscheid kan maken tussen nive-to-have en need-to-have. Blijkbaar is Agile een tovermiddel, want gezien alinea vier kan de business daarna ineens per sprint wel voor iedere iteratie goed de prioriteiten stellen.
Ik herken het probleem van niet de juiste keuzen maken, maar ik zie de oplossing daarvan niet in Agile introduceren.
Tony gaat er, gezien de tweede alinea, nog steeds vanuit dat de ICT afdeling niet facilitair is aan de business maar een eigen budget heeft voor nieuwe ontwikkelingen. Voor de “business” is het heel eenvoudig om uit te geven van het budget van een ander. Overweeg eens om het budget voor onderhoud en ontwikkeling in handen van de business te leggen. Dan worden ze ineens wel kritischer waar het aan uitgegeven wordt.
Maar nog belangrijker: zorg dat de business leert focussen op het oplossen van het business probleem. Leer ze om tussen alle problemen, die er zijn, het belangrijkste probleem te herkennen. Een hulpmiddel hiervoor is bijv. de Theory of Constraints van Goldratt.
Ik ga helemaal mee in de reactie van Alexander, scherpe kijk!