Hoe meten

De hierboven genoemde informatie is nodig om de onderstaande berekeningen uit te kunnen voeren.

ojectClass weging Uren e Efficiënti Pr ) * ( 1

∑

− =

De efficiëntie wordt gemeten door de som van de uren uit AIMS te selecteren per (deel)project en per activiteit. Dit te vermenigvuldigen met de weging voor die betreffende activiteit1. Deze weging moet worden ingevuld in het daarvoor bestemde onderdeel in de database.

De som van deze uren vermenigvuldigd met de weging moet worden gedeeld door de projectclass uit de tailoringdocumentatie.

De uitkomst van deze berekening is een getal dat kan worden gebruikt om de projecten met elkaar te vergelijken. Als voldoende informatie is verzameld van verschillende projecten kan een bandbreedte van uren worden aangegeven voor de verschillende projecten per project class. Bijvoorbeeld projecten met project class 2 zitten gemiddeld tussen de 200 en de 600 uur aan requirement engineering(Tabel 1 - voorbeeld bandbreedte)

Tabel 1 - voorbeeld bandbreedte

Project Class ondergrens Bovengrens

0 50 200

1 200 600

2 600 1200

3 >1200

1 De weging voor de activiteiten zal pas gebruikt worden als er na zorgvuldig meten is aangetoond dat de berekening moet worden gecompenseerd. Tot die tijd zal de weging voor de verschillende

∑

∑

−

=

)

*

(Re

)

*

