Waarom softwareprojecten mislukken

Over de oorzaken achter het mislukken van softwareprojecten is het laatste woord nog niet gezegd. Een nieuw rapport doet een duit in het zakje.

Over de oorzaken achter het mislukken van softwareprojecten is het laatste woord nog niet gezegd. Een nieuw rapport doet een duit in het zakje.

Alpha Software, een ontwikkelaar van databasesoftware, onderzocht waarom softwareprojecten mislukken. Het rapport is doorspekt met kritiek op concurrenten, maar wie daar doorheen prikt komt ook goed geschreven analyses tegen van de redenen achter projectmislukkingen. Volgens de auteur zijn dat er ruwweg drie: fouten in het proces, software- en hardware die niet voldoet en slechte aansturing vanuit het management.

Auteur David Moskovitz noemt een aantal fouten die in het proces kunnen optreden: het implementeren van verouderde specificaties, te weinig communicatie met de klant, ontwikkelaars die aan veel projecten tegelijk moeten werken waardoor ze iedere keer tijd verliezen doordat ze zich opnieuw moeten inwerken, werk dat voor niets blijkt te zijn gedaan omdat prioriteiten gedurende het project wijzigen, onrealistische tijdsschema’s, te krappe budgetten en rapportage-eisen die resulteren in veel onnodig geschuif met papier.

Als tweede hoofdreden voor het mislukken van projecten noemt de auteur software en hardware die niet voldoet. Daarmee bedoelt hij bijvoorbeeld schaal- en capaciteitsproblemen die sluipenderwijs aan het licht komen, bugs in softwaretools of problemen die ontstaan omdat het werkstation van de ontwikkelaar niet meer krachtig genoeg is voor een nieuwe versie van de ontwikkelomgeving.

Ook managementmissers eisen volgens de auteur hun deel. Bijvoorbeeld wanneer het management onvoldoende steun geeft aan een softwareproject. Ook het op grond van verkeerde motieven kiezen voor een bepaalde tool of leverancier kan tot problemen leiden (bijvoorbeeld dat de tool in een eerder project ook heeft voldaan).

Als oplossing noemt Alpha Software onder meer het invoeren van een ‘risk assessment’ op één of meerdere momenten in het ontwikkelproces. Bij de selectie van tools moeten de ‘MoSCoW’-regels (‘Must have, Should have, Could have, Want to have sometime’) worden gebruikt om prioriteiten af te bakenen. Voorts noemt Alpha Software nog het belang van de kennis van de leveranciersondersteuning: wordt een product nog verder ondersteund door de maker of niet?

De volledige white paper staat [hier] te lezen.

In samenwerking met Computable

Fout opgemerkt of meer nieuws? Meld het hier

Partner Content