Page 1

Reader 4

Project Planning

Ger Saris versie: 1.0 25-3-2013


Project Planning

Project Planning 1.

Inleiding

Planningen worden vaak – zeker door technische mensen – als onnodige overhead beschouwd. Het gevolg van geen of een slechte planning kan zijn dat het project later veel effort moet stoppen in het oplossen van projectrampen, in plaats van in proactief plannen om deze rampen te vermijden. Planning en projectmanagement zijn geen overhead, maar vormen een normaal onderdeel van de projectwerkzaamheden. Een planning kan vóór de aanvang van een project gemaakt worden (nodig voor de kostenbegroting en inzet van personeel en middelen) en kan vervolgens worden verfijnd aan het begin van het project.

1.1. agenda is geen plan Een opdracht in je agenda noteren, zoals dat je huiswerk af moet zijn, is niet hetzelfde als het maken van een plan. Als je alleen de deadline opschrijft, dan weet je wanneer het af moet zijn. Je weet niet hoeveel inspanning het je gaat kosten en op welk moment je die inspanning gaat doen. Je weet ook niet welke werkzaamheden er precies gedaan moeten worden om tot het resultaat te komen en je weet niet of je het werk misschien met meerdere mensen gaat doen.

Deze reader beschrijft het maken van een planning in het kader van een project, denk hierbij aan een software-ontwikkel-project, maar het past ook bij andere soorten projecten. Als eerste wordt daarom aandacht besteed aan wat projecten zijn, daarna komt het plannen aan bod en als laatste is er aandacht voor het gebruiken van de planning tijdens het projectverloop.

Pagina 1 van 17


Project Planning

2.

Softwareprojecten

De professionele software van tegenwoordig is zo complex geworden dat het meestal niet meer door één persoon vanachter zijn PC’tje kan worden geschreven. Om te zorgen dat programma’s binnen afzienbare tijd gereedkomen, moet het maken van software dan ook meestal in projectvorm worden gedaan. Eén persoon zou hiervoor veel en veel teveel tijd nodig hebben. Teams bestaande uit programmeurs, analisten, ontwerpers, architecten, adviseurs, projectleiders, testers, specialisten en anderen werken samen in een project om een softwareproduct tot stand te brengen.

2.1. Wat is een project? Een projectmatige aanpak leent zich het meeste voor activiteiten die éénmalig zijn (niet: een auto verkopen, of vakken vullen bij de supermarkt) en die van tijdelijke aard zijn (niet: productiewerk, verkoop of onderhoudswerk). Verder moeten de activiteiten resulteren in een min of meer goed omschreven product en moet er behoorlijk planmatig kunnen worden gewerkt. Dat betekent dat een groot deel van het werk voorspelbaar moet zijn, routinematig, of analoog aan eerdere werkzaamheden. Het is wel handig als soortgelijk werk al eens eerder is gedaan en als voorbeeld kan dienen. Projectmatig werken staat daarmee in tussen improviserend werken en routinematig werken:

Wanneer? Resultaat? Bekendheid? Vrijheid? Werkwijze?

3.

Improviserend Ad hoc Onzeker Nieuw, plotseling Veel Chaotisch

Projectmatig Te voorzien Redelijk zeker Vrij nieuw, planmatig Vooraf doordacht Geleidelijk duidelijker

Routinematig Herhalend Zeker Bekend Nauwelijks Vaste procedure

Kenmerken van een project

Een project is te karakteriseren door middel van een aantal kenmerken:

3.1. Tijdelijk. Een project heeft een tijdelijk karakter: Er is een duidelijk begin (ook wel start-up of kick-off van het project genoemd) en een einddatum. De einddatum is onderhandelbaar, maar staat meestal wel vroeg vast. Een project is eindig.

3.2. Product. Het doel van een softwareproject is om een softwareproduct af te leveren. Dit kan een splinternieuw programma zijn dat nog niet eerder bestond, het kan een bestaand product zijn dat is omgeschreven in een andere taal of voor een ander operating system, of een bestaand product dat fors moet worPagina 2 van 17


Project Planning den aangepast of uitgebreid. Verder moet het wel een behoorlijke klus zijn, die door meerdere personen moet worden uitgevoerd, vanwege verschillende expertises die nodig zijn, of omdat één persoon er te lang over zou doen. Als aan deze voorwaarden niet wordt voldaan is een projectaanpak door zijn organisatorische overhead niet zo zinvol.

