Tag: project

Verander complexiteit: Fulltime of parttime project medewerkers

  door

Vandaag gaan we in op de complexiteitsfactor: Fulltime of parttime project medewerkers

In de praktijk zien we dat veel medewerkers naast hun dagelijkse werkzaamheden betrokken worden bij veranderingen. Op zich niets mis mee, maar het verhoogd de complexiteit van je project en je zult er rekening mee moeten houden als je de tijdslijnen gaat bepalen.

Een medewerker die fulltime aan de verandering kan werken heeft meer tijd beschikbaar (logisch) maar hoeft zich ook maar op één verandering te richten.

Medewerkers die part-time betrokken zijn, naast hun dagelijkse werkzaamheden, moeten meer ballen in de lucht houden. Grote kans dat ze eind van het jaar in hun beoordeling afgerekend worden op de dagelijkse gang van zaken en niet op hun inspanningen voor de verandering.

Zes competenties voor succesvol veranderen

  door

Van de week hadden we het al over de 7 redenen waarom medewerkers niet meegaan in een verandering. Vandaag gaan we in op de 6 competenties voor succesvol veranderen. Ook deze competenties heb ik weer gevonden op Managementsite.nl.

  1. Check het draagvlak
  2. Voer een proefproject uit
  3. Ga de dialoog aan
  4. Zorg voor voldoende middelen
  5. Bouw een feestje
  6. Trek lessen uit het project

Het blijft interessant om te zien waarom mee zo weinig veranderingen (en projecten) succesvol zijn. Er is al veel onderzoek gedaan en er is al veel bekend waar we extra op moeten letten. Blijkbaar lukt het ons nog onvoldoende in de praktijk om de lessen ook echt toe te passen. Met CORE(BI) proberen we daar verandering in aan te brengen omdat we een gebruiksvriendelijke methode hebben ontwikkeld die aangeeft welke punten van de verandering extra aandacht behoeven.

Had CORE(BI) dit kunnen voorkomen…

  door

Het is algemeen bekend dat projecten veelal over budget en tijd heen gaan en dat het resultaat nog wel eens te wensen overlaat (understatement want in 80 tot 90 procent van de projecten is dit het geval). Juist daarom heb ik een gebruiksvriendelijke methode ontwikkeld waarmee we naast de business case ook het belang van de verandering meewegen in ons besluit. Daarna kijken we naar de complexiteit en de risico’s van het project of de verandering zodat ze beter gemanaged kunnen worden.

Als ik dan een artikel lees waarbij een Aardwarmteproject een strop van 21 miljoen euro is dan vraag ik me af of we dit hadden kunnen voorkomen of in ieder geval de schade hadden kunnen beperken door een CORE(BI)-analyse uit te voeren.

Ik zoek nog een aantal projecten die als pilot kunnen dienen. Sta jij aan de vooravond van een complex project of zit je al in de uitvoeringsfase en loop je tegen uitdagingen aan? Laat het me weten, misschien kunnen we nog op tijd ingrijpen om het geen blok aan jouw been te maken.

10 oorzaken waardoor een project kan mislukken

  door

In onze zoektocht naar redenen waarom projecten mislukken, stuitten we op de volgende oorzaken:

  1. Een project zonder duidelijke business case opstarten
  2. Een medewerker aanstellen als projectmanager die geen specifieke projectkennis heeft
  3. Geen risico inventarisatie en evaluatie houden
  4. Het telkens opnieuw formuleren en bijstellen van de business requirements
  5. Niet voldoende materiële en personele inzet aan het project toewijzen
  6. Geen draagkracht voor het project of de uitkomsten ervan binnen de organisatie
  7. Een incorrect of helemaal geen plan van aanpak
  8. Wel een plan van aanpak, maar geen of onjuiste project en activiteitenplanning
  9. Geen of te weinig support van het hoogste bestuur in de organisatie
  10. Niet de juiste vakgebieden en belanghebbende voor het project geselecteerd

Met CORE kijken we naar punt 3. Geen risico inventarisatie. Maar de oorzaak waarbij de complexiteit wordt onderschat komt niet in bovenstaand lijstje voor. Toch is het een van de redenen waarom projecten mislukken.

Naast de business case, waarin met name de positieve opbrengsten in kaart worden gebracht, moeten we bij het besluit om een project wel of niet op te starten juist ook kijken naar de complexiteit van dat project.

Waarom mislukken projecten

  door

