Tag: afhankelijkheid

Verander risico: Afhankelijkheid andere projecten

  door

Vandaag gaan we in op het risico: Afhankelijkheid andere projecten

Een project staat maar zelden op zichzelf. Er is altijd invloed van de staande organisatie, van de omgeving maar ook van andere projecten die op hetzelfde moment worden uitgevoerd. Ben je voor je project afhankelijk van opleveringen van (tussen)resultaten van andere projecten dan moet je de tijdslijnen extra goed bewaken.

Het uitlopen van het ene project heeft daarmee direct invloed op de tijdslijnen in het andere project. Als het hierbij gaat om één ander project dan is dat wellicht nog goed te managen. Maar helaas gaat het in de praktijk om vele projecten die allemaal afhankelijk zijn van elkaar.

Als één project problemen oplevert dan vallen de andere projecten als domino steentjes om. Daarom is het goed om de afhankelijkheden in kaart te brengen en op basis daarvan veiligheidsmarges of back-up scenario’s te ontwikkelen zodat jouw project door kan gaan als andere projecten vertragen.

Wie afgelopen dinsdag het blog heeft gelezen weet het inmiddels, maar we herhalen het toch nog maar even. We zijn inmiddels door de belangrijkste complexiteitsfactoren heen en hebben nog een aantal risico’s te gaan. Wil je de complexiteitsfactoren netjes gerangschikt ontvangen? Dat kan, stuur me een mail en hij komt er zo snel mogelijk aan.

Vanaf volgende week gaan we op de woensdag verder met de risico factoren die spelen bij veranderingen. Als we die allemaal behandeld hebben gaan we verder met de strategische risico’s voor organisaties. Maar nog even geduld. Kun je echt niet wachten? Neem dan alvast contact met ons op via mail

Verander complexiteit: Taken die niet volledig vooraf kunnen worden gedefinieerd

  door

Vandaag gaan we in op de complexiteitsfactor: Taken die niet volledig vooraf kunnen worden gedefinieerd

Taken die niet volledig vooraf kunnen worden gedefinieerd zijn taken die bekend zijn, maar niet kunnen worden gedocumenteerd omdat ze afhankelijk zijn van de resultaten van een voorgaande taak. We doorlopen de verandering gedurende een aantal weken, maanden of zelfs jaren. Daar zit een bepaalde tijdsvolgorde in om het resultaat te bereiken.

Hoe meer taken we vooraf inzichtelijk hebben, hoe beter we kunnen plannen. Is het merendeel van de taken echter afhankelijk van taken in een eerder stadium van de verandering dan wordt het een complexer verhaal.

We weten best dat de taken eraan zitten te komen, maar we weten niet precies wanneer en welke kennis daarvoor nodig is.
Vergelijk het met autorijden. We kunnen pas gas geven als we de sleutel in het contact hebben omgedraaid. Deze sleutel kunnen we pas in het contact stoppen als we de deur hebben geopend. De deur kunnen we pas openen als we de sleutel uit onze zak hebben gehaald, tenzij we keyless entry hebben natuurlijk.

Afhankelijkheid van securitybedrijven onwenselijk

  door

Deze week hebben we gezien dat de IT-manager vol staat van de stress omdat hij ook niet meer weet waar hij het moet zoeken op het gebied van informatiebeveiliging. Gelukkig zijn er gespecialiseerde bedrijven die graag willen helpen. Helaas denkt Minister Opstelten daar anders over.

Minister Ivo Opstelten van Veiligheid en Justitie vindt het onwenselijk dat de ict-veiligheid van de overheid afhankelijk is van externe bedrijven als Fox-IT. Het zou echter niet rendabel zijn om deze expertise in de eigen organisatie onder te brengen. (bron)

Nu zou je natuurlijk kunnen concluderen dat de Minister geen gebruik meer wil maken van externe gespecialiseerde bedrijven. Maar dat is zeker niet zoals ik het interpreteer. Zelf geeft hij ook al aan dat “In gevallen waarin dergelijke expertise vereist is, is de inhuur van externe expertise veelal een kostenefficiënte oplossing.”

Natuurlijk zou je als overheid (of als grote organisatie) de kennis zelf in huis willen hebben. In dat licht bezien is de afhankelijkheid inderdaad onwenselijk. Maar kijken we naar de meest kostenefficiënte oplossing dan ontkom je er niet aan om nauw samen te werken.

Met name in het “nauw samenwerken” zitten hem de voordelen. Als geld inderdaad niet uit zou maken, dan wil je de kennis helemaal zelf in huis hebben, maar wat als je te weinig gebruik maakt van die kennis? Gaan die specialisten het hele jaar zitten wachten totdat ze hun kunstje mogen doen? Nee, natuurlijk niet. Ze zouden al snel achterlopen op de feiten. Een samenwerking is daarom zo gek nog niet.

Waar hem eerder een punt zit, is het feit dat er veelal achteraf een gespecialiseerd bedrijf wordt ingeschakeld. Het incident heeft plaatsgevonden en we moeten snel tot oplossingen komen. Een kwestie van vraag en aanbod. Ineens is er veel vraag terwijl het aanbod beperkt blijft. De prijzen schieten omhoog.

Nee, prima dat we de brandweer bellen als er brand is. Maar ik zie liever dat we in de preventieve sfeer op zoek gaan naar die mogelijkheden om incidenten te voorkomen. Dat doen we dan weer niet met alleen maar technische maatregelen. Nee, we doen dat op basis van risico management en komen dan tot de juiste set technische, procedurele, organisatorische, bouwkundige en elektronische maatregelen.

Voor die IT-managers die bol staan van de stress geldt dit natuurlijk ook. Ga niet wachten tot je verrast wordt door een incident. De kosten voor het oplossen daarvan zijn enorm. Nee, kies ervoor om de risico’s te beheersen door preventief aan de slag te gaan.

Ja, natuurlijk weet ik het. Er wordt flink bezuinigd op de budgetten voor informatiebeveiliging. Daar lijkt weinig aan te doen. Tenzij we in onze business cases ook inzichtelijk kunnen maken wat het oplossen van een incident eigenlijk kost. Niet alleen in directe kosten maar juist ook in termen van imagoverlies, omzetverlies, kosten die doorlopen terwijl we niet kunnen produceren, klanten die weglopen, etc.