(

1

Weging

quirements

weging

Findings

eit

Effectivit

De effectiviteit wordt gemeten door het aantal findings te vermenigvuldigen met de weging en dit vervolgens te delen door het aantal requirements vermenigvuldigd met de weging.

De wegingen kunnen worden gegeven in het daarvoor bestemde onderdeel in de database.

De findings zijn een consolidatie van de review documenten behorende bij Requirements engineering per project. De requirements worden verzameld uit CaliberRM.

De weging voor de findings wordt gegeven aan de verschillende levels van severity(minor, medium, major)2. De weging van de requirements kan worden gebruikt om per type requirement een weging te geven3. De verschillende types requirements zijn opgenomen in Bijlage B – Requirement types. De uitkomst van deze berekening is een getal dat kan worden gebruikt om de projecten met elkaar te vergelijken.

Tabel 2

Voorbeeld data van het meten van effectiviteit

Findings Requirements Effectivity

Weight Minor(1) Medium(2) Major(3) Non- functional Functional Detailed

Project AA00 5 4 1 20 50 30 84% AA01 10 0 0 20 50 30 90% AA02 5 5 5 20 50 30 70% AA03 0 4 1 20 50 30 89% AA04 4 5 1 20 50 30 83% Total 24 18 8 100 250 150 83%

Voor Project AA00 uit het voorbeeld is de berekening hieronder uitgeschreven:

( ) ( ) ( )

84 , 0 16 , 0 1 30 50 20 3 * 1 2 * 4 1 * 5 1 % ) * ( ) * ( 1 = − = + + + + − ⇒ = −

∑

∑

y effectivit weight ts requiremen weight findings

Beide berekeningen worden uitgevoerd per project in de database MEER in de Cascade map <*******>. De berekeningen gaan automatisch maar de benodigde data moet vooralsnog handmatig worden verzameld uit de verschillende informatiebronnen.

In hoofdstuk 3 en 10 zal per onderdeel van de berekening worden toegelicht hoe de informatie moet worden verzameld. De informatie is in verschillende fasen in het DSDM proces beschikbaar, zoals getoond in Figuur 1.

2 De weging van de severity levels wordt gebruikt om het verschil te kwantificeren. Standaard zal de weging minor=1, medium=2 en major=3.

3 De weging voor de requirement typen zal pas worden gebruikt als er na zorgvuldig meten is aangetoond dat de berekening moet worden gecompenseerd. Tot die tijd zal de weging voor de

CaliberRM

Reviews Tailoring

AIMS

= Projectdata

Feasibility Study Business Study ^Functional modeling iteration

Design & Build iteration

Business

Acceptance ^{Implementation Post-project} >>>>>>>> DSDM >>>>>>>>>>

9 Implementeren

Voor het implementeren van de efficiëntie en effectiviteit metingen zijn de volgende aspecten van belang: - Randvoorwaarden - Kwaliteit - Subjectiviteit - Succesfactoren - Informatiebehoefte stakeholders 9.1 Randvoorwaarden

Als randvoorwaarden zijn de volgende aspecten van belang:

- Het gebruik van CaliberRM is verplicht voor alle projecten bij Business Solutions. Dit wordt afgedwongen door het management en de projectleiding.

- Het registreren van de uren wordt bijgehouden volgens de nieuwe richtlijnen die zijn opgesteld voor projecten bij Business Solutions. Dit wordt afgedwongen door het management en de projectleiding.

- De Project Class wordt voor alle projecten bij Business Solutions verplicht ingevuld. Dit wordt afgedwongen door het management.

- Het reviewen van de PRL is verplicht. Dit wordt afgedwongen door het management en de projectleiding.

- Het gebruik van het Excel review formulier is verplicht. Dit wordt afgedwongen door het management en de projectleiding.

- Het gebruik van de tool MEER en het maken van rapportages wordt gedaan door persoon die zelf inzicht heeft in de geproduceerde rapportages. Dit om te zorgen dat de rapportages niet alleen maar vragen oproepen maar juist ook direct beantwoorden. (zie uitwerking analyses)

9.2 Kwaliteit

De kwaliteit van de data uit CaliberRM, AIMS, reviews en het werkplan is van belang voor de uiteindelijke kwaliteit van de efficiëntie en effectiviteit getallen.

Het is dus van belang om de volledigheid en juistheid van de data te waarborgen zodat de uiteindelijke metingen van efficiëntie en effectiviteit van een hoge kwaliteit zullen zijn.

9.2.1 CaliberRM

Zoals gesteld in de randvoorwaarden is het gebruik van CaliberRM verplicht.

Huidige situatie is echter dat niet alle projecten CaliberRM gebruiken. Dit moet naar de 100% gebruik worden gebracht.

Om dit te kunnen stimuleren en controleren wordt de volgende taak uitgevoerd bij de afdeling Business Acceptatie.

Controle en stimulatie CaliberRM

- Een volledig lijst van nieuw gestarte en beëindigde projecten wordt opgevraagd bij de Portfolioregisseurs (afdeling Management Support).

- Voor de lopende projecten wordt gecontroleerd of deze reeds gebruik maken van CaliberRM. Dit door in CaliberRM het betreffende project op te zoeken en te controleren op gebruikers en reeds ingevoerde requirements.

- Voor de nieuw gestarte projecten word bij de projectmanager geïnformeerd of het project gebruik gaat maken van CaliberRM en of er behoefte is aan informatie of training in het gebruik van CaliberRM.

- Als het project aangeeft geen gebruik te maken van CaliberRM moet dit worden aangevraagd bij de leidinggevende. Leidinggevende kan ontheffing geven voor het gebruik van CaliberRM. Dit wordt dan met opgaaf van reden geregistreerd in de MEER tool.

- Bij de rapportages naar het management wordt gerapporteerd hoeveel procent van de projecten CaliberRM gebruikt.

9.2.2 AIMS

Zoals gesteld in de randvoorwaarden registreren alle medewerkers verplicht uren volgens de nieuwe richtlijnen die zijn opgesteld voor projecten bij Business Solutions.

Huidige situatie is echter dat:

- de gegevens in AIMS-ATR niet overeen komen met de werkelijkheid(data in AIMS is niet gesynchroniseerd met de HR database)

- niet alle medewerkers registreren hun uren

- niet alle medewerkers registreren hun uren op de juiste activiteitencode

Om dit te verbeteren moet er worden gestimuleerd en gecontroleerd. Hiervoor wordt de volgende taken uitgevoerd bij de afdeling Management Support.

Informeren projectmanager over uren registratie gedrag + Update gegevens in AIMS-ATR

- Een volledig lijst van nieuw gestarte en beëindigde projecten wordt opgevraagd bij de Portfolioregisseurs (afdeling Management Support).

- Bij de nieuw gestarte projecten word, bij de projectmanager, gecontroleerd wie er aan het project werken en of deze medewerkers correct in AIMS staan geregistreerd.(lijst uit AIMS)

- Foutieve gegevens worden middels de daarvoor bestemde entry en exit formulieren

gecorrigeerd(http://banknet.nl.eu.abnamro.com/mijn_bedrijfsonderdeel/bss/mcbs/medewerkers/af dmcbsintern_medewerkers.html)

- De projectmanager krijgt om de week een overzicht van de geschreven uren per medewerker ter controle aangeboden.

9.2.3 Project Class

De project class wordt op dit moment nog niet bijgehouden. om tijdig problemen te signaleren bij het beoordelen van de project class zal bij de afdeling Business Acceptatie de volgende taak worden uitgevoerd.

Informeren naar project class beoordeling

- Een volledig lijst van nieuw gestarte en beëindigde projecten wordt opgevraagd bij de Portfolioregisseurs (afdeling Management Support).

- Bij de projecten wordt geïnformeerd naar problemen met de beoordeling van de project class. - Na aanleiding van de gemelde problemen zal actie worden ondernomen. Dit kan door

verbeteringen of structurele problemen te melden aan een PIM(Process Improvement Manager) of het indienen van een PCR(Process Change Request) voor het aanpassen van de projecttailoring documentatie.

9.2.4 Review

Het reviewen is een verificatie en kwaliteitscontrole methode voor de deliverables van een project. Met behulp van reviewen worden fouten vroeg in het project geïdentificeerd om er voor te zorgen dat het juiste product wordt opgeleverd met een hoge kwaliteit. Reviewen voorkomt rework en faciliteert second opinions en het leren van elkaar.

De Huidige situatie kent echter de volgende risico's: - Het reviewen is subjectief.

- Het reviewproces is bedoeld om de kwaliteit te verhogen van de deliverables en niet om de effectiviteit te meten. Een ongewenst effect zou daling van motivatie, argwaan, discussie over accepteren of afwijzen van commentaar, risico dat de reviewer niet teveel findings wil vinden om collega niet af te vallen.

Om dit vast te stellen en vervolgens te voorkomen en verbeteren moeten de volgende taken uitgevoerd bij de afdeling Business Acceptatie en Business Solutions en moet in elk geval paragraaf 9.3 in acht worden genomen.

Eenmalig toetsen subjectiviteit reviews

Eenmalig toetsen om vast te stellen of de huidige reviews daadwerkelijk subjectief zijn. Toetsen wordt op de volgende manier gedaan onder supervisie van Business Acceptatie: - Toetsing: dezelfde review wordt eenmalig gedaan door meerdere reviewers. Blijkt dat de

verschillende reviewers tot dezelfde findings met dezelfde waardering(severity levels) komen. Dan is het huidige reviewproces niet subjectief.

Vinden de verschillende reviewers andere findings en waarderen zij deze ook verschillend dan is het reviewproces subjectief.

o Als de uitkomst van deze toetsing is dat het reviewproces geen subjectieve data oplevert kan het reviewproces worden gebruikt.

o Als de uitkomst van deze toetsing is dat het reviewproces subjectieve data oplevert moet er worden vastgesteld wat de invloed is van deze subjectiviteit.

Aanvulling huidige reviewen

Om risico’s te voorkomen zoals eerder genoemd of om in plaats van het huidige

reviewproces voor meetdata te gebruiken, moet er een formele inspectie worden gehouden aan het einde van de FMI fase.

Bij Business Acceptatie wordt momenteel reeds getest of de opgestelde requirements op meerdere manieren zijn uit te leggen. Deze interpretatie toetsing moet worden

geformaliseerd tot een verplichte toetsing aan het einde van de FMI fase. Deze toetsing wordt gedaan door acceptatie specialisten die niet betrokken waren bij het project. Dit omdat blijkt dat de effectiviteit van de huidige inspecties en reviews, die plaatsvinden tijdens de gehele business analyse afneemt. Dit komt omdat dezelfde club mensen keer op keer dezelfde(verbeterde) set requirements onder ogen krijgt. Op deze manier kan er niet meer objectief naar de requirements worden gekeken.

Voordelen van deze formele inspectie zijn:

- Niet meer op persoonlijk niveau, maar op projectniveau.

- Minder vragen van de vendor omdat requirements maar op één manier zijn te interpreteren.

- Kostenbesparing omdat interpretatie fouten worden gecorrigeerd voordat er wordt gebouwd aan de applicatie.

- Data voor het meten van effectiviteit verbeterd. Data is beter te vergelijken doordat de toetsing bij elk project op hetzelfde moment en dezelfde manier plaatsvindt.

Voor een goede invoering van deze formele inspectie moet bekend zijn of dat wat er gemeten gaat worden ook nodige en objectieve metingen zijn. Dit kan worden getoetst door middel van een toetsing zoals beschreven bij eenmalig toetsen subjectiviteit reviews. 9.2.5 Standaardisatie requirements

Omdat bij het meten gebruik wordt gemaakt van requirements is het van belang dat er duidelijk is hoe requirements moeten worden opgesteld en wat voor requirements er opgesteld moeten worden. Dit omdat bij het ontbreken van een standaard de kans bestaat dat bijvoorbeeld de typen requirements voor verschillende doeleinden worden gebruikt.

Huidige situatie is dat dit goed is beschreven en dat er al meerdere cursussen zijn gegeven om dit te verbeteren. Ook het reviewen en het gebruik van CaliberRM dwingen een uniforme werkwijze af.

9.3 Subjectiviteit

Omdat de project class en de reviews op zich al mogelijk subjectieve data produceren is het van belang dat de efficiëntie en effectiviteit metingen niet een wedstrijd karakter krijgen, daling van motivatie veroorzaken, argwaan wekken, discussie over accepteren of afwijzen van commentaar brengen en risico’s met zich meebrengen dat de reviewer niet teveel findings wil vinden om collega niet af te vallen. Om deze punten te voorkomen en het wedstrijd karakter niet te stimuleren is het van belang dat de efficiëntie en effectiviteit rapportages alleen bekend worden gemaakt als management informatie.

Voorbeeld:

Het aantal findings uit de reviews kan eenvoudig worden beïnvloed door een defect aan te merken als een suggestion of discussion.

Gevolg hiervan is dat het project een hoger effectiviteit getal krijgt, en dat de verwachte waarde voor toekomstige defects juist stijgt. Veel discussie of suggesties op de huidige requirements kan namelijk leiden tot defects in bijvoorbeeld detail requirements of tot meer vragen van de vendor.

9.4 Succesfactoren

Succesfactoren voor het meten van efficiëntie en effectiviteit:

- Projecten en afdelingen moeten met elkaar en/of in de tijd vergeleken kunnen worden op basis van de efficiëntie en effectiviteit percentages.

- Geleerd kan worden van een project met een hogere of lagere efficiëntie of effectiviteit, door in detail te analyseren wat de afwijking heeft veroorzaakt.

- Requirement engineering gericht en onderbouwd kan worden aangestuurd en verbeterd. - Kan worden aangetoond dat investeringen in het proces ook daadwerkelijk resultaat hebben. - Besteding van middelen kan worden verantwoord aan de interne klant.

- Ervaringscijfers kunnen worden verkregen ter ondersteuning van de resource planning voor het operational plan.

In document Appendix A - Requirement Types (pagina 32-38)