Meer dan 50 procent van de implementaties van nieuwe applicaties faalt. Dat concludeert Compuware uit onderzoek onder Europese it-managers.
Reden voor het falen is dat er geen formele methodes worden gebruikt voor het beheren van de prestaties van de applicaties. Daarnaast geeft een deel van de ondervraagden aan dat er bij implementaties vaak ineffectief wordt gewerkt.
Ruim de helft van de respondenten geeft aan dat ze onverwachte prestatieproblemen zijn tegengekomen bij zo'n 20 procent van de applicaties die in gebruik werden genomen. De gevolgen hiervan zijn groot. Tweederde van de ondervraagden geeft aan dat applicaties daardoor te laat zijn opgeleverd. Ook wordt er niet tegemoet gekomen aan de prestatiestandaarden die zijn opgesteld in de service level agreements, komen de kosten voor het opleveren van applicaties ruim boven het afgesproken budget uit en wordt er niet tegemoet gekomen aan de verwachtingen van eindgebruikers. Tot slot valt er niet te ontkomen aan de negatieve effecten op bestaande systemen en diensten.
Wanneer het prestatieniveau van een applicatie terugvalt, merkt 78 procent van de ondervraagden dat aan de tevredenheid bij klanten. Volgens 22 procent gaat het zelfs ten koste van de bedrijfsomzet. Maurice Groeneveld, directeur voor Centraal-Europa bij Compuware is niet verrast: "Deze bedrijfsgevolgen zijn te verwachten als je kijkt naar de huidige aanpak van applicatieprestaties. Organisaties volgen de verkeerde processen en bijna de helft van de bedrijven onderkent het opstellen van prestatieklassen niet eens als een essentiële stap in de cyclus van applicatieontwikkeling. Dit is een groot probleem, omdat deze klassen het mogelijk maken om te begrijpen hoe een applicatie gaat presteren zodra deze operationeel wordt."
Een groot deel van het succes van een implementatie wordt bepaald door de afbakening in de oriëntatie en selectie fase. Veel organisaties spenderen te weinig tijd aan deze cruciale fase en laten zich, gedreven door grote tijdsdruk,te snel verleiden tot een te snelle keuze van een mogelijke oplossing. Kortom, definieer het programma van eisen eerst intern, deze extra tijdsinvestering in deze oriëntatie en selectie fase levert uiteindelijk meer op!
Danny Frietman, Marqit
Meer tijd lost niet altijd het probleem op dat Danny Frietman schetst. Het gaat veel meer om, hoe doe ik een goed en compleet programma van eisen opstellen? Goede vakmensen en een goede aanpak zijn hiervoor onmisbaar. Het gebrek hieraan los je niet op met meer tijd.
Ik ben het hier volledig mee eens, met een belangrijke toevoeging dat deze vakmensen onafhankelijk moeten zijn. Dank voor jouw aanvulling.
Veel projecten ‘falen’ ook omdat de uiteindelijk gerealiseerde oplossing in de praktijk niet blijkt aan te sluiten op het verwachtingspatroon van de opdrachtgever. Het resultaat is dan volledig volgens bestek opgeleverd, maar de klant blijkt een heel andere inschatting te hebben gemaakt, en is dan niet tevreden. De enige manier om dit soort ruis te voorkomen is door een uitgebreid prototype te bouwen, maar dan wordt het project meestal weer te kostbaar. Een beetje het verhaalvan de kip en het ei dus
… en dat is dan weer de sterke kant van applicatie ontwikkelmethodes als RUP, waarbij de klant zeer regelmatig meekijkt met de tussenresultaten en die tijdig kan bijsturen. Het is een utopie te denken dat gebruikers specificaties kunnen opstellen. Probeer zelf maar eens de specificaties op te stellen van een videorecorder.
We zijn er bijna..:-) Door de agile variant van RUP te gebruiken als ontwikkelmethode, krijgt klant precies wat hij verwacht!
OK niet alles tegelijk, maar in een aantal iteraties die telkens direct bruikbare spullen opleveren voor hem. De gebruikers zijn binnen Agile RUP direct actief in het ontwikkelteam en weten op ieder moment wat ze kunnen gebruiken en wat ze binnenkort kunnen verwachten. Zij voelen zich als teamlid zo vanaf het begin mede-eigenaar van de oplossing.
Ze hoeven niet meer van te voren complete requirements lijsten te maken. Dergelijke requirementslijsten leveren alleen maar schijnzekerheid over de bruikbaarheid van IToplossing.
Vaak weten gebruikers aan het begin van het project ook nog niet precies de details van wat ze willen. Gedurende het ontwikkeltraject leren ze ook. De testfase na ontwikkeling is dan al te laat om veranderingen te doen, en het begin van onvrede en een stroom van change requests.
Agile software development is “the way to go”. Hiermee kan de kloof tussen IT en Business eindelijk weer gedicht worden.