Dutch
English
Software bouwen voor de overheid na de commissie Elias: wat doen wij anders?
Recent zijn de resultaten van de commissie Elias bekend gemaakt. Deze commissie heeft een parlementair onderzoek uitgevoerd naar de ICT-projecten bij de overheid. Wij waren erg benieuwd naar deze resultaten omdat we naast ons advieswerk al een jaar of tien aan de slag zijn voor de overheid als ICT-dienstverlener. Producten als Boogie, DGM, de Virtueel Akoestisch Adviseur en SPERoN zijn daarvan voorbeelden. We herkennen de geschetste problemen. In de loop der jaren hebben wij onze eigen visie en werkwijze ontwikkeld om projecten on-time en on-budget uit te voeren. Hoe krijgen we dat voor elkaar? Een kijkje in onze keuken.
Voor ons is een project succesvol als de (overheids)klant een product krijgt dat daadwerkelijk wordt gebruikt om een probleem op te lossen of een proces efficiënter uit te voeren. We voelen ons als leverancier echt verantwoordelijk voor de bruikbaarheid van het eindresultaat. Dat klinkt misschien logisch maar we weten van onze klanten dat dat niet vanzelfsprekend is.
We betrekken onze klant actief. Door interactie met de klant weten we beter wat er speelt , waarvoor en hoe het product zal worden gebruikt. Daarvoor gebruiken we het liefst de planning game. In een gezamenlijke sessie maken onze ontwikkelaars en de eindgebruikers (vaak niet dezelfde als de opdrachtgever) een realistisch overzicht van de te realiseren functionaliteit en de planning van het ontwikkelproces. De eindgebruikers bepalen wat ze nodig hebben en hoe het eruit moet komen te zien. Onze ontwikkelaars geven daarbij een realistisch beeld van de inspanning die daarvoor nodig is en waar de risico's liggen. Met dat inzicht kan de klant vervolgens bepalen wat belangrijk is.
We ontwikkelen de software in een iteratief proces.Periodiek leveren we een werkend softwareproduct dat de klant kan testen. Ook kan hij bepalen of het project de goede kant op gaat. De ontwikkelaars krijgen daarmee direct feedback over de bruikbaarheid van hun inspanningen. Dit voorkomt dat eventuele problemen pas aan het einde van het project zichtbaar worden. Aanpassingen kunnen daarmee veel vroeger en dus goedkoper worden uitgevoerd.
We zijn niet bang voor verandering. Als onze klant, door voortschrijdend inzicht, het eindresultaat wil aanpassen dan zullen we meebewegen. Voor ons is dat dus ook geen reden om direct met meerwerkoffertes te gaan zwaaien. We proberen de verandering gewoon binnen de bestaande offerte uit te voeren. En ja, daarin wijken we echt af van de gemiddelde ICT-dienstverlener. Dit werkt trouwens ook twee kanten op: ook wij hebben voortschrijdend inzicht tijdens het ontwikkelproces. Soms is functionaliteit goedkoper te realiseren en soms vallen dingen tegen. Daarover maken we van tevoren afspraken met onze klanten.
We vinden dat onze ontwikkelaars verstand moeten hebben van de processen en problemen waarvoor ze de software ontwikkelen. We hebben er dan ook bewust voor gekozen ons qua software-ontwikkeling te beperken tot de kernthema's van M+P: geluid, trillingen, luchtkwaliteit en bouwfysica. Onze ontwikkelaars zijn ook allemaal actief met advieswerk. Dit betekent voor onze klanten dat ze makkelijk op inhoudelijk niveau direct met onze ontwikkelaars kunnen praten en voorkomt dat alles uitgebreid gespecificeerd moet worden met kans op allerlei fouten.
We vinden wederzijdse openheid en transparantie tussen de klant en ons heel belangrijk. De klant mag zoveel meekijken in onze keuken als gewenst. We maken helder waar onze inspanning wordt geleverd en dus waarvoor de klant betaalt. Het toppunt van transparantie is als ontwikkelaars van de klant meedraaien in ons ontwikkelteam. Onze ervaring is dat dat prima kan en dat je veel van elkaar kunt leren.
Spreekt deze visie en werkwijze je aan? Ik vertel er graag meer over.