3.3. Projectorganisatie. Voor een project worden vaak medewerkers bij elkaar gezet buiten de normale organisatiestructuur van het bedrijf om. Dat kan een subgroepje uit één afdeling zijn, maar ook personen uit verschillende vakgebieden, afdelingen, of zelfs organisaties. De teamleden kunnen ook gedeeltelijk of voor een beperkte tijd (speciale klusjes) aan het project meedoen. Binnen het project worden door de leden vaak verschillende rollen vervuld. De projectleider kan een lijnmanager (= bossy type) uit de eigen organisatie zijn, of een wat meer ervaren programmeur, maar kan bijvoorbeeld ook extern worden ingehuurd. De projectleider is verantwoordelijk voor het structureren en aansturen van het project (projectplan), de werksfeer (team building), het aanstellen, inzetten en beoordelen van teamleden, het doen van rapportages naar bazen en opdrachtgevers, etc. Hij kan deze taken ook delegeren, afhankelijk van de hoeveelheid tijd die hij beschikbaar heeft voor zijn werkzaamheden. Vaak loont het om bij het samenstellen van het team of bij het verdelen van de rollen de verschillende capaciteiten van de teamleden te benutten. Hiervoor zijn verschillende methoden beschikbaar waaronder het model Belbin 1. Hiernaast staat een plaatje van een projectleider dat is spottend bedoeld, want er zijn aardige en minder aardige, zoals bij alle rollen. Daarnaast kunnen er allerlei specialisten in het projectteam zitten: van gewone programmeurs tot systeemarchitecten, specialisten op het gebied van hardware, de applicatie die gebouwd wordt, computer graphics, user interface, documentatie, etc. Een moeilijkheid voor projectleden is vaak dat ze naar twee kanten verantwoordelijkheid moeten afleggen: naar de projectleider (of meerdere, als ze in meerdere projecten tegelijk meedoen) en naar de organisatorische chef, bazen die tegenstrijdige belangen kunnen hebben. De projectleider is in eerste instantie geïnteresseerd in het succesvolle verloop van het project, de afdelingschef in de verdeling van mensen over projecten en andere werkzaamheden buiten de projecten, en in de ontwikkeling en inzetbaarheid (employability) van de medewerkers, de vakkennis binnen zijn afdeling.

3.4. Opdrachtgever. De klant van het projectteam, de persoon of organisatie die het product heeft besteld en die het gaat betalen. Hij/zij heeft belang bij een bevredigende uitkomst van het project. Het kan zijn dat de opdrachtgever op bepaalde momenten knopen moet doorhakken, beslissingen moet nemen. De opdrachtgever kan zowel binnen als buiten de eigen organisatie zitten.

3.5. Budget. Om het project tot een goed einde te kunnen brengen beschikt de projectorganisatie over een budget. Dat kan geld zijn, maar ook (in een grotere organisatie) uren, mensen, faciliteiten en middelen. Het budget wordt meestal in onderling overleg van tevoren vastgelegd op grond van een inschatting van de projectleiding en de opdrachtgever, maar kan soms gedurende het project worden bijgesteld. 1

In het model van Belbin, een Engelse managementprofessor, wordt een negental teamrollen voor persoonstypen omschreven die elkaar aanvullen of juist tegenwerken.

Pagina 3 van 17


Project Planning 3.6. Fasering en planning. Een groot project wordt vaak opgesplitst in een aantal fasen, die elk worden afgesloten met een go/no-go beslissing. Een fase zou bijvoorbeeld kunnen worden afgesloten met de oplevering van een prototype, aan de hand waarvan de opdrachtgever beslist of hij nog geld over heeft voor de verdere ontwikkeling. Verder zijn er vaak milestones gedefinieerd: belangrijke momenten of oplevering van deelproducten, met een bijbehorende geplande opleverdatum. De milestones dienen als ijkpunten voor de planning van het project. Om de kosten in de hand te kunnen houden moet er in elk project planmatig gewerkt worden. Door middel van een planning worden activiteiten, inzet en kosten zo goed mogelijk voorspeld en gevolgd om het project eventueel bij te kunnen sturen. In de voorbereidende fase worden de organisatorische aspecten van een project vastgelegd in een projectplan.

