Recente berichten

Pagina's: [1] 2 3 ... 9
2
Project / Twee types van ‘Changes’ en de kwaliteit van de Analyse
« Laatste bericht door Axel Gepost op 1 september 2017, 18:40:14 »
Is ‘change’ noodzakelijk en onvermijdelijk? Ja … en NEE! Ja, een onderneming moet zichzelf ontwikkelen en verbeteren. Ze dient zich aan te passen aan een veranderende omgeving en moet ook innoveren. Dit is een kwestie van overleven en van voorspoed. Maar we kunnen de keerzijden niet negeren. Verandering betekent herbewerking, tijd, onzekerheid en risico’s. Hoe meer veranderingen, hoe minder er opgeleverd wordt. Veranderingen kunnen ook leiden tot tijdsdruk, frustratie, conflicten en chaos. Veranderingen stuwen ook de kosten de hoogte in. Ze kunnen de winst omhoog drijven, maar kunnen deze ook verminderen en zelfs omvormen tot verlies.

En, of we dit nu graag hebben of niet, softwareontwikkeling is (voorlopig nog) een kostelijke en trage activiteit. Hierdoor vereist het een zekere graad van stabiliteit.


Softwareontwikkelingsprojecten hebben te maken met twee soorten veranderingen.


1)      De businessomgeving verandert. De strategie verandert. Nieuwe producten en diensten worden aangeboden. Nieuwe ideeën kunnen plots opkomen. De businessgemeenschap kan beslissen om in te gaan op een opportuniteit die zich aanbiedt, zoals bijv. een nieuwe samenwerking.


Deze veranderingen zijn extern aan het bedrijf of buiten het domein van de stakeholders. Ze kunnen betrekking hebben op een situatie die onzeker of onbeslist was en waar een beslissing de situatie vast legt. En een cruciale informatie kan verborgen blijven. Het is soms niet evident om tot een bepaald inzicht te komen. Een toekomstige situatie kan moeilijk te voorzien zijn.


2)      De label ‘verandering’ (of ‘change’) speelt ons parten door de waarheid te verbergen. Vele ‘veranderingen’ zijn eigenlijk geen veranderingen. Het zijn correcties van ongelukkige dessign-beslissingen, van foutieve ‘oplossingen’, van problemen gecreëerd door onjuiste ‘oplossingen’ of zelfs van een poging tot het oplossen van verkeerde problemen (gevolgen, symptomen).  Deze veranderingen hadden kunnen worden vermeden. Ze zijn eigenlijk ongewenst. Ze doen de productiviteit teniet.


De belangrijkste rede van bestaan van Analyse (de discipline van Business / Systems / Process / Information / Functional Analysis) is precies om dit type van ‘veranderingen’ (correcties) te vermijden. De Analyse tracht immers het maken deze fouten te vermijden. De snelste en goedkoopste manier om iets te doen, is om de juiste dingen van de eerste keer juist te doen. Analyse is niet nodig wanneer men zonder beperkingen aanpassingen, alsook al de implicaties en gevolgen ervan, aanvaardt.


Idealiter zouden dergelijke correcties niet moeten voorkomen. Echter, men kan het maken van fouten niet volledig vermijden en dus komen verbeterende veranderingen voor. Analyse gaat er om een oprechte inspanning te leveren om deze veranderingen zo veel mogelijk te beperken.


Een gebrekkige analyse leidt tot een gebrekkige oplossing, tot een oplossing die veel nieuwe problemen creëert of zelfs tot een poging om een verkeerd probleem op te lossen. Het leidt dus tot veel correctieve veranderingen. Het aantal late bijkomende gevraagde ontwikkelingen, late vereisten (requirements), en late vermijdbare veranderingen in een project zijn een indicatie van de kwaliteit van de analyse.


