In de praktijk blijkt dat resultaten van automatiseringsprojecten vaak tegen vallen. Te laat, te duur en software die opgeleverd wordt die niet is gevraagd en ook nog eens kwalitatief onvoldoende is. De afbeelding hieronder is een goede samenvatting van wat er allemaal mis kan gaan bij de ontwikkeling van software.
Valkuilen
Maar hoe komt het nu dat meer dan 50% van de automatiseringsprojecten niet slagen? Het komt er op neer dat softwareontwikkeling een veelomvattend en complex ontwikkelproces is met veel opeenvolgende stappen en activiteiten, met verschillende karakteristieken en deskundigheden en uiteenlopende belangen. Een fout is dan snel gemaakt. Meer specifiek worden in de literatuur de volgende oorzaken genoemd voor het mislukken van automatiseringstrajecten:
- Onduidelijke specificaties; op het moment dat specificaties niet duidelijk zijn zullen architecten, ontwerpers en programmeurs een eigen invulling geven van wat de klant wil. Het moge duidelijk zijn dat er dan een grote kans bestaat dat deze invulling niet overeenkomt met de verwachting van de klant.
- Scopecreep; vaak breidt de oorspronkelijke opdracht zich ongemerkt uit tot een veel grotere opdracht. Het opstellen van specificaties is ook een vak. Als dit niet goed gebeurd dan zal gaandeweg het ontwikkelproces zich wijziging op wijziging stapelen wat zelfs voor een ontwikkelmethodiek als Scrum lastig wordt om goed te beheersen.
- Onvoldoende betrokkenheid van gebruikers(organisatie); hoewel algemeen bekend is dat de gebruikersorganisatie gedurende het hele proces bij de softwareontwikkeling betrokken moet worden is de praktijk nog steeds dat de gebruikersorganisatie te weinig invloed heeft op het ontwikkelproces. Waardoor de gebruikersorganisatie bij oplevering veelal voor onaangename verrassingen komt te staan.
- Goed is goed genoeg; er wordt te veel gestreefd naar volledige automatisering. Maar juist het automatiseren van de (proces)uitzonderingen blijkt in de praktijk de achilleshiel van veel automatiseringsprojecten. Ook hier gaat namelijk de 80-20% regel op. 80% van de tijd en inzet gaat zitten in het automatiseren van de uitzonderingen. De 'uitzonderingen' hebben dus grote invloed op de projecttoleranties (tijd, geld en kwaliteit). Terwijl voor de uitzonderingen vaak andere oplossingen mogelijk zijn.
- 'Te veel' professionaliteit; architecten, ontwerpers en programmeurs willen de klant allemaal graag van dienst zijn. Daarom bedenken zij slimme, mooie of snelle oplossingen. Onbedoeld en vaak ongemerkt wordt de oorspronkelijke opdracht van de klant aangepast. Zo kan een simpele vraag om een stoel leiden tot een draaistoel die geautomatiseerd jou in slaap kan schommelen. Heel mooi en met de nieuwste technieken maar niet wat de klant heeft gevraagd!
- Verkeerde ontwikkelmethodiek; in de praktijk blijkt dat ontwikkelmethodieken worden ingezet die niet passen bij het betreffende ontwikkelproces. Zo passen methodieken al RUP en Scrum beter bij een iteratief ontwikkelproces. Terwijl de watervalmethode beter tot haar recht komt bij een opdracht met een stabiele omgeving en specificaties.
- Geen aandacht voor kwaliteitsmanagement en risicoanalyses; te vaak blijkt dat de kwaliteit van het eindresultaat onvoldoende is. Dit omdat gedurende het project te weinig op 'kwaliteit' wordt gestuurd. Maak tussentijds gebruik van Proof of Concepts, evaluaties of (deel)acceptatietesten zodat de kwaliteit geborgd is. Hetzelfde geldt voor risicomanagement. Zorg dat je met enige regelmaat stil staat bij de mogelijke risico's die zich voor kunnen doen. Zodat je maatregelen kunt nemen voordat het te laat is.
- Nog niet bewezen ontwikkeltechnologieën; wees voorzichtig met het inzetten van nieuwe technologieën. Gebruik van de nieuwste ontwikkeltechnologieën klinkt aantrekkelijk. In de praktijk blijkt dat er in deze technologieën nog kinderziektes zitten. Daarbij beschikken de projectmedewerkers veelal nog niet over de kennis en kunde. Het risico is daardoor groot dat het gewenste resultaat (tijd, geld en kwaliteit) niet gehaald gaat worden.
- Slechte projectleider; waarschijnlijk een open deur. Maar de praktijk laat zien dat organisaties deze deur nog niet weten te sluiten. Projecten gaan mis omdat projectleiders niet over voldoende kennis en kunde beschikken om automatiseringstrajecten goed te kunnen managen. Projectleiders met een combinatie van inhoudelijke deskundigheid en goede projectmanagement vaardigheden liggen blijkbaar niet voor het oprapen. Met alle gevolgen van dien.
- Focus op alleen de IT-component; in de praktijk wordt bij automatiseringsprojecten nog te veel de focus op de IT-componenten gelegd. Een systeem zal in de praktijk pas echt goed werken als het aansluit bij de processen, bedrijfsvoering, organisatiestructuur en cultuur van de organisatie. En het systeem moeten aansluiten bij de kennis en kunde van de medewerkers.
Beheersmaatregelen
Wat opvalt is dat de valkuilen zowel betrekking hebben op het voortbrengingsproces zelf (specificeren, kwaliteitsmanagement) als op het managen van projecten (verwachtingenmanagement, planningen, risicomanagement). Het is dan ook niet verwonderlijk dat de theorie rondom softwareontwikkeling continu op zoek is naar een integratie van softwareontwikkeling en projectmanagement. Hieronder vindt u de belangrijkste modellen die op dit moment beschikbaar zijn:
Hoe het hoort te zijn!
Het House of Control heeft daar waar mogelijk de modellen omgezet in concrete handvatten om van softwareontwikkeling binnen uw organisatie een succes te maken. Overigens in de wetenschap dat het een complexe en langdurige operatie is om van softwareontwikkeling een beheerst proces te maken. Maar mocht het u lukken dan ontstaat onderstaande afbeelding.