4.

Dimensies van een project

Kijkend naar een software-ontwikkel-project zijn er verschillende belangrijke dimensies te onderscheiden. Deze zijn:

4.1. Productgrootte De omvang van de uiteindelijke applicatie noemen we productgrootte en is bijvoorbeeld uit te drukken in het totaal aantal componenten of het aantal regels code met bijbehorende documentatie. Dit is een moeilijk te meten grootheid omdat aantal componenten niets zegt over de complexiteit en de absolute omvang. Het aantal componenten vloeit vaak voort uit de gekozen architectuur. Ook regels code wil niets zeggen over of dat efficiënt is en kwalitatief goed is. Je zou productgrootte ook kunnen zien als de implementatie van (het gevolg van) de eisen en wensen (requirements) en van het aantal Use Cases. Kortom iedereen kan zich iets voorstellen bij “de grootte van het programma” en toch is het moeilijk te meten.

Pagina 4 van 17


Project Planning

4.2. Doorlooptijd Dit is de duur van het project van startdatum tot einddatum, uit te drukken in dagen, weken, maanden of jaren. Vaak staat de deadline, de dag waarop het product af moet zijn, al in een vroeg stadium vast of wordt door de opdrachtgever opgelegd. Met hoe meer mensen tegelijkertijd aan het project gewerkt kan worden hoe korter de doorlooptijd, mits de taken opgedeeld kunnen worden.

4.3. Kwaliteit De kwaliteit van een software-product is uit te drukken in het aantal en aard van de fouten (bugs) die er in zitten. Als een projectteam slordig en haastig werkt of met ongekwalificeerde of incapabele mensen, dan zal de kwaliteit lager zijn. Dit is ook een relatief begrip.

4.4. Inspanning(Effort) Het aantal arbeidsuren dat verricht moet worden om het project te volbrengen, heet inspanning. Omdat hier geen rekening wordt gehouden met vakanties, verlofdagen, arbeidscontracten, lengte van werkdagen, aantal projectleden, deelbaarheid van taken is dit niet direct te vertalen naar doorlooptijd. Inspanning is wel heel goed te meten in aantal gewerkte uren. Dit vertaalt zich via salaris door naar projectkosten.

4.5. Productiviteit Dit is de gemiddelde werksnelheid. Ervaren mensen lossen sneller en beter problemen op dan onervaren. Ervaren mensen zijn vaak ook duurder, dus een projectmanager zal een prijs/kwaliteit afweging moeten maken bij het in dienst nemen van personeel. Sommige mensen zullen door gebrek aan motivatie minder presteren. Het hangt ook af van het moment op de dag en de dag van de week. Kortom een uur van de een is niet hetzelfde als een uur van een ander. Onder druk geplaatst, lukt het een projectleider vast om het team harder te laten werken, echter daar zit een grens aan. Het kan leiden tot stress en daarmee gepaard gaande improductiviteit. Een projectleider moet een balans zoeken tussen werkdruk en continu誰teit, korte en lange termijn, incidentele en structurele oplossingen.

Pagina 5 van 17


Project Planning 5.

Projectfasen

Tijdens een project wordt een aantal fasen, of stappen, doorlopen:

5.1. Voorbereiding. De voorbereiding van een project wordt vaak door een klein clubje gedaan, de projectleider kan daar goed deel vanuit maken. In deze fase wordt het initiatief tot het project genomen, kunnen haalbaarheidsstudies, contacten met de opdrachtgever, kostenschattingen, schrijven van projectplannen en dergelijke plaatsvinden.

5.2. Kick-off. De officiële aftrap van het project. Vaak zijn er al een aantal projectmedewerkers binnen gekruid. Vanaf dit moment gaat de planning van het project in.

