Hoe moeten organisaties requirements aanpakken? Moeten ze project based of product, applicatie of dienst based met requirements werken? Een vraag die niet één, twee, drie is op te lassen. Overstappen van project based requirements naar product based requirements betekent een paradigma verschuiving.
In veel organisaties is er een bepaalde trend te observeren rondom deze kwestie: organisaties beginnen vaak met requirementsontwikkeling en- management binnen een project. Naarmate er meer projecten worden gedaan, zeker indien deze projecten plaatsvinden binnen dezelfde product of applicatie, blijkt de eerdere project based requirementsaanpak minder efficiënt en wil men overgaan naar een product basedaanpak. Deze andere aanpak vergt een paradigma verschuiving, waarbij men anders wil werken (vaak ook efficiënter) om meer voordelen voor de organisatie uit te halen.
Maar waar horen de requirements bij? Horen de requirements bij een project, tijdens welke de requirements opgesteld worden? Of horen ze misschien bij het product die ze definiëren? Het antwoord op die vraag hangt samen met de volwassenheid van de organisatie in het requirementsmanagement.
Bij organisaties die net beginnen met requirementsmanagement of nog weinig volwassen zijn in het gebruik van requirementsmanagement, zullen requirements in eerste instantie onderdeel zijn van de (individuele) projecten. Dit is niet moeilijk te verklaren. De requirements passen binnen de kaders van de projecten en zijn daarmee vanuit projectdoelstelling te definiëren en te beheersen. Dit zorgt ervoor dat requirementsmanagement zich conformeert aan projectmanagement doelen, maar ook analisten hebben zo een duidelijk afgebakende scope waarbinnen zij werken. Alle requirements en de afhankelijkheden tussen requirements en andere projectinformatie zijn in de context van een project beheerd en bewaard. Het gemak van deze werkwijze is zijn grootste voordeel. Daar staan een aantal nadelen tegenover, waarvan de belangrijkste zijn:
• Gebrek van overzicht bij welke producten de requirements horen;
• Hergebruik van requirements is heel moeilijk,
Naarmate requirements meer en meer het uitgangspunt worden voor nieuwe en veranderde dienstverlening, vinden de meeste organisaties de genoemde nadelen storend en inefficiënt. Deze nadelen stimuleren organisaties om over te gaan tot een andere werkwijze, waarbij men zoekt naar een verhoogde efficiëntie, onder andere door beter hergebruik (niet copy/paste), beter consistentie en volledigheid. De organisaties met een volwassen requirementsmanagement, komen vaak tot conclusie dat het beter is om requirements per product te organiseren en te beheren. De voordelen zijn dat het uiteindelijk mogelijk wordt om requirements te hergebruiken. Hierdoor wordt het opstellen van een requirementsspecificatie voor een volgende generatie product op basis van de bruikbare requirements een veel simpelere handeling, de focus ligt op de wijziging/verandering die het project wil realiseren, waarbij volledigheid en consistentie veel makkelijker zal worden verkregen.
De product based requirementsmanagement-aanpak, vraagt wel een andere regie ten aanzien van de gezamenlijke, herbruikbare set requirements. Dit vraagt om een hoger volwassenheidniveau van de organisatie en een andere positionering van het requirementsbeheer. Dit samen met verhoogde complexiteit rondom requirementsorganisatie, maakt de transitie naar product based werken met requirements een echte paradigma shift, die niet moet worden onderschat.
Een ander deel van de uitdaging ligt in de requirement managament-tooling die veel organisatie met een hoog volwassenheidsniveau gebruiken. Requirement management-tools helpen niet bij de transitie van project naar product based aanpak. Er zijn nog geen requiremens management-tools die de product gebaseerde manier van werken actief ondersteunen. Requirement management-tools zijn vaak projectgebaseerd. Ze vragen om een project in plaats van een product om de requirements aan te relateren. Zolang dit het geval is, blijft de transitie naar een efficiëntere product based manier van werken met requirements voor veel organisaties lastig en vraagt het work-arounds, tool-specifieke of zelf ontwikkelde oplossingen. Dit moet veranderen!
Requirements worden nog vaak zeer matig begrepen. Vaak denkt men in oplossingen in plaats van requirements. Het vereist een abstractie nivo. Mijn inziense moet je eerst principes afspreken. Dit zijn meer de algemene regels waar men over product, project of service moet aan voldoen. Het zijn de de fundamenten onder requirements.
Paradigma verschuiving? projectrequirements? productrequirements?
Ik zou graag willen praten met deze auteur. Wellicht kunnen wij de kwaliteit van het artikel omhoog schroeven.
Voor de helderheid:
* projectrequirements vormen een onderdeel van Assurance Services binnen een bedrijf of van iets gelijkwaardigs. Dit zie ik niet terug in het artikel. NB! Gevoeligheid voor veranderingen is laag.
* ik mis het onderscheid in requirements naar niveau. Dit is belangrijk vanwege de dynamiek van wijzigingen in requirements. Business requirements), mits juist gesteld, zijn vrij stabiel gelden voor langere tijd i.t.t. client requirements dat gevoeliger is voor wijzigingen i.v.m. techniek- en marktontwikkelingen.
Ik mis in het verhaal stakeholders en de wijze van benadering in houding en werk.
Ik ben het ermee eens dat requirements binnen een project nog steeds niet op de juiste waarde wordt geschat en dat er veel projectmedewerkers hiermee niet weten om te gaan.
m.i. Is het elementair om de primaire bedrijfs- en/of projectdoelstelling geen seconde uit het oog te verliezen en het vak requirements engineering ten alle ten hieraan onderwerpen.
Ik heb de tekst nu drie keer gelezen, maar volgens mij komt niet helemaal uit de verf wat je precies met “product based ” bedoelt.
Als “product” het softwareproduct betreft, bedoel je dan niet eigenlijk “product oriented requirements” ofwel productgerichte eisen? Immers, met goede requirements wil je de gewenste functionaliteit beschrijven van het (te ontwikkelen of aan te kopen) product.
Maar als je met “product” juist de dienst aan de eindklant bedoelt dan klopt je verhaal veel beter. Want daarvoor breng je requirements in kaart: ze beschrijven de gebruikersvraag naar functionaliteit die hen (beter) ondersteunt bij het leveren van de dienst, of het product, aan de eindklant.
Overigens ben ik het eens met Pradiep.
Er van uit gaande dat een project aan het eind van de rit een product oplevert, is er toch geen probleem ???
Waar in het artikel mijns inziens naar gezocht wordt is een stukje program- of roadmap management.
Program management beheert het totaalpakket aan requirements, en doseert deze middels projectbrieven naar projecten welke ze vervolgens implementeren, resulterend in een productrelease.
Leuk om een opiniestuk te beginnen met een meerkeuzevraag:
Hoe moeten organisaties requirements aanpakken?
Moeten ze
a) project based of
b) product,
c) applicatie of
d) dienst based
met requirements werken?
Ook als de auteur nog een vijfde mogelijkheid had toegevoegd, namelijk
e) process based, was mogelijkheid d) dienst based (of service based) het enige juiste antwoord.
Het pleidooi voor een product based aanpak is ongelukkig, omdat de paradigma verschuiving nu juist verloopt van een produktgerichte naar een klantgerichte, dus servicegerichte benadering.
‘Produktgericht’ doet teveel denken aan de bekende silo-apllicatie’s: grote monolithische systemen, die naast specifieke functionaliteit ook allerlei generieke functionaliteit bevatten
Een dienstgebaseerde benadering sluit overigens optie a) project based, niet uit, zolang deze zich maar conformeert aan de architectuurprincipes: de architecturale randvoorwaarden waarbinnen requirements kunnen worden getoetst en gerealiseerd.
En ik maar denken dat requirements altijd een eigenaar moeten hebben, dus business, user, beheer requirements die uiteindelijk moeten leiden naar producten die vervolgens resulteren in resultaten voor de organisatie.
Product bases requiemmis kunnen passen in de price methodiek van een productbased planning waaraan per product requirements kunnen worden gehangen die vervolgens kunnen worden getest.
Projectrequrements zouden meer in een programma opgehangen kunnen worden, waarbij de som van de projecten uiteindelijk de resultaten voor de organisatie oplevert.
Lastig geschreven opinie zonder echt duidelijk te maken wat de doelstelling van dit artikel is of zou moeten zijn. Ik sluit mij aan bij de vorige reageerders.