Navigeren door de grijze zone: wanneer projecten niet helemaal aan de verwachtingen voldoen

De kloof overbruggen: strategieën om de resultaten af te stemmen op de aspiraties van de klant in toekomstige projecten

Het is gemakkelijk te begrijpen dat het succes van elk project afhangt van de kwaliteit en precisie van de specificaties. Daarom moeten projectsponsors, dat wil zeggen de klant, altijd uitgebreide, nauwkeurige en hoogwaardige projectspecificaties leveren voordat ze een aanbesteding uitschrijven. Zoals vaak het geval is, is mijn ervaring dat er altijd wel iets ontbreekt, waardoor de klant blijft zitten met een grotendeels, maar niet volledig, functionele applicatie die niet aan de verwachtingen voldoet.

Onthulling. Ik gebruik Generative AI tools om me te helpen bij het schrijven. Van contour suggesties tot onderwerpen of subtiliteiten, die ik nog moest bedenken.

Bekijk hier meer artikelen, posts en discussies over ondernemen, projectmanagement, Generatieve AI en Creatief Schrijven op Medium. Abonneer je op Medium als je dat nog niet hebt gedaan. Of volg me hier op Substack.

Softwarebedrijven bouwen precies wat je hen vraagt te bouwen binnen de beperkingen van de technologie. Het sleutelwoord hier is precies. Dat wil zeggen, zoals gespecificeerd in de geleverde documentatie. Als de specificatie van eisen niet gedetailleerd of niet specifiek genoeg is, dan zal de geleverde software niet alles zijn wat de klant verwacht. In het ergste geval kan dit een mislukt project worden genoemd.

Versplinter complexiteit: Essentiële vereisten verzamelen

De dichotomie van klantverwachtingen en projectresultaten

Softwareprojecten kunnen om vele redenen mislukken, maar de meest voorkomende oorzaak is een gebrek aan precieze vereisten. Zonder een duidelijk begrip van de bedrijfsvereisten en gebruikersbehoeften is het moeilijk voor het projectteam om te begrijpen wat het project moet bereiken en hoe het moet functioneren. Slechte communicatie tussen teamleden en belanghebbenden kan daarom leiden tot het mislukken van een project. Als belanghebbenden niet betrokken zijn bij het hele project, kan het zijn dat er niet aan hun behoeften wordt voldaan, wat resulteert in een product of dienst dat niet volledig aan hun verwachtingen voldoet.

Vertrouwen kan het slachtoffer worden van een project dat niet aan de verwachtingen voldoet. Vertrouwen opbouwen tussen mensen of organisaties kost tijd, maar dit vertrouwen kan van de ene op de andere dag worden weggeblazen.

Beschouw dit scenario: wanneer een nieuwe of bestaande klant vraagt om een nieuw product of een nieuwe dienst of om een uitbreiding van een bestaande dienst, is een van de ergste fouten te veronderstellen dat de klant precies weet wat hij wil. Natuurlijk denken ze dat ze dat weten, en het is altijd mogelijk dat ze gelijk hebben. Het is echter altijd verstandig om aan te nemen dat de klant slechts een vaag idee heeft van de vereisten.

Klantrelaties moeten gebaseerd zijn op wederzijds vertrouwen en respect. Anders, kijk uit!

Als er daarentegen voldoende tijd wordt genomen om ervoor te zorgen dat alle verwachtingen van de klant goed worden gedocumenteerd en dus worden waargemaakt, kan het vertrouwen tussen beide partijen alleen maar groeien. Ze leiden vaak tot vervolgprojecten.

De kloof tussen verwachtingen en levering overbruggen

Het is tijdrovend om ervoor te zorgen dat het uiteindelijke document aan alle verwachtingen van de klant voldoet.

en ogenschijnlijk duur. De investering is altijd de moeite waard, want als je ontdekt dat de deliverable een zelden gebruikte maar vitale functie mist tijdens de laatste fasen van het project, zal het nog duurder en tijdrovender blijken om te repareren.

Hier volgen een aantal eenvoudige best practices voor het produceren van een nauwkeurige Specificatie van Eisen document en het bijbehorende, technisch getinte, Functionele Specificatie document. Ze zijn afkomstig uit een eerder artikel dat in mei 2023 is gepubliceerd.

Praktische behoeftenanalyse en klantspecificaties zijn het resultaat van beste praktijken die grondigheid, duidelijkheid en samenwerking bevorderen. Als deze praktijken worden gevolgd, ontstaan specificaties die in overeenstemming zijn met de verwachtingen van de klant. Hier volgen enkele essentiële best practices om te overwegen:

1. Betrek belanghebbenden vanaf het begin: Betrek de belangrijkste belanghebbenden, waaronder klanten, eindgebruikers, deskundigen op het gebied van materie en leden van het projectteam, vanaf de eerste stadia van de analyse van de vereisten.
2. Definieer een gestructureerde aanpak: Stel een gestructureerde aanpak op voor de analyse van eisen, inclusief duidelijke stappen, methodologieën en documentatiesjablonen.
3. Grondig verzamelen van eisen: Gebruik technieken zoals workshops, interviews en enquêtes om uitgebreid eisen te verzamelen.
4. Eisen prioriteren op basis van hun impact, haalbaarheid en afstemming op de doelstellingen van het project.
5. Eisen effectief documenteren: Gebruik gestandaardiseerde formaten en hulpmiddelen om eisen te documenteren, zodat ze duidelijk, volledig en begrijpelijk zijn.
6. Valideren en verifiëren van vereisten: Valideer en verifieer regelmatig de vereisten met de belanghebbenden om de nauwkeurigheid, volledigheid en afstemming te garanderen.
7. Voortdurende communicatie en samenwerking vergemakkelijken: Stimuleer open en frequente communicatie met klanten en belanghebbenden.
8. Overweeg veranderingsbeheer: Erken dat de eisen kunnen veranderen.
9. Gebruik visuele hulpmiddelen en prototypes: Visuele hulpmiddelen, zoals stroomdiagrammen, wireframes of prototypes, kunnen belanghebbenden helpen de kenmerken en functionaliteiten van het project te visualiseren.
10. Bevorder een cultuur van voortdurende verbetering: Moedig een mentaliteit van voortdurende verbetering aan door de lessen die uit elk project worden getrokken vast te leggen.