5.3. Projectrealisatie fase(-iteraties) In een groot project is het werk meestal in een aantal fasen onderverdeeld. Hiervoor kunnen diverse methodes worden gebruikt, bijvoorbeeld Waterval. Dit faseren gebeurt om het project beter beheersbaar te maken. Grote projecten lopen namelijk nogal makkelijk uit de hand als er geen duidelijke overzichtelijke structuur is en geen controlepunten op gezette tijden. Een fasering zou kunnen zijn: Definitiefase, Ontwerpfase, Implementatiefase. De fasering kan afhangen van het gebruikte lifecyclemodel 2. Het voordeel van fasering is dat het project is opgedeeld in een aantal duidelijk onderscheidbare onderdelen die telkens moeten worden afgerond om aan een volgende fase te kunnen beginnen en die elk aan het eind kunnen worden beoordeeld. Na elke fase kan de opdrachtgever een go/no-go beslissing nemen. De detailplanning (en betaling) kan per fase gaan. Hiermee verklein je de kans dat door tussentijdse wijzigingen de zaak onoverzichtelijk wordt en uit de hand gaat lopen. Aan het eind van het project wordt het product overgedragen aan de klant en wordt de projectgroep ontbonden. Vaak wordt er nog een nazorgtraject ingezet.

5.4. Nazorg. Als het project is afgelopen moeten er soms nog een aantal werkzaamheden worden verricht, zoals nacalculatie van de kosten, ondersteuning en onderhoud (bugs oplossen, aanpassingen en nieuwe wensen implementeren). Soms gaan er zelfs projectmedewerkers na afloop van het project over naar de organisatie van de klant, als expert “mee met het product” om onderhoud te verrichten. 2

Lifecyclemodel: Een reeks methoden, technieken en algemene wijsheden (ervaringsfeiten) om een (software ontwikkel) project beheersbaar te maken en zo op tijd en binnen budget het gewenste product af te leveren.

Pagina 6 van 17


Project Planning 6.

Waarom een projectplanning?

Het zal duidelijk zijn dat een correcte planning van softwareprojecten van zeer groot belang is vanuit een aantal oogpunten:

Realistische schatting van de kosten voor de klant. Realistische schatting van de kosten voor het eigen management. Realistisch beeld van de uitvoerbaarheid van het project. Optimale inzet van resources: personeel, hardware, software, ruimte: wanneer is wat nodig, hoeveel, hoelang? • Aansturing van het project. Hoe loopt het? Waar liggen eventuele knelpunten? • Duidelijkheid naar de projectleden (Wat moet ik doen?) en de opdrachtgever (wat spoken ze eigenlijk uit?). • Persoonlijke beoordeling (Wat zijn de taken van de medewerkers en worden ze naar behoren uitgevoerd?). • • • •

7.

Het plannen

Het plannen van een project bestaat in de simpelste vorm uit:

het bepalen van de totale duur van het project ( inspanning, doorlooptijd) het opdelen in taken  workbreakdown het in de tijd plannen van die taken, waarbij met eventuele afhankelijkheden rekening moet worden gehouden. • In een planning moet het totale project worden opgedeeld in hanteerbare, overzichtelijke stukken, die liefst worden afgerond met een milestone. • • •

7.1. Workbreakdown Van elke deeltaak moet de begin- en einddatum vastliggen, de totale effort (Hoeveel arbeidstijd in maanden/dagen/uren?) en de eventuele afhankelijkheden. (Welke onderdelen moeten eerst af zijn? Welke taken zijn er van afhankelijk?) Verder moet uit een planning de inzet van de medewerkers duidelijk zijn: Hoeveel mensen zijn wanneer nodig? Als het mogelijk is zijn de activiteiten al aan personen gekoppeld. De omvang van de deeltaken moet in enige verhouding staan tot de totale effort(inspanning) van het project. In een project van 12 maanden moet je geen taak van 27,5 minuten hebben, maar ook geen van 7 maanden. Een reden om niet te langdurige taken te hebben is, dat de status van een taak onduidelijk kan zijn (“Loopt nog!”), zolang deze nog niet is afgerond. Een criterium kan dus zijn dat een taak niet zó groot mag zijn dat hij over diverse projectbijeenkomsten heen loopt. Het risico dat eventuele problemen dan niet tijdig worden geconstateerd wordt dan te groot. Als voorbeeld van het maken van een workbreakdown kun je, je eigen studie nemen. Neem als voorbeeld een vak waarbij je een boek moet bestuderen. Hoe lang doe je daar op? Je kunt een pagina lezen en meten hoeveel minuten je dat kost. Tel het aantal pagina’s van het boek en vermenigvuldig het aantal minuten. Als je op meer dan 8 uur uit komt, is het beter om de detailgraad te verlagen. Pagina 7 van 17


