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: Aanpak Customer Organization Strategy op: 2016-11-23 14:13 Checklist
Toezenden van eerdere beoordelingen per e-mail.
E-mailadres:

SISP 1.2 Het Projectplan

sisp

Inleiding projectplan Het belangrijkste mijlpaalproduct van fase SISp1 is het Projectplan. In het vervolg van de methode worden per fase ook plannen gemaakt maar het projectplan is duidelijk anders van aard. In het Projectplan worden belangrijke zaken vastgelegd en fungeert als contract voor de loop van het project. Zaken die vastgelegd worden zijn: * De […]

SISP 1.1 Inrichten projectmanagement

sisp

Inleiding Projectmanagement Om een selectie en implementatie project succesvol te laten verlopen is het belangrijk dat het er een projectteam wordt samengesteld, een duidelijk doel wordt omschreven en een werkwijze wordt beschreven. Een project wordt hiermee beheersbaar en inzichtelijk. De SISp methode gaat ervan uit dat er projectmatig wordt gewerkt. In de eerste fase wordt […]

SISP 0.8 Volwassenheid van de organisatie.

sisp

Het is zinvol om voor het starten van een SISp project vast te stellen of de organisatie dit project wel aankan. Dit doen we met behulp van een self-assessment. Als iedere betrokkene de assessment invult en vervolgens over de antwoorden discussieert kan worden vastgesteld welk volwassenheidsniveau de organisatie per fase heeft. Daar waar de tekorten […]

Van Wim Hoogenraad op 1 november 2016 | Best practices, Methoden | Aanvullen?
Tags:,
Checklisten: Geen

Beveiliging elektronische informatie-uitwisseling met derden

filetransfer

1. Inleiding Hieronder een voorbeeld van een kader voor de beveiliging van elektronische informatie uitwisseling. In het Beleidsdocument Informatiebeveiliging wordt duidelijk welk belang van de gegevensuitwisseling met derden wordt onderkend. Informatiebeveiliging is daarom niet meer een zaak die zich beperkt tot de eigen interne bedrijfsprocessen maar zich steeds meer uitstrekt over de grenzen van de […]

SISP 0.7 SISP fasering

sisp

Het selecteren en implementeren van een standaard software pakket gebeurt in een aantal stappen, ook wel fases genoemd. Iedere fase levert een resultaat op dat beoordeelt kan worden en bepalend is voor de uitvoering van de volgende fase. Omdat deze fases na elkaar worden uitgevoerd wordt dit ook wel een watervalmethode genoemd. In deze methode […]

SISP 0.6 Projectstart, ICT-Strategie en project opdracht

sisp

Aanleiding voor een project Voor het starten van een project is er altijd een aanleiding. Goede aanleidingen zijn: – Groei van de organisatie vraagt om meer functionaliteit en capaciteit. – De organisatie fuseert. – Het aantal bedrijfsprocessen neemt toe. – De bedrijfsprocessen worden complexer. – De huidige oplossing mist functionaliteit en rapportage mogelijkheden. – De […]

SISP 0.5 Suite of Best of Breed

sisp

In de markt zijn standaard software pakketten in allerlei soorten en mate te verkrijgen. Dit maakt het vaak lastig om tot een goede selectie van het juiste pakket te komen. Belangrijk onderscheid tussen de verschillende pakketten is de Suite of de Best of Breed oplossing. Suite Bij een suite is sprake van een bundeling van […]

SISP 0.4 Definitie Standaard Software Pakket

sisp

Definitie Er zijn een aantal criteria waaraan software moet voldoen om het label standaard software te kunnen krijgen. Een meeste staan vast en over een kleiner aantal valt te discussiëren. In deze reeks richten we ons op standaard software die voldoet aan de volgende kenmerken: 1. Software die meerdere gebruikersorganisaties kent. 2. Gebruikers hebben geen of […]

SISP Methode voor standaardsoftware

sisp

Ondanks de enorme hoeveelheid standaardsoftware is er geen methode voor het invoeren van een standaard pakket. Bij het inzetten van standaard software in de organisatie komen heel andere uitdagingen kijken dan bij het ontwikkelen van maatwerk software. De methoden die gebruikt worden voor het ontwikkelen van maatwerk zijn dan ook niet geschikt voor het selecteren […]

