Code14

Software projecten lijken vaak te mislukken, dit is hoe wij dat voorkomen

De afgelopen tijd heb je het waarschijnlijk vaker in het nieuws voorbij zien komen: grote bedrijven of overheidsinstellingen die hun IT niet op orde kunnen krijgen doordat transformatietrajecten niet verlopen zoals verwacht. Hoe komt dat nou eigenlijk en hoe proberen wij dit te voorkomen?

Vrijblijvend adviesgesprek bij CODE14
clock
Harm-Jan Hazelhorst Co-founder
Harm-Jan Hazelhorst, Co-founder CODE14

De angst voor ICT projecten, maatwerk software en ICT’ers in het algemeen: het komt ergens vandaan. Alle mislopende, dure en vertraagde software projecten worden breed uitgemeten in het nieuws en toegerekend aan de betrokken software ontwikkelaars. Niet geheel eerlijk, want er zijn meer grote en kleine projecten die lukken dan dat ze mislukken.

Software ontwikkelaars slecht in dienstverlening?

Wat vaak geroepen wordt is dat ontwikkelaars slecht zijn in planning, zij zich niet kunnen houden aan afspraken en eigenlijk gewoon ondermaats presteren als het gaat om service en dienstverlening. Zoomen we dieper in op gefaalde projecten, dan zien we dat dit niet het geval is. De meeste ontwikkelaars werken agile, waarmee ze flexibel kunnen blijven en vertraging in veel gevallen kunnen voorkomen. Echter zijn zij wel afhankelijk van de klant, haar bestaande systemen en wat zij aanleveren.

Vaak zijn er namelijk meerdere partijen, ook wel stakeholders genoemd, betrokken bij een project. Aan de opdrachtgever de taak om alle stakeholders dezelfde kant op te krijgen en ze met elkaar te verbinden. Als deze communicatiestroom niet loopt, dan stokt het project vaak als eerste bij de software ontwikkelaar. In veel gevallen zijn zij namelijk afhankelijk van het huidige applicatielandschap en de stakeholders die daar weer aan hangen. Dat levert vertragingen op.

Het belang van de factor ‘mens’

Natuurlijk is het frustrerend dat ICT projecten uitlopen, vertraging hebben of gewoon helemaal mis lopen. Echter is dit nooit aan één iemand, en zeker niet aan één partij, toe te wijzen. Het is een combinatie van factoren, waarvan één van de belangrijkste de factor ‘mens’ is. Wij mensen kunnen heel veel en als we over goede projectmanagement eigenschappen beschikken (en een goed samenwerkend team) dan is een software project een prachtige uitdaging. Maar er zijn ook projecten waarbij de omvang zo groot is dat het bijna niet meer te behappen is voor een intern team. Daar komt vaak nog bij dat er zoveel stakeholders zijn (met allemaal eigen belangen) dat het een fulltime taak is om überhaupt te communiceren met alle partijen.

Naast de factor ‘mens’ blijft het een feit dat projecten met een dergelijke omvang langdurig lopen, soms zelfs jaren. Hierdoor komt het vaak voor dat wat aan de voorzijde is bepaald, aan de achterzijde (bijvoorbeeld een jaar later) niet meer opgaat. Andere systemen of werkwijzes zijn in een jaar tijd al weer veranderd, waardoor het plan binnen een jaar alweer gedateerd kan zijn. Daarom is het belangrijk om aan de voorzijde al die buffer in te bouwen in begroting en planning. Plannen veranderen namelijk altijd, helemaal als ze ver van te voren bepaald worden.

Slim werken met scrum

Wij willen niets liever dan voldoen aan een gestelde planning en begroting, want dat werkt voor ons ook positiever en meer rendabel. Daarom werken wij graag op een scrum manier met korte sprints. Door bijvoorbeeld iedere twee weken een onderdeel op te leveren en daarover met elkaar te sparren, gooien we nooit meer dan twee weken ontwikkeling weg als het onderdeel al achterhaald is of niet meer nodig is. Zo beperken we de kosten en blijven we nauw met elkaar communiceren op afgesproken tijden. Goed voor onze planning, maar ook voor je eigen planning. Daarnaast, en niet geheel onbelangrijk, kunnen we initiële plannen wijzigen met elkaar. Doordat we iedere twee weken iets afronden kunnen we ook na iedere twee weken het plan iets bijsturen of aanpassen.

Een scrum manier van werken vraagt van zowel de klant als ons extra effort. Bij de klant moet er een aanspreekpunt zijn die precies weet wat er moet gebeuren en het project bewaakt. Ook bij ons is er altijd één vast aanspreekpunt: de projectmanager. Elke twee weken komen de stakeholders bij elkaar om de afgelopen sprint te beoordelen en de volgende sprint te definiëren. Het overlegmechanisme is een stuk intensiever dan bij een traditionele manier van ontwikkelen. Echter is dat juist ook wat de basis meer solide maakt en de samenwerking beter!

Inspired by our Fresh Family!

Wil je meer weten over onze dienstverlening, scrum of de factor 'mens'? Neem dan contact met mij op! Je kunt mij bereiken op 06 4166 4217 of door te mailen naar h.hazelhorst@code14.nl.

Wil je meer van dit soort blogs lezen met software tips, informatie of nieuws? Bekijk dan onderstaande artikelen en schrijf je in voor onze nieuwsbrief. Iedere maand krijg je dan de nieuwste artikelen over applicaties, webapplicaties, koppelingen en code in je mailbox!

Wij bellen jou terug.

Wil je meer weten over onze dienstverlening, scrum of iets anders? Vrijblijvend advies? Een kop koffie? Harm-Jan belt jou terug om een afspraak in te plannen.

Wij bewaren deze gegevens om u terug te bellen Ontwerp en Ontwikkeling van Webapps en mobiele apps bij CODE14

Meld je aan voor onze nieuwsbrief en krijg artikelen, projecten en bedrijfsupdates rechtstreeks in je inbox.