project

Gebruik de 522 IT checklisten van ITpedia, met in totaal 22028 vragen.

Zoek in de omschrijvingenOmschrijvingAantal vragen
IT projectfaseringBestaat uit meerdere checklisten
Application Services Library (ASL)Bestaat uit meerdere checklisten
ContinuïteitBestaat uit meerdere checklisten
KwaliteitsattributenBestaat uit meerdere checklisten
Functies in de automatiseringBestaat uit meerdere checklisten
WebdesignBestaat uit meerdere checklisten
Of zoek naar een woord: Fulltekst

Laatst gebruikt: Rapportage acceptatietest op: 2017-02-25 17:12 Checklist
Toezenden van eerdere beoordelingen per e-mail.
E-mailadres:

De projectorganisatie: stuurgroep, projectgroep, werkgroep

De fase Informatie Analyse aan het begin van een project is de belangrijkste fase. Veel gebruikers beseffen dit echter niet omdat de opleverdatum nog ver weg is en er slechts enkele personen met de Informatie Analyse bezig zijn die voornamelijk lastige vragen stellen. Tenslotte komen van deze personen allerlei fraaie documenten over zaken die de […]

Opdrachtgeverschap met programma’s en projecten

De conclusies die de Rekenkamer trok in haar rapport “Lessen uit ICT-projecten bij de overheid” waren niet mals. Volgens de Rekenkamer zouden de ministers hun verschillende rollen (o.a. bestuurlijk verantwoordelijk voor de uitvoering, ambtelijk opdrachtgever) beter kunnen invullen wanneer zij meer realistisch zouden zijn in hun ambities en wanneer zij meer grip zouden houden op […]

Het plan van aanpak, een hele klus

Hoe groot of hoe klein maak je een plan van aanpak? Welke onderdelen neem je er in op en welke niet? Het hangt af van de aard en de omvang van een project. In deze bijdrage wordt een uitgebreid concept voor een plan van aanpak beschreven. Haal er uit wat je nodig hebt, maar beter is het om alle elementen te beschrijven zodat men weet dat er rekening is gehouden met deze elementen. Ook als je besluit om een onderdeel niet in te vullen beschrijf je dus waarom je het niet invult.  [Klik op de titel voor het gehele artikel]

Wat is een audit, wat is een review?

Audits en Reviews lijken in vele opzichten op elkaar en worden vaak met elkaar verward. Beide zijn het activiteiten om de kwaliteit van automatiseringsproducten vast te stellen en beide vinden ze onafhankelijk van het eigenlijke maak-proces plaats. Er zijn echter een aantal belangrijke verschillen.  [Klik op de titel voor het gehele artikel]

Van Wim Hoogenraad op 23 januari 2011 | Definities, Organisatie | Aanvullen?
Tags:, , , ,
Checklisten: 8

Mapping IT-procedures over projectfasering

De IT-procedures zijn gericht op fysieke handelingen met IT-objecten. Daarbij moet bijvoorbeeld worden gedacht aan het inrichten van een werkplek, de installatie van een module of het toekennen van een autorisatie. M.b.v. deze procedures kunnen ook series worden verwerkt, doch altijd series van gelijksoortige objecten.
Projecten daarentegen bestaan uit meerdere fases waarin d.m.v. verschillende activiteiten naar een bepaald einddoel wordt gewerkt. Dit einddoel is in veelgevallen een samengesteld geheel van infrastructurele objecten, software en AO. Tijdens het project wordt dit geheel opgebouwd en is het noodzakelijk om planmatig IT-procedures te triggeren om dit te bewerkstelligen. [Klik op de titel voor het gehele artikel]

Van Wim Hoogenraad op 14 januari 2011 | Adviezen, Organisatie | Aanvullen?
Tags:, ,
Checklisten: 4

Minimale taakverdeling bij Automatiseringsprojecten is essentieel.

Automatiseringsprojecten wijken niet af van andere project. Specifiek is wel dat deze zich afspelen op een snijvlak van complexe techniek, wisselende prioriteiten en formele procedures. De ervaring leert dat het vele malen effectiever is om in een vroeg stadium duidelijkheid te hebben, op basis waarvan alle partijen zich kunnen binden, dan om dit te doen nadat er al veel is geïnvesteerd in een project. [Klik op de titel voor het gehele artikel]