Van Wim Hoogenraad op 4 oktober 2016 | Methoden | Aanvullen?
Tags:,
Checklisten: Geen

SISP 0.3 Voor- en nadelen van standaard software

sisp

Voordelen standaard software Een belangrijke reden om standaard software te kopen en te gebruiken is het drukken van de kosten. * Standaard software is relatief goedkoper dan maatwerk. Het scheelt immers 50% van de kosten als je samen een pakket laat maken ten opzicht van het zelf laten maken. Als je met z’n vieren bent […]

SISP 0.2 Ontwikkelmethoden standaard software

sisp

Waterval methoden Bij waterval methoden wordt per project systematisch een aantal vaste stappen achtereenvolgens doorlopen (bijvoorbeeld; analyse, ontwerp, bouw, testen, trainen, implementeren). Je moet als het ware voordat het eerste stukje code geschreven wordt al precies weten hoe het eindresultaat met alle details eruit komt te zien. Nadeel van deze methode is dat er weinig […]

SISP 0.1 Geschiedenis ontwikkeling van standaard software

sisp

In de beginjaren van de ICT, de jaren 1950, 1960 bestond er nog geen standaard software. Binnen organisaties die in het bezit waren van een computer werden applicaties ontwikkeld door programmeurs die in dienst van die organisatie. – Deze software was precies toegesneden op de wensen van die organisatie. Zogenaamde maatwerk software. Het zorgt ervoor […]

Definities en kenmerken van Cloud

Definitie van cloud Cloud is een verzamelnaam voor technieken die een zekere mate van gemeenschappelijk gebruik van I of IT, geredeneerd vanuit het perspectief van de individuele eindgebruiker, ondersteunen. Strikt genomen is de techniek dan ook niet zo nieuw – het gebruik van een gemeenschappelijke printer of schijf valt ook al onder de definitie. Verschillende […]

Van administrator op 7 augustus 2015 | Achtergronden, Definities | Aanvullen?
Tags:
Checklisten: 2

Governance op IT-dienstverlening uit de cloud

asl-bisl

Beheersing van Informatie Voorziening uit de wolk Door Lex Scholten en Frank van Outvorst Gepubliceerd in Keynotes 04, winter 2013 (Uitgeverij TIEM, Baarn) onder de titel: “Cloud verandert de regiefunctie”. Door toenemende complexiteit van bedrijfsprocessen, globalisering, ketensamenwerking, maar ook door de groeiende klantverwachtingen, worden organisaties steeds meer afhankelijk van informatie. Het thema “regie op informatievoorziening” […]

Van administrator op 4 augustus 2015 | Discussies, Methoden | Aanvullen?
Tags:, , ,
Checklisten: 2

Achtergronden
Adviezen
Analyses
Best practices
Definities
Discussies
ITpedia
Juridisch

1.3 Activiteiten inrichten projectmanagement

sispIedere fase binnen de SISp methode bestaat uit een aantal activiteiten. De fase Inrichten projectmanagement bevat de volgende activiteiten.

Activiteit 1: De projectinitiatie

Tijdens de projectinitiatie komen een aantal onderwerpen aan de orde die later onderdeel worden van het projectplan. De initiatie wordt door de opdrachtgever in samenwerking met de projectleider uitgevoerd. Deze worden eventueel bijgestaan door enkele sleutelfiguren en/of materiedeskundigen. De volgende onderdelen worden vastgesteld:
* Aanstellen van de projectleider en vaststellen van zijn verantwoordelijkheden
* De projectleider wordt definitief aangewezen en er wordt vastgelegd hoe ver hij met het nemen van projectbeslissingen kan gaan.
* De opdracht en de afbakening van het project worden bepaald.
Deze beslissingen zijn bepalend voor de omgang en de personele bezetting van het project. De doelstellingen moeten aan het eind van de initiatie vastliggen.
* De projectorganisatie wordt bepaald
* Bepaald wordt wat voor structuur het project krijgt en welke teams moeten worden samengesteld.
* Opstellen van een lijst met projectaannames

