Size Estimation in ERP Projects

by marc 22. december 2010 06:37

 

Difference ERP vs non-ERP

          Non-ERP: make your use cases etc. Estimate on a use case basis

          ERP: basic functionality already available, making usecases not seen as useful…

 

ERP: use available components as metric objects

How?

 

 

What is available at the end of Inception phase?

          Highlevel Business Process

          Highlevel Business Requirements

          Global Impact Analysis                

          Use Case Model

          Architecture Description

And because you chose ERP

All documentation/experience/knowledge of that ERP

 

 

 

 

Proposal for Metric Objects in ERP projects

Classify business process

        New: New business process (not implemented in ERP before)

        Modified: Business process implemented in ERP but with modifications

        Re-use: Business process implemented in ERP without processmodifications

 

Classify Standard & Custom components

        New: components to be developed because COTS application does not provide for required functionality

        Modified: components to be modified because COTS application already contains (standard components but these do not entirely meet the requirements

        Re-use: pre-existing software will be used, but needs to be tested and integrated with new and modified components

 

 

 

 

Detail level

Classification business process

        Clear link to process-model tool must be used

Classification COTS components

        ‘Chunk of functionality’ within ERP-module: Receipts, Payments etc

        Independent functioning customization: 1 Interface, 1 report

 

      Detail too low: ERP module Accounts Payable

      Detail too high: Individual form, parameter for report

 

 

Find Agreement on classification

          Classification done individually by

        Business keyusers

        Supplier – application consultants

        Supplier – customization consultant

        Testconsultant

 

 

 

          Together agree on complexity per businessprocess

        Per businessprocess count

      Nr of new components

      Nr of reused components

      Nr of modified components

        Result is: estimation points. A number (like function points) which gives:

      indication of expected effort needed for a businessprocesses

      Indication of complexity of a businessprocess in relation to the other businessprocess (relative weight).

 

 

How to use the results to refine estimates?

First use own experience on how many hours per point

Then:

Ask supplier to report (weekly) on hours spent per business process in elaboration phase.

This gives an indication of the hours needed in elaboration phase per process identified in the impact analysis.

Supplierdeliverables in elaboration phase can be linked to businessprocesses from the impact analysis. Therefore reporting on hours spent per process should not be a problem.

 

Future projects can be used to refine this.

        

 

Tips

          Do not treat it as a science

          Try to find the most suited variable for your situation

          Use more then one estimating technique

          Just do it!

 

 

Tags: , ,

Mogelijk Interessant

Wat werkt er allemaal niet op de gemiddelde IT afdeling waar we projecten voor de 'business' uitvoeren?

by marc 2. november 2009 07:26

Wat werkt er allemaal niet op de gemiddelde IT afdeling waar we projecten voor de 'business' uitvoeren?

- De organisatie blijf dusdanig veranderen qua koers en bemensing dat iedere keer het wiel weer opnieuw wordt uitgevonden. De lessons learned worden wel opgesteld, maar zijn bij begin van het volgende project al onvindbaar.

- De invoering van nieuwe ontwikkelmethoden (RUP) stokt door de omvang en interdepentie van projecten en door het outsourcingscontracten. Alles blijft waterval.

- Het niet opleveren (van voldoende kwaliteit) lijkt acceptabel, het niet hebben van een planning of zeggen dat je je aan een planning lijkt NIET acceptabel. Dat is raar, want iedereen vindt het dan blijkbaar prima dat er iets (een requirementsdocument, een ontwerp, een systeem) wordt opgeleverd waar iedereen van weet dat er nog een slag overheen moet. Maar de planning blijft heel lang heilig. Op een afgesproken datum krijgen we dus iets wat we onvolledig vinden, of eigenlijk niet willen, terwijl we dan nog steeds niet weten wanneer we wel krijgen wat we willen.


Dat moet worden aangepakt...

Naar mijn overtuiging werkt het (een beetje beter) als we
1. Agile planning toepassen
2. Vertrouwen creeeren tussen klant (business) en leverancier (it)
3. Fouten mogen maken.

 

Agile planning toepassen

Agile planning zegt dat plannen waarschijnlijk snel kunnen veranderen. Het is daarom nuttig om een 'feature'planning te maken. Los inschatten wat de omvang van een stukje functionaliteit is. Oftewel hoeveel tijd zou het kosten om een bepaald requirement te gaan realiseren. Nog even los van andere requirements. Pas nadat we alle inschattingen gemaakt hebben, proberen we de doorlooptijd in te schatten. Voordeel: je denkt elk requirement afzonderlijk door. Ook dat is nuttig bij het zien van de afzonderlijke risico's. Pas daarna voeg je gedeelde functies samen. Doe je het niet in deze volgorde dan zul je zien dat je per requirement minder goed weet wat er mee gemoeid is en tegelijkertijd reken je je rijk in de planning omdat je vermoed dat er gedeelde componenten in zitten.
Wees ook helder over onzekerheid òf in functionaliteit òf in de opleverdatum. Maar niet in allebei!

Vertrouwen creeren

Politiek gezien is de focus van verschillende afdelingen vaak erg uiteenlopend. Gevolg hiervan is dat beide partijen vaak enigszins wantrouwend zijn ten aanzien van de doelen die men met een bepaald programma of project denkt te bereiken.
Vertrouwen ontstaat pas als op meerdere niveau's bij zowel klant als leverancier helder en open gecommuniceerd wordt over korte en lange termijn doelen. Met daarbij uiteraard de kanttekening dat korte en lange termijn consistent moeten zijn en in elkaars verlengde liggen.

Fouten mogen maken

Het vermijden van fouten leidt tot gedrag waarbij risico's en onzekerheid onder de oppervlakte blijven. Dat op zijn beurt is niet goed voor het onderling vertrouwen. Des te eerder wordt overgegaan van planvorming naar uitvoering (van een eerste deelgebied) des te eerder loop je tegen je eigen onwetenheid aan. Dit moet niet afgestraft worden door de omgeving, maar herkend worden als aandachtsgebied.

 

Tags: , ,

Mogelijk Interessant