ProjectManagement is risicomanagement

Het kiezen van een bepaalde softwareontikkelmethode heeft grote gevolgen voor het management van een project. Het implicitiert risicos’s. De softwareprojectmanager zit vaak met de handen in het haar: Hoe de projectsituatie te “matchen”met een methode? We zijn niet in staat, constateert KlaasJan Molendijk en Stef Oud, om alle relevante factoren te definieren en te wegen.

Het slagen danwel falen van een softwareproject heeft alles te maken met management. En ondanks de technische lading van de term 'softwareontwikkelmethode' , is een methode een van de sterkste krachten achter het management van een project. Hoewel deze stelling ongetwijfeld op weerstand stuit, is dit eenvoudig te motiveren: met de keuze voor een bepaalde methode als startpositie van een project maken we veel impliciete managementkeuzes. Ter illustratie: we kunnen niet voor een 'agile' methode kiezen en vervolgens ook nog eens 'kiezen' voor een autoritaire manage­mentstijl. Een van agile's fundamenten is namelijk een coachende leiderschaps­stijl die uitgaat van gelijkheid. Zonder dit fundament kan een project niet 'agile' worden genoemd. De selectie van een methode is derhalve van groot belang, omdat het mogelijk is dat we bij een keuze voor een methode onbewust ook keuzes maken die een risico voor het project zijn.

Een softwareontwikkelmethode - zoals RUP (Rational Unified Process) en XP (Extreme Programming) - beschrijft elementen zoals de levenscyclus van het project, de principes, de belangrijke rollen en producten, en de technieken die gebruikt kunnen worden om een softwareproject aan te pakken. Kijkend naar alle beschikbare methoden, dan is er een heel aantal dimensies waarop ze kunnen verschillen. Zo ontwikkelt de ene methode bijvoorbeeld alles in één keer terwijl de andere de software opdeelt in kleinere, gemakkelijker beheersbare projecten (iteraties). De ene methode beschrijft gedetailleerd 'wat' de projectleden moeten doen en 'hoe' dat te doen, terwijl de andere methode het projectteam vrij laat in zijn keuzes.

Het is duidelijk dat deze verschillen niet per definitie 'goed' of 'slecht' danwel 'sterk' of 'zwak' zijn. Wel is expliciet te stellen dat het ene sterker is in een bepaalde situatie dan het andere. Dit lijkt een open deur, maar denkend aan ongenuanceerde claims die veel boeken en websites bezitten, wordt duidelijk dat deze deur in de praktijk vaak hermetisch is gesloten. XP's keuze om primair te werken op basis van 'tacit knowledge' (kennis in de hoofden van mensen) in tegenstelling tot gedocumenteerde kennis, werkt bijvoorbeeld uitstekend in het geval van 'bewegende' functionele eisen. Wijzigingen zijn dan immers sneller en gemakkelijker door te voeren. Echter, de kracht van XP is beduidend zwakker wanneer het een project van langere duur betreft, vanwege het kennisverlies dat wordt geriskeerd door onvermijdelijk personeelsverloop. Of in het geval dat projectmedewerkers niet gemakkelijk bij elkaar langs kunnen lopen, zoals het geval is bij offshore outsourcing.

Door de grote verscheidenheid aan projectsituaties en het missen van een raamwerk om de projectsituatie te 'matchen' met een methode, staat de softwareprojectmanager met de handen in het haar. Wat is 'de juiste' keuze? Hoe maak je die keuze? De projectmanager kiest er vervolgens veelal intuïtief voor om een klein aantal vuistregels ('gebruik <methodenaam> wel/niet als <omschrijving van situatie>') toe te passen. De beschikbare literatuur, maar ook gezond verstand, biedt hiervoor prima handvat¬ten. Kortom: we beseffen dat ieder project anders is en daarom een andere methode c.q. aanpak vereist. Daar hande¬len we dan ook naar met behulp van een aantal algemene vuistregels. Wat is dan nog het probleem?

De genoemde vuistregels vormen inderdaad een nuttige uitgangspositie voor een projectmanager. Een aantal clichévoorbeelden: wanneer de eisen duidelijk en stabiel zijn, dan kiezen we een watervalaanpak. Wanneer er sprake is van grote dynamiek en software met hoge interactiviteit, dan kiezen we voor een 'agile' methode zoals XP of Scrum. Zonder in dit artikel uitspraken te willen doen over de validiteit van deze voorbeelden, is het achterliggende 'waarom' gemakkelijk te begrijpen. Er zijn namelijk projectrisico's die we willen voorkomen, en daarom maken we bepaalde keuzes. Softwareprojectma¬nagement is dan ook in essentie risicomanagement.