Alle betrokken dienen op de hoogte te zijn van de belangrijkste aannames die gelden voor het project. Bekende aannames zijn de uitgangspunten en randvoorwaarden. Vaak wordt er al uitgegaan van een ICT-platform of een standaard interface met leveranciers en klanten. Het wijzigen van de aannames tijdens het project kan leiden tot grote gevolgen voor de planning en de kosten.

Opstellen van lijst met succesfactoren
Iedere betrokkene moet weten welke factoren het project tot een succes maken. Een aantal algemene succes factoren zijn;
– betrokkenheid van de gebruikersorganisatie
– betrokkenheid van het management
– competente projectleden
– heldere communicatie
Verder zijn er in ieder project specifieke succesfactoren te bedenken, die gelden voor die organisatie. Bijvoorbeeld. Hoe zal het  software pakket bijdragen aan de business van de organisatie? De lijst met succesfactoren wordt met de opdrachtgever afgestemd.
Het project wordt een duidelijke herkenbare naam gegeven.
Als er over het project wordt gesproken weet iedereen welk project er wordt bedoeld.

De basis leggen voor het communicatieplan
Definieer een communicatiedoelstelling en bepaal wat de betrokken partijen zijn, wat hun behoefte is, hoe ze benaderd moeten worden en welke beschikbare middelen hebben we hiervoor hebben. Vanuit deze basis kan het communicatieteam  verder.

Activiteit 2: Projectorganisatie, het selecteren van de juiste medewerkers

Na de projectinitiatie gaat de projectleider aan de slag om de projectgroep te formeren. Vanuit de projectinitiatie weet hij eveneens welke andere teams samengesteld moeten worden. De teams die gelijk aan de slag gaan moeten het eerst worden samengesteld, de andere teams kunnen alvast worden benoemd. Deze teams komen dan nog niet bij elkaar maar krijgen wel de stukken zodat zij zich een oordeel kunnen vormen over hun toekomstige bijdrage. Als daar behoefte aan is staat het hen vrij om ook in een eerder stadium bijeen te komen.
Binnen deze activiteit kan worden bepaald wat de vergader frequentie moet zijn.
* Opdrachtgeversgroep.
De SISp-opdrachtgeversgroep komt iedere maand bij elkaar en bemoeit zich alleen met de grote lijnen. De stukken die daar op tafel komen gaan over de voortgang, de besteding van het budget en de eventuele knelpunten.

* Projectgroep.
Binnen de projectgroep worden alle mijlpaalproducten besproken en beoordeeld. Afhankelijk van de fase kan de vergaderfrequentie variëren.

Juiste mensen
Een verkeerde samenstelling van een team kan veel leed veroorzaken voor een project. Daarom is het belangrijk om zorgvuldig te selecteren. Om te beginnen kan aan de afdelingsmanagers die in de projectgroep zitten worden gevraagd om medewerkers voor het project vrij te stellen. Zij moeten bereid zijn om hun beste mensen te leveren. Alle taken die in de projectinitiatie zijn gedefinieerd moeten aan medewerkers worden toegewezen. Als blijkt dat de gevraagde capaciteit niet vanuit de organisatie zelf kan worden geleverd, zal deze ingehuurd moeten worden.

Vragen bij samenstellen team
Bij het samenstellen van de teams moet de projectleider met de volgende vragen rekening houden:
=> Zijn alle, volgens de projectinitiatie benodigde bekwaamheden binnen de organisatie te vinden?
=> Is bij de selectie van medewerkers rekening gehouden met de bekwaamheden van deze medewerkers?
=> Bevat het project voldoende elementen om de vaardigheden van de medewerkers tot hun recht te laten komen?
=> Is bij de indeling van de medewerkers rekening gehouden met de beschikbaarheid van deze medewerkers?
=> Is er bij de medewerkers voldoende motivatie om de geplande producten op tijd op te leveren?
=> Is de afdelingsmanager duidelijk gemaakt hoeveel tijd zijn medewerkers aan het project moeten besteden?
=> Worden in de huidige fase medewerkers ingezet die waarschijnlijk ook in latere fases gaan deelnemen?
=> Is het aantal geselecteerde medewerkers zo klein mogelijk?