Project Planning Neem het bestuderen van een hoofdstuk als taakgrootte. Bepaal de omvang van de hoofdstukken en neem indien mogelijk, ook de moeilijkheidsgraad mee. Zo kom je tot een veel preciezere deeltakenlijst.

7.2. Partitioneren (opdelen onder meerdere mensen) Deeltaken kunnen door één of meerdere personen worden uitgevoerd. In het algemeen geldt: hoe meer personeel wordt ingezet, hoe sneller een taak af is. Sommige taken zijn perfect op te delen. Als je een groot veld met aardbeien moet plukken gaat dat met twee keer zoveel personeel ook bijna twee keer zo snel (zolang ze elkaar niet in de weg lopen). Een taak als het krijgen van een baby door een vrouw is niet op te delen. Dat is een atomaire taak die (normaal ongeveer) 9 maanden duurt en niet te verdelen is over meerdere vrouwen. Een dergelijke taak kan alleen maar door één persoon worden uitgevoerd. Veel taken zitten hier tussenin. Ze gaan wel sneller met meer personen, maar door overhead (afstemming en informatieoverdracht) gaat het toch relatief minder snel. Aan de andere kant is er ook een effect dat maakt dat een taak beter door meerdere personen kan worden gedaan: Synergie, het onderling stimuleren van mensen, de meerwaarde van samenwerking, kan soms maken dat het eindresultaat beter is dan de som van de delen.

7.3. Het opstellen van een planning Om een goede planning te maken moeten er eerst deeltaken worden onderscheiden. Dat zijn stukken werk die door één of meerdere medewerkers worden gedaan en die met een duidelijk controleerbaar product worden afgesloten. De deeltaken moeten overzichtelijk zijn. Als er iets mis gaan, of het loopt uit, moet dat snel te constateren zijn. Van elke deeltaak moet een schatting van de benodigde hoeveelheid werk worden gegeven (hoeveel personen zijn er hoe lang mee bezig?). Vervolgens moeten de afhankelijkheden van de deeltaken worden bekeken: Welke taken moeten eerst zijn afgerond om een bepaalde deeltaak uit te kunnen voeren? Aan de hand de afhankelijkheden en de beschikbaarheid van de benodigde medewerkers kan nu worden bepaald wanneer elke taak moet worden uitgevoerd. Het kan nog een heel gepuzzel zijn om alles goed in elkaar te passen. De geschatte tijdsduur van deeltaken kan door de projectleider worden vastgesteld, maar het is beter om dit in samenspraak te doen met de mensen die het gaan uitvoeren. Hierdoor voelen zij zich meer betrokken en zullen ze meer geneigd zijn om de schatting ook waar te maken. Desondanks blijft schatten heel moeilijk en is het aan te bevelen om slack time in de planning op te nemen. Dit is reservetijd voor calamiteiten, zoals: te krap geplande activiteiten, onvoorziene problemen, vergeten taken, etc. Het is redelijk om hier zo’n 15% van de totaal beschikbare tijd voor uit te trekken. Let er tijdens de uitvoering op dat slack time die niet nodig is (in het geval van een perfecte planning), maar die ook niet wordt gebruikt (om bijvoorbeeld een activiteit eerder te starten) onherroepelijk verloren is, dit is improductieve tijd geworden. Projectleden gaan dan chatten, of eerder naar huis, maar deze tijd komt niet ten goede aan het project.

7.4. verschil tussen werktijd(inspanning) en doorlooptijd Eén van de problemen bij plannen wordt veroorzaakt door het verschil tussen werktijd en doorlooptijd. De werktijd is de tijd die nodig is om een taak uit te voeren. De doorlooptijd is de tijd die verstrijkt vanaf het begin van de taak tot aan het eind van de taak. De doorlooptijd kan korter zijn dan de werktijd, want een taak van 2 dagen kan door twee mensen in één dag worden gedaan. De door-

Pagina 8 van 17


Project Planning looptijd kan echter ook groter zijn dan de werktijd, als er andere taken tussendoor komen. Een aantal redenen voor het verschil tussen deze twee tijden vind je hieronder: • • • • • • • • • •