Sommige veranderingen zijn gemakkelijker te voorspellen en te vermijden dan andere. Soms was de relevante informatie gemakkelijk te verkrijgen. Of, het vereiste slechts enkele bijkomende vragen en wat meer denkwerk om tot een juist inzicht te komen die tot een juiste beslissing zou hebben geleid. Hoe meer dergelijke correctieve veranderingen voorkomen in een project, des te meer men de kwaliteit van de analyse in vraag kan stellen. De analist kan verantwoordelijk zijn voor een slechte analyse. Echter, daar hij of zij is erg afhankelijk van andere stakeholders, is dit niet altijd het geval.


De vraag die zich nu aanbiedt is: “Hoe komt men tot een degelijke analyse?”. Nieuwe stof tot nadenken.


Axel Vanhooren
Freelance Consultant Business Informatics



3
Project / Re: Plannen en toch falen of plannen voor success
« Laatste bericht door Jos De Clercq 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.
4
Project / Re: Plannen en toch falen of plannen voor success
« Laatste bericht door Axel 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.
5
Project / De sleutel naar een succesvolle methodologie
« Laatste bericht door Axel Gepost op 17 augustus 2017, 19:17:30 »
Vele softwareontwikkelingsprojecten worden als gefaald beschouwd. Daar deze onlosmakelijk verbonden zijn met methodologieën, wordt deze laatste al snel als boosdoeners aangewezen. Methodologieën worden vaak allerhande gebreken aangewreven. De huidige methodologieën worden dan al gauw verdreven en onze geest staat open voor een nieuwe. We koesteren de hoop om eindelijk de methodologie te vinden die ons naar succesvolle projecten zal leiden. Deze redenering is echter gebaseerd op een erg oppervlakkig inzicht in software engineering, en in het bijzonder in methodologieën. De sleutel naar de methodologie die een project succesvol zal ondersteunen is nochtans voor de hand liggend. Laten we dit van dichterbij bekijken.

De kern van een methodologie is een algemene omschrijving van een proces. De aard van het te bouwen product of van het te bekomen resultaat is de meest bepalende factor die het project en zijn proces bepaalt. Projecten die een gelijkaardig product creëren hebben bijgevolg heel wat gemeen. Deze gemeenschappelijkheden werden dan gesynthetiseerd en geformaliseerd in een methodologie. De methodologie kan verder nog verrijkt worden met elementen die nuttig kunnen zijn voor projecten.


Het fundamenteel doel van de methodologie is bij te dragen aan het succes van toekomstige projecten. Ditzelfde doel geldt ook voor alle andere elementen, principes, aspecten en componenten uit de methodologie.


De ontwikkeling van een kleine softwaretoepassing is doorgaans vrij eenvoudig. Men kan deze ontwerpen, ontwikkelen en testen in één trek zonder veel voorbereidend werk. Dit stelt geen echte uitdaging voor en is dus ook geen valabele test voor een methodologie. De situatie ligt anders bij grotere en complexere softwaresystemen die bijvoorbeeld functioneel en architecturaal geïntegreerd zijn in een overkoepelend systeem en die tevens een algemene coherentie en standaardisatie nastreven terwijl ze door verschillende gebruikersgroepen worden gebruikt die informatie uit diverse domeinen delen voor verschillende doeleinden. Bij het bouwen van een wolkenkrabber zal men andere problemen tegenkomen dan bij het bouwen van een schuurtje. Beide vereisen een verschillende aanpak. Het is bij de ontwikkeling van grotere en complexere systemen dat een methodologie pas haar nut bewijst en dit over een langere periode, zoals een decennium. Ze kunnen echter een zegen of een vloek zijn.


Sinds de jaren ‘70 tot vandaag zijn de te bouwen softwaresystemen sterk geëvolueerd. Hun grootte, hun complexiteit en hun connectiviteit zijn aanzienlijker geworden. Ook de omgevingen van de softwaretoepassingen zijn sterk veranderd. Deze evolutie stelde projecten telkens voor belangrijkere uitdagingen en voor nieuwe problemen. Het is door hieraan een antwoord te bieden dat projecten, hun aanpak en de methodologieën evolueerden. Elk onderdeel van de methodologie heeft een rede van bestaan, een doel, een nut, een functie. Dit alles bestaat dus niet zonder rede en men mag hier niet lichtzinnig over gaan.

