Een goed contract

Deze tip ligt wellicht voor de hand, maar dat maakt deze uiteraard niet minder waar. Zonder heldere spelregels ontstaat een onduidelijk spel, met alle misverstanden, spraakverwarringen en conflicten van dien. Het loont om daar tijd en aandacht aan te besteden. En ja, een goede contractjurist is daarbij onontbeerlijk.

Een projectleider die het contract goed kent

Een goed contract is vers één. Dat contract vervolgens ook goed gebruiken vers twee. Het komt nogal eens voor dat een contract na contractsluiting in de spreekwoordelijke la verdwijnt, waarna men enthousiast aan de slag gaat. Pas op het moment dat zaken misgaan komt het contract dan weer tevoorschijn (als het tenminste nog te vinden is). Soms studeert de projectleider er eerst zelf nog even op – legal maakt immers altijd alles ingewikkelder dan nodig – waarna hij of zij toch maar bij de juristen aanklopt. Uiteindelijk moeten er dan herstelwerkzaamheden worden verricht en in het ergste geval is de juridische positie inmiddels verzwakt. Allemaal niet nodig. Ook de aarzeling bij menig opdrachtgever om de leverancier tijdig en correct in gebreke te stellen kan deze in een later stadium lelijk opbreken.

Gebruik dat scheermes van Ockham!

Veel projecten zijn eenvoudigweg te ambitieus. Softwareontwikkeling is een creatief proces, waarbij ook nog eens vele stakeholders zijn betrokken. Er moet rekening worden gehouden met de legacy, technische specificaties, gebruikerswensen, contractuele afspraken, wet- en regelgeving en met beperkingen in tijd en geld. In ieder traject is het lastig genoeg die zaken met elkaar te combineren en daarop grip te houden, dus maak het niet ingewikkelder dan strikt noodzakelijk. Wees als opdrachtgever dus ook kritisch ten aanzien van het Programma van Eisen dat je opstelt. Meer is niet altijd beter.

Documenteer

De neiging bestaat om afspraken niet of slechts half te documenteren. Opdrachtgever en opdrachtnemer overleggen veel en e-mailen flink heen en weer, maar van duidelijke verslaglegging is geen sprake. Toch is dat laatste wel van belang. Uiteraard niet om alles met protocollen en parafen eindeloos dicht te timmeren, maar belangrijke gebeurtenissen, zoals opleverdata, criteria waaraan moet zijn voldaan om te bepalen of een milestone is gehaald, als ook de uitkomsten van (acceptatie)testen, moeten zonder meer duidelijk, strak en volledig worden gedocumenteerd. In het geval ‘agile’ wordt ontwikkeld is de uitdaging om dat goed te doen wat groter dan wanneer ‘waterval’ wordt gewerkt, maar ook dan is het niet onmogelijk.

Een exit-strategie

Software is nooit af en voordat je het weet, ben je als opdrachtgever met huid en haar overgeleverd aan je opdrachtnemer. Denk daarom vooraf goed na over een exit-strategie. Spreek bijvoorbeeld af dat je steeds na een sprint van de leverancier afscheid kan nemen. Uiteraard dien je vooraf dan wel rekening te hebben gehouden met de IE-rechten, zodat je de software vervolgens zelf kunt gebruiken en verder kunt (laten) ontwikkelen. Ook de documentatie van de software moet aanwezig, volledig en duidelijk zijn.

Vragen?

Heeft u vragen over deze blog, neemt u dan contact op met Jeroen van Helden.