Marijn Mulders beschrijft in zijn boek Business & Managementmodellen de theorie van Waarderend Onderzoeken (Appreciative Inquiry) als volgt:

Achtergrond
Bij veranderprocessen wordt veelal uitgegaan van problemen en hoe deze op te lossen. Veranderingsprocessen worden vaak ingegeven door vragen zoals 'Waarom is er zo veel stress?', 'Waarom is bijna niemand gemotiveerd', 'Waarom begrijpen we elkaar niet goed'? Hierdoor komt de focus bijna automatisch op de problemen te liggen. Om dit te voorkomen is Appreciative Inquiry, Waarderend Onderzoek, ontwikkeld. Deze veranderfilosofie heeft als centraal startpunt dat een systeem zich positief ontwikkeld op het moment dat mensen samen gaan onderzoeken wat werkt en wat er goed is. Hiermee worden manieren verkend om successen verder uit te bouwen en met de gevonden sterktes de toekomst op een meer positieve wijze in te richten. Een project dat volgens deze methode wordt uitgevoerd kan wel een vraag hebben zoals 'Terugkerende klanten omdat ze tevreden zijn', maar dus nooit een opdracht zoals 'Hoe verlagen we het aantal ontevreden klanten'? De aanpak bij waarderend onderzoek is sterk ontwikkel gericht. Gedurende het proces wordt steeds bijgestuurd op basis van het geleerde uit de vorige stap.

Toepassing
Het waarderend onderzoeken is gebaseerd op vijf principes die beschrijven hoe veranderen volgens waarderend onderzoek werkt.

(1) het constructionistische principe: onze verbeeldingskracht, ons vermogen om toekomstbeelden te creëren, maakt het mogelijk dat menselijke systemen, maar ook organisaties, veranderen of gereconstrueerd kunnen worden;

(2) Het simultaniteitsprincipe: zodra de eerste vraag gesteld is begint het veranderproces. Daarom zijn onderzoek (inquiry) en interventie onderling verbonden en gelijktijdig;

(3) Het poëtische principe organisaties zijn als een open boek of poëzie. Alle medewerkers in een organisatie kunnen co-auteur zijn van hoe het boek van de organisatie zich ontwikkelt;

(4) Het anticipatoire principe: een beeld van de toekomst gaat altijd vooraf aan feitelijke verandering;

(5) Het positieve principe: hoe positiever de vraag, hoe positiever de data zal zijn. Hoe positiever de bereidheid om te participeren, hoe duurzamer het veranderingsproces zal zijn.

De eerste stap bij een waarderend onderzoek is het definiëren van het kernthema (Define) of affirmative topic. Dit moet dus een positief omschreven kernthema zijn en niet een uitgangspunt als vermindering van het aantal klachten van klanten. Veelal is hier ondersteuning nodig om te komen tot een positievere verwoording. Dit kan bereikt worden door af te vragen wat er dan komt nadat de klachten zijn afgenomen. Wat kan er dan gezien worden en kan dat dan omschreven worden?

Wanneer het kernthema bepaald is kan het waarderend onderzoek gestart worden dat bestaat uit vier fasen.

(1) Discovery (Verwonderen). Ontdek de positieve kern van het kernthema. Wat zijn de beste ervaringen die met het kernthema te maken hebben? Betrokkenen gaan hier in gesprek en delen hun eigen positieve ervaringen. Hierdoor ontstaat eigenlijk een soort 'dna', de bouwstenen voor succes komen naar boven. Door de onderlinge gesprekken krijgen de medewerkers een gedeeld en gevoeld begrip wat de organisatie allemaal kan. Dit versterkt het zelfvertrouwen van de betrokken medewerkers van de organisatie.

(2) Dream (Verbeelden). Welke toekomst ziet iedereen voor de organisatie? Het durven kijken naar de toekomst en het verbeelden daarvan leidt automatisch tot nadenken over de toekomst en de mogelijkheden die er zijn. Het delen en verbeelden van deze toekomstdromen met behulp van collages, filmpjes, verhalen enzovoorts doet de toekomst werkelijk tot leven komen.

(3) Design (Vormgeven). Waar wil de organisatie staan binnen een bepaalde periode en hoe ziet dat er dan uit? Door de volgende stap met een duidelijke focus vorm te geven, kan een helder en duidelijk beeld verkregen worden van de toekomst vanuit de droom. Als je droom .....is, waar wil je dan over ..... staan? In deze fase kan ook gebruik gemaakt worden van Design Thinking om het gedroomde toekomstbeeld vorm te geven.

