Auteur Topic: Plannen en toch falen of plannen voor success  (gelezen 89 keer)

Offline Axel

  • Algemene moderator
  • Nieuweling
  • *****
  • Berichten: 7
    • Bekijk profiel
    • Taurus Enterprise Engineering
Plannen en toch falen of plannen voor success
« Gepost op: 15 augustus 2017, 17:07:57 »

We zijn allemaal al wel de zeer terechte quote “If you fail to plan, you are planning to fail!” van Benjamin Franklin tegengekomen. Nochthans, indien velen plannen en velen falen ze ook mèt een plan. Als we niet kunnen plannen, waarom dan nog plannen?

Wel Franklin is niet de enige die ons iets leert. Ooit zei Dwight D. Eisenhower “In preparing for battle, I have always found that plans are useless, but planning is indispensable”. Verder, is het ook belangrijk even stil te staan bij hoe men juist plant, hoe men met een plan omgaat en hoe men het succes van een project definiëert.

Plannen en falen is mogelijk. Het is zelfs niet moeilijk. Maak een plan gebaseerd op weinig inzicht en volg dan het plan nauwkeurig op. “Stick to the plan”. Falen is dan gegarandeerd. Is dit niet wat men doet?

Vanuit deze instelling is het plan waardeloos. Het plannen, het opstellen van het plan, indien fatsoenlijk uitgevoerd, verplicht de projectleider om na te denken. Dit levert een dieper inzicht op. En dat is net de waarde van "het plannen".

Uiteraard is het plan niet waardeloos, indien het juist wordt gebruikt.

Hoe moet het dan wel?

1) Plan op basis van inzicht

Hiervoor dient de ‘Analyse’. Analyse is voornamelijk een activiteit die een diagnose stelt (bepaling van oorzaken en root causes) en die het probleem, de situatie en de omgeving tracht te begrijpen. Cru gesteld, zonder dit inzicht "weet men niet waar men mee bezig is". De discipline 'Analyse' (zoals in "Systeem Analyse") is uiteraard niet te verwarren met de term 'analyse' uit het woorenboek. De Analyse discipline levert informatie en inzicht op om tot een oplossing te komen en omvat ook het ontwerpen van een functionele/logsiche oplossing of systeem. Of, analyseren wanneer een oplossing reeds bepaald is, heeft weinig zin. Dit is dan meer detailering, dan Analyseren. Een plan opstellen vergt dus een duidelijk inzicht in het product, in de verandering, in de oplossing, in WAT men gaat implementeren. Het product is pas redelijk goed gekend nadat het ontworpen is, dus na de Analyse, en nog meer na Design-fase. Voorafgaandelijke plannen zijn zeker nuttig, maar zijn minder betrouwbaar, minder stabiel. Indien de Analyse of Design, later in het project, tot een aanpassing leiden, dan dient het plan te worden herbekeken.

En, in meer hoofden zit meer dan in één hoofd. Plan samen met andere specialisten.

[/size]2) Leer met buffers omgaan[/font]

Te korte inschattingen leidt tot druk. Hierdoor gaat men meer op basis van assumpties werken. Men vertrouwt erop dat verkregen vragen en informatie correct zijn. Men gaat veel controles overboord gooien. Men gaat ook simpeldere, en soms te simpele oplossingen kiezen. Druk leidt ook tot meer conflicten. Dit alles leidt tot slechte kwaliteit en grotere risico’s. Het is vragen om te falen. Met buffers kan men de druk op het project regelen. Een projectleider is immers een behoeder, een schild die het project beschermt van negatieve invloeden van buiten af.

[/size]3) Herbekijk en pas het plan aan wanneer noodzakelijk[/font]

Tijdens het projectverloop kunnen een paar “plan reviews” worden voorzien. De plannen worden dan aan de werkelijkheid van het project afgetoetst. Het einde van een projectfase, of wat hiervoor kan doorgaan, is een ideaal moment. Bij de gewone regelmatige projectopvolging kan ook blijken dat er een discrepantie is tussen het plan en de realiteit. Dit is noch uitzonderlijk, noch erg. Indien dit verschil tussen het plan en de realiteit klein is, dan kan de realiteit worden aangepast aan het plan. Hiervoor dienen, o.m. de buffers. Maar indien dit verschil te groot of te belangrijk is, indien de werkelijkheid niet kan worden aangepast, dan moet het plan worden aangepast. Projectleiders hebben dit niet graag. Maar dit is de meest logische en natuurlijke reactie op de situatie. Het alternatief is falen.