Activiteiten buiten het project. Vakantie, vrije dagen, (tand)artsbezoek. Te laat, verslapen, vergeten. Overleg met anderen. Coaching door of bij anderen. Administratie (bijv. urenregistratie, reisaanvragen, declaraties). Opleidingen. Niet-projectvergaderingen. Telefoontjes, afhandelen van e-mail, koffiepraatjes. Wachttijden voor vergaderingen (die te laat beginnen, uitlopen), printer, computer. Schakeltijden tussen verschillende activiteiten.

Een verlies van 30% is typisch iets voor een beginnend programmeur, terwijl een meer ervaren analist eerder rond de 50% zal zitten, omdat hij in het algemeen meer coördinerende, coachende en andere taken zal hebben.

7.5. PERT-chart Bij het bekijken van afhankelijkheden kan het handig zijn om een PERT-chart te gebruiken. Hieronder is een voorbeeld opgenomen:

PERT (Program Evaluation and Review Technique) is een projectplanning analyse methode. De methode heeft tot doel om de benodigde minimale tijd te berekenen om een project te realiseren. Elke taak in een PERT is gebaseerd op drie soorten inschattingen: O = Optimistische inschatting ( ET = Earliest Time) Pagina 9 van 17


Project Planning W = Waarschijnlijke inschatting P = Pessimistische inschatting (LT = Latest Time) De inschatting volgt uit de berekening: (O + 4W + P)/6 De PERT methode wordt vaak toegepast bij projecten met hoge onzekerheden en geringe ervaring. Bij routinematige projecten wordt vaker de kritieke pad-methode toegepast.

8.

Kritieke pad

Het kritieke pad is een begrip uit de theorie van projectplanning dat aangeeft welke activiteiten in een tijdsplanning de einddatum bepalen. In de planning van een project ontstaat een kritiek pad als sommige van de uit te voeren activiteiten (of 'taken') van andere activiteiten afhankelijk zijn, bijvoorbeeld omdat de ene activiteit pas kan starten nadat een andere activiteit is voltooid. Zo kunnen bij het bouwen van een huis, de muren pas gemetseld worden als de fundering gereed is, en de ramen kunnen pas gezet worden als de muren klaar zijn. Activiteiten liggen in het kritieke pad, als het schuiven van de activiteit het schuiven van de einddatum veroorzaakt.

8.1. Voorbeeld In het onderstaande voorbeeld van een Gantt-chart moet taak C na taak A uitgevoerd worden, en taak D na taak B. Door de gezamenlijke lengte bepalen taak A en taak C de einddatum van de planning. Hierdoor liggen Taak A en Taak C in het kritieke pad (hier rood gekleurd).

Het kritieke pad is dynamisch. Mocht bijvoorbeeld Taak D 2 dagen langer duren dan oorspronkelijk gepland en de planning wordt tijdens uitvoering gewijzigd, dan zullen Taak B en D het kritieke pad bepalen en vallen Taak A en C niet meer onder het kritieke pad. Kritieke paden kunnen eenvoudig zichtbaar gemaakt worden met planningssoftware, zoals MSProject.

Pagina 10 van 17


Project Planning 9.

Gannt-chart

Een voorbeeld van een Gantt-grafiek. De blauwe balken zijn taken die uitgevoerd moeten worden. De pijlen geven condities aan: een taak die eerst volbracht moet zijn voordat aan de volgende begonnen kan worden. De zwarte ruiten zijn milestones: ijkpunten waarop een bepaalde toestand gereed moet zijn.

9.1. Geschiedenis Henry Laurence Gantt ontwikkelde de Gantt-grafiek rond 1910. In zijn werk als werktuigkundig ingenieur, management consultant en bedrijfsadviseur werd de Gantt-grafiek gebruikt als een visueel hulpmiddel om de planning en voortgang van een project te laten zien. In die tijd werd dit gezien als een opzienbarende innovatie. De Gantt-grafiek werd onder andere gebruikt bij grote bouwprojecten als de Hoover Dam in 1931 en het interstate highway-netwerk in 1956. In 1952 publiceerde Berend Willem Berenschot het eerste Nederlandse boek over de Gantt-kaart, waarbij deze werd gepresenteerd als een hulpmiddel voor de bedrijfsleiding. Tegenwoordig wordt de Gantt-kaart wereldwijd beschouwd als een geaccepteerde standaard. Voor het maken van een projectplanning met Gantt-charts en dergelijke zijn zeer veel tools beschikbaar, bijvoorbeeld MS Project.