(4) Destiny (Verwerkelijken). De laatste fase is het maken van een planning met resources en budgetten om de ambitie waar te maken. Welke acties en projecten leiden tot het gestelde doel. Wie gaat concreet aan de slag met welke projecten en experimenten.

Resultaat
Bij waarderend onderzoek wordt uitgegaan van de positieve invalshoek die een organisatie maakt tot wat hij is. Dit positivisme straalt uit op anderen die erdoor gemotiveerd worden. De verandering stopt dan niet bij de oplossing van het probleem, maar blijft leiden tot vernieuwing.

Aandachtsgebieden
Veranderen is geen planmatige exercitie omdat het gaat over het veranderen van gedrag van mensen. Dit kan niet gepland worden als zijnde het bouwen van een huis. Waarderend Onderzoek kan dat ook niet en de ontwikkeling ligt bij de mensen zelf die volgens het waarderend onderzoek te werk gaan. De medewerkers in de organisatie moeten wel met deze manier van veranderen om kunnen gaan die veel zelfstandigheid vraagt en erg intensief is. Hierdoor kunnen de kosten tevens hoog oplopen. Waarderend onderzoek gaat niet over dat iets positief of negatief is. Waarderend onderzoek gaat meer over energie en verbinding tussen samenwerkende mensen.

Bron: Business & Managementmodellen, Marijn Mulders

In hun boek Precies volgens plan!, Succesvolle IT-projecten met heldere requirements gaan Mark Hoogveld, Jan Willem Knop en Marcel Schaar in op de relatie tussen heldere requirements en het succes van een IT-project. Hieronder een samenvatting van het eerste hoofdstuk.

Omdat bij informatie-intensieve organisaties de ict nauw verweven is met de bedrijfsvoering, hebben veranderingen in de ICT rechtstreeks invloed op de bedrijfsvoering van een organisatie. Grote veranderingen vinden veelal plaats middels programma’s en projecten. Een ICT-project is succesvol te noemen als het de informatievoorziening zodanig heeft veranderd dat deze de beoogde bijdrage aan de bedrijfsdoelstellingen levert. Randvoorwaarde is vanzelfsprekend dat deze bijdrage binnen de grenzen van tijd, geld en kwaliteit (inclusief de functionaliteit) gerealiseerd moet worden, de zgn. duivelsdriehoek.

Mark Hoogveld, Jan Willem Knop en Marcel Schaar baseren zich op Aart J. van Dijk, gepromoveerd op een onderzoek naar succes- en faalfactoren bij ict-projecten, die een project als succesvol definieert wanneer geldt dat het doel van de verandering wordt bereikt door (a) realisatie van de afgesproken kwaliteit (inclusief functionaliteit); (b) de geplande doorlooptijd met maximaal 50 procent wordt overschreden, geaccordeerde scopewijzigingen uitgezonderd; en (c) de kosten voor de verandering met maximaal 50 procent worden overschreden, geaccordeerde scopewijzigingen uitgezonderd (‘overrun’).

Volgens Van Dijk zijn er zeven aspecten van IT-projecten die bepalend zijn voor een succesvolle afloop, de zgn. Big Hitters:

1. Goed projectmanagement

2. Realistische deadlines

3. Goede communicatie

4. Sterk en compleet requirementsdocument

5. Voldoende betrokkenheid van toekomstige gebruikers

6. Betrokkenheid en commitment van senior management

7. Voldoende professionaliteit (professionals)

Van Dijk stelt: “[g]eef aandacht aan deze Big Hitters en je maakt grote kans op een succes, verwaarloos er één van, en de kans dat je project niet succesvol wordt is haast een zekerheid.” Requirements worden niet alleen expliciet genoemd als 4e Big Hitter, maar bovendien geldt dat ze ook een cruciale rol spelen bij alle andere Big Hitters.

Volgens Hoogveld, Knop en Schaar zijn er drie pijlers van belang bij het goed (kunnen) beschrijven van requirements:

1. Belanghebbenden

2. Kwaliteit

3. Context