Methodologieën kunnen ook het resultaat zijn van een nieuw inzicht, via de introductie van nieuwe principes of uit experimentele projecten.

De keuze van de methodologie


Het is de verantwoordelijkheid van het projectteam om de gepaste methodologie te kiezen. Het creëren van een nieuw administratief softwaresysteem, de aanpassing van een dergelijk systeem, een datamigratie, de fusie van bestaande softwaresystemen, de ontwikkeling van online games, de ontwikkeling van websites, de ontwikkeling van robotsoftware of van een wetenschappelijke softwaretoepassing, de implementatie van een ERP-systeem zijn allemaal totaal verschillende types van projecten. Het is de verantwoordelijkheid van het team om de methodologie te selecteren die voor hun specifiek project het meest geschikt is. Dit gaat niet om een keuze op basis van voorkeur of smaak, maar van geschiktheid. Zelfs indien de keuze ongelukkig is, kan het project nog slagen. Het kan wel wat moeilijker worden.

Aanpassing van de methodologie


Eenmaal gekozen, worden vele methodologieën trouw gevolgd. Het volgen van een methodologie is noch een doel, noch een verplichting. Dit zou immers fundamenteel onlogisch en zinloos zijn. Het kan zelfs niet eens worden aangeraden.


Verwachten dat door het trouw volgen van een methodologie het gewenst resultaat bereikt kan worden is een grote illusie. Een procedure zal, doorgaans, het bedoeld resultaat opleveren indien het stipt uitgevoerd wordt. Echter, een methodologie is geen procedure. Dit is zo belangrijk dat het dient te worden herhaald: “een methodologie is geen procedure”. Een methodologie is een synthese van een patroon die in gelijkaardige projecten voorkomt. Het is een algemeen proces. Echter, elk project is verschillend. Het is dus weinig waarschijnlijk dat een methodologie perfect beantwoordt aan de noden van een project. In tegenstelling tot een procedure, zal het strikt volgen van een methodologie veel eerder het succes van het project ondermijnen.


Een methodologie is geen oplossing. Het is geen kant-en-klaar of afgewerkt proces. Het is een vertrekbasis waaraan moet worden gesleuteld. Het is een suggestie van een template. Zo kunnen taken worden herschikt, toegevoegd of weggelaten. Elk aspect van de methodologie kan en moet worden aangepast aan het project en zelfs aan de individuele situaties binnen een project. Voor elke aanpassing, dient men te weten waarom de aanpassing noodzakelijk is.

Omdat het doel van elke methodologie er uit bestaat om bij te dragen tot het succes van het project, heeft het ook geen zin om taken uit te voeren of documenten te produceren die voor het specifiek project, voor het product of voor de organisatie geen toegevoegde waarde betekenen, ook rekening houdend met bijvoorbeeld langere termijn of risico’s.

Stellen dat een methodologie ook maar iets zou opleggen gaat regelrecht in tegen de geest van een methodologie. In een onderneming, kunnen mensen wel bepaalde verplichtingen opleggen aan projecten, zoals de verplichting om een PID (Project Initiation  Document) op te stellen. Maar dit zijn mensen die verplichtingen via de methodologie doorgeven. Het is niet de methodologie zelf die iets oplegt.

Competenties


Een methodologie biedt steun aan projectleiders, architecten, analisten en engineers. Maar het leidt hen niet. Het vertelt hen niet wat ze moeten doen. Dit moeten ze zelf bepalen. Het is geen substituut of excuus voor het niet nemen van bepaalde verantwoordelijkheden.


Een methodologie vervangt de kunde en inzicht in softwareontwikkeling niet, noch ontheft de projectleden van het autonoom en kritisch denken. Deze competenties zijn nog steeds broodnodig. Projectleden moeten immers de methodologie aanpassen aan het project. Dit vereist een diepgaand inzicht in software engineering. De teamleden zouden in staat moeten zijn om een project succesvol uit te voeren door een hele methodologie en projectorganisatie zelf vanaf nul te bepalen zonder gebruik te maken van een bestaande methodologie. Indien het team hiertoe niet in staat is, loopt het project een ernstig risico.