Randvoorwaarden voor het uitvoeren van projecten

Voor de succesvolle afronding van projecten spelen vele aspecten een rol. Een goede start is echter van het grootste belang omdat eenmaal verkeerd begonnen projecten maar moeilijk weer op het goede spoor komen. Als bepaalde zaken onduidelijk zijn en blijven zweven kan een project verzanden in discussies en tot hoge kosten leiden. Randvoorwaarden kunnen dus ook worden gezien als kritische succesfactoren die bepalend zijn voor het slagen van een project. Probleem hierbij is dat de invulling van de randvoorwaarden niet voor ieder project hetzelfde is maar van project tot project kan verschillen. Voor de aanvang van een project dient de invulling van randvoorwaarden in de opdracht te worden beschreven zodat deze deel uitmaken van het project. Van belang is dat een project pas wordt gestart nadat de randvoorwaarden zijn ingevuld. [Klik op de titel voor het gehele artikel]

Van Wim Hoogenraad op 5 januari 2011 | Adviezen, Best practices, Organisatie | Aanvullen?
Tags:,
Checklisten: 3

Waarom slagen projecten?

Project organisatieIn de wereld van de ICT is het nu eenmaal zo dat veel projecten mislukken. Er worden cijfers genoemd van 75 tot 90%! In iedergeval vele malen vaker dan bijvoorbeeld in de bouw. Alleen al om die reden lijkt het me niet leuk om in de ICT te werken. Als argument wordt vaak gebruikt dat men in de bouw al duizenden jaren ervaring heeft en in de ICT hooguit 50. Een project kost veel geld en iedereen wil graag weten waarom het fout is gegaan, al was het maar om die fouten de volgende keer niet meer te maken. Zulke evaluaties geven een gemixed beeld en de vraag is of wel de juiste conclusies worden getrokken. Evalueren lijkt immers op het Zwarte Pieten spel. Hij die als laatste de Zwarte Piet heeft is de dader cq het slachtoffer.

Omdat er maar 10-25% van de projecten slaagt is het misschien slim om het eens om te draaien en te kijken waarom die projecten dan wel slagen. Het Zwarte Pieten spel wordt daarbij sowieso minder hard gespeeld zodat de waarheid beter in beeld komt.

Hoeveel analyse hebben we nodig? Als je op je gevoel afgaat weet je het eigenlijk al. Er is maar één reden waarom projecten slagen en dat is omdat ze moeten slagen.

Voorbeelden:

– Deze server loopt op zijn laatste benen en moet dit weekend worden vervangen.
– De nieuwe regelgeving wordt per 1 januari ingevoerd! De nieuwe website moet voor die tijd werken!
– De concurrentie bedreigt ons voorbestaan, we moeten dat ERP pakket invoeren om te overleven!
– Het systeem moet draaien omdat bij down gaan het voorbestaan van de onderneming op het spel komt te staan.

Opvallend bij dit soort projecten is de aanleiding. Er is geen vage reden en dus ook geen vaag doel. Het project is doelgericht en afwijken van dat doel is dodelijk voor de organisatie. Aan het einde van de dag zitten er alleen maar  Zwarte Piet kaarten in het spel dus iedereen moet zijn bijdrage leveren om te voorkomen dat het spel uberhaupt gespeeld gaat worden.

Deze projecten slagen meestal wel. We hebben het hier dan ook niet over businesscases maar over keiharde noodzaak. Bij een businesscase project worden de planning, de kosten of de baten niet altijd even realistisch gepresenteerd  omdat men een project graag wil binnenhalen. Gaande het project komen er verborgen kosten bovendrijven. In het begin verwacht men deze later in het project nog wel terug te verdienen maar dat gebeurt natuurlijk niet. Op dat moment komt het Zwarte Pieten spel al uit de tas en dekt men zich in en gaat men duikgedrag te vertonen. Het project is feitelijk al mislukt voordat aan de realisatie is begonnen.

Belangrijk verschil tussen een businesscase project en een moet-project zit in vaagheid tegenover concreetheid.