Het management moet alle risico's zoveel mogelijk beperken. In het geval we bijvoorbeeld levenskritische software ontwikkelen, moeten we ervoor zorgen dat de aanwezigheid van defecten minimaal is. Wanneer de software een lange geplande levensduur heeft, moeten we er zeker van zijn dat toekomstig onderhoud geen probleem wordt. De crux is dat de ene methode beter is in het voorkomen/beperken van het risico dan de andere.

Er bestaat weinig tot geen regelgeving voor softwareontwikkeling

Dit sluit aan op de filosofie achter de vuistregels. Het groteprobleem van de selectie en toepassing van een methode zit dan ook niet in deze vuistregels op zich, maar meer in de beperkte dekking ervan. De meest eminente risico's zijn wellicht gedekt, maar het is een misvatting om te denken dat de methode er dan niet zo veel meer toe doet. De ervaring leert namelijk dat het project vervolgens toch telkens tegen problemen (het optreden van risico's) aanloopt en dat de initiële aanpak tot het einde toe evolueert tot 'de juiste' aanpak. Een van deze problemen kan bijvoorbeeld zijn dat ondanks de gebrekkige klantdomein­kennis van het team, de betrokkenheid van de klant laag is, wat vervolgens misverstanden (en daarmee vertraginingen) in de hand werkt. Als dit wordt geconstateerd - er is dan al pijn geleden - kan de aanpak zodanig worden aangepast dat de kennis van de klant (die het domein zonder meer het beste kent) beter wordt benut.

