archive-nl.com » NL » I » ITPEDIA.NL

Total: 523

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Besturen van een project | Welkom op ITpedia
    hun product had het personeel het gevoel dat ze van hot naar her moesten rennen om het werk gedaan te krijgen Het personeel wilde dat er meer mensen werden aangenomen Het management was daar uit kostenoverwegingen huiverig voor en voerde druk uit op het personeel om harder te werken Maar hoeveel werk kan een team aan Deze vraag bleek niet goed te beantwoorden omdat er in deze organisatie geen tijd werd geschreven Als een nieuw project werd gestart was er wel een schatting gemaakt van de hoeveelheid uren die men dacht nodig te hebben maar nooit werd er tijdens en na het project gecontroleerd of bij de uitvoering van het project daadwerkelijk zoveel uren nodig waren Projectleiders werden wel aangespoord projecten goed in de hand te houden De projectleiders protesteerden dat ze zonder urenregistratie geen grip hadden op de projecten Ze hadden namelijk geen inzicht in de hoeveelheid verbruikte uren bij het uitvoeren van de taken van een project en dan kon er van bijsturen natuurlijk al helemaal geen sprake zijn Een projectleider besloot om met zijn team de uren te gaan registreren Het project bleek uiteindelijk vier keer zoveel uren nodig te hebben dan oorspronkelijk begroot Na eerst de projectleider op zijn kop te geven dat het project zo veel was uitgelopen besloot het management toch maar een urenregistratie in te voeren Na enige maanden werden knelpunten zichtbaar Bijna alle projecten bleken veel te krap begroot Personeel dat voor 100 uren op een project stond bleek in de praktijk vaak wel tot drie keer zoveel uren te moeten werken aan het project De transparantie bracht nieuwe dilemma s Aan de ene kant werd er gesteld dat er inderdaad te weinig personeel was om de projecten goed uit te voeren Er zou dus meer personeel nodig zijn De kosten van voldoende personeel waren aanzienlijk Aan de andere kant kon je ook stellen dat projecten veel te goedkoop voor te weinig uren werden verkocht aan klanten Het management was echter bang geen opdrachten binnen te halen als ze meer uren zouden offreren Geld De geldfactor uit zich in de budgetten van projecten Het beheersen van geld binnen een project is ervoor zorgen dat de kosten binnen de begroting blijven Aangezien in de meeste projecten de kosten voor het overgrote deel bestaan uit arbeidskosten zijn de factoren geld en tijd hoeveelheid arbeidsuren sterk verweven Geld in projectplannen nagaan wat de tarieven zijn van de teamleden uren teamleden begroten budgetten aan teamleden toekennen voor bepaalde taken materiaal en materieelkosten bepalen Geld in voortgangsbewaking geldstromen bewaken onderhandelen met leveranciers nagaan of de oorspronkelijke kosteninschattingen nog kloppen budgetten bijstellen onderhandelen met klant en of opdrachtgever over bijstellingen budget Geld in de projectverantwoording financiële rapportage en verantwoording opstellen analyse definitieve financiële rapportage Kwaliteit Het projectresultaat zal aan bepaalde kwaliteitseisen moeten voldoen Dat geldt dan ook automatisch voor de diverse tussenproducten van het project Voor het sturen van het project is het met name van belang dat kwaliteitseisen in de definitiefase bepaald afgesproken en opgeschreven worden Voorkomen

    Original URL path: http://www.itpedia.nl/2012/01/09/besturen-van-een-project/ (2014-12-07)
    Open archived version from archive


  • Mislukken door falende opdrachtgevers | Welkom op ITpedia
    de networked economy begrijpen 5 december 2014 ICTWaarborg stelt inkoopvoorwaarden ICT bedrijven op 5 december 2014 Fujitsu ontwikkelt slimme kleine krachtige RFID tag 5 december 2014 IBM hokt nu ook met Docker 5 december 2014 Exchange Server patch alsnog onderdeel Patch Tuesday 5 december 2014 Google project Loon blijkt hoogvlieger 5 december 2014 Sinterklaas koopt veel meer online 5 december 2014 Sonylek gegevens 47 000 werknemers les voor elk bedrijf 5 december 2014 Toegang Inloggen RSS Feed Aanvullingen RSS Mislukken door falende opdrachtgevers Een goede invulling van de rol van opdrachtgever blijkt in toenemende mate bepalend te zijn voor het succesvol uitvoeren van een ict project Maar wat wordt verstaan onder opdrachtgeverschap en welke onderwerpen zijn van belang om het opdrachtgeverschap op een goede manier uit te voeren Falend opdrachtgeverschap is een veelvoorkomende oorzaak van het mislukken van ict projecten De opdrachtgever formuleert zijn vraag ongelukkig de ict leverancier denkt de vraag te begrijpen en blijft in gebreke en de ict opdrachtgever doorziet dat niet Binnen de kortste keren hebben beide partijen een compromitterende hoeveelheid boter op hun hoofd zodat juridische maatregelen bij voorbaat heilloos zijn en het verlies van beide partijen slechts bezegelen Een andere belangrijke reden voor het falen van projecten is dat het schatten van kosten doorlooptijd en risico s van ict projecten nog steeds erg moeilijk is De opdrachtnemer kan of wil geen goede inschattingen afgeven of inschattingen dekken slechts een deel van de werkelijke kosten af De opdrachtgever kan of wil deze inschattingen niet op waarde beoordelen Bovendien blijkt vaak dat de opdrachtgever ambitieuzere plannen heeft dan hij oorspronkelijk heeft gecommuniceerd en verzuimt de opdrachtnemer om de verwachtingen te managen De voornaamste kritiek op de opdrachtgever is dat deze bij het formuleren van zijn eisen onvoldoende concreet is de voornaamste kritiek op de opdrachtnemer is dat deze onvoldoende communiceert met de opdrachtgever De opdrachtnemer lijkt te snel tevreden met de opdracht ook al is deze niet goed geformuleerd Maar het probleem begint en eindigt bij de opdrachtgever die onvoldoende geëquipeerd is om doelen prioriteiten en vragen te stellen en om vervolgens de aanbiedingen oplossingen en antwoorden op waarde te schatten Wat maakt een ict opdrachtgever tot een goede ict opdrachtgever De kern van ict opdrachtgeverschap is als volgt te definiëren het richting geven aansturen en bewaken van de ict activiteiten van een organisatie en het onderhouden van de relatie met leveranciers De drie hoofdonderwerpen van ict opdrachtgeverschap zijn derhalve de strategiebepaling voor het uitbesteden van activiteiten het regisseren en bewaken van de uitvoering van deze activiteiten en het managen van de relatie tussen opdrachtgever en opdrachtnemer Strategie Een onderdeel van goed opdrachtgeverschap is het bepalen van een sourcingstrategie die tot doel heeft om de opdrachtgever te laten bepalen wat zijn rol is welke taken hij eventueel uitbesteedt de wijze waarop hij opdrachtnemers aanstuurt en hoe hij voorkomt te worden overgeleverd aan techniek of leverancier In de sourcingstrategie worden de kernactiviteiten van de organisatie bepaald er wordt vastgesteld welke activiteiten uitbesteed kunnen worden en hoe regie

    Original URL path: http://www.itpedia.nl/2011/12/05/mislukken-door-falende-opdrachtgevers/ (2014-12-07)
    Open archived version from archive

  • Opdrachtgeverschap | Welkom op ITpedia
    nu gratis aan het werk 5 december 2014 Vier organisaties die de networked economy begrijpen 5 december 2014 ICTWaarborg stelt inkoopvoorwaarden ICT bedrijven op 5 december 2014 Fujitsu ontwikkelt slimme kleine krachtige RFID tag 5 december 2014 IBM hokt nu ook met Docker 5 december 2014 Exchange Server patch alsnog onderdeel Patch Tuesday 5 december 2014 Google project Loon blijkt hoogvlieger 5 december 2014 Sinterklaas koopt veel meer online 5 december 2014 Sonylek gegevens 47 000 werknemers les voor elk bedrijf 5 december 2014 Toegang Inloggen RSS Feed Aanvullingen RSS opdrachtgeverschap Gebruik de 521 IT checklisten van ITpedia met in totaal 22022 vragen Zoek in de omschrijvingen Omschrijving Aantal vragen IT projectfasering Bestaat uit meerdere checklisten Application Services Library ASL Bestaat uit meerdere checklisten Continuïteit Bestaat uit meerdere checklisten Kwaliteitsattributen Bestaat uit meerdere checklisten Functies in de automatisering Bestaat uit meerdere checklisten Webdesign Bestaat uit meerdere checklisten Of zoek naar een woord Fulltekst Laatst gebruikt Exploitatie en auditing op 2014 12 06 17 57 Checklist Toezenden van eerdere beoordelingen per e mail E mailadres applicatiebeheer ASL beheer beveiliging BiSL checklisten copyright formulier Het Nieuwe Werken HNW internet kosten kwaliteit Management methodologie outsoursing project projectfasering projectmanagement SEO Sociale software social media uitbesteden web 2 0 websites WP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better Mislukken door falende opdrachtgevers Een goede invulling van de rol van opdrachtgever blijkt in toenemende mate bepalend te zijn voor het succesvol uitvoeren van een ict project Maar wat wordt verstaan onder opdrachtgeverschap en welke onderwerpen zijn van belang om het opdrachtgeverschap op een goede manier uit te voeren Falend opdrachtgeverschap is een veelvoorkomende oorzaak van het mislukken van ict projecten De opdrachtgever formuleert zijn vraag ongelukkig de ict leverancier denkt de vraag te begrijpen en blijft in gebreke en de ict opdrachtgever doorziet dat niet Binnen de kortste keren hebben beide partijen een compromitterende hoeveelheid boter op hun hoofd zodat juridische maatregelen bij voorbaat heilloos zijn en het verlies van beide partijen slechts bezegelen Een andere belangrijke reden voor het falen van projecten is dat het schatten van kosten doorlooptijd en risico s van ict projecten nog steeds erg moeilijk is De opdrachtnemer kan of wil geen goede inschattingen afgeven of inschattingen dekken slechts een deel van de werkelijke kosten af De opdrachtgever kan of wil deze inschattingen niet op waarde beoordelen Bovendien blijkt vaak dat de opdrachtgever ambitieuzere plannen heeft dan hij oorspronkelijk heeft gecommuniceerd en verzuimt de opdrachtnemer om de verwachtingen te managen De voornaamste kritiek op de opdrachtgever is dat deze bij het formuleren van zijn eisen onvoldoende concreet is de voornaamste kritiek op de opdrachtnemer is dat deze onvoldoende communiceert met de opdrachtgever De opdrachtnemer lijkt te snel tevreden met de opdracht ook al is deze niet goed geformuleerd Maar het probleem begint en eindigt bij de opdrachtgever die onvoldoende geëquipeerd is om doelen prioriteiten en vragen te stellen en om vervolgens de aanbiedingen oplossingen en antwoorden op waarde te schatten Wat maakt een ict opdrachtgever

    Original URL path: http://www.itpedia.nl/tag/opdrachtgeverschap/ (2014-12-07)
    Open archived version from archive

  • Projectmanagementmethoden op een rij | Welkom op ITpedia
    het beschikbare budget de maximaal te realiseren softwarefuncties Binnen een increment wordt op kleinere schaal wel weer gebruik gemaakt van de standaard fasering uit de watervalmethode De ervaringen met de incrementele methode zijn zeker op het gebied van systeemontwikkeling positief te noemen 4 Critical Chain methode Ondanks de hiervoor beschreven methoden bleken veel projecten nog steeds langer te duren en meer te kosten dan oorspronkelijk gepland Naar aanleiding hiervan ontwikkelde dr E Goldratt midden jaren negentig zijn methode met de naam Critical Chain Projectmanagement en Buffermanagement Hij constateerde dat bij vrijwel iedere projectmanagementmethode op taakniveau een extra veiligheidsmarge werd ingebouwd ter bescherming tegen allerlei onzekerheden En omdat de praktijk uitwijst dat iedere projectmedewerker de aan hem of haar toegewezen tijd altijd opmaakt Wet van Parkinson komt ieder project uiteindelijk toch weer in de knel Zeker als de Wet van Murphy ook nog eens bewaarheid wordt alles wat mis kan gaan zal ook mis gaan en wel op het meest ongunstige moment in de meeste desastreuze vorm De Criticial Chain methode richt zich op het project als geheel en niet op de afzonderlijke taken De taakbuffers veiligheidsmarges die worden ingebouwd in de taaktijd om deze te beschermen tegen onzekerheid worden dan ook samengevoegd waardoor er een projectbuffer aan het eind van het project ontstaat De totale veiligheidsmarge wordt en blijft op deze manier zichtbaar voor de projectmanager én opdrachtgever Het bewaken van de projectbuffer is een overzichtelijke manier om de status van het project continu te bewaken Een Critical Chain geeft de snelste tijd weer waarin een project afgerond kan worden rekening houdend met zowel de taakafhankelijkheden als de beschikbaarheid van de juiste resources Deze methode kijkt daarnaast niet alleen naar het kritieke pad maar ook naar kritieke resources afhankelijk van taak en projectmedewerker De critical chain is dus een combinatie van het kritieke pad én kritieke resources Om deze keten worden projectbuffers zodanig gedefinieerd zodat als er wat gebeurt de werkzaamheden op het kritieke pad zo min mogelijk last hebben en de geplande einddatum wordt gehaald Deze methode kan als een aanvulling beschouwd worden op andere projectmanagementmethoden 5 Projectmatic creëren De hiervoor beschreven projectmanagementmethoden leggen vooral de nadruk op de strakke beheersing van projecten en dan met name de aspecten tijd time controle geld cost control en kwaliteit quality control Nieuwe methoden die de afgelopen jaren ontwikkeld werden zoals beschreven in het boek Projectmatig Creëren leggen vooral de nadruk op het managen van chaos energie creativiteit en het scheppend vermogen van het projectteam als je het wilt dan lukt het ook Dit vanuit de filosofie dat een eenzijdige focus op harde projectmanagementaspecten ook geen garantie is voor succes Vanuit deze visie passen de mensen zich niet aan een bestaande projectstructuur maar creëren de betrokkenen voor zichzelf een maatwerk projectstructuur Projectmedewerkers worden daarbij volledig op hun creativiteit en commitment aangesproken waardoor de projectverantwoordelijkheid maximaal gedelegeerd kan worden Anders dan de bedenkers willen doen geloven is deze methode vooral een aanvulling op bestaande methodieken die zich veelal alleen maar concentreren op de

    Original URL path: http://www.itpedia.nl/2011/10/11/projectmanagementmethoden-op-een-rij/ (2014-12-07)
    Open archived version from archive

  • Critical Chain | Welkom op ITpedia
    meer bureaucratische methode dat veel papierwerk genereerde Daarnaast moet eerst het gehele informatiesysteem ontworpen gebouwd en getest worden voordat het in gebruik genomen kon worden Tegen de tijd dat het zover was waren de gebruikerswensen al weer veranderd en voldeed het systeem niet meer aan de verwachtingen Als antwoord hierop werd begin jaren negentig de incrementele methode populair Andere namen zijn bijvoorbeeld RAD Rapid Application Development of EVO Evolutionaire systeemontwikkeling Ook werd SDM getransformeerd tot een Dynamic System Development Methodology DSDM dus Al deze methoden hebben dezelfde kenmerken een cyclisch proces met incrementele stapsgewijze oplevering een klein projectteam met ontwikkelaars en gebruikers die nauw samenwerken sterke betrokkenheid van gebruikers bij het ontwerp via bijvoorbeeld prototyping flexibiliteit in projectuitvoering en volgorde van op te leveren incrementen en projectbeheersing via timeboxing hierbij staat de doorlooptijd vast en bepaalt dat mede met het beschikbare budget de maximaal te realiseren softwarefuncties Binnen een increment wordt op kleinere schaal wel weer gebruik gemaakt van de standaard fasering uit de watervalmethode De ervaringen met de incrementele methode zijn zeker op het gebied van systeemontwikkeling positief te noemen 4 Critical Chain methode Ondanks de hiervoor beschreven methoden bleken veel projecten nog steeds langer te duren en meer te kosten dan oorspronkelijk gepland Naar aanleiding hiervan ontwikkelde dr E Goldratt midden jaren negentig zijn methode met de naam Critical Chain Projectmanagement en Buffermanagement Hij constateerde dat bij vrijwel iedere projectmanagementmethode op taakniveau een extra veiligheidsmarge werd ingebouwd ter bescherming tegen allerlei onzekerheden En omdat de praktijk uitwijst dat iedere projectmedewerker de aan hem of haar toegewezen tijd altijd opmaakt Wet van Parkinson komt ieder project uiteindelijk toch weer in de knel Zeker als de Wet van Murphy ook nog eens bewaarheid wordt alles wat mis kan gaan zal ook mis gaan en wel op het meest ongunstige moment in de meeste desastreuze vorm De Criticial Chain methode richt zich op het project als geheel en niet op de afzonderlijke taken De taakbuffers veiligheidsmarges die worden ingebouwd in de taaktijd om deze te beschermen tegen onzekerheid worden dan ook samengevoegd waardoor er een projectbuffer aan het eind van het project ontstaat De totale veiligheidsmarge wordt en blijft op deze manier zichtbaar voor de projectmanager én opdrachtgever Het bewaken van de projectbuffer is een overzichtelijke manier om de status van het project continu te bewaken Een Critical Chain geeft de snelste tijd weer waarin een project afgerond kan worden rekening houdend met zowel de taakafhankelijkheden als de beschikbaarheid van de juiste resources Deze methode kijkt daarnaast niet alleen naar het kritieke pad maar ook naar kritieke resources afhankelijk van taak en projectmedewerker De critical chain is dus een combinatie van het kritieke pad én kritieke resources Om deze keten worden projectbuffers zodanig gedefinieerd zodat als er wat gebeurt de werkzaamheden op het kritieke pad zo min mogelijk last hebben en de geplande einddatum wordt gehaald Deze methode kan als een aanvulling beschouwd worden op andere projectmanagementmethoden 5 Projectmatic creëren De hiervoor beschreven projectmanagementmethoden leggen vooral de nadruk op de strakke

    Original URL path: http://www.itpedia.nl/tag/critical-chain/ (2014-12-07)
    Open archived version from archive

  • MOSQUITO | Welkom op ITpedia
    bureaucratische methode dat veel papierwerk genereerde Daarnaast moet eerst het gehele informatiesysteem ontworpen gebouwd en getest worden voordat het in gebruik genomen kon worden Tegen de tijd dat het zover was waren de gebruikerswensen al weer veranderd en voldeed het systeem niet meer aan de verwachtingen Als antwoord hierop werd begin jaren negentig de incrementele methode populair Andere namen zijn bijvoorbeeld RAD Rapid Application Development of EVO Evolutionaire systeemontwikkeling Ook werd SDM getransformeerd tot een Dynamic System Development Methodology DSDM dus Al deze methoden hebben dezelfde kenmerken een cyclisch proces met incrementele stapsgewijze oplevering een klein projectteam met ontwikkelaars en gebruikers die nauw samenwerken sterke betrokkenheid van gebruikers bij het ontwerp via bijvoorbeeld prototyping flexibiliteit in projectuitvoering en volgorde van op te leveren incrementen en projectbeheersing via timeboxing hierbij staat de doorlooptijd vast en bepaalt dat mede met het beschikbare budget de maximaal te realiseren softwarefuncties Binnen een increment wordt op kleinere schaal wel weer gebruik gemaakt van de standaard fasering uit de watervalmethode De ervaringen met de incrementele methode zijn zeker op het gebied van systeemontwikkeling positief te noemen 4 Critical Chain methode Ondanks de hiervoor beschreven methoden bleken veel projecten nog steeds langer te duren en meer te kosten dan oorspronkelijk gepland Naar aanleiding hiervan ontwikkelde dr E Goldratt midden jaren negentig zijn methode met de naam Critical Chain Projectmanagement en Buffermanagement Hij constateerde dat bij vrijwel iedere projectmanagementmethode op taakniveau een extra veiligheidsmarge werd ingebouwd ter bescherming tegen allerlei onzekerheden En omdat de praktijk uitwijst dat iedere projectmedewerker de aan hem of haar toegewezen tijd altijd opmaakt Wet van Parkinson komt ieder project uiteindelijk toch weer in de knel Zeker als de Wet van Murphy ook nog eens bewaarheid wordt alles wat mis kan gaan zal ook mis gaan en wel op het meest ongunstige moment in de meeste desastreuze vorm De Criticial Chain methode richt zich op het project als geheel en niet op de afzonderlijke taken De taakbuffers veiligheidsmarges die worden ingebouwd in de taaktijd om deze te beschermen tegen onzekerheid worden dan ook samengevoegd waardoor er een projectbuffer aan het eind van het project ontstaat De totale veiligheidsmarge wordt en blijft op deze manier zichtbaar voor de projectmanager én opdrachtgever Het bewaken van de projectbuffer is een overzichtelijke manier om de status van het project continu te bewaken Een Critical Chain geeft de snelste tijd weer waarin een project afgerond kan worden rekening houdend met zowel de taakafhankelijkheden als de beschikbaarheid van de juiste resources Deze methode kijkt daarnaast niet alleen naar het kritieke pad maar ook naar kritieke resources afhankelijk van taak en projectmedewerker De critical chain is dus een combinatie van het kritieke pad én kritieke resources Om deze keten worden projectbuffers zodanig gedefinieerd zodat als er wat gebeurt de werkzaamheden op het kritieke pad zo min mogelijk last hebben en de geplande einddatum wordt gehaald Deze methode kan als een aanvulling beschouwd worden op andere projectmanagementmethoden 5 Projectmatic creëren De hiervoor beschreven projectmanagementmethoden leggen vooral de nadruk op de strakke beheersing

    Original URL path: http://www.itpedia.nl/tag/mosquito/ (2014-12-07)
    Open archived version from archive

  • Prince2 | Welkom op ITpedia
    projecten nog steeds een goede aanpak 3 Incrementele methode De watervalmethode had in de praktijk nogal wat nadelen vooral zoals die binnen de ICT wereld door SDM werd voorgeschreven Het was een formele min of meer bureaucratische methode dat veel papierwerk genereerde Daarnaast moet eerst het gehele informatiesysteem ontworpen gebouwd en getest worden voordat het in gebruik genomen kon worden Tegen de tijd dat het zover was waren de gebruikerswensen al weer veranderd en voldeed het systeem niet meer aan de verwachtingen Als antwoord hierop werd begin jaren negentig de incrementele methode populair Andere namen zijn bijvoorbeeld RAD Rapid Application Development of EVO Evolutionaire systeemontwikkeling Ook werd SDM getransformeerd tot een Dynamic System Development Methodology DSDM dus Al deze methoden hebben dezelfde kenmerken een cyclisch proces met incrementele stapsgewijze oplevering een klein projectteam met ontwikkelaars en gebruikers die nauw samenwerken sterke betrokkenheid van gebruikers bij het ontwerp via bijvoorbeeld prototyping flexibiliteit in projectuitvoering en volgorde van op te leveren incrementen en projectbeheersing via timeboxing hierbij staat de doorlooptijd vast en bepaalt dat mede met het beschikbare budget de maximaal te realiseren softwarefuncties Binnen een increment wordt op kleinere schaal wel weer gebruik gemaakt van de standaard fasering uit de watervalmethode De ervaringen met de incrementele methode zijn zeker op het gebied van systeemontwikkeling positief te noemen 4 Critical Chain methode Ondanks de hiervoor beschreven methoden bleken veel projecten nog steeds langer te duren en meer te kosten dan oorspronkelijk gepland Naar aanleiding hiervan ontwikkelde dr E Goldratt midden jaren negentig zijn methode met de naam Critical Chain Projectmanagement en Buffermanagement Hij constateerde dat bij vrijwel iedere projectmanagementmethode op taakniveau een extra veiligheidsmarge werd ingebouwd ter bescherming tegen allerlei onzekerheden En omdat de praktijk uitwijst dat iedere projectmedewerker de aan hem of haar toegewezen tijd altijd opmaakt Wet van Parkinson komt ieder project uiteindelijk toch weer in de knel Zeker als de Wet van Murphy ook nog eens bewaarheid wordt alles wat mis kan gaan zal ook mis gaan en wel op het meest ongunstige moment in de meeste desastreuze vorm De Criticial Chain methode richt zich op het project als geheel en niet op de afzonderlijke taken De taakbuffers veiligheidsmarges die worden ingebouwd in de taaktijd om deze te beschermen tegen onzekerheid worden dan ook samengevoegd waardoor er een projectbuffer aan het eind van het project ontstaat De totale veiligheidsmarge wordt en blijft op deze manier zichtbaar voor de projectmanager én opdrachtgever Het bewaken van de projectbuffer is een overzichtelijke manier om de status van het project continu te bewaken Een Critical Chain geeft de snelste tijd weer waarin een project afgerond kan worden rekening houdend met zowel de taakafhankelijkheden als de beschikbaarheid van de juiste resources Deze methode kijkt daarnaast niet alleen naar het kritieke pad maar ook naar kritieke resources afhankelijk van taak en projectmedewerker De critical chain is dus een combinatie van het kritieke pad én kritieke resources Om deze keten worden projectbuffers zodanig gedefinieerd zodat als er wat gebeurt de werkzaamheden op het kritieke pad zo

    Original URL path: http://www.itpedia.nl/tag/prince2/ (2014-12-07)
    Open archived version from archive

  • De cloud, een mistige propositie | Welkom op ITpedia
    december 2014 IBM hokt nu ook met Docker 5 december 2014 Exchange Server patch alsnog onderdeel Patch Tuesday 5 december 2014 Google project Loon blijkt hoogvlieger 5 december 2014 Sinterklaas koopt veel meer online 5 december 2014 Sonylek gegevens 47 000 werknemers les voor elk bedrijf 5 december 2014 Toegang Inloggen RSS Feed Aanvullingen RSS De cloud een mistige propositie De uitspraak oude wijn in nieuwe zakken aangaande de Cloud kan je in verschillende artikelen tegenkomen Daarnaast zijn er ook al verschillende gevallen bekend van haperende Cloud diensten waarbij de dienst een paar dagen niet beschikbaar was In sommige gevallen hebben deze problemen tot definitief data verlies geleid Desondanks Cloud is nog steeds een hot topic Het voornaamste probleem blijft nog steeds dat het niet een vastomlijnd topic is Elke zichzelf respecterende IT dienstverlener of IT adviesbureau lijkt een eigen definitie geformuleerd te hebben Als ons wordt gevraagd hoe wij tegen Cloud aan te kijken is het antwoord steevast dat een Cloud dienst een van de componenten is die invulling kan geven aan de business needs van een organisatie Het kijken naar Cloud omdat het de IT omgeving goedkoper zou maken moet niet de primaire drijfveer zijn maar het proces binnen de organisatie dat met IT ondersteund wordt Als Cloud daar volledig aan voldoet en het wordt ook nog goedkoper dan heeft het pas zin om de overstap te overwegen In reacties op eerdere publicaties wordt gesuggereerd dat bepaalde componenten uit de prijsvergelijking gelaten zijn Dat is niet het geval Alle componenten zijn opgenomen van aanschaf installatie en beheer van hardware tot en met de eindgebruikersondersteuning De ervaring is dat in de meeste Cloud TCO berekeningen de werkplek niet meegenomen wordt alsof deze niet aangeschaft of beheerd hoeft te worden Waarbij het trainen van gebruikers en verminderde efficiëntie bij de start van het gebruik van de oplossing voor het gemak ook vergeten wordt Terug naar de processen binnen de organisatie van opdrachtgevers Gaan zij Salesforce inzetten omdat het nu goedkoop mogelijk is Of omdat zij zoeken naar een goede CRM oplossing En past Salesforce dan het beste bij de eisen die de organisatie stelt en de wensen die zij heeft Of is Microsoft CRM misschien handiger Zijn ze eigenlijk wel op zoek naar een CRM pakket Gaat een organisatie Sharepoint of Lync adopteren omdat het nu binnen Office365 mogelijk is Of voldoet de bestandsstructuur op de fileserver nog goed en biedt de aangeschafte telefooncentrale afdoende mogelijkheden Hoe vervelend is het dat de bedrijfsmacro s en sjablonen in de online versie van Office niet goed werken Door antwoord te geven op deze en vele andere vragen krijgen wij een goed beeld van de eisen en wensen van de opdrachtgever Om daar vervolgens een passende oplossing bij aan te bieden Voor een aantal opdrachtgevers blijkt inderdaad dat het inzetten van een Cloud dienst als Virtual Dedicated Server of BPOS de eigenschappen biedt die de opdrachtgever zoekt De nadelen van Cloud wegen dan niet zwaarder dan de voordelen van eigen hard en software

    Original URL path: http://www.itpedia.nl/2011/07/12/de-cloud-een-mistige-propositie/ (2014-12-07)
    Open archived version from archive



  •