10. Voorbeeld van het plannen met afhankelijkheden We bekijken een klein project. Het werk is van tevoren opgesplitst in elf deeltaken A, B, t/m K. Elk van de deeltaken kan door ĂŠĂŠn programmeur tegelijk bewerkt worden. Het aantal mensdagen dat per activiteit gepland is, is te vinden in de onderstaande tabel: activiteit

A

B

C

D

E

F

G

H

I

J

K

geschatte duur (in mandagen)

5

3

7

6

2

8

2

4

5

2

1

Pagina 11 van 17


Project Planning Je zou nu al kunnen gaan plannen, hoewel nog niet alles duidelijk is. Als je alle deeltaken optelt zie je dat het totale project een omvang heeft van 45 mensdagen. Dat betekent dat één programmeur het project in 45 werkdagen zou kunnen afronden, als hij full-time beschikbaar is. Een andere mogelijkheid zou zijn om met 45 programmeurs het project in één dag te doen. Dat is in dit geval niet mogelijk, omdat we al gezien hebben dat elk van de deeltaken maar door één programmeur tegelijk kan worden uitgevoerd. Als we het project zo snel mogelijk willen afronden dan moeten we kijken naar de langste opdracht die voor komt. In ons geval is dat taak F, die 8 dagen duurt. Als je dus elf programmeurs ieder één van de deeltaken geeft, dan kan het project in 8 werkdagen klaar zijn:

Het kan zelfs nog met minder programmeurs, want: 45 mensdagen / 8 dagen = 5,625 mensen, dus je zou het project in principe met 6 programmeurs moeten kunnen doen. Dat kun je ook echt voor elkaar krijgen in dit geval, bijvoorbeeld op de volgende manier:

In de praktijk is een dergelijke planning vaak niet mogelijk, omdat er sprake is afhankelijkheden tussen de taken. Bepaalde taken kunnen pas worden uitgevoerd nadat andere zijn afgerond. Zo moet er bijvoorbeeld eerst een ontwerp worden gemaakt voordat er gecodeerd kan worden, een tweede fase van een project kan pas starten nadat de opdrachtgever de kans heeft gehad om een prototype te testen, er kan pas getest worden als de betreffende software geschreven is. In ons project gelden

Pagina 12 van 17


Project Planning ook afhankelijkheden, en wel de volgende: B kan pas na A worden uitgevoerd, C na B, E na A en D, F na D, G na B, E, en F, H na C en G, I na G, en J na H en I. Verder is K willekeurig.

Het is duidelijk dat de oplossing met 6 programmeurs van hierboven in dat geval niet werkt. Taak C zou dan bijvoorbeeld beginnen vóórdat B begint. Om de afhankelijkheden te visualiseren maken we het volgende plaatje:

Hierin geven de pijlen de afhankelijkheid aan. Bij het plannen moet met al deze afhankelijkheden rekening worden gehouden. Een dergelijke figuur heet een graaf (Engels: graph): een aantal punten, of knopen (taken) is met lijntjes verbonden. In ons geval is het zelf een gerichte graaf, omdat de knopen door middel van pijlen zijn verbonden, ze hebben een richting. Voor de taak K zijn geen afhankelijkheden gegeven, die kan willekeurig worden ingepland. Elk pad in de graaf dat je krijgt door ergens te beginnen en vervolgens met de pijltjes mee te lopen, bestaat uit taken die ook achter elkaar moeten worden uitgevoerd. Je kunt de “lengte” van zo een pad uitrekenen door de doorlooptijden van de taken op te tellen. Het langste pad dat je zo tegen kunt komen bepaalt dan de minimale lengte van het project (even afgezien van taak K die nog niet in dit verhaal voor komt). Het langste pad dat voor komt heet het kritieke pad. In ons voorbeeld is het kritieke pad D – F – G – I – J, met een totale lengte van 23 dagen. Dit pad heet kritiek, omdat het meteen de minimale duur van het project van het project bepaalt. Als één van de taken uit het kritieke pad uitloopt, loopt ook meteen het hele project uit. Het blijft nog wel de vraag of je de minimale tijd volgens het kritieke pad echt kunt realiseren, want het kan bijvoorbeeld zijn dat de taak K, die we nog niet hebben meegenomen, pas na afloop kan worden uitgevoerd, omdat er bijvoorbeeld eerder geen medewerkers beschikbaar zijn.