De initiële keuzes zijn, kortom, vaak minder compleet en doordacht dan wordt aangenomen. Dit heeft alles te ma¬ken met onze gelimiteerde rationaliteit ('bounded rationality'). Het is bekend dat we niet in staat zijn om alle relevante factoren (in dit geval risico's) te definiëren en te wegen. Een ander psychologisch feit betreft onze neiging om besluitvormingsprocessen af te breken op het moment dat we iets gevonden hebben dat acceptabel lijkt. We hebben wat vuistregels om een methode te selecteren en te gebruiken, zien vervolgens een methode die daar op aan lijkt te sluiten (bij voorkeur natuurlijk een methode die we al kennen) en beginnen enthousiast aan het project. Softwareprojectrnanagement is complex. Veel softwareprojecten zijn op dit moment te reactief: op het moment dat er iets misgaat, wordt dit gesignaleerd en actie ondernomen. Het probleem is echter dat er dan al extra kosten zijn gemaakt, tijd is verloren en frustraties zijn gecreëerd.

Juist door aan het begin van een nieuw project inzicht te creëren in de risico's, kunnen we objectiever en proactief nadenken over de 'juiste' methode/ aanpak.

Klaas-Jan Molendijk (kmolendijk@deloitte.nl) is als consultant en
Stel Oud is als partner werkzaam bij
Deloitte Consulting - Business Technology Advisory

LESSONS LEARNED

• De projectsituatie is geen statisch element en bestaat derhalve voor een groot deel uit beïnvloedbare elementen. Het contracttype, wel of geen off­shoring, de mate van klantbetrokken­heid: het zijn allemaal keuzes.
  
  Een voorbeeld: waarom een project starten als de software-eisen onduidelijk zijn, maar de klant toch niet intensief betrokken kan/wil zijn? Een methode kan nooit de risico's compenseren die wij op een dergelijke manier zelf creëren.
  
  
• Een projectsituatie is vrijwel altijd niet upiform; één deel van de software is misschien wel bedrijfskritisch, maar een ander deel niet. Niet alleen ieder project behoeft een specifieke aanpak, ook de verschillende deelsituaties. Het is in deze gevallen zelfs aan te raden om een eigen methode/aanpak te kiezen voor deze subprojecten en de aandacht te concentreren op het managen van interfaces.
  
  
• De IT-wereld staat bekend om al zijn methoden. Het projectteam zou het echter los moeten laten om in metho­den te denken.
  
  Veel belangrijker zijn de elementen uit een methode die succesfactoren zijn voor het specifieke project. Het gaat er niet om of een project MSF wordt genoemd of XP, maar om het voorko­men danwel beperken van projectrisi­co's.
  
  De oplossing is dan ook niet altijd de selectie van een andere methode, maar juist om het op een andere manier toepassen van een methode.
  
  
• Ondanks alle beschikbare methoden en technieken bestaat er weinig tot geen regelgeving op het gebied van software­ontwikkeling. Iedereen mag zich bijvoorbeeld ontwikkelaar noemen en vrij gebruikmaken van methoden. Kortom: er is geen controle op methoden en daarmee op de kwaliteit van softwareontwikkeling.

BEKENDE METHODEN

• RUP (Rational Unified process)
  Een via een tooI aangeboden raamwerk voor het creëren van een projectspeci­fieke aanpak, gebaseerd op onder meer iteratief en architectuurgeoriënteerd ontwikkelen. Wordt gekenmerkt door de compleetheid en de sterke relatie met UML (use cases).
  
  
• SDM (Software Development Methodo­logy)
  Een concrete invulling van de waterva­laanpak die met name bekend is in Nederland. In een watervalaanpak volgen ontwikkelingsfasen - van definitiestudie tot de implementatie - elkaar sequentieel op. De aanpak wordt veelal bekritiseert vanwege het formele karakter en het gebrek aan flexibiliteit.
  
  
• XP (Extreme Programming)
  Zonder meer de bekendste 'agile' methode. Bekend door de korte iteraties, focus op eenvoud, face-to-face communi­catie, een volledig participerende klant en door 'practices' zoals 'refactoring' en 'pair programming'.
  
  
• MSF (Microsoft Solution Framework)
  Een relatief nieuwe, door Microsoft geïntroduceerde aanpak voor software­projecten. Is ook gebaseerd op 'agile' principes (zie bijvoorbeeld XP).
  Het 'framework' biedt twee smaken:
• MSF4Agile en
• MSF4CMMI.

Het grootste verschil is dat MSF4CMMI formeler is en daarmee geschikter voor grotere en langer durende projec­ten.

• DSDM (Dynamic Systems Development Method)
  Een aanpak die is gebaseerd op sterke gebruikersparticipatie, iteratief ontwik­kelen, zelforganiserende teams en een informele aanpak. Wordt vaak geassoci­eerd met technieken als prototyping, timeboxing en het prioriteren met behulp van MoSCoW.
  
  
• Scrum
  Een op rugby gebaseerde iteratieve aanpak, die grote vrijheid geeft aan de (kleine) teams wat betreft de te gebrui­ken technieken. Hierdoor wordt Scrum soms alleen een managementaanpak genoemd. De methode is bekend door de 'daily stand­up meetings'.

23 NOVEMBER 2007 Automatisering Gids

Technorati Tags XP, project, Automatisering, Gids, Projectmanagement, risicomanagement, RUP, SDM, MSF, DSDM, Scrum

Estimating Duration

Whereas effort is normally given in terms of hours, duration is given in terms of days and an end-date. For instance, it could be confusing to say that the duration of a project is three months, since you don't know if this means that the duration is actually 90 days or 60 work days. What you should say instead is that the project duration is 90 days and the estimated end-date is 31 December 2004. If you describe the estimates in those terms, the estimated number of days of duration, as well as the targeted end-date, is clear.

If everyone worked eight hours per day, and was absolutely 100% productive for all eight hours, you could easily calculate duration by taking the number of effort hours, divided by the number of resources, divided by the number of hours they work per day. For instance, if an activity was estimated at 80 hours, and you have one person assigned, and they work eight hours per day, the duration would be (80 / 1 / 8) = 10 days. Likewise, if four people were assigned full time, the duration would be (80 / 4 / 8) = 2.5 days.

However, those perfect circumstances are not indicative of how work is actually performed. Therefore, you can convert effort hours to duration activities using the following process and techniques.

1. Estimate the productive hours per day. Normally the first step is to determine how many productive hours of work you can count on each person working per day over time. In other words, if an activity is scheduled to take 40 effort hours, it is unlikely that it can be completed in a calendar week, without overtime. Using a factor of 6.5 productive hours per day will help you take into account socializing, ramp-up time, going to the bathroom etc. The 6.5 hours per day reflects the general observation that people are actually productive around 80% of the time they are on the job.
   
2. Determine how many resources will be applied to each activity. In general, the more resources you can apply to activities, the quicker they can be completed. Obviously two resources may be able to complete an activity faster than one person, but it may not be twice as fast. Similarly, a third person may allow the task to be completed sooner, but not in one-third the time. However, at some point, adding resources will not make the activity complete any sooner, and in fact, may make it go longer.
   
3. Factor in available workdays, taking into account holidays, vacations and training. This was not included in the productivity factor in the first item, since this non-project time can be scheduled and accounted for in advance. For instance, on a three-month project, one team member may be out for two holidays, while another may also have ten days of vacation. To make your schedule more accurate, take into account any days that you know your team will not be available to work on the project.
   
4. Take into account any resources that are not full-time. If you have a resource 50% of the time, it will take them at least twice as long to do any individual activity. If you have an activity that has an estimated effort of 40 hours, and you assign a resource that is only available for 25% of his or her time, the resulting duration will be at least five weeks, if not more.
   
5. Calculate delays and lag-times. Some activities have a small number of effort hours, but a long duration. For instance, if you are counting on vendor resources, you may need to wait until the vendor is ready before you can begin. Another example is the duration required to get a deliverable approved. You may estimate the effort at only a few hours, yet it may take a number of days or weeks to gain the actual approval.
   
6. Identify resource constraints. When you build your initial workplan, you identify the activities that can be done sequentially and those that can be done in parallel. If you have enough resources, all of the parallel activities can, in fact, be done in parallel. However, you can only do the activities in parallel if you have the right resources available at the right time. If you do not have enough resources (you rarely do), you will find that some of the parallel activities need to be done sequentially, since the same resource needs to be assigned to the activities. Even if you think you have enough people, you also need to recognize that not all activities and team members are interchangeable. There may be a set of activities that can be done in parallel; however they need to be worked on sequentially because only one person has the right skills to do the work - even though other resources are available.
   
7. Document all assumptions. You will never know all the details of a project. Therefore, it is important to document all the assumptions you are making along with the estimate.

The Philosophy of Scrum

The core of the Scrum approach is the belief that most systems development has the wrong philosophical basis. The stated, accepted philosophy is that systems development process is a well understood approach that can be planned, estimated, and successfully completed.

The failed projects, inappropriate systems, and ineffective productivity tools are seen as proof that the development process needs more rigor, that if we can get those unruly developers to actually follow it, these maladies will go away.

Scrum states that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression. Cookbook, step-by-step approaches do not work because they aren't adequately defined and don't cope with the unpredictability of systems development.

Scrum defines the systems development process as a loose set of activities that combines known, workable tools and techniques with the best that a development team can devise to build systems. Since these activities are loose, controls to manage the process and inherent risk are used.

The following maladies occur as a result applying the wrong philosophy and techniques to systems development:

By the time the system is delivered, it is often irrelevant or requires significant change. This occurs because environmental inputs are used only during planning.

Management actually believes that it can predict the cost, delivery schedule, and functionality that will be delivered.

Developers and project managers are forced to live a lie...they have to pretend that they can plan, predict and deliver, and then work the best way that they know how to deliver a system. They build one way, pretend that they build another way, and are without controls.


Scrum is applicable to internal IS Organizations. Scrum will relieve IS Organizations of these terrible symptoms.


The approach is called Scrum. It starts with the acceptance that this is a complicated, unpredictable world and development environment. It also starts with the premise that you can't predict or definitively plan what you will deliver, when you will deliver it, and what the quality and cost will be. It starts with the assumption that you can estimate these, and then negotiate them according to various risks as you proceed. It is understood at the start, that you will deliver the best possible software given the circumstances, and that following any cookbook approach won't improve the definition of "best", and will only hinder appropriate responsiveness to the complexity and unpredictability.

The reaction of many IS organizations to this approach includes "we can't do that, everything will be out of control..." and "our board of directors will never approve funding to build an undefined product." However, that is exactly the way it is right now: out of control because of the inability to respond to unpredictability, and the funding is for products whose definition changes from the first day of the project.

As the divergence between those who are succeeding with a Scrum-like development process and those who are failing with SEI-CMM type processes increases, the heat of the argument is rising.

ADM and VMark have formalized the Scrum process, based on packaged software vendor experiences, because they feel that OO will suffer and possibly fail using the current development philosophy.

Scrum is applicable to new or existing systems that use clean interface or objects and components. Scrum enables component based development. Scrum tolerates on the job learning. As a matter of fact, Scrum is a knowledge creating process, where tacit knowledge is created and shared as work progresses. Collaborative teamwork ensures knowledge sharing and creation.

Standaard Plan van Aanpak

Inhoudsopgave
- Management samenvatting
- Introductie
- Projectopdracht
- Aanpak
- Projectinrichting en voorwaarden
- Plannen
- Kwaliteitsborging
- Overige plannen
- Bijlagen


Voorwoord
Het standaard plan van aanpak, dat in dit artikel is weergegeven, heeft met name betrekking op de ontwikkeling van informatiesystemen.
Daarnaast is het dermate generiek, dat het ook voor andersoortige trajecten gebruikt kan worden. De specifieke detailpunten kunnen dan enigszins afwijken.

1. Management samenvatting

Op een beknopt aantal pagina's worden de "high-light's" uit het Plan van Aanpak weergegeven, aangevuld met de geldigheidscondities van het Plan van aanpak.
Tot slot wordt een overzicht van alle beslispunten voor de opdrachtgever gegeven.

2. Introductie

De introductie is gericht op het Plan van Aanpak en het tot stand komen ervan.
Ingegaan wordt op de volgende aspecten:

• Aanleiding
  Hierbij wordt ingegaan op de oorzaak die geleid heeft tot het formuleren van de projectopdracht, het effectueren ervan en de omstandigheden waaronder dit Plan van Aanpak tot stand is gekomen. Indien van belang zal worden verwezen naar gevoerde gesprekken en referenties.
• Accordering en bijstelling
  Hier wordt opgenomen op welke wijze het Plan van Aanpak wordt goedgekeurd en bijgesteld. De voortgang en bijstellingen op het plan worden vastgesteld middels de voortgangsrapportage. Nadat voorgestelde wijzigingen zijn goedgekeurd is impliciet het Plan van Aanpak bijgesteld. Het actuele Plan van Aanpak wordt op deze wijze gevormd door het oorspronkelijke Plan van Aanpak en de voortgangsrapportages.
• Toelichting op de opbouw van het plan
  Hierin wordt de structuur van het plan toegelicht.

3. Projectopdracht

In dit hoofdstuk wordt de gewenste verandering in beeld gebracht. De opdracht wordt afgebakend, door middel van het beantwoorden van de "waarom", de "waarover" en de "wat"-vragen.
Deze zaken worden in "opdrachtgevers bewoordingen" aan de orde gebracht. De paragrafen worden als volgt ingevuld:

• Projectomgeving
  Wat is het beschouwingsgebied?
  Hierin wordt een schets gegeven van het beschouwingsgebied in termen van organisatie eenheden en bedrijfsprocessen. Tevens wordt aangegeven wat de problemen en oorzaken zijn die aanleiding geven tot de ontwikkeling van het resultaat.
• Doelstelling project
  Waarom heeft de opdrachtgever het resultaat nodig en wat wil de opdrachtgever met het resultaat bereiken?
  In deze paragraaf wordt een beschrijving gegeven van de doelstellingen van het te ontwikkelen resultaat, zoals aangegeven door de opdrachtgever. Met name wordt hierbij de koppeling gelegd naar bedrijfsprocessen. Hierbij is het van belang om te weten, waarop de opdrachtgever wordt afgerekend. Iedere doelstelling wordt zo mogelijk onderbouwd door kwalitatieve en kwantitatieve gegevens.
• Opdrachtformulering
  Wat is de projectopdracht?
  Waarover gaat het project procesmatig (afbakening)?
  Deze paragraaf beschrijft de opdracht, voortvloeiend uit de doelstelling, zoals aangegeven door de opdrachtgever. Hierbij wordt expliciet aangegeven welke zaken wel en welke zaken niet tot de verantwoordelijkheid van het project worden gerekend. Aangegeven wordt ook of het een resultaat- of een inspanningsverplichting betreft.
• Op te leveren producten en diensten
  Wat is het resultaat van het project?
  Waarover gaat het project inhoudelijk (afbakening)?
  Deze paragraaf bevat de specificatie van de op te resultaten zoals aangegeven door de opdrachtgever. Dit is een nadere uitwerking van de projectopdracht, zoals aangegeven bij de opdrachtformulering.
• Eisen en beperkingen
  In deze paragraaf worden de acceptatiecriteria en beperkingen vermeld, die de opdrachtgever stelt aan het resultaat en de eisen en beperkingen die gesteld worden aan de gebruikte resources en aan de wijze, waarop het resultaat tot stand komt. De eisen moeten zo nauwkeurig mogelijk worden gekwantificeerd. Indien mogelijk worden er ook prioriteiten vastgesteld.
• Cruciale succesfactoren
  Deze paragraaf beschrijft de door de opdrachtgever onderkende en specifiek voor deze opdracht geldende cruciale succesfactoren. Het moet zowel de opdrachtgever als de projectmanager duidelijk zijn welke maatregelen mogelijk zijn c.q. door beiden genomen moeten worden om deze factoren te beïnvloeden.

Van groot belang is de juiste interpretatie van een aantal onderdelen van de Projectopdracht :

• De Doelstelling geeft aan wat het achterliggende doel is van het starten van het project. Dit kan het doorvoeren van een organisatorische verandering zijn op uiteenlopende niveau's, zoals klant-, bedrijfs-, efficiëntie-, of middelenniveau.
• De Opdrachtformulering geeft weer door welk middel de opdrachtgever de gewenste doelstelling denkt te bereiken.
• De Eisen en beperkingen geven aan welke eisen de opdrachtgever stelt aan het eindresultaat en het procesmatige verloop van de opdracht.
• De Cruciale Succesfactoren geven aan, welke door de opdrachtnemer beïnvloedbare zaken er vanuit de opdrachtgever gezien essentieel zijn om het resultaat zo goed mogelijk te laten aansluiten bij de te bereiken doelstelling.

4. Aanpak

In het hoofdstuk Aanpak wordt de brug geslagen tussen het afgebakende resultaat en de inrichting van het project, door middel van beantwoording van de "hoe"-vraag. Doel is om door middel van Aanpak overeenstemming te verkrijgen over de te volgen weg, om te komen tot het gewenste resultaat.

Per eindresultaat wordt aangegeven welke activiteiten zullen worden uitgevoerd en eventueel welke tussenresultaten worden opgeleverd. Tevens wordt hierbij ingegaan op het waarom van de gekozen oplossing. Daarbij wordt verwezen naar de cruciale succesfactoren, de resultaten van de uitgevoerde risico analyse, en de geformuleerde eisen en beperkingen ten aanzien van proces, resultaat en kwaliteit. Als de projectmanager daarin op basis van de uitgangspositie, cruciale succesfactoren, risico analyse of kwaliteitseisen onduidelijkheid of onvolledigheid vaststelt, geeft hij aan hoe hij met deze zaken omgaat.

De projectmanager zal het project structureren en faseren om aan te geven in welke globale stappen hij de projectopdracht denkt uit te voeren.

Bij het structureren groepeert hij de gewenste eindresultaten primair naar algemene aandachtsgebieden. De volgende algemene aandachtsgebieden worden onderkend:

• Ontwikkeling resultaat
• Voorbereiding gebruik, dit zijn de activiteiten die samenhangen met het (her)inrichten van de gebruikersorganisatie
• Voorbereiding beheer, dit zijn de activiteiten die samenhangen met het (her)inrichten van de beheerorganisatie
• Acceptatie gebruik, het voorbereiden en uitvoeren van de gebruikers-acceptatie
• Acceptatie beheer, het voorbereiden en uitvoeren van de beheeracceptatie
• Kennis, dit zijn de activiteiten die samenhangen met het opbouwen van materiekennis met betrekking tot het resultaat (ook van het gebruik en het beheer ervan) en de activiteiten die samenhangen met de overdracht van deze kennis naar de staande organisatie.

Afhankelijk voor het type project worden de voor het project te hanteren aandachtsgebieden afgeleid uit de algemene aandachtsgebieden. Ook spelen andere criteria bij het structureren een rol, bijvoorbeeld:

• risico factoren
• cruciale succesfactoren
• kwaliteitseisen

Naast het structureren zal het project tevens in de tijd worden gefaseerd om formele meet- en beslismomenten te verkrijgen. De fasering wordt gericht op de beslissingen die de opdrachtgever wil nemen en vindt ondermeer plaats op basis van invoeringstijdstip of product.

Per aandachtsgebied en verdere onderverdeling, wordt aangegeven door welke activiteiten het eindresultaat wordt bereikt, wat de samenhang van de activiteiten is en welke tussenresultaten worden opgeleverd binnen c.q. buiten de projectopdracht. Indien nodig kan de samenhang gevisualiseerd worden in de vorm van een eenvoudig netwerkplan zonder kwantitatieve gegevens.

Conform de structuur en fasering wordt dit hoofdstuk in paragrafen opgedeeld.

5. Projectinrichting en voorwaarden

5.1 Projectinrichting
Het doel van projectinrichting is het zichtbaar maken van de wijze waarop de projectmanager van plan is het project in te richten om de opdracht uit te voeren volgens de voorgestelde aanpak. Hierbij zal de gekozen inrichting afhankelijk zijn van de resultaten van de risico analyse, kwaliteitseisen en de cruciale succesfactoren.

Afhankelijk van de opdracht en de organisatie komen de OPAFIT aspecten aan de orde:

• Organisatie
  waarbij aangegeven wordt hoe de projectorganisatie eruit komt te zien inclusief taken en verantwoordelijkheden. Deze worden per persoon en per rol gesteld
• Personeel
  waarbij de eisen aan de gewenste inzet en beschikbaarheid van personeel worden aangegeven zoals condities voor het betrekken van personeel, per groep de vereiste vakkennis, skills gerelateerd aan de plannen
• Administratieve procedures
  waarin alle binnen en rond het project van toepassing zijnde procedures worden genoemd
• Financiering
  alle financiële zaken worden hier behandeld, bij voorkeur met verwijzingen of, bij afwezigheid, expliciet opgenomen zoals tariefwijzigingen, facturering, subcontractors, btw en dergelijke;
• Informatie
  waarbij ingegaan wordt op alle informatie rond het project, overleg- en rapportagestructuren;
• Techniek
  waarbij wordt ingegaan op de voorgestelde inrichting qua hard- en software, werkplekken, hulpmiddelen en dergelijke.

5.2 Voorwaarden aan opdrachtnemer
Opsomming van voorwaarden, die gerealiseerd dienen te worden door de opdrachtnemer om het project volgens plan te kunnen uitvoeren. Deze voorwaarden zijn gerelateerd aan en aanvullend op de inrichtingsaspecten.

5.3 Voorwaarden aan opdrachtgever
idem als 4.2, echter met opdrachtgever i.p.v. opdrachtnemer.

5.4 Voorwaarden aan derden
idem als 4.2, echter met derden i.p.v. opdrachtnemer.

6. Plannen

In het hoofdstuk plannen wordt de resultante vastgelegd van het evenwicht tussen activiteiten, tijd, geld en middelen teneinde de opdracht te kunnen uitvoeren.

De verschillende paragrafen worden als volgt ingevuld:

• Normen en aannames
  Hierbij worden de gehanteerde normen, aannames en veronderstellingen zowel ten aanzien van de schattingen als ten aanzien van planning vermeld, zoveel mogelijk per eenheid verbijzonderd. Deze kunnen afkomstig zijn uit geraadpleegde literatuur aangevuld met "ervaringscijfers".
• Activiteitenplan
  In deze paragraaf worden de uit te voeren activiteiten beschreven. De detaillering hiervan is sterk afhankelijk van de opdrachtformulering en de fase waarin het project zich bevindt. Per activiteit wordt weergegeven de benodigde inspanning, de tijdsduur, de samenhang met andere activiteiten en het benodigde resourceniveau.
• Mijlpalen-/Productenplan
  Het mijlpalenplan geeft de meet- of beslismomenten weer. Hierbij worden de meest belangrijke momenten voor toetsing en sturing benadrukt.
  Het productenplan geeft de momenten weer waarop de (tussen)producten zullen worden opgeleverd en geaccepteerd.
• Resourceplan
  Het resourceplan verschaft duidelijkheid over personele en overige middelen. Het plan geeft weer over welke perioden inzet benodigd is. Bij de personele middelen wordt tevens het niveau van de resource aangegeven.
• Financieel plan
  In deze paragraaf wordt inzicht gegeven in de kosten (mensen, middelen en overig) van het project. Aangegeven worden de resources die in de planning zijn opgenomen, de hiervoor gehanteerde tarieven en de hieruit resulterende verwachte kosten.

7. Kwaliteitsborging

Dit hoofdstuk geeft inzicht in de relatie tussen de voorgestelde maatregelen en de door de opdrachtgever gestelde eisen ten aanzien van de kwaliteit. Hiernaast worden maatregelen getroffen om onderkende risico's uit te sluiten of de gevolgen te minimaliseren, en de cruciale succesfactoren te beïnvloeden.

Als uitgangspunt worden de door de opdrachtgever gestelde kwaliteitseisen gehanteerd. Deze worden verbijzonderd naar de te stellen kwaliteitseisen per product. De voorgestelde maatregelen in het proces zijn een vertaling van deze vastgestelde productkwaliteitseisen.

Naast maatregelen in het proces om te voldoen aan de kwaliteitseisen per product worden additioneel maatregelen getroffen voor de kwaliteit van de tussenproducten of het proces zelf. Laatstgenoemde wordt ontleend aan ondermeer de vereiste kwaliteit van besturing of het minimaliseren van risico's.

Alle maatregelen zijn in het proces ingebouwd en zijn dus elders in het plan van aanpak opgenomen als activiteit, inrichtingsaspect of voorwaarde. Dit hoofdstuk geeft het totaaloverzicht van de invulling van het kwaliteitsaspect.

De paragrafen worden als volgt ingevuld:

• Productkwaliteit
  Eisen per product per kwaliteitsattribuut voorzien van weging en acceptatiecriteria. Relatie met de gestelde eisen aan, en acceptatiecriteria van, het projectresultaat
• Proceskwaliteit
  Eisen te stellen aan het proces. Voorbeelden hiervan zijn;
  - vakbekwaamheid
  - gebruik van (systeem)ontwikkelmethode
  - procedures
  - gebruik van methode voor projectmanagement;
  - uitbesteding en inkoop
  Controle achteraf is mogelijk door verificatie en validatie
• Voorgestelde maatregelen
  Maatregelen in het proces met per maatregel de relatie naar de eisen. Voorbeelden hiervan zijn:
  - opleidingsplan
  - gebruik van methode voor systeemontwikkeling
  - testplan
  - gebruik van Managing Projects als methode voor projectmanage-ment
  Maatregelen ter verificatie en validatie
  Voorbeelden hiervan zijn;
  - audits
  - reviews

Bovenstaande, mogelijk lange en droge opsomming van, relaties kunnen visueel meer inzichtelijk worden gemaakt door deze op te nemen in een matrix.

8. Overige plannen

In dit hoofdstuk worden alle plannen opgenomen die niet op tijd, geld en middelen zijn gericht. De invulling is afhankelijk van de projectbehoefte.

Voorbeelden:

• communicatieplan
• documentatieplan
• configuratiebeheerplan
• beveiligingsplan

9. Bijlagen

In dit hoofdstuk wordt verwezen naar de relevante standaards en projectprocedures. In het voorkomend geval zal verwezen worden naar reeds bestaande c.q. gebruikelijke bedrijfsstandaards. Voorwaarde is wel dat deze gedocumenteerd zijn.
In de bijlagen worden ook Begrippen en definities opgenomen om begripsverwarring te voorkomen. De begrippenlijst hoeft niet uitputtend te zijn, alleen de gehanteerde begrippen in het Plan van Aanpak komen hiervoor in aanmerking.

What Project Management Is

Project Management is a seatbelt.
Just like a seatbelt, a good set of Project Management practices and a good plan won't do much if you're caught in a catastrophic situation. For the minor fender-benders and even bigger problems, it will definitely assist, and potentially provide some safety measures and even an escape route or two.

Project Management is a sign of something more.
Going back to the seatbelt analogy, if you put on your seatbelt as soon as you get in the car, I *believe* (no quantitative data to back this up) that you are more likely to be a safer driver. If you habitually perform good project management practices, you will be more likely to detect problems early and have a response plan in place.

Project Management is required.
For any project that involves more than a few hours of effort, some sort of planning is needed. The planning required is directly proportional to the size of the project. If the project consists of writing a new report this afternoon, the "planning" might be 5-10 minutes to think about it. If the project is version of your system, the planning will involve more people and more time. If the project is a $170M system for a major government agency, the planning will involve representatives from numerous meeting repeatedly throughout the lifecycle of the project.

Project Management is about sharing information.
Personally, I don't care if you use a text file sitting out on a shared drive somewhere. There are better tools available, but the point of all of them boils down to making information available to the required people at the required time. It doesn't matter how great your tools are if the decision makers can't get at the information they need.

Project Management is purposeful.
At some point in every project, a decision will have to be made that others are not going to like. In order to have credibility for cutting features, requesting more resources (time, money, people, etc), or pushing back against requirements, the information needs to be available to state unequivicolly "If we do/don't do X, the project is going to suffer in area Y."

Project Management is ongoing.
von Moltke's dictum says that "No battle plan survives first contact with the enemy." Having a project plan a the beginning of the project is a first step, but it's not the last. Regular evaluation, adjustment, and sometimes even retreat is necessary.

I know that last point is a repeat from yesterday, but it bears repeating. Just because you have a pretty Gantt, PERT, or Critical Path diagram on the wall means precisely nothing. As soon as the project begins, there should an evaluation of your Estimates vs your Actuals. Maybe your estimation technique was off, maybe a supporting vendor moved faster/slower than you expected, or maybe a new product is replacing some of the planned work.

If you're not regularly reevaluating the plan, you're not managing... you're coasting.