Some people walk in the rain, others just get wet.

Roger Miller

What happened? Small Accident. The road curved but I didn’t.

The strange love of Martha Ivers 1946

Voorbij verandermanagement
Whole Scale Change, de wind onder de vleugels
Antonie van Nistelrooij, Rob de Wilde

Bij Managementboek

The problem is never how to get new, innovative thoughts into your mind, but how to get the old ones out.

Dee Hock (Former CEO, Visa International)

Our greatest challenge as leaders is not understanding the practice of leadership; it is practicing our understanding.

Marshall Goldsmith

If HP knew what HP knows, it would be three times more profitable.

Lewis Platt (former CEO, Hewlett-Packard)

In het artikel “Informatiemanager? ICT or business?” betoogt Rik Maes dat informatiemanagers zich niet moeten opstellen als ict-managers en intermediair tussen business en ICT, maar op zoek moeten gaan naar een nieuwe identiteit. Volgens Maes gaat informatiemanagement in ieder geval niet over het managen van ICT, noch over het managen van het ‘alignment’ van business en ICT.

“Informatiemanagers zouden moeten ophouden te werken als vermomde ICT-managers. Evenmin zouden ze zich nog moeten definieren als intermediairs tussen business en ICT. Succesvolle informatiemanagers zijn ‘infopreneurs’, hypergevoelig voor het onthullende karakter van menselijke activiteiten, een bijdrage leverend aan het herinterpreteren van hun organisatie en van de maatschappij als geheel en dit alles belichamend in hun professionele en persoonlijke leven.”

Bij de term ‘informatiemanagement’ wordt vaak de link gelegd met computers. Niet verwonderlijk volgens Maes: “Geen wonder: gedurende decennia werd de betekenis van informatie en informatiemanagement voor organisaties in feite verborgen achter de overweldigende opkomst van informatie- en communicatietechnologie (ICT). Deze laatste werd beschouwd als een strategische ‘resource’, die een directe en beslissende impact had op de business.”

“Op de keper beschouwd heeft ICT geen andere al of niet strategische impact dan via het faciliteren van informatie- en communicatieprocessen. (…) CEO en CIO zouden zich primair moeten inlaten met ICT-onafhankelijke conversaties over de informatie- en communicatieprocessen …, in plaats van quasi-automatisch terug te vallen op ‘techno talk’…”

Het risico van het positioneren van informatiemanagement al seen intermediare functie tussen business en ict, is dat dit volgens Maes vaak resulteert in “‘stuck in the middle’: missionarissen die aan de businesskant tegen dovemansoren praten, halfbakken overlopers voor de ICT-kant en voor henzelf vredesstrijdkrachten zonder een duidelijke identiteit en missie.”

Wanneer de business de informatie-/communicatieverantwoordelijkheden delegeert richting de ict dreigt informatie te worden gereduceerd tot “feiten die beheerd worden in databases en haar kwaliteit wordt gemeten aan de hand van de kwaliteit van deze databases en andere technische artefacten, in plaats van aan de hand van haar bijdrage aan de business. ICT’ers zijn slechte informatiemanagers, als ze blijven redeneren vanuit hun technische wereld!”

Maes is van mening dat informatiemanagement gepositioneerd moet worden aan de linkerkant van de business-ICT-as: "Op deze manier wordt informatie in essentie gezien als een bedrijfsmiddel en kan de relatie met ICT een contractuele zijn: ICT heeft een ondersteunende functie en moet als dusdanig gemanaged worden; outsourcing is hier een logisch uitvloeisel van. Bovendien komt hierdoor beter tot uiting dat informatiemanagement een gedeelde algemene businessverantwoordelijkheid is: separaat, in de vorm van een aparte functie, is informatiemanagement enkel accommoderend en stimulerend, maar nooit leidend.”

“Organisatorische informatie gaat niet over feiten, maar over de interpretatie van feiten. Daarom is informatiemanagement in essentie de constructie van betekenis voor de organisatie. Daarnaast draagt het bij aan de betekenis van de organisatie voor haar omgeving; informatiemanagement gaat over de identiteit van de organisatie. Informatiemanagers zouden moeten ophouden te werken als vermomde ICT-managers. Evenmin zouden ze zich nog moeten definiëren als intermediairs tussen business en ICT. Informatiemanagers zijn bouwers van betekenis voor hun organisatie; hun ultieme taak is bij te dragen aan de identiteit van hun organisatie. (...) [I]nformatie-’governance’ [is] belangrijker voor hun slagen dan ICT-’governance’, beter informatiegebruik belangrijker dan steeds maar ingewikkelder informatieproductie en het begrijpen van organisatorische dubbelzinnigheid belangrijker dan het vatten van technische complexiteit. Uiteindelijk zijn hun attitude en hun gedrag van vitaler belang dan hun kennis: succesvolle informatiemanagers zijn ‘infopreneurs’, hypergevoelig voor het onthullende karakter van menselijke activiteiten, een bijdrage leverend aan het herinterpreteren van hun organisatie en van de maatschappij als geheel en dit alles belichamend in hun professionele en persoonlijke leven. Welke moderne organisatie kan aan een dergelijke informatiemanager voorbijgaan?”

Bron: Informatiemanager? ICT or business (mei 2011), Rik Maes

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)

Bij het uitleggen van nut en noodzaak van requirements aan collega's ontstonden spontaan de 4 B's voor het opstellen van requirements:

1. Betrek de belanghebbenden (stakeholders): "If you believe that you know the requirements better than the customer, you are part of the problem, not the solution" (Alan M. Davis)

2. Begrijp: probleem, behoefte.

3. Beschrijf het 'WAT' (en dus niet het 'HOE'); oplossingvrij, eenduidg, identifcieerbaar én uniek.

4. Beslis: valideren, prioriteren en autoriseren tót er een volledige set aan requirements is vastgelegd en vastgesteld.

Succesvol veranderen
Het werkt echt...! Het draagt bij aan beter presteren op lange termijn...!
Rudie Jansman, Kim de Vries

Bij Managementboek