Inleiding tot Projectmanagement

Inleiding tot Projectmanagement
Objectieven cursus
•
•
•
Kennis en inzicht:
– Verschillende fasen van een project kunnen situeren
– Deeldomeinen van project management kennen en kunnen situeren
– Belang van de onderdelen kennen
– Ermee kunnen werken
Vaardigheden:
– In staat zijn om aangepaste rapporten te genereren
– Het geleerde in praktijk brengen
Attitudes
– Vaardigheden van een projectleider verwerven
Inhoud volgens syllabus
•
•
•
Allereerst wordt de student vertrouwd gemaakt met basisbegrippen rond Projectmanagement :
wat is een project en projectmanagement, eigenschappen van projectmatig werken, verschillende
rollen in een project, communicatie, kritische succesfactoren.
Vervolgens worden de verschillende fasen van een project toegelicht : Pre-projectwerk (analyse,
haalbaarheid), definitie (opdracht- en resultaatbepaling), planning (WBS, faseren, beheersactiviteiten,
risicoanalyse, planningstechnieken - Gantt, PERT, …), Uitvoering- en voortgangsbewaking en
afronding (evaluatie, overdracht naar de operationele omgeving).
Ten slotte wordt er gekeken naar Program Management en de noodzaak hiervan.
Inhoudstafel cursus
•
•
•
Situering van PM
Projectfasen
– Vóór de project initiatie
– Project initiatie
– Project definitie
– Project planning
– Project uitvoering
– projectafronding
Program & Portfolio management
1
Situering van PM
Situering van PM - inhoud
•
•
•
•
•
•
Definitie project
Korte historiek
IT-projecten
Definitie project management
Voordelen project management
De rol van de Project manager
Opmerkingen
PM=Project Management
Pmer=Project Manager
Wat is een project ?
“Een project is de tijdelijke bundeling van activiteiten die worden uitgevoerd om een uniek product of
unieke dienst te creëren”
Een project heeft een 3-voudig objectief / beperking
Time
Cost
Triple
constraint
Quality
Dus
– Project is uniek en tijdelijk
– Maakt gebruik van menselijke middelen
– Wordt uitgevoerd binnen een organisatie
– Dient een (vooraf bepaalde) kwaliteit te behalen
Verschil met ‘operations’ / productie / exploitatie
– Is continu
– Repetitief
– Binnen een statische organisatie
Volgende kenmerken zijn meestal ook van toepassing op een project
– De aanduiding van een opdrachtgever (of projectsponsor) die zich engageert voor het eindresultaat
– Inzet van meerdere experten van verschillende disciplines wiens kennis wordt samengebracht
– Risico en onzekerheid over het projectresultaat
Voorbeelden van projecten
•
•
•
•
•
•
Openingsceremonie van de Olympische Spelen
Bouw van de Concorde
Bepaling en invoering van een nieuw vormings- en loopbaanconcept voor medewerkers
Efficiënter gebruik van het luchtruim
Verhuis naar een nieuwbouw
Reorganisatie van een afdeling
•
Opmerking; soms wordt een project te omvangrijk
– Opgevangen door programmawerking
2
–
Programma = verzameling van aantal projecten die gemeenschappelijk objectieven hebben en
afhankelijkheden vertonen
Voorbeelden van IT-projecten
•
•
•
•
•
•
•
Ontwikkeling van een website voor de werken van de Ring van Antwerpen
Implementatie van een IP Telephony systeem
Outsourcing van de mainframe-capaciteit
Ontwerp van een geautomatiseerd bevragings-systeem voor personeelsleden
Implementatie van een Content Management System
Invoering van MOM
Ontwerp en implementatie van een bedbezettingsprogramma
Projecten kunnen allerlei soorten objectieven hebben…
Kwantitatieve objectieven: bijv
• Reductie van de communicatiekost met 30%
• Verlengen van de levensduur van een vliegtuig met 2 jaar
Kwalitatieve doelen: bijv
• Verbeteren van de dienstverlening naar de burger
• Creëren van een commerciële houding bij technisch personeel
Projecten zijn niet nieuw…
1937: bouw van Golden Gate Bridge
“Strauss will never build his bridge, no one can bridge the Golden Gate because of insurmountable
difficulties which are apparent to all who give thought to the idea .”
•
gepland budget van 27 M$
•
uitgevoerd voor 25,7 M$
•
binnen de vooropgestelde termijn
The mythical man-month….
•
•
•
•
•
Klassieker voor software project management, geschreven door Fred Brooks
Gebaseerd op ervaringen tijdens project van eind jaren ’60
Ontwikkeling van OS/360 bij IBM
Project van 5000 manjaar
– Explosie van bijkomende mankracht om einddatum te halen
– Na 3 maanden; verbod om fouten te corrigeren
Brooks’ law: Adding manpower to a late software project makes it later."
The mythical man-month – verdere inzichten
•
•
•
Good cooking takes time. If you are made to wait, it is to serve you better, and to please you. Menu
of Restaurant Antoine, New Orleans
Second-system effect: second system an engineer designs is the most dangerous system he will ever
design, since it will be disastrously overdesigned.
Progress tracking:
– How does a large software project get to be one year late? One day at a time!
– Incremental slippages on many fronts eventually accumulate to produce a large overall delay
3
•
•
•
•
•
•
Conceptual integrity: In order to make a user-friendly system, the system must have conceptual
integrity, which can only be achieved by separating architecture from implementation. A single chief
architect (or a small number of architects), acting on the user's behalf, decides what goes in the
system and what stays out.
Pilot system: When designing a new kind of system, a team will design a throw-away system
(whether it likes it or not). This system acts as a pilot plant that will reveal techniques which will
subsequently cause a complete redesign of the system.
Formal documents: Every project manager must create a small core set of formal documents which
acts as the roadmap as to what the project objectives are, how are they to be achieved, who is going
to achieve them, when are they going to be achieved and how much are they going to cost.
Communication: In order to avoid disaster, all the teams working on a project should remain in
contact with each other in as many ways as possible
Code Freeze and System Versioning: At a certain date, no more changes would be allowed to the
system and the code would be frozen. All requests for changes, will be delayed until the next version
of the system.
Specialized Tools: Instead of every programmer having his own special set of tools, each team should
have a designated tool-maker that may create tools which are highly customized for the job that team
is doing
historiek
•
•
•
•
1944 : Institution of Civil Engineers van UK erkent de noodzaak tot een systematische aanpak voor
de planning van publieke werken
1969 : PMI (Project Management Institute, USA) opgericht
– Okt 2002 : 98 114 wereldwijde leden
– Chapters, SIG (Specific Interest Groups)
– PMBOK versies : 1984, rev 1987, 1996, 2000, 2003
Vroege jaren 80 : PRINCE (Projects IN Controlled Environments) CCTA, UK : management van
applicatie-ontwikkelings projecten
1989 : PRINCE2 : proces-gebaseerde aanpak die een project behandelt van initiatie tot afsluiting
Succes en mislukking bij IT-projecten
•
•
•
•
Chaos report Standish group (1994)
– Sample : 365 respondenten, 8380 applicaties, all industry segments
Project Success : 16 %
– completed on-time and on-budget with all features and functions as originally specified
Project Challenged : 53 %
– Completed and operational, but over budget, over the time estimate and offers fewer features
and functions than originally specified
Project Impaired : 31 %
– The project is canceled at some point during the development cycle
Waarom bepaalde projecten wel succesvol zijn
Project Success Factors
% of
Responses
1. User Involvement
15.9%
2. Executive Management Support
13.9%
3. Clear Statement of Requirements
13.0%
4. Proper Planning
9.6%
5. Realistic Expectations
8.2%
6. Smaller Project Milestones
7.7%
7. Competent Staff
7.2%
8. Ownership
5.3%
9. Clear Vision & Objectives
2.9%
10. Hard-Working, Focused Staff
2.4%
4
Redenen voor mislukking van een project
% of
Responses
Project Challenged Factors
1. Lack of User Input
12.8%
2. Incomplete Requirements & Specifications
12.3%
3. Changing Requirements & Specifications
11.8%
4. Lack of Executive Support
7.5%
5. Technology Incompetence
7.0%
6. Lack of Resources
6.4%
7. Unrealistic Expectations
5.9%
8. Unclear Objectives
5.3%
9. Unrealistic Time Frames
4.3%
10. New Technology
3.7%
Redenen waarom projecten worden stopgezet
% of
Responses
Project Impaired Factors
1. Incomplete Requirements
13.1%
2. Lack of User Involvement
12.4%
3. Lack of Resources
10.6%
4. Unrealistic Expectations
9.9%
5. Lack of Executive Support
9.3%
6. Changing Requirements & Specifications
8.7%
7. Lack of Planning
8.1%
8. Didn't Need It Any Longer
7.5%
9. Lack of IT Management
6.2%
10. Technology Illiteracy
4.3%
10 determinanten voor een succesvol project
User involvement
Executive support
Clear Business Objectives
Experienced Project Manager
Small Milestones
Firm Basic Requirements
Competent Staff
Proper Planning
Ownership
Other
•
•
•
20 Points
15 Points
15 Points
15 Points
10 Points
5 Points
5 Points
5 Points
5 Points
5 Points
Hebben voorspellende waarde
Geen enkel project heeft alle factoren nodig
Hoe meer factoren aanwezig zijn, hoe meer kans op succes
Projecten kunnen succesvol zijn indien…
•
•
•
Er een gestructureerde aanpak wordt gevolgd
Opzetten van randvoorwaarden binnen de organisatie
– Commitment van de directie
– Impliceert cultuurverandering
– Is ontwikkeling van een professionele vaardigheid
Ook noodzaak tot:
– Standaarden en Hulpmiddelen algemeen
– Standaarden hulpmiddelen die specifiek zijn voor de organisatie
5
–
–
Kennis van PM-technieken
‘softe’ vaardigheden van de projectmedewerkers
Wat is Projectmanagement?
•
•
•
•
•
“Projectmanagement is de organisatie, planning, leiding en beheersing van de bedrijfsmiddelen, die
voor een beperkte tijd ingezet worden om specifieke resultaten te verwezenlijken.”
“Project management is the application of knowledge, skills, tools and techniques to project activities
in order to meet (or exceed) stakeholder needs and expectations from a project” (PMBOK Guide)
“Projectmanagement is het bedrijfsproces van schatten, toekennen en beheersen van werkkapitaal
om een aanvaardbare ‘return on investment’ (ROI) te bekomen.”
Projectmanagement behelst meestal:
– Concurrerende vereisten; omvang, tijd, kost, risico, kwaliteit
– Betrokkenen / Belanghebbenden (stakeholders) met verschillende noden en verwachtingen
– Vastgelegde vereisten / behoeften; kunnen evolueren
– Onbepaalde vereisten (verwachtingen)
Projecten worden gefinancierd van het werkkapitaal, niet van het exploitatiebudget.
Waarom doet men projectmanagement
•
•
Verandering staat centraal in onze maatschappij:
– Continue verandering is de enige constante
– Snelle uitvoering vereist
Projectmanagement biedt een raamwerk aan, waarbinnen veranderingen op een gestructureerde en
efficiënte manier kunnen worden uitgevoerd
Basisprincipes van projectmanagement
•
•
•
•
Eerst denken, dan uitvoeren en vervolgens afbouwen
Ontbinding van grote gehelen in kleinere, beheersbare delen
“plannen” is:
– Creëren van voorspelbaarheid
– Opzetten van een projectstructuur
– Beheren en opvolgen van inhoudelijke activiteiten
– Risico’s bepalen en vermijden dat ze voorkomen
Als dusdanig is een plan
– Leidraad voor uitvoering
– Maatstaf om afwijkingen van het voorspelde pad te identificeren
– Raamwerk dat toelaat om snel correctieve acties te bepalen en uit te voeren
Betrokken partijen bij een project
•
•
Direct betrokkenen;
– Opdrachtgever
– Projectteam
– Projectmanager
– Projectsponsor
– gebruikers
– Leveranciers
– …
Indirect betrokkenen
– Lijnmanagement
6
•
– Vertegenwoordigers van vakbonden
– Radio couloir
Bepaling van en communicatie naar indirect betrokkenen is even cruciaal als de directe; “Don’t miss a
stakeholder”
Projectrollen
•
•
•
•
•
•
•
•
•
•
•
•
Klant; diegenen die directe baat hebben bij het project
Klant PMer: primair contactpunt bij de klant
Lijnmanager; naar wie men rapporteert in de ‘normale’ organisatie
Projectdirecteur: senior manager die belangrijke invloed en beslissingsbevoegdheid heeft
(escalatiepunt)
PMer: diegene die de autoriteit heeft gekregen om het project te beheren
Projectteam: alle full- en part-time mensen die een taak uitvoeren in het project
Executive Sponsor : diegene met de finale autoriteit over het project, die het project betaalt.
Project sponsor: operationele delegatie van de executive sponsor
Stakeholder: diegenen die, op één of andere wijze, belang hebben bij het projectresultaat (zowel +
als -)
Stuurgroep: een groep van (+) stakeholders met hoge autoriteit die advies kunnen geven over de te
volgen richtingen
Leveranciers: externe partijen die producten of mensen leveren aan het project
Gebruikers: diegenen die de resultaten van het project zullen gebruiken
Rol van de projectmanager
•
•
Verantwoordelijke voor een project
Taken
– Opdracht- en resultaatsbeschrijving opmaken en vastleggen
– Plan van Aanpak opstellen dat een opsomming is van
• Inhoudelijke activiteiten (faseren en beslissen) WAT DIENT ER TE GEBEUREN en IN
WELKE VOLGORDE?
• Continue beheersactiviteiten; voor planmatig verloop van de inhoudelijke activiteiten HOE
GAAN WE DIT OPVOLGEN EN BIJSTUREN?
PVA: Inhoudelijke activiteiten
•
Faseren en beslissen
Projectresultaat
Fase n
…
Fase 2
Fase 1
Startsituatie
Beslissingsmomenten / Mijlpalen
7
PVA: beheersactiviteiten
•
•
Beheersactiviteiten betreffen volgende domeinen;
– Mbt het projectresultaat:
• Kapitaalbeheersing
• Tijdsbeheersing / planning
• Kwaliteitsbeheersing
– Mbt het proces
• Teambeheersing
• Informatie- en communicatiebeheersing
Deze activiteiten hangen nauw met elkaar samen
– Competenties team hebben invloed op kwaliteit
– Efficiënte organisatie en planning leiden tot besparingen
Verschillende fasen van PM
•
Project
initiatie
Project
planning
Beheers
processen
•
Uitvoerende
processen
•
•
Project
afsluiting
•
Projectinitiatie; vastleggen van wat er
dient te gebeuren en verzamelen alle
projectparameters
Projectplanning; faseren van de
activiteiten en deze in een logische
volgorde zetten. Beslissen hoe de
beheersing voor dit project zal
gebeuren
Projectuitvoering; uitvoering van de
inhoudelijke activiteiten volgens
planning
Projectbeheersing; uitvoering van de
beheersactiviteiten en bijsturen van de
projectuitvoering (of planning)
Project afsluiting; ontbinden van de
projectorganisatie
Verschillende projectcycli kunnen overlappen
Bijv: “Ontwikkeling van een website”
klant
projectaanvraag
prospectie
GO-beslissing
Idee
Keuze uitvoerder
lastenboek
qualificatie
Project
initiatie
offerte
implementatie
Ontwerp
uitvoering
oplevering
Close-down
Project
planning
Beheers
processen
Uitvoerende
processen
leverancier
Project
afsluiting
8
Vaardigheden van de PMer
•
•
De rol van PMer is een ambacht en een ‘sluitstukfunctie’
Vereist zowel:
– Technische kennis
• PM en planning-methodes
• Financiële analyse
• …
– ‘Zachte’ vaardigheden
• Communicatie
• Onderhandelen
• Leiding geven
• Management
• Commerciële instelling
• …
• Wat headhunters ervaren als essentieel….from Internet \S_i_ Systems Ltd_ - Hiring Tips
and Techniques.htm
Belang van de contractformule
•
•
Er bestaan 2 basisformules bij de bepaling van contracten:
– “Time & Material” (middelenverbintenis, ‘in regie’)
• De leverancier levert capaciteit of kennis aan
• Wordt vergoed per prestatie
– “Fixed price” (resultaatsverbintenis)
• Leverancier verbindt zich tot het behalen van een resultaat
• Tegen vooraf overeengekomen prijs
– Risico-dekking is de differentiator
Contractformule kan bepalend zijn voor gedrag en houding van het projectteam
Contractformule - resultaatsverbintenis
•
•
•
•
•
•
Succes en betaling wordt volledig bepaald door het al dan niet halen van de vooropgestelde
objectieven
Objectieven worden gemeten volgens overeengekomen maatstaven
Vereist veel nauwkeurigheid en volledigheid bij de opstelling van de objectieven (=
verantwoordelijkheid klant)
Eens de prijs bepaald is, ligt al het risico bij de uitvoerende partij
Is aantrekkelijk, want lijkt meer mogelijkheid te creëren tot vergelijking tussen concurrenten
Moeilijk om wijzigingen door te voeren na het ondertekenen van het contract
Contractformules - middelenverbintenis
•
•
•
•
•
•
•
•
Inkopen (insourcen) van expertise of diensten
Verrekening per effectief verbruik, van zowel mensen als middelen
Op voorhand worden de tarieven onderhandeld
Vereist minder nauwkeurige beschrijving van de objectieven
Risico voor de opdrachtgever qua;
– Kwaliteit van de expertise die hij inhuurt
– Noodzakelijk budget voor een project
Tijdens de uitvoering van een contract kunnen er gemakkelijk wijzigingen worden aangebracht
Controle van de activiteiten (qua inhoud en resultaat) is essentieel
Mogelijke mengvorm: time-boxing.
9
Overheidsterminologie
•
•
•
•
•
Lastenboek
Offerte
Belangrijk verschil tussen:
– Aanbesteding
– Offerte-aanvraag
– Met of zonder onderhandelingsprocedure
Gebruik en Belang van proces-verbalen: voorbeelden\PV LuM.TIF
‘dirty tricks of war’:
– Maatregelen van ambtswege
– Ingebrekestelling
– Vormfactoren (facturen, meetstaat…)
– De ‘geest’ versus de ‘letter’ van de wet
Oorsprong van projecten
Waar komen projecten vandaan?
Wat gebeurt er vóór een project wordt gestart?
Bedrijfsmatige oorsprong van projecten
Pre-project analyse – minder formalisme
•
•
•
•
•
Binnen organisaties begint, ‘plotsklaps’, een IDEE te leven of een gezamenlijke BEHOEFTE te
ontstaan
Typisch hierbij is het stellen van vragen als
– Wat moeten we doen om….? (winst te verhogen, hogere klantentevredenheid…)
– Hoe gaan we dat aanpakken / ons doel bereiken?
– Welk doel willen we bereiken?
– Wie zal dat doen?
– Hoe snel kunnen we dit realiseren?
Leidt meestal tot een “explicitering van de behoefte”
Vormen van explicitering:
– Invullen van projectaanvraag
– Gaan spreken met het management
– …
Informatie wordt verzameld;
– Duidelijke omschrijving van de objectieven en de op te leveren resultaten
10
•
– Mogelijke opties
– Te verwachten kost (mensen en middelen) en tijd
– Te verwachten meerwaarde
– voorbeelden\vod.doc
Leidt tot GO / NO GO beslissing
– Kan heel formeel gebeuren via vooraf bepaald proces en criteria (ook hier is beleidsvoorbereiding
belangrijk) voorbeelden\projectinitialisatie.vsd voorbeelden\beslissingsmotor.xls
– Of minder formeel
• The louder the shouting, the bigger the projects
• Gebruik van sociaal netwerk binnen bedrijf
Projectinitiatie
Project
initiatie
Project
planning
Inleiding
•
•
•
•
Beheers
Projectinitiatie is sterk gekoppeld aan de ‘scope’ van een project
processen
Project scope management omvat alle processen die noodzakelijk
zijn om de garantie te bieden dat het project alle noodzakelijke, en
enkel de noodzakelijke taken zal uitvoeren om het project succesvol
Project
afsluiting
te kunnen afsluiten
De uitdaging van deze fase is om te definiëren en vast te houden aan
wat deel uitmaakt van het project, en wat niet.
Vasthouden aan de scope is een gevecht dat de ganse looptijd van een project in beslag neemt.
Uitvoerende
processen
In de praktijk is projectinitiatie…
1.
2.
3.
4.
5.
6.
Identificatie en bevestiging van de scope of Work
Validatie van de contract-, SOW- of offerte-assumpties
Ontwikkelen van de lijst van werkproducten en -vereisten
Verificatie van de technische aanpak en opleverdata met de klant
Bepalen van beperkingen
Afsluiting van deze fase (overgang naar de volgende fase)
1. Identificatie en bevestiging van de scope
•
•
•
•
Opeenvolging van “begrijp”-fase en een “bevestig” fase.
BEGRIJP:
– kennismaking van de PMer met zijn project
– Eerste validatie (of teken aan de wand)
– Lees de waarschuwingssignalen
BEVESTIG
– Bewijs dat PMer het goed begrepen heeft
– Typisch een eerste probleemgolf
Scope is dé basis van alles
Scope - BEGRIJPEN
•
•
Een PM moet de omvang van de taken, de voorgestelde aanpak begrijpen
Nalezen van projectaanvraag, SOW, bestelbon…
– Hangt af van de beschikbaarheid van de doc
– Verzamel alle gegevens. Indien er al een planning werd voorzien, kan dit als uitgangspunt dienen
– Verzeker jezelf ervan dat JIJ het begrijpt en dat het consistent is met de scope
– Praat met opstellers/management over alle mogelijke beperkingen die gelden op de offerte, het
contract of de bestaande plannen
– Vraag / eis verduidelijking indien nodig
11
–
•
Analyseer alle documenten grondig
• Belangrijke informatie kan verscholen zitten in de kleinste hoekjes, de kleinste documenten
of de ‘stomste’ mailtjes
• Meestal is informatie verspreid aanwezig
Opmerkingen:
– Opgepast met projecten die beginnen met een telefoon of mail
– Opgepast met ‘technologische verdrinking’
– Lees de signalen!!
Scope - BEVESTIGEN
•
•
•
•
Breng alle informatie samen in één coherent geheel en bevestig de SOW met
– Management
– Klant
Vraag expliciete goedkeuring hierover en documenteer deze
Consulteer ook, indien mogelijk, mensen of experten die al op dit project gewerkt hebben
Indien de scope gewijzigd is sinds de beslissing:
– Identificeer en documenteer de wijzigingen
– Bespreek deze met klant / management
– Documenteer de beslissing (= nieuwe baseline)
2. Validatie van de assumpties
•
•
•
•
Belang Statement of Work (SOW)
– SOW = contractgedeelte dat expliciet aangeeft wat de uitvoerende partij zal uitvoeren en
afleveren aan de klant
– Moet specifieke, meetbare en realiseerbare doelen beschrijven
– Is meestal opsomming van elke uit te voeren activiteit en elk te behalen resultaat
– SOW bevat ook expliciete acceptatiecriteria en test-specificaties
– Als er geen SOW bestaat => creëer er één!!
Assumpties:
– ASS U ME
– Assumpties zijn uitspraken die voor waar worden aangenomen wegens;
• Te weinig informatie
• Om beslissingen te kunnen nemen rond het project
– Is populair, maar zeer gevaarlijk mechanisme
– Voorbeelden van assumpties: voorbeelden\Assumpties 20030402_V41.xls
Cruciaal dat assumpties gevalideerd worden voorbeelden\Consolidatiedocument vragen en
antwoorden v3.doc
Bij afwijzing;
– Duidelijk identificeren wat er fout is aan de assumptie
– Nagaan gevolgen hiervan
– Documenteren
– nvSH: een assumptie staat er nooit toevallig!
3. Bepalen van de werkproducten en -vereisten
•
•
•
•
Kijk contract én SOW na
Verzamel informatie rond de werkproducten / vereisten
– kijk zowel naar de inhoud als de vorm
– Soms kunnen eisen heel diep verscholen zitten; (bijv. AAV bij overheidsopdrachten of technische
normen en geprefereerde hobby van bepaalde ambtenaren)
– Beeldvorming gebeurt typisch door gesprekken met experten
Inventariseer alle vereisten
– Zorg voor een complete lijst; hard- en software, CI’s, wisselstukken, hulpmiddelen, test-systemen,
documenten
Organiseer resultaatgerichte workshops met beperkte groepen van gemachtigde experten
– Identificeer en bevestig delivery requirements
– Zo specifiek mogelijk zijn: Moet voldoen aan de SMART-criteria:
12
•
Specific, Measurable, Achievable, Realistic & Time framed
Maak finale inventaris van de werkproducten – en vereisten en laat hem valideren door
– Klantzijde
– Management uitvoerende organisatie
4. Verificatie van de technische aanpak en opleverdata met de klant
•
•
Verificatie van de technische aanpak
– Technische aanpak kan een uitdaging zijn voor het projectteam
• Gekende bron van risico’s en problemen
• Noodzakelijk om deze grondig te onderzoeken door
– Benchmarking
– Lessons learned van andere projecten
– Handige vragen hierbij zijn
» Waar komt de aanpak vandaan?
» Hoe vaak werd die aanpak al toegepast?
» Wie heeft die voorgesteld? Is die opgelegd door de klant?
» Welke gevolgen heeft die aanpak?
Cruciaal dat de PMer overtuigd is / wordt van en gelooft in de aanpak!!
5. Bepalen van de beperkingen
•
•
•
Bij de minste contradicties, misverstanden, uitzonderingen of afwijkingen van de voorgestelde aanpak
of de eindproducten
– Leg ze op tafel bij management en klant
– Zo snel als mogelijk!
– Los ze op
Een PMer moet de verplichtingen en beperkingen ‘herkennen’ die de bewegingsvrijheid beperken
– Verplichtingen zijn typisch contractuele bepalingen zoals data en omvang van het budget
– Indien er onredelijke of onrealistische zijn; leg ze op tafel &…
Voorbeelden van beperkingen
– Beperkte beschikbaarheid van personeel
– Beperkte middelen qua behuizing, ondersteuning
– Gebrek aan toegang tot personeel van de klant
– Standaarden die gevolgd dienen te worden (bijv. inpassing in de projectaanpak van de klant)
– Verplicht te halen kwaliteitsnormen
– …
6. Afsluiten van de project-initiatie
•
•
Het projectmanagement plan zal alle noodzakelijke acties, sjablonen, eindproducten… bevatten
– Begrip en bevestiging van de scope of work
– Gevalideerde assumpties
– Werkproducten en –vereisten
– Door de klant gevalideerde technische aanpak en opleveringsdata
– De beperkingen die van toepassing zijn
Nu is het project klaar om over te gaan naar de volgende stap
Projectplanning
Project
initiatie
Project
planning
Inleiding
•
•
Deze fase is bijzonder complex
Is iteratief;
– de voorgestelde aanpak levert enkel een aangepast projectplan op,
indien er verschillende keren interactie geweest is tussen
verschillende domeinen
– Top-Down / Bottom-up aanpak
Beheers
processen
Uitvoerende
processen
Project
afsluiting
13
•
•
Ervaringsgegevens zijn eveneens heel belangrijk
Zware invloed van kost- en tijdsparameters tijdens deze fase
Rol van de PMer tijdens deze fase
•
•
PMer is integraal verantwoordelijk voor
– De ontwikkeling van een roadmap naar een succesvolle oplevering
– Een concreet plan om het werk uit te voeren
• Begrijpbaar en geïntegreerd
• Voldoende overtuigend om buy-in van de klant en de uitvoerders te verkrijgen
Het plan verschaft duidelijkheid over
– Uit te voeren werk, hoe dit zal uitgevoerd worden, in welke volgorde dit zal gebeuren, hoeveel
mensen nodig zullen zijn en hoeveel geld op welk ogenblik zal vereist zijn.
– Een meetbare en controleerbare vooruitgang van het project, ongeacht omvang en duur
Uitdagingen van de PMer tijdens deze fase
•
•
•
•
•
•
•
•
Veranderingen in de scope
Verduidelijking van de specificaties
Gebruik van part-time medewerkers
Beschikbaarheid van medewerkers
Nauwkeurige meetsystemen;”Meten is weten”
Bekomen van relevante en tijdige administratieve informatie (boekhouding & facturatie)
Kennis en expertise van de mensen
Begrijpen en aanvoelen van het onderwerp van het project
Processen tijdens deze fase
Project TIME management
Processen die noodzakelijk zijn om de
vooropgestelde termijnen te halen
–
bepalen van de activiteiten
–
opeenvolging activiteiten
–
schatten van de duurtijd per taak
–
consolidatie in planning
–
bewaken van de planning
Project COST management
Processen die noodzakelijk zijn om binnen het
vooropgestelde budget te blijven
–
resource planning
–
schatten van de kost
–
toewijzen van kosten aan taken
–
kostbeheersing
Opmerking; bij kleinere activiteiten kunnen de
eerste 4 stappen intuïtief in één keer gebeuren
Belangrijkste onderwerpen van Time & Cost management
•
•
•
•
•
Bepalen van de activiteiten en opstelling van de planning
Kost inschatten en budgetteren
‘Base lining” van het project
Tijds- en kostopvolging is geïntegreerd
Een methode om dit alles te bekomen is de “Top down / bottom-up” aanpak
14
Schematisch overzicht van TD / BU
Activity definition
and sequencing
Het Top down planning proces - inleiding
•
•
•
•
•
TD
Activity duration
estimating
Bevat 6 fasen
Na de uitvoering van de 2 BU fasen, bekomt
men een:
Schedule
development
– Project management plan (PMP)
– (optionele) ondersteunende management
plannen (SMP)
Planning
Worden in volgorde doorlopen waarbij er veel
resources
iteratie is met de vorige fasen
– Hierdoor wordt de informatie ‘rijper’
Cost estimation
– Opbouw en update van PMP en SMP’s
& budgeting
TD planning gaat maar tot op een bepaald
detailniveau, het Management Control Point
Review process
– Bevestiging van de scope of work
– Bepaalt zowel de technische als de
beheersaspecten
BU or
– Bepaalt een basis voor latere metingen en
Detailed planning
rapportering
– Voorziet in een baseline qua tijd en kost die
reconciliation
zal toelaten om de impact van wijzigingen
process
te bepalen
Deze aanpak dient tijdens iedere fase rekening
te houden met ondersteunende risico- en kwaliteitsplannen, die geleidelijk worden verfijnd
BU
TD fase 1.1: activity definition - algemeen
Behelst
• Bepalen en registreren van de specifieke activiteiten die resulteren in de verwachte eindproducten,
zoals vastgelegd in de WBS
• Iedere activiteit dient de projectresultaten te dienen
• Gebruikt input van de initiatiefase:
– SOW
– contract
TD fase 1.1: activity definition - inputs
•
•
•
•
•
•
•
Work breakdown structure
Scope statement; vooral voor de objectieven
Historische informatie:
– Welke activiteiten waren noodzakelijk bij eerdere, analoge projecten?
– Welke valkuilen dient men te vermijden?
– Is ervaringscomponent
Beperkingen; maken het leven van de PMer en het projectteam … spannend
Assumpties:
– dit zijn factoren die, tijdens de planning, als waar/bestaand of onzeker moeten worden
beschouwd.
– Gaat meestal over een waarschijnlijkheid -> risico bepaling
Initieel bepaalde risico’s
Initieel PMP
15
TD fase 1.1: activity definition – tools & techniques
•
•
Ontbinding
– “Hoe eet je een walvis op?”
– Onderverdelen van de project-elementen in kleinere, beheersbare componenten
– Outputs van die componenten zijn activiteiten (noodzakelijke acties), en niet langer
werkproducten
Gebruik van templates
– Vaak hergebruik van een ander project (of van een concurrent…) als startpunt: handle with care
– Andere methode; na een eerste bepaling kan informatie van een ander project dienen als
‘klankbord’
TD fase 1.1: activity definition - outputs
•
•
•
Activiteitenlijst
– Bevat alle activiteiten die op het project zullen worden uitgevoerd
– Moet aansluiten op de WBS (garantie voor volledigheid)
– Bevat ook beschrijvingen van de activiteit, zodat deze ondubbelzinnig bepaald en begrepen wordt
Detail-informatie
– Moet op een doordachte manier worden verzameld en opgeslagen, voor later gebruik
– Altijd documentatie van alle bepaalde assumpties en beperkingen
Verfijning en update van de WBS
– Door gebruik te maken van de WBS als vertrekpunt, kunnen er gaten en/of vergissingen bepaald
worden
– Moet terug gevoed worden in de WBS
Randproces rond TD1 - Risicobeheer
•
•
•
•
•
•
•
Risico = er is kans dat een bepaalde gebeurtenis zich voordoet, maar er kan niet met zekerheid
gezegd worden ‘of’ en ‘wanneer’ dit zal gebeuren
Maar… mogelijke gevolgen zijn wel in te schatten!
Risico-analyse & beheer
– Gestructureerde aanpak om risico’s te identificeren
– Vooraf bedenken en voorzien van ‘mitigerende’ maatregelen
Risicobeheer is een continue activiteit!!
Van alle projectteamleden
Principes van risicobeheer
– Identificatie
• oorzaak; wat kan er allemaal mislopen?
• Gevolgen; welke zijn dan de gevolgen?
– Probabiliteit; hoe groot is de kans dat dit risico zich voordoet?
– Mitigatie: hoe voorkom ik dat het ooit gebeurt?
– Remediëring: wat is mijn noodplan indien het wel gebeurt?
Er zijn 2 scholen qua berekening en behandeling van risico’s:
– Kwantitatieve methode:
• GROOTTE RISICO = PROBABILITEIT * GEVOLG
• PROJECTRISICO = ∑ RISICO’S
• voorbeeld: voorbeelden\risks analysis Consortium 220402 V2.xls
16
Risicobeheer - Kwalitatieve benadering – situering van risico’s
Risicobeheer – kwalitatieve methode (voorbeeld)
Voorbeeld van classificatie van risico’s
voorbeelden\risico kwalitatief.xls
17
Risico-rapportering en opvolging
TD fase 1.2: activity sequencing - algemeen
•
•
•
Opsporen en documenteren van de afhankelijkheden tussen de activiteiten
Activiteiten moeten een volgorde krijgen:
– Voldoende precies
– Als ondersteuning voor de ontwikkeling van een realistische en uitvoerbare planning
Maakt bij voorkeur gebruik van geautomatiseerde hulpmiddelen
– Ontslaat de PMer en het projectteam niet van weten waar ze mee bezig zijn.
TD fase 1.2: activity sequencing - inputs
•
•
•
•
Activiteitenlijst
productbeschrijving: karakteristieken van het op te leveren product bepaalt vaak de volgorde.
Beperkingen en assumpties
Afhankelijkheden
– Verplichte afhankelijkheden
• HARDE LOGICA
• Hangen samen met het soort werk dat dient uitgevoerd te worden.
• Hangen vaak samen met fysische beperkingen (eerst beton gieten en daarna pas metselen;
eerst een prototype bouwen en dan pas testen)
• Houden vaak ook een verplichte wachttijd in
– Bijkomende afhankelijkheden
• ZACHTE LOGICA (geprefereerde logica)
• Zijn een keuze van het projectteam
• Moeten met de nodige omzichtigheid worden gebruikt en goed worden gedocumenteerd;
kunnen (zware) beperkende invloed uitoefenen op de planning
• Worden meestal bepaald door
– “Best practices” vanuit een bepaald domein
– Één specifiek aspect van een project waardoor een bepaalde volgorde wordt opgelegd
– Externe afhankelijkheden
• Hebben betrekking op de invloed van niet-project activiteiten op project activiteiten
• Bijv. testen hangt af van de beschikbaarheid van de testomgeving
18
TD fase 1.2: activity sequencing – tools & techniques
•
•
Wordt later in meer detail besproken
Zijn deel van planningstechnieken zoals
– Precedence Diagramming Method
– Arrow Diagramming Method
– GANTT charts
– Mijlpaalplannen
TD fase 1.2: activity sequencing - outputs
•
•
Project network diagram
– Schematisch weergave van de projectactiviteiten en de logische afhankelijkheden ertussen
– Dient altijd aangevuld te worden met een korte beschrijvende tekst
• Die aangeeft hoe de volgorde tot stand kwam
• Alle ongewone opvolgingen dienen volledig gedocumenteerd te worden
Update van de activiteitenlijst
– Op basis van de volgorde kunnen vergeten activiteiten aan de oppervlakte komen
– Ook andere opsplitsing van activiteiten is mogelijk
TD fase 1.2: Best Practices in Sequencing
•
•
•
•
Doorheen de jaren zijn er heel wat discussies en methodes geweest die een leidraad zijn voor het
bepalen van de volgorde van activiteiten
Project Life Cycle
Gekende modellen;
– Waterval model
– System Engineering of ‘V’-model
– Prototyping / spiraalmodel
– Rapid prototyping
Perfecte en universele levenscyclus bestaat niet….
Best practices in sequencing - watervalmodel
Watervalmodel – voor- en nadelen:
•
•
•
een validatie van de gebruikers komt
Besluit: OK voor kleinere projecten
Voordelen
– Gekend in vele domeinen
– Eenvoudig en makkelijk te begrijpen
– Erkent de noodzaak om één stap per
keer te zetten en goed de resultaten
van de vorige stap te valideren
Nadelen
– Heel moeilijk te beheren in complexe
omgevingen
– Integratie en testen komt laat in de
cyclus; nu nog een aanpassing
doorvoeren is een enorme kost
– Is een lange cyclus, waar er pas laat
19
Best practices in sequencing –System Engineering
System Engineering – voor- en nadelen
•
•
•
Voordelen
– Gebruikt voor complexe systemen: goed bekend in ingenieursomgevingen
– Geschikt voor omgevingen waar de behoeften met grote zekerheid kunnen beschreven worden
– Autoriteiten hebben een goed gedocumenteerd en diepgaand inzicht in de vorderingen =>
populair bij overheid
Nadelen
– Zwaar documentatieproces
– Steunt op veronderstelling dat alles terug te vinden is in een bijna-perfecte documentatie
– De requirements moeten op een gegeven ogenblik bevroren worden
Besluit; soms gebruikt, maar zeker niet altijd geschikt in IT-omgevingen
Best practices in sequencing - Spiraalmodel
20
Spiraalmodel - principe
•
•
•
Combineert waterval en risico-analyse
Uitermate geschikt voor grote ontwikkelingstrajecten
Bevat 4 grote blokken:
– Planning: bepaling objectieven, alternatieven en beperkingen
– Risico-analyse; bepaling en analyse van de risico’s (ook op de requirements) en studie
alternatieven
– Engineering; “doe-fase” + klant die weergeeft indien een volgende fase al dan niet wordt
aangevat
– Klanten-evaluatie: klant evalueert resultaten va engineering en bepaalt de wijzigingen
Spiraalmodel – voor- en nadelen
•
•
Voordelen
– Goed voor complexe en grote projecten
– Per cyclus is er een evaluatie door de klant; goed voor ‘voeling’ en voor inbrengen van nieuwe
technologieën
– Klant en ontwikkelaars bepalen en reageren op risico’s in iedere cyclus
– Risico’s worden onmiddellijk meegenomen en kan zodoende problemen vermijden
– Grote betrokkenheid klant
Nadelen
– Soms moeilijk om de klant te overtuigen van beheersaspecten
– Vraagt discipline van de gebruikers
– Beperking op aantal cycli is cruciaal!
– Risicobeheer moet bij iedereen in de genen zitten
– Moeilijk toe te passen bij resultaatsverbintenissen
– Niet ontdekken van een risico = problemen!
Rapid prototyping - principe
•
•
Wordt ook ‘Joint Application development’ genoemd
Vergeet alle up-front documentatie en ga, door contact met de gebruikers, onmiddellijk over tot
ontwikkeling
– Spreek met de klant
– Bouw een prototype
– Toon het aan de klant en verkrijg feedback
– Pas aan volgens feedback
– Herhaal stappen van hierboven en
• Voeg functionaliteiten toe
• Verbeter fouten
Rapid prototyping – voor- en nadelen
•
•
Voordelen
– Alle tijd wordt al ontwikkelend gespendeerd; geen kost om ‘papier’ te genereren
– Gebruikers kunnen meteen feedback geven, zonder zich te moeten ingraven in ontwerpen en
modellen
– Software engineers zijn onmiddellijk aan het ontwikkelen (en gelukkig)
– Assumpties zijn niet meer nodig
– Hoge gebruikers buy-in
– Behoeften kunnen gradueel verfijnd en afgestemd worden
Nadelen
– Aantal build-and-display cycli zijn onmogelijk te bepalen
– Moeilijk te plannen en op te volgen qua tijd en kost
– Niet toepasbaar voor complexe en grote projecten
– Niet toepasbaar bij vele verschillende stakeholders
– Moeilijk om een project af te sluiten
21
TD fase 2: activity duration estimating - algemeen
•
•
•
•
betreft bepaling van het aantal werkeenheden dat nodig is om iedere project-activiteit uit te voeren
De persoon of personen die het meest kennis hebben van de activiteit, zijn verantwoordelijk voor het
inschatten ervan
– Moet minstens door hen gevalideerd worden
– Verschillende experten MOETEN tot één besluit komen
Ook rekening houden met de looptijd
– Verschil werkdagen / kalenderdagen
Het inschatten zelf kan hier gebeuren; beter bij opstellen van de planning
TD fase 2: activity duration estimating - Belang
•
•
•
•
Waarom schat men?
– Realistische inschattingen zijn een betere vertaling van de behoeften van de klant naar taken,
kost en verwachte duurtijd
– Cruciaal bij projectbudgettering en afsluiten van fixed price contracten
– Enige methode om zicht te krijgen op de vereiste resources
– Belangrijke input voor opvolging en beheer van omzet en winstgevendheid
MAAR…. Schatten is mensenwerk
Redenen voor onderschatting
– Druk om te winnen of een contract te verliezen
– Wens of behoefte om te behagen
– Ongebreideld optimisme
– Gebrek aan ervaring
– Vergeten van de tools
– Documentatie wordt niet voorzien
– Onvoldoende test-tijd ingeschat
– Onderschatting van de benodigde trainingstijd (zowel gebruikers en projectleden)
– Niet gebruiken van best practices
Kan gedeeltelijk opgevangen worden door een goed proces en de juiste tools te gebruiken
TD fase 2: activity duration estimating - terminologie
•
•
•
•
•
•
Doorlooptijd (elapsed time)
Aantal kalenderdagen die de uitvoering van de taak in beslag zal nemen, incluis weekend –
vakantiedagen…
Werklast
Aantal mandagen die nodig zijn om de taak uit te voeren ( 1 dag is meestal 8 uur)
Duurtijd
Aantal werkdagen die de uitvoering van de taak in beslag zal nemen
Beschikbaarheid
Aantal dagen dat een persoon beschikbaar is om taken uit te voeren, inclusief ‘idle time’
Productiviteit
Aantal dagen waarbij een persoon zijn job effectief uitvoert (aantal dagen waar hij omzet genereert;
“billable” dagen)
Deze termen kennen en beheersen is cruciaal voor planning (en kostbepaling)
TD fase 2: activity duration estimating - inputs
•
•
•
Activiteitenlijst
Beperkingen en veronderstellingen
Bemanningsvereisten
22
•
•
•
– Duur van een activiteit wordt zwaar beïnvloed door het aantal mensen dat erop werkt
– Pas op met lineaire berekeningen
– Cfr “The mythical man month”
Competentie van de uitvoerders
– Eveneens zware invloed
– Maar… experten worden meer gestoord dan mindere goden
Historische informatie
Wordt meestal aangereikt door één van de volgende bronnen
– Lessons learned databases
– Projectfiles
– Commercieel beschikbare inschattings databases
– Kennis van het projectteam
TD fase 2: activity duration estimating – tools & techniques
•
•
•
•
•
Engineering of ‘expert judgement’
– Veel factoren kunnen de duur beïnvloeden die voor een niet-expert niet zichtbaar zijn
– Heel sterk middel in combinatie met historische informatie
Analoge schatting
– Speciale vorm van engineering; schat een activiteit in op basis van een eerdere instantie van
dezelfde activiteit
– Meest betrouwbaar bij
• Dezelfde activiteiten, ook in de feiten
• Ervaren schatters
Simulatie
– Brute berekening van de verschillende werklast die ontstaat bij verschillende assumpties
– Statistische behandeling van de berekende resultaten
– Geeft distributie van mogelijke resultaten
Parametrische modellering
– Voor ‘universele’ standaard-taken
– Parameters opgenomen in normen
Bottom-up schatting
– De uitvoerder schat de duur
– Zou meest betrouwbaar zijn
TD fase 2: activity duration estimating – outputs
•
•
Schatting van de duurtijd van de activiteiten
– Effectieve cijfers
– Aanduiding van mogelijke ‘range’ van resultaten
• 4 weken ± 2 dagen betekent dat een taak minstens 18 en maximaal 22 dagen zal duren
• 10% probabiliteit om langer dan 5 weken in beslag te nemen; geeft aan dat er grote kans
is dat de taak binnen de 3 weken zal worden uitgevoerd
– Schattingsbasis
• Bevat veronderstellingen die genomen zijn tijdens de schatting
Hoe een schatting beoordelen / evalueren?
– Zijn ze gevalideerd en door wie?
– Zijn de schattingen voorbereid, opgesteld en overeengekomen met de uitvoerders?
– Vergelijk schattingen met standaarden
– Verkrijg een duidelijk beeld over welke ‘contingency’ er in de schattingen vervat zit
– Bij twijfel… vraag bijkomend advies
– De PMer zelf MOET achter de schattingen staan
23
TD fase 3 – schedule development - algemeen
•
•
•
•
Schedule development (ontwikkeling van de planning) is het bepalen van de begin- en einddata van
de projectactiviteiten
Heel veel kans op mislukken indien deze data niet realistisch zijn
Is sterk iteratief
2 vormen
– Master projectplanning:
• bevat belangrijkste mijlpalen en werkproducten; verantwoordelijke = PMer;
• Creëert een voorwaartse zichtbaarheid naar management
– Gedetailleerde planning
• Planning met hoog detailniveau; bevat afhankelijkheden; benodigd aantal mensen…
• Gegevensbron voor de master projectplanning
• Instrument voor de PMer om permanent de voortgang te evalueren
TD fase 3 – schedule development - inputs
•
•
•
•
•
•
•
•
Project network diagram
Schattingen van de duurtijd per activiteit
Resource vereisten
Resource pool informatie
– Kennis van welke mensen wanneer beschikbaar zijn
– Hoe kunnen ze worden ingezet? Onder welke randvoorwaarden?
Werkkalenders;
– Project(werk)kalender: heeft invloed op alle medewerkers
– Individuele kalender: geeft beschikbaarheid aan van 1 specifieke medewerker (cursusdata,
verlofplanning…)
Beperkingen
– Opgelegde data: het opleveren van een werkproduct tegen een vaste datum
– Extreem gevaarlijk!!
Veronderstellingen
Leads en lags (voorijlen en naijlen)
– Elke afhankelijkheid kan een lead of lag inhouden. Vbn;
• Een telecom-lijn dient 6 weken op voorhand aangevraagd te worden (=lead)
• Beton heeft 28 dagen droogtijd nodig (=lag)
TD fase 3 – schedule development – tools & techniques
•
•
•
Rekenkundige analyse
– Berekening van theoretische start- en einddata , zonder rekening te houden met beperkingen van
resources
– Berekende data resulteren niet in planning, maar zijn eerder indicatief
– Door aanvulling met de resourcebeperkingen en de assumpties, bekomt men een effectieve
planning
– 2 methodes bekend
• (CPM) Critical Path Method
• (PERT)
Duurtijd compressie
– Zoekt naar manier om de planning in te korten, ZONDER de scope te wijzigen (handig voor
noodgevallen)
• Crashing
• Fast-tracking; meer taken parallel uitvoeren
– Garandeert een risico-verhoging!!
Heuristische methodes
24
–
•
Een planning kan op sommige ogenblikken heel veel resources vragen, of een onbeheersbaar
aantal mensen vragen
– “ken zeldzame mensen toe aan kritische taken”
– Leidt meestal tot een langere duurtijd
Resource constrained scheduling; absolute beperking van het aantal resources (bijv. familiaal
aannemer met twee zonen voor de bouw van een huis)
TD 3 – SD – voorstellingswijzen voor planning
•
•
Voorbeeldproject:
3 meest frequente voorstellingswijzen
– Bar / Gantt charts
• ..\..\Presales\Projecten\Azur\AZURv3.mpp
– Mijlpaaloverzichten
• Bijzonder geval van Ganntt
• Vooral voor management-doeleinden
• ..\..\Vlaamse Overheid ICT-dienstverlening\00
departementen\eGov\programmaopvolging\projectopvolging ET eGov v241103.mpp
– Netwerkdiagram
TD3 – SD – voorstellingswijzen - Gantt
•
•
Voordelen
– Efficiënte manier om planning visueel te communiceren
– Gemakkelijk voor te bereiden en te onderhouden
– Manier om zowel op detail als globaal in te zoomen
– Koppeling van planning aan kalenderdata
– Geeft start- en einddata weer
Nadelen
– Grafische voorstelling is meteen ook de beperking
– Moeilijk om de afhankelijkheden te visualiseren en analyseren
– Creëert geen zicht op de float (of slack)
– Geen leidraad die alternatieve acties snel blootlegt
TD3 – SD – voorstellingswijzen - mijlpaaloverzicht
•
•
Voordelen
– Legt nadruk op de cruciale gebeurtenissen van een project
– Gemakkelijk te creëren
– Goed om de voortgang te tonen ten opzichte van het origineel plan
– Aangewezen bij programma management
Beperkingen
– Geen zicht op afhankelijkheden
– Geen objectieve meting van de projectstatus
– Niet bruikbaar voor planningswijzigingen
TD3 – SD – voorstellingswijzen - netwerkdiagram
•
voordelen
– Visuele weergave van de chronologische voorwaarden en tijdsbeperkingen voor elke activiteit
– Geeft buitenstaanders een goed inzicht in de afhankelijkheden tussen activiteiten
25
•
Beperkingen
– Maar zo goed als de tijdsschattingen van de activiteiten waarop ze gebaseerd zijn
– Visualisatiemethode beperkt te behandelen projectomvang: ..\..\Presales\Projecten\KBC
WAN\Projectplan WAN Backbone & Access Network.mpp
– Creëert neiging om management-aandacht toe te spitsen op afhankelijkheden, terwijl er meer
beïnvloedende parameters zijn bij een project
Projectplanning
opstellen van een planning (TD1 tot TD3) in de praktijk
Fast track voor ontwikkeling van een planning
1.
2.
3.
4.
5.
Bepaal de activiteiten en hun geschatte tijdsduur (pro memore)
bepaal de afhankelijkheden
Analyse van het kritisch pad
Personeelsgebruik (‘levelling’)
“What if” analyse
Kan allemaal door gebruik te maken van standaard, geautomatiseerde tools. Maar… weet wat je doet (of
de tool voor jou doet)
Bepaling van de afhankelijkheden
Voorijlende relaties
–
Finish to start; taak 1 moet volledig
afgewerkt zijn vóór taak 2 kan beginnen
Taak 1
–
Finish to finish: taak 1 kan niet beëindigd
worden voordat taak 2 is afgewerkt
Taak 1
Taak 2
Taak 2
–
Start to Start: taak 2 kan niet beginnen
vóór taak 1 start
Taak 1
Taak 2
•
•
Per relatie kan een lead of een lag worden toegevoegd
– Lead: een taak kan beginnen in het vooruitzicht van het einde van een andere taak
– Lag; een taak kan maar beginnen na de afwerking van een andere taak, en wordt dan nog
bijkomend vertraagd met een tijd
Meest gebruikte methode:
– Precedence diagramming method (PDM)
– Soms aangeduid als Activity on Node diagram
PDM – beschrijving methode
•
•
Taken worden voorgesteld door nodes, terwijl afhankelijkheden worden voorgesteld door pijlen die de
nodes verbinden
Creatie van een precedence diagram
26
Inventariseer taken
en afhankelijkheden
Teken pijlen van start node
naar de eerste activiteit
Creëer start
node
Plaats alle activiteiten in
volgorde vanaf de start node
Herhaal voor alle
volgende taken
Verifiëer op eventuele
Vergeten afhankelijkheden
Generatie en analyse van het kritisch pad
•
•
Gebeurt via een tweede methode; CPM
– Duiding methode
– Belang van slack (of float)
Aanpassingen aan de planning
– Verkorting van de duur
• Crashing
• Fast tracking
– Resource smoothing
– Resource leveling
CPM: de methode
•
•
•
•
•
•
•
•
Berekent de kortst noodzakelijke tijd om een project uit te voeren
Maakt gebruik van één schatting van de benodigde tijd per taak (de meest waarschijnlijke duur)
Gebeurt door voor iedere taak de vroegste en laatste start- en begindata te berekenen.
De route waar er geen verschil is tussen de vroegste en de laatste data = het kritische pad!
(zero float)
Impact van kritisch pad: het niet behalen van de data van een taak die op het kritisch pad ligt,
heeft een onmiddellijke impact op de einddatum van het project, indien er geen correctieve acties
worden genomen
(total) float: de hoeveelheid tijd die een taak mag uitlopen of kan uitgesteld worden, ZONDER invloed
te hebben op de einddatum van het project
De float van een taak kan variëren tijdens de loop van een traject
Free float; de hoeveelheid tijd die een taak kan uitgesteld worden, zonder invloed te hebben op de
vroegste start ven één van de onmiddellijk daaropvolgende activiteiten
Earliest Start
ES
EF
Earliest finish
LF
Latest finish
Taak 1
Duur XX
Latest Start
1.
2.
3.
4.
LS
Bereken de voorwaartse stap: ES + duur = EF
Bereken de achterwaartse stap: LF – duur = LS
Bepaal float per activiteit: LS – ES
Activiteiten met float = 0; liggen op kritisch pad
27
CPM - voorbeeld
Taak 1
Duur 2
0
start
0
Taak 2
Duur 4
Taak 3
Duur 3
0
einde
0
Taak 4
Duur 7
Taak 5
Duur 1
Taak 6
Duur 5
CPM – voorbeeld – voorwaartse pas
10
7
0
0
0
start
Taak 1
Duur 2
2
2
Taak 2
Duur 4
6
6
0
0
Taak 3
Duur 3
9
1
0
Taak 4
Duur 7
0
Taak 6
Duur 5
7
7
Taak 5
Duur 1
8
0
einde
1
0
5
28
CPM – voorbeeld – achterwaartse pas
0
Taak 1
Duur 2
1
0
start
0
2
2
3
3
Taak 2
Duur 4
6
7
7
7
Taak 3
Duur 3
1
01
0
0
0
0
Taak 4
Duur 7
2
0
7
7
9
9
Taak 5
Duur 1
einde
1
einde
01
0
8
1
1
01
0
0
7
0
1
5
Taak 6
Duur 5
5
1
0
CPM – voorbeeld – kritische pad
0
Taak 1
Duur 2
1
0
0
start
2
2
3
3
Taak 2
Duur 4
6
7
7
7
0
0
0
Taak 4
Duur 7
0
0
5
Taak 6
Duur 5
7
7
7
9
Taak 5
Duur 1
8
1
Taak 3
Duur 3
1
01
0
01
0
1
01
0
0
5
1
0
29
The proof of the pudding… alfabet project
taak
duur (dagen)
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
Z
predecessors
start
15
20
12
4
12
8
20
11
6
15
13
4
5
10
20
15
15
42
A
B
A
D
E
F
E
C,G,H
A
J
K
L
M,P
J
O
O
Q
A
einde
Alfabet project - probleemstelling
Construeer en analyseer het PDM netwerk diagram en beantwoord de volgende vragen:
1. Wat is het kritieke pad voor dit project?
2. Hoe lang zal het duren voor het project afgewerkt is?
3. De klant is beloofd dat de uitvoering van het project niet langer dan 9 weken zal duren.
1. Kan dit?
2. Indien niet; wat dient er te gebeuren om de terlijn wel te halen?
PERT; Program Evaluation & Review techniek
•
•
•
Analoog aan CPM
Gebruikt gewogen gemiddelde per activiteit om het project te plannen
Weging bepaald door analyse van case-studies
Optimistische + 4 x meest waarschijnlijke + pessimistische
6
Evaluatie en bijsturing van de planning
Initiële tijdsschattingen en planning moet geëvalueerd en bijgestuurd worden
Beperkingen
•
tijdsbeperkingen (deadlines…)
•
gelimiteerd aantal mensen
Gebruikte methodes
•
•
compressie van de tijdsduur door
–
crashing
–
fast tracking
levelling of smoothing
30
Compressie van de tijdsduur
•
•
Is verkorten van de doorlooptijd van een project, ZONDER de scope te wijzigen!
Twee belangrijke methodes:
– Crashing
• Verkort doorlooptijd, na analyse en prioritisatie van de kost en planning parameters
• Onvermijdelijk gevolg; hogere kost
– Fast tracking
• Parallel laten verlopen van activiteiten die normaliter na elkaar zouden worden uitgevoerd
• Is ‘strohalm’ methode; alleen gebruiken bij gebrek aan alternatieven
• Gevolg; verhoging risico
Hoe een planning te ‘crashen’
•
•
•
•
•
•
•
Bepaal huidige en target duurtijd van project (berekening van % dat ingekort dient te worden)
Overloop iedere afhankelijkheid kritisch van taken op het kritische pad; behoud enkel de
‘onvermijdbare’
Bepaal mogelijke tijdswinst per taak op het KP (tijdswinst vs kostverhoging)
Bepaal een volgorde voor de te behandelen taken
Crash 1 enkele activiteit en herbereken KP
Bij wijziging KP, herhaal de bovenstaande stappen op het nieuwe KP
Blijf dit uitvoeren tot target bereikt
“Best practices” bij compressie
•
•
•
•
Reduceer een individuele taak NOOIT met meer dan 25%
Comprimeer eerst de taken met de laagste kost
Crashing enkel op taken die voldoende resources hebben
Hou rekening met ‘span of control’; cfr “Mythical manmonth”
•
Denk ook aan decompressie!!
Resource levelling & smoothing
•
•
•
Een planning gaat eerst uit van een oneindig aantal beschikbare mensen
Resource levelling; betreft het inbrengen van de resource realiteit in de planning
Bijzondere vorm; zorgen dat ‘pieken’ in aantal benodigde mensen verdwijnen uit de planning:
resource smoothing
Hoe resource levelling uitvoeren
1.
2.
3.
4.
5.
6.
7.
Creëer planning met assumptie van oneindig aantal mensen
Bepaal KP
Bereken de tijdsgebonden resource load
Bepaal de taken waarvoor onvoldoende mensen beschikbaar zijn
Geef voorrang aan de taken die op het KP liggen
Pers de andere taken uit door gebruik te maken van de float
Monitor wijzigingen in KP
31
Tips bij resource levelling
Probeer taken maximaal naar voor te schuiven, maar begin dan met een kleiner aantal mensen
– Beperkt risico van een planning die te ver naar achter evolueert
Resource levelling heeft meestal als gevolg dat de doorlooptijd van het project verhoogt (WvBM)
– Anderzijds wordt het project hierdoor realistischer
Resource smoothing
Zelfde aanpak als resource levelling, maar
– Kan geen of beperkte (bijkomende) gevolgen hebben voor de duurtijd van het project
– Objectief is hier vooral om een zo stabiel mogelijk projectteam te verkrijgen
– Vooral toepasbaar bij ‘vrije’ activiteiten (consultancy, rapportering…)
Risicobeheer binnen een planning
•
•
•
ALLE planningen bezitten een bepaalde hoeveelheid risico
Probeer deze te identificeren en te onderkennen
Risico is meestal niet uniform verdeeld over de planning;
– Bepaalde activiteiten zijn meer risicovol dan anderen
– Een planning kan risico absorberen, door de activatie van de beschikbare float
– Er dient risicomarge voorzien te worden in de planning voor taken op of ‘tegen’ de KP en die een
risico inhouden
Risico’s en reserves
•
•
Reserves worden gebruikt om de impact van het niet-behalen van tijds- of planningsobjectieven te
verminderen
Soorten
– noodreserves
• Bij voorkeur gepland binnen de kritische taken
• Zitten vervat in de project kost en planning
• Beheerd door de PMer
– Management reserves
• Apart voorziene reserve, gebaseerd op risico-analyse en gebruikt voor moeilijk voorspelbare
gebeurtenissen
• Worden toegevoegd aan een baseline, maken meestal deel uit van een bredere portfolio en
worden vrijgegeven indien het risico niet langer bestaat
• Beheerd en toegekend door management
Schedule control – beheer van wijzigingen…
Schedule control omvat:
– Beïnvloeden van de factoren die wijzigingen in de planning kunnen teweegbrengen
– Vaststellen van wijzigingen aan de planning
– Beheer van de wijzigingen wanneer ze effectief voorkomen
Moet zwaar geïntegreerd zijn in:
– Andere beheersprocessen
– Het hoofd van ALLE project-teamleden
32
Schedule control
•
•
•
inputs
– Projectplanning als baseline voor metingen
– Voortgangsrapportering
– Change requests!!
Tools & techniques
– Change control procedure
– Tools / templates voor impact-analyse
Outputs
– Updates / bijsturingen van de planning
– Revisies van de planning (re-baselining)
– Correctieve acties;
TD4 – Resource planning
•
•
•
•
•
•
Bepalen welke fysische middelen en hoeveelheden noodzakelijk zijn om de projecttaken uit te voeren
– Omvat zowel mensen, uitrusting als materialen
– Heeft een belangrijke invloed op de schatting van de kost
– Een planning die een goed inzicht geeft in wanneer welke resources nodig zijn
Eigenschappen van een goed projectteam
– Een redelijk bemanningsniveau bij de start-up
– Noodzakelijke expertise is aanwezig bij opstarten project
– Realistische smoothing zodat een “correct” bemanningsniveau bereikt wordt
– Consistent met de productiviteitsparameters die gebruikt zijn bij de schatting
– Stabiel team
– Realistische ‘staff down’
Hoe meer zielen,… hoe beter dient vastgelegd en opgevolgd te worden wie wat doet (Activity
responsibility matrix)
Inputs;
– WBS
– Historische informatie
– Scope
– Richtlijnen van de organisatie aangaande planning-toewijzing-gebruik van resources
Tools & techniques
– Geen echte hulpmiddelen
Outputs
– Resource plan / behoeften; een beschrijvingvan welke soorten middelen noodzakelijk zijn, volgens
welke hoeveelheden en wanneer.
TD5 – kostenbeheersing
Opgedeeld in 3 delen
– Schatten van de kosten
– Verdelen van de kosten over de tijd
– Beheer van de wijzigingen
TD 5.1 – Cost Estimating
•
•
•
Behandelt de ontwikkeling van een (benadering) van de kosten van de middelen die nodig zijn om het
project te kunnen uitvoeren
Kost ≠prijs!!
De kost bepalen kan een heel inspannende en creatieve fase zijn
33
–
–
–
Alternatieven dienen grondig bekeken te worden
Rolls-Royce vs VW Passat
Vaak dient een (belangrijke) keuze gemaakt worden tussen langer voorbereiden en sneller
uitvoeren
TD 5.1 – Cost estimating
•
Inputs
– WBS
– Resource planning
– Profielprijzen
– Duur van de activiteiten => geldwaarde
•
Belang van een kostenmodel; alle teamleden dienen op voorhand te beschikken over dezelfde
template, mét duidelijke richtlijnen!!
TD 5.1 – Tools & Techniques
•
•
•
Analoge schatting (of top-down schatting)
– Gebruik de reële kost van een ander, analoog project als schattingsbasis voor huidig
project
– Vaak gebruikt indien weinig andere informatie beschikbaar is
– Sneller, maar ook minder precies
– Vooral betrouwbaar indien:
• Het analoog project gelijkaardig lijkt en het ook in de feiten is
• Diegenen die schatten de nodige expertise hebben
Parametrische modellering
– Op basis van projectparameters
– Kunnen zowel eenvoudige als complexe projecten betreffen
– Voorbeeld; prijs van een huis per m2, gebruik van functiepunten
Bottom-up schatting;
– bepaal een geschatte kost per taak en sommeer
– Wvbm tussen schattingskost en juistheid
TD5.1 - Outputs
•
•
Kost-schatting: kwantitatieve bepalingen van de waarschijnlijke kost
– Kost moet geschat worden voor ALLE resources die zullen aangerekend worden (mensen,
materiaal, inflatie, overhead…)
– Druk alles uit in $ of € voor vergelijking
– Kosten kunnen verfijnd worden tijdens de loop van het proces, door bijv. marktevolutieaankooptechnieken
Kostmanagementplan:
– beschrijft hoe varianties in de kost zullen worden opgevolgd en beheerd
– Maakt deel uit van PMP
TD 5.2 – Cost Budgeting
•
•
Betreft toekennen van algemene kostenplaatsen aan individuele taken zodat men inzicht bekomt in de
kostenopbouw
– Hoe is de projectkost gespreid over de tijd?
Inputs
34
•
•
– Kostschattingen
– WBS
– Projectplan
Tools en hulpmiddelen
– Creativiteit!
– Bedrijfsrichtlijnen rond kosten-allocatie en facturatie
Outputs
– Cost baseline
TD 5.3 – Cost Control - algemeen
•
•
•
•
•
•
Cost control is:
– Beïnvloeden van die factoren die positieve veranderingen aanbrengen aan de kost-baseline
– Beheer van de wijzigingen aan die baseline
– (in feite een beheersproces)
Noodzakelijke activiteiten
– Permanente opvolging van de kosten om de afwijkingen te identificeren
– Reflecteren van alle wijzigingen in de kost-baseline
– Voorkomen van niet-goedgekeurde of ‘dure’ wijzigingen
– Informeren van de betrokken stakeholders
Gaat dus over WAAROM er wijzigingen zijn in de kosten. Hangt nauw samen met alle andere
beheersprocessen!
Inputs
– Kost-baseline
– Voortgangsrapportering
– Change requests
Tools & hulpmiddelen
– Cost change control system; wie fiatteert een wijziging die invloed heeft op de kost en hoe gaat
dit in zijn werk
– Performance management-technieken; hoever staan we?
Outputs
– Herzieningen van de kost-schattingen
– Budget-updates
– Correctieve acties
TD6 – Review proces
•
•
•
•
Cruciale stap in de TD-aanpak
– Wordt meestal voorbereid door verschillende fora
• ‘throw spaghetti at the wall’ – sessions
• Peer-review assesments
• Strawman-review, Dry-runs…
Alle mogelijke stakeholders worden bij de review betrokken om een zo goed mogelijke evaluatie,
validatie of bijsturing te bekomen
Ook goed voor de inschatting van de risico’s, bepalen van de kwaliteits-aspecten
Expliciete goedkeuring van de TD-aanpak door directie of management is noodzakelijk!
TD6 – review proces – nuttige tips
•
Zorg ervoor dat:
– Alle uit te voeren taken zijn opgenomen in de SOW en het contract
– Alle taken en planningen in één planning zijn geconsolideerd (geen parallelle planning!!)
– Alle schattingen zijn onderbouwd
35
–
–
–
–
Assumpties, beperkingen en rationale volledig en gedetailleerd zijn gedocumenteerd
De personeelsmix en de personeelsvereisten realistisch en doenbaar zijn
Het budget samengesteld is uit doenbare en beheersbare blokken
Alle niet-menselijke middelen en de samenhangende werklast ook gebudgetteerd zijn
Bottom-up 1: gedetailleerd planningproces
•
•
Doel
– Creatie van een comfort-niveau op de planning door een validatie uit te voeren van het TDplanning
– Identificeren van;
• Inconsistenties
• Vergeten activiteiten
• Aanvullende risico’s of risico-mitigatie strategieën
– Één niveau dieper qua planning. Bepaalt voor iedere MCP
• De werkproducten
• Bemanning
• Competentiemix
• Meetparameters
Opmerking; wordt niet gedetailleerd besproken in deze cursus
Bottom-up 2: reconciliation (samenvoeging)
•
•
•
•
Is voeden van gedetailleerde informatie van het BU-plan naar het TD-plan, om consistentie te
behouden
Hieruit komen typisch
– Onmogelijkheden van de planning
– Vergeten kosten
– Bijkomende (tricky) afhankelijkheden
Bedoeling is dat deze gecorrigeerd worden
Iteratie kan nodig zijn
Project management plan
•
•
Na de TD en de BU is alle relevante projectinformatie geconsolideerd en opgenomen in het PMP
Is de projectbijbel en bevat
– Wijze waarop project zal beheerd worden
– Details aangaande de bemanning
– Beschrijft huidige toestand en te bereiken toestand
– Beschrijving van de aandachtspunten
– Omschrijving van hoe de kost, planning en technische status zal opgevolgd worden.
Projectuitvoering en beheersing
Sleutelprocessen van uitvoering en beheersing
•
•
•
Beheer van wijzigingen
Opvolgen en bijsturen van de voortgang
Oplossen van problemen
Project
initiatie
Project
planning
Beheers
processen
Uitvoerende
processen
Project
afsluiting
36
Effecten van wijzigingen
•
•
Als
–
–
–
de scope niet voor iedere fase perfect is bepaald,
Kunnen de juiste resources niet worden gepland
Zal men bijna zeker niet de gewenste resultaten bekomen
Ontsporing van het project
• Langer duren dan gepland
• Meer kosten dan noodzakelijk
– Zal de PMer hiervoor verantwoordelijk worden gesteld
ALLE scope wijzigingen hebben een invloed op het projectplan of de kost
Bronnen van wijzigingen
•
•
•
•
•
•
Deliverables
– Design, ontwikkeling, opleiding…
– Documentatie
– Acceptatietesten
Verplichtingen vanuit de klant qua
– Architectuur
– Partners
– Software…
Verantwoordelijkheden en afhankelijkheden van de klant
Data
Kost- en betalingsplannen
assumpties
Oplossing; gebruik van change control proces
•
•
•
•
•
•
•
•
Bepaal baseline en verkrijg goedkeuring van de klant
Spreek een change control proces af
Documenteer alle aanvragen tot wijziging
Evalueer de impact van de wijzigingen
– Financieel
– planning
Vraag het akkoord van de klant over de impact
Wijzig de baseline en implementeer de wijziging
Documenteer de wijziging
Breng stakeholders op de hoogte van de wijziging
Onderdelen van een change control proces
•
•
•
•
•
Overeengekomen project baseline
Overeengekomen change control procedures
Change control documenten
Change control logboek
Change control review board
•
EN…
– Discipline bij de PMer
– Discipline bij alle projectleden
– Discipline bij de klant
37
Opvolgen en bijsturen van de projectvoorgang
•
Inleiding
– Zelfs indien de rapportering beperkt is tot het verschaffen van getallen over kost, planning en
percentages….
® Het enige wat telt, is om de betekenis achter de cijfers te kunnen identificeren
® Alleen dan en enkel dan, kan de juiste correctieve actie worden genomen
– Eerst bedoeling van monitoring is NIET te kunnen zeggen welke problemen zijn opgelost of te
zeggen welke resultaten zijn behaal, WEL om een zicht te krijgen op de problemen die kunnen
opduiken
Ook de projectvoortgang moet gepland worden…
•
•
•
•
•
Projectvoortgang dient gepland te worden als alle andere ‘normale’ taken
Bepaal WAT dient opgevolgd te worden
Door WIE
HOE (bepaling van de output en hoe deze tot stand zal komen)
Op welke FREQUENTIE
WAT dient opgevolgd te worden?
•
•
•
Status tov baseline
– Actual kosten vs geplande kosten
– Behaalde mijlpalen vs geplande mijlpalen
Wat is de impact van de geïdentificeerde afwijkingen indien er geen actie wordt ondernomen?
Review van
– Resource plan
– Afhankelijkheden
– Risico’s
– Gemaakte assumpties
Meetings versus reviews
•
•
Status meetings
– Voor het projectteam
– Evaluatie van huidige varianties en de noodzakelijke correctieve acties
– Mogelijke problemen
– Risico’s
Project reviews
– Presentatie naar de stakeholders
– Op sleutelmomenten van het project
– Uitgelezen ogenblik om de grote problemen aan te kaarten (en een oplossing aangereikt te
krijgen)
Voortgang van projecten – kernpunten
•
•
•
Goede beslissingen vereisen goede gegevens
– Moedig de mensen aan om tijdig en eerlijk te rapporteren
Er zullen ALTIJD afwijkingen zijn
– Zorg ervoor dat je de oorzaak ervan kent
Bewaak de baseline zorgvuldig
– Vang wijzigingen op via het change control proces
38
‘stille’ alarmsignalen
•
•
•
•
•
•
Achteruitschuiven van activiteiten op het KP
Reductie van de tijd die voorzien was voor validatie
Verwaarlozen van documentatie
Problemen met de bemanning
– Mensen die worden teruggetrokken
– Moeilijkheid om bijkomende mensen te vinden
– Onervaren personeel
Mensen willen geen garanties geven rond data
Verslechterende sfeer binnen het projectteam
Oplossen van problemen
•
•
•
Één van de hoofdbezigheden van de PMer tijdens de uitvoering van een project
Slechts weinig “technieken” hiervoor beschikbaar
– Fish-boning
– Oorzaak-en-gevolg diagramma
Belangrijk om een aantal basisprincipes te hanteren
– Speel de bal en niet de man
– Focus op de oplossing van het probleem
– Wees onderbouwd pragmatisch
Project afsluiting
Project
initiatie
Project
planning
Afsluiting van het project - kernpunten
•
•
•
•
•
Beheers
De afsluiting start bij het begin van het project (bij opstelling
processen
projectplan)
– Leg de verwachtingen van de klant vast
– Voorzie voldoende mensen en tijd
Zorg ervoor dat de testen een antwoord leveren op de acceptatiecriteria
Vraag voldoende op voorhand aan de klant dat de test-data worden voorbereid
Stel alle nuttige informatie beschikbaar voor toekomstige projecten
Allerlaatste actie; een formele debriefing en een lessons learned meeting
Uitvoerende
processen
Project
afsluiting
Afsluiting met … de klant
•
•
•
•
Organiseer review meeting om de finale goedkeuring te bekomen van de klant
– Waarde van het project en de betalingen
– Klantentevredenheid
– Lessons learned
Officialiseer belangrijke punten zoals licenties en eigenaarschap
Behandel alle lopende problemen en voorzie een overeengekomen actieplan
Zorg voor een eventuele hand-over naar de nieuwe verantwoordelijken
Afsluiting met … het projectteam
•
Organiseer einde-project sessies
– Op individueel niveau;
• evaluatiegesprekken en functioneringsgesprekken
• Updating van de persoonlijke CV’s
39
–
• Bepaal de project bonussen (indien van toepassing)
Volledig projectteam
• Structureer de feedback van alle leden in lessons learned
• Communiceer lessons learned binnen de organisatie
Afsluiting met … de uitvoerende organisatie
•
•
•
•
•
•
Ontruim alle burelen en lokalen (inclusief toegangsbadges)
Geef alle gebruikte uitrustingen terug
Ontmantel de ontwikkelomgeving
Finale update van de projectdocumentatie
Stel het afsluitend projectrapport op
Sluit af met de financiële diensten aangaande
– Facturen
– Aankopen…
Afsluiting met … iedereen
•
•
Organiseer een fuif met alle stakeholders, als erkenning van het geleverde werk en bijdragen
Communiceer over het behaalde project-succes
Programmabeheer
Wat is programmabeheer
•
•
Programmabeheer behandelt simultaan lopende projecten
Complexiteit wordt geïnduceerd door de afhankelijkheden die bestaan tussen de verschillende
projecten
Principes van programmabeheer
•
•
•
Projecten blijven hun eigen managementmethodiek en –structuur behouden
Rapportering gebeurt naar programmaniveau
Typisch explicitering van enkele rollen
– Project Management Office of Project Support Office
– Risk manager
Voorbeeldmethodologie programmabeheer
40
Beheersmodel
Programma beheer
Tools
Portfolio management
Definitie Portfolio management
Portfolio management brengt een aantal projecten samen in één enkele portefeuille van rapporten die
– Projectobjectieven
– Kosten
– Planningen
– Resultaten
– Mensen
– Risico’s
– Alle andere kritische factoren
groepeert zodat een managementzicht gecreëerd wordt op de lopende projecten
En de juiste managementsbeslissingen kunnen worden genomen.
Voorbeelden
41
Pril begin van portfolio management; start-up binnen een bestaande organisatie
Eerste voorstel tot aanpak voor portfolio management
Definitie – wat is portfolio management?
•
Portfolio management is een systematische aanpak voor de selectie en prioritisatie van (IT) projecten
– Vertrekt vanuit de bedrijfsstrategie / objectieven
– Selectie en prioriteitsstelling gebeurt op basis van vooraf bepaalde criteria
– Grootste deel van deze activiteiten worden geleid door de directies
– Binnen budgettair kader; “Er zijn altijd meer projecten dan budget”
•
Doel portfolio management
– Enkel projecten toelaten en begroten die een effectieve bijdrage leveren aan de objectieven
– Permanent impact behouden van de directies op de nieuwe en de lopende projecten
– Transparantie creëren en behouden gedurende de ganse duur van het proces
Eerste stappen in de realisatie van een portfolio management proces
•
•
Bepalen en volgen van een projectflow
– Aantal vaste stadia die door een project gevolgd dienen te worden
– Neem de juiste managementbeslissing op het juiste ogenblik
Opstellen van de beslissings- en prioritisatie criteria
– Is vorm van scoring
– Criteria dienen met zorg gekozen te worden; is cruciaal in het ganse proces
Resultaat van scoringsproces
42