Activiteit 3: Projectplanning: Schatten van kosten en doorlooptijd.

In SISp1 wordt ingeschat hoeveel uren werk de komende fases bij benadering in beslag gaan nemen. Daarbij wordt rekening gehouden met de uren die nodig zijn voor het maken van documentatie, rapportages en projectleiding. De tijd die nodig is voor projectleiding hangt af van de ervaring van de projectmedewerkers en de mate waarin SISp wordt gevolgd. Als SISp strak wordt gevolgd door ervaren medewerkers is minder aangsturing nodig. 10 tot 20 procent van de tijd moet worden gereserveerd voor de projectleiding.

Gevoel voor kosten
Het schatten gebeurt in meer dan 90% van de projecten op basis van ervaring en gevoel. Omdat nog niet duidelijk is wat de echte omvang van de in te voeren software is kunnen er geen definitieve antwoorden gegeven worden op de kosten en doorlooptijden hiervan.
Bedenk echter het volgende:
=> Als de het projectplan met de schatting eenmaal geaccepteerd is, wordt de tijdschatting ineens een deadline. Communiceer helder over de betrekkelijkheid van de planning.
=> Na fase 3, als het gekozen pakket duidelijk is, zal de planning en het budget bijgesteld worden.
=> Aan het eind van het project is de schatting een maatstaf waarop het projectteam afgerekend zal worden.

Globale functionaliteit
De functionaliteit van een softwarepakket is in dit stadium nog niet concreet, ook niet voor de opdrachtgever. De organisatie heeft behoefte aan een softwarepakket dat een bedrijfsproces moet ondersteunen. Hoe dit softwarepakket er precies uitziet is nog niet helemaal duidelijk.
De definitie van de functionaliteiten die de software moet ondersteunen wordt pas in de volgende fases gemaakt. Toch moeten de functionaliteiten van het softwarepakket in zekere mate duidelijk zijn bij de start van een project. Zodoende kan ook worden nagezocht wat zulke pakketten ongeveer kosten.

Andere bronnen
Om enigszins een richtingsgevoel te krijgen, kan informatie worden verzameld uit verschillende bronnen.
=> Eerdere ervaringen van de medewerkers binnen de organisatie.
=> Ervaringen van collega organisaties van een vergelijkbare omvang die een soortgelijk pakket hebben ingevoerd.
=> Benchmark gegevens.
=> Publicaties in vakliteratuur en internet.

Licentie kosten
Voor het bepalen van de licentiekosten moet meestal worden bepaald hoeveel gebruikers van het pakket gebruik gaan maken.
=> Concurrent users.
=> Named users.

Nauwkeurigere schatting
Voor projecten die in deze globale schatting boven de 200.000 euro of de geldende aanbestedingsgrens komen moet de Driepunten techniek worden ingezet voor een meer nauwkeurige schatting. Dit is nodig in verband met een meer nauwkeurige berekening van de projectrisico’s.

Activiteit 4: Risico analyse

Een belangrijk onderdeel van het werk van de projectgroep is het beheersen van de projectrisico’s. De projectgroep voert daarom een risicoanalyse uit. Risicobeheersing heeft als doel het opsporen van risico’s die het project bedreigen en deze vervolgens beheersen. Het is niet nodig om alle risico’s te elimineren. Dat zal waarschijnlijk te veel geld en inspanning kosten.
Als blijkt dat het project grote risico’s met zich meebrengt moet worden getwijfeld aan de haalbaarheid van het project. Mogelijk moeten de projectdoelstellingen worden bijgesteld.

Berekenen risico

Risico = de Kans dat een dreiging zich voordoet maal de Schade die dat tot gevolg heeft,
R = K * S
Een kleine kans met veel schade levert een laag risico op (evenals een grote kans op een kleine schade). Een grote kans gecombineerd met een hoge schade zal een groot risico vormen voor het project.