Onthulling van de sleutel tot projectsucces: De kracht van eisen-analyse en klantspecificaties

Onvoorzien en ongepland

De lijst met vereisten van de klant kan zeer nauwkeurig zijn ingevuld. Er kunnen er echter een of twee tussen zitten die, hoewel ze op papier eenvoudig lijken als het op implementatie aankomt, onmogelijk zijn vanwege technische beperkingen. Webapplicaties zijn berucht om deze situatie, omdat de ontwikkelaars niet de vrije hand hebben over de omgeving, maar zich moeten houden aan specifieke fundamentele regels.

Soortgelijke problemen kunnen zich voordoen wanneer het ontwikkelteam de visie van de klant begrijpt over hoe een functie anders zou moeten werken. Aan de oppervlakte lijken beide partijen het volledig eens te zijn over de vereisten. Maar aan de kant van de ontwikkelaar verhindert het rekening houden met bekende technische beperkingen, waarvan ze misschien denken dat het voor de hand ligt, om precies zo te bouwen als de klant wil.

Door de jaren heen ben ik herhaaldelijk getuige geweest van ten minste één probleem in de uiteindelijke projectoplevering, wat onvermijdelijk leidde tot teleurstelling bij de klant. Ik zal geen specifieke projecten of klanten noemen, maar ik kan me met moeite één honderd procent succesvol opgeleverd softwareproject herinneren.

Voorzien en gepland

Het is niet genoeg om in de beginfase van het project de juiste documenten te leveren (de Specificatie van Eisen en de Functionele Specificatie); ze zien er misschien perfect uit en zijn redelijk op elkaar afgestemd. De onvoorziene problemen zijn in dit stadium voor een hoog percentage vermijdbaar.

Tijdens de eerste technische analyse moet speciale aandacht worden besteed aan de belangrijkste gebieden met onbekende factoren. Ze moeten door een team uitvoerig worden bekeken, mogelijk zelfs zo grondig dat er een semi-werkend prototype van de voorgestelde oplossingen wordt gemaakt. De kunst is om deze potentiële probleemgebieden al tijdens de eerste analyse te identificeren. Om er zeker van te zijn dat er niets over het hoofd wordt gezien, zouden er idealiter twee onafhankelijke analisten moeten worden ingeschakeld voor elk project. Zelfs als dit onmogelijk is, moet de eerste analyse op zijn minst onafhankelijk worden beoordeeld (een Cold Eye Review).

Als alle onbekenden naar tevredenheid zijn aangepakt of aangetoond, kan de Functionele Specificatie worden opgesteld. Alleen dan kunnen de klant en de ontwikkelaar het eens worden over de Scope of Work van het project. De extra inspanning die zo'n grondige technische analyse met zich meebrengt moet niet worden gezien als ongewenste kosten, maar als een investering. Alle kennis die wordt opgedaan tijdens deze oefening kan alleen maar ten goede komen aan iedereen die betrokken is bij toekomstige projecten en uitdagingen.

We stimuleren probleemoplossend vermogen, aanpassingsvermogen en veerkracht binnen het ontwikkelingsteam door deze uitdagingen aan te gaan. Het vertrouwen van de klant kan alleen worden versterkt door blijk te geven van professionaliteit en toewijding aan het bereiken van een wederzijds bevredigend resultaat.

Laatste gedachten

Zoals je kunt zien aan de links, heb ik verschillende aspecten van het artikel van deze week al eerder behandeld en dat zal ik nu weer doen. Gerelateerd, dat wil zeggen, niet dezelfde inhoud herhaaldelijk herhalen. Dit artikel gaat over softwareontwikkelingsprojecten. De meeste van de besproken punten gelden echter voor elke branche.

De sleutel tot alle projecten is de betrokkenheid van belanghebbenden; hoe meer alle belanghebbenden betrokken en geïnformeerd zijn, hoe groter de kans dat een project in één keer goed gaat. Vandaag de dag een zeldzaamheid.

Ik was van plan om deze week nog een artikel te publiceren, maar ik heb besloten het niet te doen. Het is heel persoonlijk; ik weet niet of ik het durf. Misschien volgende week of volgende maand. Of misschien ook niet...

---

Bekijk hier meer artikelen, posts en discussies over zaken, projectmanagement, de menselijke natuur, Generatieve AI en Creatief Schrijven op Medium. Abonneer je op Medium als je dat nog niet hebt gedaan. Of volg me hier op Substack. De KodifyIT Substack nieuwsbrief is een door lezers ondersteunde publicatie. Als je nieuwe berichten wilt ontvangen en mijn werk wilt steunen, overweeg dan om je gratis of betaald te abonneren. Ik waardeer de steun; je zult er geen spijt van krijgen. 👍

Ik bied mijn lezers mijn verontschuldigingen aan voor sommige spellingen die volgens u onjuist zijn. Ik ben geboren en getogen in het Verenigd Koninkrijk, en dit is de spelling waar ik me prettig bij voel(Grammarly is er in ieder geval blij mee).