Pagina 13 van 17


Project Planning

Het project van 45 mensdagen zou in principe in 23 dagen door twee programmeurs kunnen worden uitgevoerd (2X23 > 45). In dit voorbeeld blijkt dit ook te kunnen:

11. Projectmanagement Bij het uitvoeren van projecten zal er door de betrokkenen worden getracht om de planning na te leven. De planning is gebruikt voor het maken van afspraken en daar zijn kosten en opbrengsten mee verbonden. Het beheersbaar maken van het verloop van een project heet projectmanagement, dat is niet het onderwerp van deze reader. Hierna volgen een paar onderwerpen die samenhangen met het gebruik van een planning die nuttig zijn om te kennen. • • •

80/20-regel Slip-chart Burndown chart

12. 80/20 regel Hoe ver ben je? Ik ben bijna klaar. Wat is dat “bijna”? Als je het in productgrootte zou uitdrukken, bijvoorbeeld in regels code dan zou je op een gegeven moment kunnen zeggen dat je 80% klaar hebt. Dat is in het plaatje hieronder, de bovenste balk.

Vaak wordt echter het deel van het werk dat het moeilijkst is of het complext of onverwacht meer moeite kost dan gedacht tot het laatst bewaard. In tijd uitgedrukt resteert nog 80% van het werk. Dat is in het plaatje de onderste balk.

Pagina 14 van 17


Project Planning

Er is geen wetenschappelijk onderbouwing voor de 80/20 verdeling , maar het is een populaire manier van zeggen dat er een verhouding is tussen twee delen; een groot en een klein deel. Als je projectbeheersing nastreeft is het niet voldoende om mensen op hun blauwe ogen te geloven. De moraal van dit verhaal is; “meten is weten”. Sommige projectleiders gebruiken het motto “vertrouwen is mooi, controle is beter.”

13. Slip-chart Deze methode heet “milestone trend analyse” (MTA), en is gebaseerd op voorspellingen van opleveringen van milestones. Hiervoor moeten zoals in het voorbeeld hiernaast wekelijks (maar kan ook met een ander interval) nieuwe schattingen worden gemaakt voor de verwachte einddatum per milestone. Bij die schattingen wordt inmiddels verkregen kennis, voortschrijdend inzicht, gebruikt. Op de verticale as (Y) staat de verwachte einddatum. Op de horizontale as (X) staat de week waarin de schatting werd gemaakt (vaak de week waarin we leven, de actuele week). Iedere keer dat er sprake is van het veschuiven van een milestone, is dat een “slip”. Vandaar de naam slip-chart. Het ideaal is zo min mogelijk slip te krijgen. Een projectleider die dit middel gebruikt is wel op de hoogte van de toestand van het project, maar is niet bezig met sturen. Hij loopt achter de feiten aan. Het is mooier om grip te hebben op het verloop van het project. Pagina 15 van 17


Project Planning

14. Burndown-chart

Een burndown- chart is een grafische weergave van het werk dat nog gedaan moet worden tegenover de resterende tijd. Het uitstaande werk (backlog) staat op de verticale as. Hiervoor is het niet van belang welke eenheden worden gebruikt, in het plaatje zijn het dagen. De tijd staat op de horizontale as, in dit geval ook dagen. De punten op de lijn representeren de hoeveelheid werk op een bepaalde dag. Dat is een gevolg van een schatting waarbij ook voortschrijdend inzicht wordt gebruikt. Het diagram is nuttig bij het voorspellen wanneer het werk klaar is. In het plaatje staat de ideale lijn, dat is de blauwe. Hierbij is er geleidelijke en gestage voortgang. De rode lijn representeert de werkelijke meting. Als de rode lijn boven de blauwe komt is er minder voortgang dan zou moeten zijn. Dat kan veroorzaakt worden doordat er niet hard genoeg gewerkt is, dat er tegenslagen waren of dat er werk bijgekomen is. Een burndown-chart lijkt op een omgekeerde slipchart, met dat verschil dat in een burdown-chart al het werk (inspanning) te zien is en geleidelijk afneemt; "taken branden op".

Pagina 16 van 17


Project Planning

Pagina 17 van 17

test  
Advertisement