Risico’s van gehele project overzien
Een projectleider moet zich vanaf het begin van het project bewust zijn van de risico’s van het gehele project en zich niet beperken tot SISp1. Naarmate het project vordert nemen de risico’s voor het project af. Iedere fase kent echter zijn specifieke risico’s.
Risicobeheersing houdt dus in dat de risico’s die het project bedreigen onderkent worden en het nemen van maatregelen op deze risico’s.

Acties op risico’s
Er zijn vijf soorten acties die ondernomen kunnen worden met betrekking tot de risico’s: acceptatie, preventie, reductie, overdracht en escalatie. Een klein risico kan gemakkelijk geaccepteerd worden. Een groot risico moet aan de opdrachtgever worden voorgelegd. Kan het project wel doorgaan?
Als de projectbegroting lager is dan 200.000 kan worden volstaan met een lijst van risico’s en maatregelen. Bij grotere projecten is het noodzakelijk om het risico beter te berekenen. Deze rekenmethode wordt uitgewerkt in de verdiepende module “Plannen, begroten en risicoanalyse”.
Veel voorkomende projectrisico’s zijn:
• Geen duidelijke opdrachtgever
• Geen goede projectleider
• Een onduidelijk doel, onduidelijke afbakening
• Geen goed projectplan
• Niet alle competenties zijn in de projectgroep aanwezig
• Tijdens het project verandert het doel
• Het nieuwe pakket blijkt achteraf niet in de behoefte te voorzien
• Leveranciers die niet op tijd leveren
• Overschrijding van de kosten en looptijd schattingen
• Onvoldoende tijd om de mijlpaalproducten te maken leidt tot kwaliteitsverlies
• Onvoldoende tijd om de mijlpaalproducten te controleren leidt tot kwaliteitsverlies
• De beslisstructuur binnen het project is te complex
• Onvoldoende betrokkenheid van de ICT afdeling
• Onvoldoende betrokkenheid van de gebruikersorganisatie
• Bedreigingen van buitenaf zijn niet onderkend

Specifieke risico’s
Ieder project kent zijn eigen specifieke risico’s. Voor al deze risico’s dient een analyse te worden gemaakt. Het complete beeld van de risico’s is namelijk bepaald voor de haalbaarheid van het project. Het is te hopen dat de kans op alle risico’s klein is want de schade kan enorm zijn.
De risico’s nemen toe naarmate meerdere projecten die elkaar raken tegelijkertijd lopen.

Activiteit 5: Samenstellen projectplan

Nadat de activiteiten 1 tot en met 4 zijn afgerond kan de projectleider het projectplan maken. Alle producten uit de eerdere activiteiten worden in het plan opgenomen.

Activiteit 6: Validatie projectplan

Laat het projectplan reviewen door meerdere betrokkenen. Het gaat hier niet alleen om de opdrachtgever maar ook om de projectgroep en de materiedeskundigen. Iedereen kijkt er naar vanuit een eigen perspectief. Zodoende kunnen er soms verrassende opmerkingen komen waar de anderen helemaal niet aangedacht hebben.
Het valideren van het projectplan vindt plaats vanuit 3 verschillende perspectieven.

Inhoudelijke validatie
In de eerste plaats is dat natuurlijk inhoudelijk.
– kloppen de bedragen,
– kloppen de namen,
– kloppen de datums,
– klopt de planning,
– zijn alle risico’s benoemd,
– is de fasering juist,
– is de afbakening van het project juist,
– zijn alle bedrijfsprocessen die gekoppeld worden benoemd.
– kan een Go-nogo beslissing worden gemaakt op basis van het plan.

Validatie opzet
In de tweede plaats wordt er gekeken naar de opzet van het plan.
– kloppen de paginanummers,
– klopt de inhoudsopgave,
– kloppen de verwijzigen,
– zijn de schema’s goed leesbaar,
– klopt de huisstijl,
– is het taalgebruik foutloos

Procedurele validatie
Ten derde moet worden gekeken naar de procedurele aspecten:
– is de validatietermijn duidelijk,
– zijn de reviewers benoemd,
– is de routing van het document aangegeven

sisp1activiteiten


-- Printbare PDF-versie --