Ad (1) Belanghebbenden
Hoogveld, Knop en Schaar definëren requirements als de eisen die belanghebbenden stellen ten aanzien van een product. Dit kan een fysiek product zijn, maar ook een dienst, organisatie, proces, functionaliteit of systeem. Requirements zijn niets anders dan een communicatiemiddel, een gezamenlijk vastgelegd referentiekader. Binnen een project stellen requirements een projectteam in staat om een eindproduct te realiseren dat voldoet aan de eisen van de belanghebbenden. Om aantoonbaar te maken dat het eindproduct voldoet aan de requirements geven de belanghebbenden aan welke requirements zij dermate belangrijk vinden, dat ze in het eindproduct gecontroleerd moeten worden om tot acceptatie over te kunnen gaan. Deze requirements noemen we acceptatiecriteria .

Belanghebbenden zijn in te delen in drie groepen:
• huidige belanghebbenden;
• toekomstige belanghebbenden;
• transitiebelanghebbenden (projectbelanghebbenden).

Ad (2) Kwaliteit (inclusief functionaliteit )
Requirements omschrijven de eisen aan het eindresultaat; wanneer is het product, in de ogen van de belanghebbenden, goed genoeg? Ze definiëren de kwaliteit. De kwaliteitseisen zijn meestal afgeleiden van de algemene kwaliteitseigenschappen die producten kunnen hebben. Zoals bijvoorbeeld functionaliteit, veiligheid, robuustheid, gebruikersvriendelijkheid, et cetera.

Ad (3) Context
De werkelijke invulling van kwaliteitseigenschappen moet samen met belanghebbenden worden gedaan en de kwaliteitseigenschappen krijgen een specifieke betekenis binnen de context van het product. “In de context van het ontwikkelen van een informatiesysteem kan de kwaliteitseigenschap ‘veiligheid’ bijvoorbeeld resulteren in het requirement ‘Onbevoegden
mogen geen toegang hebben tot het informatiesysteem’. Binnen de context van een gastank denken we veel meer aan explosiegevaar.”

Niveaus van requirements
In de praktijk worden requirements vaak verdeeld over vier niveaus:

1. Doelstelling: welke bedrijfsdoelstellingen wil het bedrijf realiseren?

2. Business requirements: aan welke eisen moeten de organisatie en bedrijfsprocessen voldoen om de bedrijfsdoelstellingen te (kunnen) realiseren?

3. User requirements: aan welke eisen moet een deelproces voldoen en wat zijn de bijbehorende functionaliteiten, bijvoorbeeld de marketing-, sales- of financiële processen van de organisatie?

4. System requirements: aan welke eisen moeten de IT-systemen voldoen die de functionaliteiten moeten ondersteunen?

Requirements engeneering
Het voortbrengingsproces van requirements wordt requirements engineering genoemd.
Requirements engineering resulteert in vastgelegde en vastgestelde requirements.

Een van de werkpakketten in een projectplan is is het verzamelen van de wensen en eisen ten aanzien van de oplossing, eerst de user requirements en later de system requirements. Een requirements engineer krijgt als opdracht dit werkpakket uit te voeren. Een belangrijke eerste stap – na afstemming met de opdrachtgever over de opdracht en de scope, is het inventariseren van de belanghebbenden en hun belang, de belanghebbendenanalyse. De fase van het opstellen van requirements resulteert in een eisendocumt (‘programma van eisen’) dat ter goedkeuring wordt voorgelegd aan de belanghebbenden en de opdrachtgever.
De projectmanager neemt het resultaat van het werkpakket in ontvangst en tekent het af.
De goedgekeurde set requirements vormt de basis voor de volgende fasen van het project. Ze zijn het uitgangspunt voor analyses, ontwerpen, de te bouwen oplossing, de acceptatiecriteria ten behoeve van testen, et cetera. Binnen een project blijft de rol van de requirements engineer van belang bij het overdragen van requirements aan diegenen die deze nodig hebben voor het uitvoeren van hun werkpakketten. Verder beheert de requirements engineer de opgeleverde set van requirements om te borgen dat de uiteindelijke oplossing voldoet aan de eisen van de belanghebbenden en het resultaat bijdraagt aan de doelstelling van de opdrachtgever.

Bron: Precies volgens plan!, Succesvolle IT-projecten met heldere requirements Mark Hoogveld, Jan Willem Knop, Marcel Schaar (pdf-versie Hoofdstuk 1: Succesvolle IT-projecten)