Tijdig bijsturen van de projectplanning

Welke redenen (=vaagheden) worden er voor het mislukken van projecten genoemd en hoe worden die in een succesvol project getackeld?

– Angst voor veranderingen
“Aanpassen aan veranderende omstandigheden is de enige manier om te overleven”. (Darwin). Angst is een slechte raadgever. We hebben geen keuze, veranderen moet om te overleven. Benoem de angst en maak de veranderingen concreet.

– Onduidelijk opdrachtgeversschap
Dit komt bij een moet-project nauwelijks voor. Als het imago of voorbestaan van de organisatie van het project afhangt zal het management als opdrachtgever optreden. Dat zal er boven op zitten en geregeld om een rapportage vragen als die niet snel genoeg vanzelf komen. Zorg voor een concrete opdrachtgever.

– Is er onvoldoende commitment van de opdrachtgever
Tweederde van de projectleiders van een businesscase project krijgt geen structurele ondersteuning van de opdrachtgever. Leeft de opdrachtgever soms in een sprookjeswereld? Zijn organisatie staat op het spel. Het is de plicht van de projectleider om hem daar op te wijzen. Als de PL dan nog geen commitment krijgt moet hij het bij andere stakeholders gaan halen. Het project moet slagen! Zorg voor concreet commitment voor het project van de opdrachtgever.

– De bestaande procedures van de organisatie worden niet gevolgd
Er zijn altijd managers die de formele besluitvormings-, plannings-, prioriterings- en uitvoeringsprocessen proberen te omzeilen. Niet toegestaan. Waar zijn ze mee bezig! Wie denkt er nog aan eigen belang? Alles moet ondergeschikt worden gesteld aan het slagen van het project. Maak duidelijk volgens welke procedures het project verloopt, zorg voor een concrete inbedding in de organisatie.

– De planning is niet op harde feiten gebaseerd.
Bij de meeste businesscase projecten is dat het geval. Deadlines, doelstellingen en budgetten worden namelijk vaak onder politieke druk te positief ingeschat. Zodra de projectleider van een moet-project merkt dat de planning niet realistisch zal hij direct aan de bel trekken. De organisatie staat immers op het spel. Binnen de kortste keren zal er een realistische planning met een realistisch budget zijn. Zorg concreet voor een realistische planning en budget.

– Voortgang en risico’s worden niet eerlijk gerapporteerd.
Problemen en risico’s worden vaak genegeerd, gebagatelliseerd of verzwegen. In een moet-project moet je openkaart spelen. De opdrachtgever moet weten waar hij aan toe is om tijdig bij te kunnen sturen. Zorg voor een eerlijke concrete rapportage en concrete rapportage lijnen.

– De projectorganisatie is te groot.
Te grote projecten met meerdere teams en verschillende subdoelen worden op den duur onbestuurbaar. Het recept voor mislukking. Stel je ambities bij, concentreer je op dat ene doel en gooi de rest van de ballast overboord. Zorg voor een bestuurbare projectorganisatie.

– Niet alle projectteamleden doen voldoende hun best.
Projectleiders krijgen geregeld te maken met teamleden die niet komen opdagen op vergaderingen, zich niet aan planningen houden of niet competent genoeg zijn om het doel te realiseren. Gelijk vervangen. Het kan niet zo zijn dat een moet-project gefrustreerd wordt door teamleden. Het is er op of er onder! Zorg voor een ge-olied en sterk projectteam met de juiste specialisten.

– Er wordt slecht gecommuniceerd.
Wel of niet goed communiceren maakt in een moet-project weinig uit. Het project moet sowieso doorgaan. Met een goede communicatie is wel een wereld te winnen en helpt het project natuurlijk enorm. Een project verloopt een stuk soepeler als er voldoende wordt gecommuniceerd. Zorg voor een heldere en juiste communicatie.

Zodra de projectleider één van deze problemen tegenkomt moet hij direct en concreet bijsturen. Door deze regels ook bij businesscase projecten toe te passen zouden veel meer projecten slagen. Als je het zo bekijkt is het toch allemaal niet zo moeilijk om een project te laten slagen….


-- Printbare PDF-versie --