Waarom mislukken projecten? Dit is een vraag die veel managers zichzelf stellen. Als je een project opstart dan zorg je er immers voor dat alle parameters in de goede richting staan. Je maakt een inschatting van de benodigde capaciteit en middelen, je maakt een planning en toch mislukt uiteindelijk het project. Waarom mislukken projecten dan toch terwijl je de voorbereiding zo goed hebt gedaan?

Als je een nieuw project wilt starten dan ga je er van uit dat het beoogde resultaat zal worden behaald. Daarvoor stel je alles in het werk om het voor elkaar te krijgen. Toch lukt het vaak niet om het vooraf vastgestelde resultaat te behalen. Dit heeft een aantal oorzaken. De meeste problemen concentreren zich rondom de volgende onderdelen van een project:

  1. Projectplanning mislukt
  2. Te weinig draagvlak voor het project
  3. Buiten de procedures om werken
  4. Projectrisico’s negeren
  5. Te veel informatie
  6. Geen goede business case
  7. Te weinig geld, tijd of capaciteit
  8. Geen commitment

Met CORE (Complexity & Risk Exposure) brengen we daar verandering in. We kijken vooraf naar de Complexiteit en daarna naar de risico’s die het resultaat in de weg kunnen staan.

Vijf redenen waarom de meeste projecten mislukken

  door

Uit Amerikaans onderzoek (gepubliceerd op ManagersOnline) blijkt dat in de meeste projecten vijf cruciale vragen worden genegeerd:

  1. Is de planning op harde feiten gebaseerd?
  2. Is er (voldoende) ondersteuning van de sponsor?
  3. Worden de gangbare processen in de organisatie gevolgd?
  4. Is eerlijk vastgesteld welke vorderingen en risico’s er zijn?
  5. Dragen alle teamleden hun steentje bij?

Met onze Complexity & Risk Exposure (CORE) aanpak verhogen we de slagingskans van projecten.

Virtuele servers vaak onveiliger dan fysieke

  door

Een groot deel van de virtuele servers zijn minder veilig dan de fysieke servers die ze vervangen. Dat zegt Gartner op grond van onderzoek…Dat de virtuele servers onveiliger zijn komt doordat er in het vroege stadium van architectuur en planning geen beveiligingsteams bij het project betrokken worden (bron).

Ja wie ben ik om Gartner tegen te spreken. Maar wat is nu het nieuws? Dat virtuele servers onveiliger zijn of dat er geen beveiligingsteams bij het project betrokken zijn? Dat laatste zie je maar al te vaak en echt niet alleen bij de ontwikkeling van architectuur of servers. Het geldt voor alle projecten…die beveiligers worden vergeten of ze zijn te lastig waardoor ze gewoon niet gevraagd worden.

Nu wil ik niet zeggen dat je beveiliging bij ieder project moet betrekken, maar bij een groot deel wel. Al is het alleen maar even in het ontwikkeltraject je plannen aanhouden tegen de beveiliging. Misschien hebben ze nog wat handige tips waardoor het veiliger kan.

In de praktijk zie je dat beveiliging, als er al over nagedacht wordt, pas in een laat stadium zijn zegje mag doen. Alleen pleisters plakken is dan nog mogelijk om het enigszins veilig te houden. Hierdoor worden er gedrochten van beveiligingsoplossingen verzonnen die enorm veel geld kosten. Dat bevestigd dan weer het beeld dat binnen de organisatie toch al leeft: zie je wel, dat beveiligen is alleen maar lastig, werkt tijdvertragend en is enorm duur.

De kunst voor beveiligers blijft om pro-actief en positief te adviseren. De stelling: nee dat mag niet want het is niet veilig…is zo 1980. We moeten er toch echt vanuit gaan dat alles kan, maar wel zo veilig mogelijk. Geloof me, de business zet je volledig buitenspel als je je meerwaarde niet aantoont en het alleen maar lastig maakt. Heb ook niet de illusie dat een ontwikkeling (die geld op moet leveren) niet doorgaat omdat wij het niet veilig vinden.

Nee, we zeggen het wel vaak: beveiliging is ondersteunend aan de business…maar in de praktijk moeten we dat ook echt gaan toepassen en onze meerwaarde aantonen. Probeer eens een beveiligingsadvies te geven waarbij de business juist meer kan verdienen of meer kan bezuinigen door die maatregel te nemen, dan heb je een stap gezet in de juiste richting.

Oh ja, het ging om virtuele servers en daarvan betwijfel ik of die echt onveiliger zijn…maar goed ik wil Gartner niet tegenspreken en ga er maar niet verder op in. Wie mijn mening wil weten, weet me te vinden.