Veel software ontwikkelaars richten zich op oplossingen voor een bepaalde sector. Logisch, want als je eenmaal een oplossing hebt ontwikkeld is niets makkelijker dan deze oplossing nogmaals te verkopen.Wij bij Deep Blue kiezen er juist voor om dat niet te doen. Om een aantal redenen

1. We zijn goed in het snel doorgronden van de vraag van een klant, en het verzamelen van alle relevante informatie om te komen tot een goed systeemontwerp. Dát is onze expertise: softwareontwerp en -ontwikkeling. De kennis van het betreffende vakgebied zit juist bij de klant. Door onze kennis te combineren ontstaat een partnership dat leidt tot mooie oplossingen. Kennis delen, en ieder laten doen waar hij goed in is. Dat werkt;

2. Bovendien houden we van diversiteit en afwisseling. Het is veel te leuk om je telkens weer te verdiepen in een nieuwe case en een nieuw vakgebied. Die uitdaging om telkens opnieuw tot de bodem te komen van een vraag, dat houdt ons scherp. We kiezen er daarom heel duidelijk voor om diensten aan te bieden, geen producten. Producten verkopen gaat na enige tijd vervelen, terwijl de dienstverlening afwisseling blijft bieden. Dat is in ieder geval onze mening….

3. Tenslotte is het niet eens toegestaan dat we producten herhaaldelijk verkopen. Het eigendom van de software die we ontwikkelen ligt altijd bij onze klant. Wij mogen hetzelfde product dus niet aan anderen (concurrenten) verkopen. En terecht, de klant heeft hierin geïnvesteerd (geld en kennis). Natuurlijk is hiervan in overleg af te wijken. Soms accepteert een klant dat zijn product aan anderen wordt verkocht. Dat levert hem geld op én kan positieve effecten hebben op het product (doorontwikkeling).

Eén van de meest gehoorde opmerkingen over IT-projecten is dat ze altijd later worden opgeleverd dan gepland en meer kosten dan gepland. Wij zijn ervan overtuigd dat dat niet nodig is. Zeker niet bij projecten met een doorlooptijd van maximaal een jaar.

Het begint met een goed ontwerp van de software. Als dat er is, zou een ervaren ontwikkelaar in staat moeten zijn om redelijk nauwkeurig in te schatten hoeveel tijd hij nodig heeft om het systeem te bouwen. En een projectmanager weet hoeveel uren er nodig zijn voor gerelateerde werkzaamheden als ontwerp, test, documentatie en projectmanagement.

Wij vinden dat het risico op uitloop (in tijd of kosten) niet bij de klant dient te liggen. Een klant heeft geen (of weinig) verstand van software ontwikkeling, en kan dus de kosten en risico’s niet inschatten. Daarvoor schakelt hij nou juist een IT dienstverlener in.

Deep Blue neemt haar verantwoordelijkheid en biedt projecten meestal tegen een vooraf vastgestelde prijs aan. En belangrijker nog: we houden ons daar ook aan. Ook wij schatten wel eens iets verkeerd in, maar dat is dan ons eigen probleem. En dat verschuiven we niet naar de klant. We proberen op deze manier het negatieve imago van IT-dienstverleners te verminderen. Omdat u van ons vakkennis mag verwachten. En omdat we erin geloven dat een tevreden klant het belangrijkste resultaat is dat we kunnen bereiken. Al leveren we soms wat op onze marge in, uiteindelijk levert een tevreden klant ons meer op.

SCRUM en agile, grote kans dat u die termen langs hebt zien komen op websites van bedrijven die software ontwikkelen. Klinkt goed. Flexibiliteit, dat is nooit verkeerd. En toch dient u op uw hoede te zijn als leveranciers deze termen gebruiken bij het beschrijven van hun projectaanpak.

Er zijn drie belangrijke aspecten van projecten die met elkaar samenhangen: de kosten, de gerealiseerde functionaliteit en de kwaliteit. Wijzigt een van deze aspecten, dan heeft dat invloed op de anderen. Minder budget: dan dus minder functionaliteit of minder kwaliteit. Meer functionaliteit nodig? Dan kost dat meer geld, of het gaat ten koste van de kwaliteit. etcetera.

Bij een SCRUM project wordt vooraf vastgesteld hoeveel tijd er beschikbaar is (resources en einddatum). Dit bepaalt dus de kosten. Ook over de kwaliteit worden vaak afspraken gemaakt, waardoor de functionaliteit dus de variabele factor is. Je weet dus wel vantevoren wat het kost en wanneer het klaar is, maar niet (precies) wat je op dat moment krijgt. Zou je op die manier een huis gaan bouwen? Waarschijnlijk niet, je wilt toch vooraf weten of er vloerverwarming in zit, en dat je straks onder die regendouche kunt staan.

Wij geloven in projecten met een gefaseerde waterval aanpak:

1. Op basis van een (vrijblijvend) gesprek met de klant doen we een voorstel, waarin we de projectfasen toelichten. Voor de ontwerpfase geven we meestal direct een vaste prijs af, en we geven een kostenindicatie voor de realisatiefase.

2. In de ontwerpfase stellen we samen een ontwerp op. We ontvangen informatie van de klant over de gewenste functionaliteit en verwerken dit tot een functioneel ontwerp.Indien relevant maken we aansluitend een grafisch ontwerp van de schermen in de software.

3. Nadat het ontwerp is afgerond, opgeleverd en goedgekeurd (door de klant) stellen we een fixed-price offerte en een planning op voor realisatie van de software. Deze vaste prijs dient in de buurt te liggen van de eerder afgegeven indicatie. Afwijkingen zullen worden onderbouwd.

4. Als de klant akkoord gaat met het voorstel, starten we het realisatie (bouw)proces. We leveren in veel gevallen tussentijdse versies op die de klant al kan beoordelen. Het testteam voert parallel aan de ontwikkelaars test van de software uit op basis van een vooraf opgesteld testplan. Pas als alle tests goed worden doorlopen gaan we over tot oplevering van de software.

Dit proces biedt duidelijkheid en zekerheid vooraf over kosten, doorlooptijd, functionaliteit en look&feel.

Dat wil niet zeggen dat er tijdens het project geen wijzigingen mogelijk zijn: op elk moment zullen we wijzigingsverzoeken beoordelen en de impact ervan bepalen. Als onderdelen nog niet zijn gebouwd, kan het best zijn dat wijzigen zonder extra kosten mogelijk is. Na akkoord van de klant wordt het ontwerp aangepast en  wordt de wijziging doorgevoerd.

Dat wil trouwens niet zeggen dat we de Agile aanpak nooit toepassen. In sommige projecten (onderzoek, experimenteel) past het juist prima. En ook na oplevering van software leent een agile aanpak zich prima voor het flexibel en marktgericht bepalen van de inhoud van de maandelijkse release.