Conclusie


Methodologieën doen projecten niet falen en kunnen dit ook niet. Het zijn de mensen en situaties die projecten kunnen doen falen. Het kan hoogstens een project in meer of in mindere mate ondersteunen. De sleutel tot een methodologie is de juiste methodologie te selecteren en deze aan te passen aan het project. Dit vereist het juist identificeren en begrijpen van de noden van het project. Verder vereist dit ook autonoom denken en stevige inzichten en competenties in softwareontwikkelingen en het kundig kunnen omspringen met het project.


Axel Vanhooren
Freelance Consultant Business Informatics
6
Project / Plannen en toch falen of plannen voor success
« Laatste bericht door Axel 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
7
Project / ISEDMAM - Maturity Awareness Model voor Software Engineering
« Laatste bericht door Axel Gepost op 13 augustus 2017, 16:38:07 »
Enerzijds is IT een jonge en snelgroeiende discipline waar zowat iedereen bij betrokken raakt. Hierdoor zijn er vele vreemde aannames, hersenkronkels, denkpatronen en wereldbeelden (belief systems) over IT ontstaan.


En, men zal dezelfde problemen tegenkomen tot men de les leert die men moet leren. Pas dan kan men evolueren naar een hoger niveau van maturiteit door ons wereldbeeld, ons geloofssysteem aan te passen. De oudere problemen zijn dan wel opgelost maar nieuwe zullen opduiken. Deze nieuwe problemen vormen dan op hun beurt een nieuwe opportuniteit om te evolueren.


ISEDMAM - Information Systems Engineering Discipline Maturity Awareness Model - legt dit en veel andere dingen uit. Het legt ook een aantal visies over IT van diverse maturiteitsniveaus naast elkaar. Een aantal visies en veronderstelde en aangenomen ideeën of principes worden gechallenged.


[color=rgba(0, 0, 0, 0.7)]DOWNLOAD: [/color][/size]https://goo.gl/noPwQp


Succes !!

8
Evolutie in Supply Chain denken? / niet iedereen durft te luisteren, of kan het niet
« Laatste bericht door Jos De Clercq Gepost op 30 april 2017, 20:39:53 »
Hi Jos,        Bemoedigende wijze spreuken , luisteren kan moeilijk zijn[/size]You can lead a horse to the water, but you can't make it drink.
[/size][size=78%]You can move a manager in a new position, but you can't make him think.[/size][/size][size=78%] [/size][/font][/font][/size][size=78%]Of zoals mijn wijze oude broer ooit tegen mij zei toen ik aan het mopperen was over een bedrijf waar geen hond luisterde....[/size][/size][/font]Specialisten luisteren naar specialisten, amateurs luisteren naar niemand[/font]
9
Evolutie in Supply Chain denken? / Blijkbaar niet van toepassing voor software
« Laatste bericht door Jos De Clercq Gepost op 30 april 2017, 20:34:47 »
Vroeger durfden wij nog eens een spreuk gebruiken, die vandaag[/size]hoogstwaarschijnlijk verboden zou worden:'je mag nooit brillen verkopen in de jungle met de belofte dat ze zullenkunnen lezen' :-)
10
Nieuw board / Re: Bestaat er nog beroepsfierheid?
« Laatste bericht door Jos De Clercq Gepost op 3 april 2017, 21:44:23 »
Zo stilaan overtuigd geraakt dat een minder competente consultant , programmer meer opbrengt voor een softwarehuis, dan een echte vak-man of -vrouw, dan duurt het langer, en mogen ze vaker terugkomen.  Waar geven ze die ondergrondse opleidingen hoe je de schuld bij de servicevragende leert te leggen? En vermits dit toch een moderne benadering is, kan steun via KMO-portefeuille bekomen worden?
Pagina's: [1] 2 3 ... 9