Het doel is niet de uitvoering van een plan. Het doel is het creëren van een degelijk systeem of oplossing. Het plan is een organisationeel tool dat een efficiënte uitvoering ondersteunt. Het plan dient de uitvoering te ondersteunen en het is niet aan de uitvoering om het plan waar te maken.

[/size]4) Zoek en begrijp de risico's, limieten, beperkingen, ...[/font]

[/size]5) Wanneer is een project succesvol?[/font]

De traditionele mantra “Een project is succcesvol wanneer het binnen scope, tijd en budget wordt opgeleverd”. [/size]Stop! Plannen dienen continu te worden aangepast. Dit geldt ook zo voor de scope, tijd en budget. Wanneer men merkt dat er onvoldoende middelen zijn voor het project, of dat het product niet meer zal renderen, dan moet men het doel van het project en het product aanpassen om er alsnog een waarde uit te halen, of het project stop zetten. Het succes van het product is en blijft vele malen belangrijker dan het succes van het project. Hoe belangrijk is het om binnen scope, tijd en budget een gevraagd product op te leveren, wanneer dit een non-oplossing is? De vraag is dus minder of het project geslaagd is, dan wel meer of het product geslaagd is. Het plan bepaalt niet wanneer het product klaar is. Het product is klaar wanneer het klaar is en niet eerder.[/font]

Nog vele succesvolle producten toegewenst.

Axel Vanhooren

Freelance Consultant

Business Informatics
Axel.

Offline Axel

  • Algemene moderator
  • Nieuweling
  • *****
  • Berichten: 7
    • Bekijk profiel
    • Taurus Enterprise Engineering
Re: Plannen en toch falen of plannen voor success
« Reactie #1 Gepost op: 23 augustus 2017, 09:18:03 »
Nog een meegevertje :


De "Scope".


De functie van de scope is om een omlijning van het project te hebben. Namelijk, men dient precies te weten wat in het project voorzien is en wat niet. De scope is dus geen high-level en dikwijls vage omschrijving van het project. Met een vage omschrijving weet men waar het project over gaat, maar kan men niet checken of iets door het project voorzien is of niet.


Wanneer een vraag komt om iets in het project op te nemen, dan moet men aan de hand van de scope kunnen zeggen of dit voorzien is of niet.
Indien het niet voorzien is, dan betekent dit niet dat het niet kan gedaan worden. Dan wordt de vraag in overweging genomen: nut, wanneer het meest opportuun, voor- en nadelen, de impact ervan op het project (ivm resources, tijd, ...) en dan beslist men of men dit niet, wel, gedeeltelijk opneemt in het project, of of men er gewoon nu reeds mee rekening mee moet houden dat dit later kan komen en eventueel zelfs enige zaken reeds voorbereidt.


Indien een analist, architect of ingenieur aan de hand van de scope niet kan zeggen of een gevraagde ontwikkeling van een feature of uitvoeren van een werk in het project is voorzien of niet, dan is de scope ondermaats.


Hiervoor is een scope ook multi-dimensioneel: bvb: functies, technologieën, horizontale spanwijdte (vb tot waar in de organisatie reikt het), graad van automatisering en ondersteuning, ...


Het product is pas redelijk goed gekend na de design, en dus een redelijke scope-stabilitieit zou er pas zijn na de design-fase. Dat men een onverandelijke scope in een project heeft kan, maar kan ook van een te rigide attitude getuigen. Een voortdurende veranderende scope kan een indicatie zijn van gebrekkige analyse, van een uitgebreidelde creativtieit en het niet weten van wat men wilt ... van wat nodig is, dus van een gebrekkige analyse. Het risico van een voortdurende veranderende scope is 1) te veel herwerk dan wat normaal nodig zou zijn en 2) het blijvend werken aan het project zonder ooit een oplevering.
Axel.

Offline Jos De Clercq

  • Forumbeheerder
  • Junior
  • *****
  • Berichten: 68
    • Bekijk profiel
Re: Plannen en toch falen of plannen voor success
« Reactie #2 Gepost op: 28 augustus 2017, 11:43:25 »
@Axel:  proefondervindelijk moeten vaststellen dat er nog iets bestaat dat erger is bij het plannen.
Er is inzicht nodig, en de kwaliteit ervan beinvloed het resultaat.
Maar FOUTE inzichten , en het laattijdig inzien, is wel een nachtmerrie. Dan kan je wel raden tot wat zoiets leidt.