POW… Plaats Onafhankelijk Werken.

Op de laatste dag van een jaar komt de bespiegeling… Het jaar 2020 was op zijn zachts gezegd een heel apart jaar. Maar dat hoef ik niemand te vertellen, jullie waren erbij tenslotte.

Plaats Onafhankelijk Werken is vanaf 2020 een feit. Nooit gedacht dat een virus dit zo massaal voor elkaar zou krijgen. Jaren geleden bij Belfius Verzekeringen (Belins) op last van de vakbonden een project geleid die als doel had om alle medewerkers van Belins minimaal 2 dagen per week te laten thuiswerken. Ja hoor, ook de directie en zeker ook de call centers. Een forse klus die correct binnen de gestelde tijd en budget is geklaard. Belins heeft geen noemenswaardige economische last ondervonden van Covid. Sterker nog, zij waren voorbereid en hebben mooie cijfers gehaald. Het personeel was al gewend aan thuiswerken en had hier geen problemen mee. Enkel tijdens de periode dat de scholen gesloten waren… het thuisonderwijs combineren met thuiswerken is echt een energievreter en soms stomweg niet haalbaar. Daar denken de vakbonden nu over na en proberen samen met de directie, de ondernemersraad en medewerkers er iets op te vinden. Niet omdat zij denken dat er een Covid20 zal komen maar omdat zij graag klaarstaan voor de toekomst.

Het komende jaar zal nieuwe uitdagingen brengen en oplossingen, daar ben ik zeker van.

Wat de uitdaging ook mag zijn… de oplossing is er ook. Ik wens iedereen project succes toe!

SPIEGELS…

 “Jeetje, wat ben jij dik geworden!”, wordt mij toegeroepen in de vertrekhal van een luchthaven. “En jij kaal!”, beantwoord ik de luide groet van een oud-collega waar ik jaren geleden een kantoor mee heb gedeeld. Onze partners staan verbouwereerd toe te kijken en verwachten min of meer dat er ruzie zal ontstaan. Niks is minder waar, we zijn blij elkaar te treffen en onze begroeting is een spiegel van onze relatie: eerlijk, open en vol humor.

Spiegels, je hebt ze overal tenminste zo ervaar ik het.

Ik lees in mijn assessment van De Jong & Laan, dat ik 60% Grensverlegger ben, en dat de laatste 40% keurig evenredig verdeeld zijn over Beslisser, Mensen-mens, Visionair en Verbinder. Verbaasd lees ik de beschrijving bij Grensverlegger en herken mijzelf.

Terwijl ik hierover nadenk, kom ik een veel te klein en oud T-shirt tegen met het opschrift “Bloemkool & Kaviaar”. Het T-shirt was een afscheidscadeau van mijn teams jaren geleden en ik snapte de opdruk toen niet direct tot grote hilariteit van de gevers. De uitleg was simpel en bood weer een spiegel: Erika, jij eet bloemkool én kaviaar… jij beweegt je gemakkelijk op allerlei niveaus.

Met een hoofd vol bespiegelingen drink ik koffie met mijn gezin en vertel over mijn diverse spiegelbeelden. Er wordt smakelijk gelachen en de aanvullingen vliegen om mijn oren. Mama is degene die altijd beslist en haar nee blijft nee, ook als je puppy-ogen opzet. Mama gaat letterlijk altijd over grenzen want ze werkt meestal in het buitenland. Mama is sentimenteel want het T-shirtje in maatje 32 gaat weer in de kast. Mijn partner doet eveneens verschillende duiten in het spreekwoordelijke zakje, wat de kinderen en mijn nichtje geweldig vinden.

De eindconclusie van mijn familie is “gelukkig ben je uniek want de wereld kan geen tweede aan”. Ik glimlach terwijl ik mijn gezicht gespiegeld zie in de tuindeuren. De natuur is wijs, eentje is genoeg.

Find Money for Your Project(s)

Some Projects or Ideas have it all: great potential, great teams, and excellent support but no funds. For a lot of Project Managers, this is a reason to stop. The general idea is that if there is no money then the organization is not ready or not willing to execute the project.
I can relate to that way of thinking but there is also another side to it.

FIND MONEY FOR YOUR PROJECT(S)…

First of all, you need to analyze WHY there is no budget assigned to your Project. By figuring out the WHY you get the direction for WHERE to collect funds, and then the HOW is easy enough.

IT IS EASIER THAN YOU THINK. GIVE IT A TRY…

Ask at least on 3 levels WHY the budget is not available, e.g. at your CFO, your Project Sponsor, and at a Project Manager on your own level. Interview them in order to obtain as much information as you can. Ask open questions and try to avoid making assumptions.
Take your time to (double) check your conclusions because these are the starting point for the next step.

When your conclusion is “internal problem, my project was not (properly) presented at the budget commission” then you have your work cut out: create an elevator pitch, put your Project on the agenda of the budget commission and prepare a hell of a presentation.

If your conclusion is “external problem, there is not enough money incoming”, then you look outside the organization e.g. subsidies, gifts, contests, fundraising… In all cases, you have to do the same preparation: the elevator pitch, the presentation, and really know all the ins- and outs of your Project needs and the situation the organization is in.

Does this work?

Yep, it does! We won a contest and collected €500.000, we applied to a fund and raised €175.000, we got salaries paid from a subsidy… Be creative, be brave, and just go for it. Money is always available when you look in the right places. Always.

Celebration as a project tool

WTF is probably the first thing that sprung into your mind, or maybe you are knotting your head because you’ve discovered this already. Celebration as a Project Tool.

None of the existing Project Methods is mentioning Celebration so why do I? Simply because it adds proven value to your Project Management toolbox and it works in all branches, countries, and in all types of projects.

We are used to marking the start of a project with a kickoff, the placement of the first brick or the first pole. So, the start of a project or program is covered and in some fields the marking of the end of a project is also clear, e.g. cutting the ribbon or baptizing a boat.

What happens in between? That is up to the Project Manager who is busy with scope, time, and budget. With solving problems, getting deliverables in, and stakeholder management. Busy, busy! No time or budget to celebrate… Then let’s be creative and find time and budget because celebrating is helping to keep project fatigue out of the picture, is helping to keep up the spirit, it bonds across different borders and across departments or project parts. It makes your project attractive. Every person wants to be part of success.

It doesn’t take much to get the celebration feeling started. Buy ice creams at the convenience store, minibars, or cakes (e.g. Stroopwafels) and present this on well-timed occasions to all involved. They are going to be pleasantly surprised and you’ll see your spin-off almost immediately. For big landmarks or deadlines, you’re serving bubbling (non-alcoholic) wine and beer in a meeting room or venue where invited guests will celebrate with you and your team. In all cases, you’re sure to take pictures and use this in your communication. It happened when we see it.

Zoeken en vinden… echt twee verschillende zaken

“Wie zoekt, zal vinden”, is een Nederlandse uitspraak. En het klopt: zonder zoeken wordt er niks gevonden. Of je iets vindt, hangt af van verschillende factoren. Het besef dat deze twee werkwoorden echt iets anders betekenen gaat je helpen bij het maken, testen of uitleggen van software.

Wat er niet is… daar kan je wel naar zoeken maar wordt daarom niet gevonden. Er is een prachtig zoekveldje, dus zoeken kan maar als een bepaald artikel niet is ingevoerd dan zal het vind-resultaat nul zijn. Andersom kan ook, de artikelen zitten er wel in maar het zoekbereik ‘kijkt’ niet op de plek waar de artikelen zijn opgeslagen. Het resultaat is weer “niet gevonden”.

Het zoeken zit dus overwegend aan de technische kant, en het vinden is typisch iets wat gebruikers willen. Het kan gebruikers niet schelen waar of hoe zaken zijn opgeslagen, zij willen vinden! Probeer bij het bedenken van software, app’s of websites deze twee kanten expliciet te maken.

Een potentiële klant wil bijvoorbeeld in een webshop zijn/haar maat vinden en dat zou je dan ook zo als een gebruikerswens of -eis moeten noteren. Door het zo te doen wordt de vertaalslag naar de techniek dat er een veld moet zijn waar de diverse maten in opgeslagen kunnen worden en dat dit veld doorzoekbaar moet zijn. Zou je opschrijven als gebruikerswens “gebruiker moet kunnen zoeken naar maat” dan kan dat net zo gemakkelijk vertaald worden naar het zoeken in tekstvelden zodat het vind-resultaat mogelijk een marketingtekst wordt… “iedereen met een maatje meer..”, want daar staat toch “maat” in. Built as desiged, kan dan de conclusie zijn. De IT-er heeft gelijk en de gebruiker heeft niet wat hij/zij verwacht.

Door het zoeken en vinden expliciet te maken in ontwerpen, testen en trainingen zal minder tijd en geld verbruikt worden. Het eindresultaat zoals een webshop, een app of andere software zal (sneller) bruikbaar zijn. Het lijkt maar een kleine, bijna triviale wijziging in denken maar de effecten zijn groot.

Dit effect kan je nog verder versterken door niet geslaagde vind-acties te bewaren en te analyseren. Hiervan kan je veel leren. Je kan bijvoorbeeld zien dat er veel voorkomende schrijffouten of leken benamingen in het zoekveld worden gebruikt. Door deze toe te voegen aan de database of assortiment zal het vind-percentage toenemen en daarom ook de kans op verkoop of tevredenheid van de gebruiker.

Make New Mistakes…

Making new mistakes is hard. The old are easy. How to change it?

The year 2019 started for me and my teams with the New Years intention to make new mistakes.

Are you grinning right now?

That is probably because you relate to the subject. Making old mistakes is easy. We do not want this to happen but every now and then we are confronted with the fact that we are repeating our mistakes.

Habits, habits and habits

We are all creatures of habits. In our personal life as well as at the job. On top of that we are as Project Managers conditioned by the Project Methods we follow. The deliverables “Lessons Learnt” and “Closing Report for Steering” are just a couple examples. We deliver them and then? Is the new project that starts after yours, looking at your Lessons Learnt? Are they acting on the recommendations? Is the Steering interested in how much money is not spoiled on old mistakes? Nope.

Stop spoiling money and effort on old mistakes

By accepting that we are habits trigged we have half of the solution. We need to establish new habits. And that is hard work for all involved. Do we need to put effort into this? I do not know your specific situation but in general 4 to 13% of the project budget is spoiled on stuff you could avoid by not repeating old mistakes. Nice isn’t it?

How to?

A good start is to have a focus point. Beside the out loud spoken intention, I used a replica of the tile you see in the left corner and put it in our project room, so we looked at it daily. It did remind us at our intention and brought the subject in several occasions to the table.

We started the habit of asking ourselves the question out loud “Have we seen this before?”. By doing this we were creating a new habit and we were using previously used solutions or insights more quickly. The downside is that we didn’t had any experience with the new mistakes, but our new habits were helping us out. Creating new habits is work in progress so don’t be too hard on yourself. Be honest, laugh about your own stupidity and move on. Describe the mistake and the work around. Be sure to keep on making new mistakes.

Keep on growing.

Techniek is alles!

Een knappe en uiterst verzorgde adviseur toegangssystemen roept dit bijna lyrisch als ik hem vraag om uit te leggen wat hij adviseert voor de Trade afdeling. Techniek is alles!, herhaalt hij nog eens enthousiast.

Een Trade afdeling hoort een gesloten domein te zijn, en dat is het nu nog niet. Het gaat om groot geld en om serieuze contracten. Hier horen geen onbekenden rond te lopen, dat kan echt niet.

Ik werk als programma manager bij een energiebedrijf in het zuiden van Nederland en heb de opdracht gekregen om het handelsplatform te vervangen. Uitdagende klus omdat de handel tijdens deze exercitie gewoon moet doorgaan. En nu, is het dus tijd om de toegang tot de zaal aan te scherpen want het laatste wat ik wil, zijn verrassingen… onaangename verrassingen die voorkomen hadden kunnen worden.

De mooie man vertelt van irisscanners, duimafdrukken, databases, noodstroom-voorzieningen en hoe fantastisch dit allemaal is. De goedkoopste oplossing kan ik al voor een paar ton inkopen en de beste heb ik al voor een kleine miljoen. Ik laat hem een poosje oreren en vraag dan zacht “Wat zijn de kwetsbare punten?”, waarop de beste man stilvalt.

Uh, eh… sputtert de man. Zijn verkooptechniek heeft hem geleerd dat we nu over de kostprijs moeten gaan steggelen en dat doe ik niet. Een tikje ontredderd kijkt de man mij aan en beweert “die zijn er niet” en dat was zijn fout.

Techniek is alles! Onderhandelen is daar één van. Een geweldig systeem bij die man afgenomen voor een halve ton. Zijn provisie is waarschijnlijk nul, maar hij heeft ook een gratis lesje techniek gekregen dus een win-win situatie wat mij betreft.

Retrospective is ouderwets!

Een Retrospective is ouderwets!, wordt mij stellig verteld. Dat is dan mooi is mijn reactie. Dan halen jullie hier al alles uit… toch? Nou, we zijn ermee gestopt. Het kost te veel tijd en dat kunnen we beter stoppen in programmeren.

Dit maken we echt heel vaak mee en wat er mee bereikt wordt, is dat oude fouten blijvend worden herhaald. De grootste opbrengst financieel, in doorlooptijd en kwaliteit wordt gerealiseerd met Retrospectives. Mits, goed gedaan… Dus, niet stoppen maar jezelf en je team bekwamen is ons advies.

Een van de meest voorkomende fouten die gemaakt wordt is het gebruik van een JIRA pagina. De pagina zelf is niet het probleem, maar het sjabloon gericht zijn wel. Het team weet precies wat er gevraagd gaat worden. Doet dit omdat de Scrum Master hen hiertoe dwingt en dan wordt het een verplicht riedeltje. De resultaten van een Retrospective bewaren is heel, heel wenselijk alleen zou dat door de Scrum Master separaat gedaan moeten worden.

In de meeste teams kijken we uit naar de Retrospective. Daar zien we onze groei, onze verbeterpunten en voelen we de wind in de zeilen. En wat is er mooier dan dat gevoel?! Dat gun je echt iedereen. Elk team en elke organisatie.

Gebruik eens beeldtaal (bijvoorbeeld de association box), of het Yahtzee spel, de zeilboot-poster, het M&M vragenrondje… kortom, blijf creatief. Hou het kort (15-20 minuten) en bewaar de resultaten op een uniforme wijze zodat deze met elkaar vergeleken kunnen worden. Verras je team eens met een terugblik waarmee jullie goed zien waar jullie vandaan kwamen en nu al beland zijn. Omarm verbetering en groei! Elke stap is er een.

Gevraagde oplossing past niet bij het probleem, en nu?

Aan de telefoon wordt expliciet om een projectmanager gevraagd. Er zijn functionaliteiten aan nieuwe klanten verkocht die nog niet bestaan. Deze moeten snel bedacht en geïmplementeerd worden. En de opdrachtgever wil dat dit gewoon nog in Waterfall-projecttechniek gedaan wordt want ze zijn toch nog niet zo lang met Agile bezig. De capaciteit is het grootste probleem vertelt mijn contact, de aanwezige programmeurs en analisten zijn overbezet. Een stevige projectmanager wil hij. Eentje die de beloofde functionaliteiten voor de nieuwe klanten op tijd levert, de nieuwe klanten blij maakt en de relaties intern goed houdt. Gewoon analisten lospeuteren in de organisatie, begroting van mandagen maken en lekker strak in Waterfall het project leiden. Kom dat maar even doen, beëindigt hij zijn monoloog.

Ik laat een korte stilte vallen en vraag dan “Mag ik ook een oplossing voorstellen die echt gaat werken?”. De doodse stilte die hierop volgt is een beetje onaangenaam maar dan klinkt het “Vertel!”.

Ik snap jullie goed begin ik. De nieuwe werkwijze rapporteert anders dan je gewend was, de nieuwe werkwijze voelt wellicht niet echt sturend aan. De analisten en programmeurs plukken zelf hun werk uit een lijst… Het is allemaal zo nieuw.
En, om tot jouw gewenste resultaat te komen “werkende functionaliteiten en blije klant” is Agile je beste kans. Niets zo veranderlijk als de wensen van de klant…

“Maar eh…”, reageert mijn relatie “hoe verkoop ik dit aan de financieel directeur? Want, ik weet dat jij jouw adviezen altijd goed overweegt maar zij wil alleen maar duidelijkheid. Wil op voorhand weten wat het kost en wat we krijgen.”

Dan kan ik je gerust stellen. Agile biedt dit, wel op een andere wijze als je gewend was maar zeker even goed. Hierna maken we een afspraak om een Teams-meeting te hebben met de CFO .

Assumptions are dangerous to Projects

Wouldn’t it be great if a sign, like shown here above, popped up in your Project every time an assumption is presented or made?! It would warn you, the Project Manager in time.

Assumptions are dangerous to your Project…

You’ve got the assignment, you’re PM for a challenging project. Your contact used phrases like “most important project this year for our company” and “all are excited”, during your intake meeting. You assume “I am needed, I am wanted, the whole organization is anxious to work with and for this project.”

When working with suppliers and the key person states “we deliver all working tomorrow”. With no prior experience with this key person. You assume “Delivery is okay”

You leave the Steering after presenting your weekly progress and no remarks of questions were posted from the attendees. You assume “Everything is fine!”

Let us stop with these 3 examples.

Some readers will argue that the given examples of assumptions were conclusions based on the given input or info. True! You can look at it that way. And, checking is better, really the best.

Start your stakeholder management directly and ask your contact during the intake-meeting more in-depth questions like “Can you tell me more about the support this project already has?”, “Who is the biggest supporter?”, “Which department is the least supportive?”, etc.

In the case of the supplier: Check with other colleagues that have previous experience with the supplier what their experiences were, so you know the risks upfront for this delivery.

And, mannn… leaving a Steering Committee without having to answer questions or replying to remarks is a big red flag. Your project is not fine at all. It misses support of the stakeholders at least or the communication is not fine-tuned towards the attendees and they had no clue what you were telling them. Or, in the worst case, this was the last meeting with this group. On another level, the decision is already made to shut your project down. In all cases it is all hands on deck Project Manager: time to meet your stakeholders one-to-one.

Schiet of niet?

“Stop, niet schieten!” of “Stop niet, schieten!”

In beide zinnen staan 3 woorden, 1 komma en 1 uitroepteken maar er is een wereld van verschil in de lading van de tekst. Zo krachtig, mooi maar ook gevaarlijk is communicatie.

Voor een programmascan mochten wij jaren geleden eens meer dan 100 projecten scannen. Een van de onderdelen van zo’n scan is het lezen van de Lessons Learned van elk project. En wat bijzonder opvallend was, was het terugkerende onderwerp communicatie. Dat moest de volgende keer echt beter.

Nu zijn we jaren verder en de klacht blijft. In de retrospectives, een techniek behorende bij Scrum en Kanban, horen we deze ook vaak. Soms als smoes, dat moet ik toegeven. Het is gemakkelijker om de communicatie de schuld te geven want het is lastig om hardop te zeggen wat jezelf kan verbeteren. En toch is dat precies wat we dan gaan doen.

Communicatie heeft heel veel te maken met relaties. Kijk maar naar de social media. Daar wordt allerberoerdst Nederlands en Engels gebezigd en toch gaat het heel vaak goed. Mensen willen de boodschap achter de geschreven tekst goed interpreteren.

Een van de conclusies uit de eerder genoemde scan was dan ook dat relatiebeheer verbeterd moest worden. Dit heeft dat betreffende ministerie echt gedaan en de klachten over slechte communicatie namen meetbaar en drastisch af met als gevolg een betere projectcultuur en betere projectresultaten.

Afhankelijk van de relatie kies je voor “Stop, niet schieten!” of juist voor “Stop niet, schieten!”.

Wat een MUTS!

Geen idee wat er tegenwoordig in het water zit of misschien komt het door het aanhoudende warme weer maar ik herinner mij de meest leuke zaken uit projecten die al heel lang geleden afgerond zijn.

Zo zie ik in mijn verbeelding weer een hele jonge collega stiekem wijzen naar een bloedmooie vrouwelijke accountant terwijl de pukkelige jongen lispelt “Wat een muts!”.
Ik reageer verontwaardigt “Hoe zo muts? Je kent haar niet!”. Waarop hij wijsneuzig kijkt en heel beslist knikt “MUTS, zeer zeker! Mooi Uiterlijk Toch Slim”. Het mannetje had gelijk.

Of die keer dat ik moest toegeven dat ik een projectmethode niet kende. “Sorry, maar de JBF methode ken ik niet.” Waarop ik smakelijk werd uitgelachen. “Dat staat voor Jan Boeren Fluitjes”. Tja, die ken ik wel.

Met een glimlach klap ik nu mijn laptop dicht en ga ik op zoek naar een koel drankje.

Scrum Master en Projectmanager in één

Officieel zijn Scrum Master (SM) en Projectmanager (PM) twee compleet verschillende functies maar in de praktijk worden de functies vaak gecombineerd uitgevoerd. Niet in de laatste plaats omdat een bedrijf volop in de transitie naar het Agile werken zit. Er zijn dan teams of deelprojecten die werken nog volgens Prince2 of IPMA en een aantal andere zijn al ‘over’ naar Scrum of Kanban.

Met twee petten op je hoofd wordt van een SM/PM extra agility gevraagd. Immers de Prince2/PMI, zeg maar de meer traditionele projectmethodes, die gaan uit van een PUSH mechanisme. De projectmanager draagt de taken op aan de teams en/of teamleden en bepaalt volledig de wat en wanneer. In de Agile technieken, zoals Scrum en Kanban wordt met een PULL mechanisme gewerkt. Iedereen haalt van de backlog (de to do lijst) het werk op waar we dan bij hebben afgesproken dat het meest urgente bovenaan de lijst staat. De Scrum Master bewaakt de snelheid waarmee de taken worden opgepakt en uitgevoerd en bepaalt dus niet wat er door wie wordt uitgevoerd.

Een andere reden waarom Scrum Masters eveneens Projectmanagers blijven, is omdat de afdeling Financiën vaak als laatste de transitie naar Agile werken aangaat. De directieleden zoals CFO, CEO, CIO werken nog steeds met een traditioneel budgettenstructuur, met traditionele verslaglegging en rapportages. De aanleverende afdeling Financiën blijft hierdoor aan de uitvoerende Scrum Masters en/of Project Managers hun input vragen op de traditionele manier.

Een uitdaging voor SM/PM! Zoals altijd wil je project succes en dat wordt nu langs twee compleet verschillende meetlatten gemeten. De traditionele manier van Scope, Break down, planning en budget status en de nieuwe manier van Sprint Backlog, Burn Down en Velocity.

Op welke manier kun je de transitieperiode zonder al te veel kleerscheuren doorkomen?

Met eenvoud. Beide methodes kennen de eenheden Scope, Tijd, Geld. Dat is je kruispunt.

In Agile spreken we niet van geld maar dat is er natuurlijk wel. Als een team bijvoorbeeld 8 teamleden heeft met een totaal aantal te besteden uren voor dit team van, zeg 100 uur of 150 story points dan is dat het budget. De scope is dat wat in de sprint backlog staat en de tijd is je sprint lengte (meestal 2, 4 of 6 weken).

Het is echt valide en zelfs prima om voor een bepaalde afgesproken tijd een hybride rapportage te gebruiken. Neem de tijd om de collega’s bij Financiën uit te leggen wat je exact rapporteert. In zo’n hybride rapport wordt eerst de nieuwe rapportage getoond en aansluitend de traditionele variant. Stuur de rapportage niet op maar laat ze zien waar het gehaald kan worden. Dat is weer een stapje in de richting van een PULL.

Mixed Methods… what recipe works?

You arrived early to avoid traffic jams or other obstacles in order to get a great first impression. You’re are a seasoned Project Manager with the necessary paperwork and track record to proof you’re up to the task. They asked for a PM with Scrum and minimum of 5 years’ experience. The meeting went fabulous and you’ve got the assignment.

After some days you realize that the Scrum-method is still to be implemented over the organization, basic data is kept in various systems, data quality is not always reliable… Now the real job starts. How to get all Project Teams aligned, get accurate data for the Steering, get control over progress, problems, and solutions?

Mixed Methods in your Project, Program or Organization: What recipe works?

The first part is that we never fight complexity with more complexity! Keep it as simple as possible. Always.

Second part is to acknowledge that we Project Managers, navigate on 3 basic things;

Scope, Time and Budget. No more, no less.

Sounds easy enough but then reality kicks in (again). The majority of your teams are from external parties, the teams work in different countries and maybe in their time zone, and last but not least the level of maturity differ extremely. It is time to call in the troops…
Your team! Find a timeslot that works for all project leads and invite them to the Problem Review Board. Every workday e.g. at 12h the group spends 30 minutes where all answer briefly to “What is your problem? Who or what do you need?”. The match between problem and solver is made and you move on to the next participant. All the details will be worked out outside the PRB. The sole purpose of a PRB is to match the problem with the solution/solver.

Up till a group of 20 this works great.

There you have it. Your basic recipe. Now it is up to you to extend it to your needs, your situation, your skill level.

Gruwelen van twijfeltaal

Ik lees een auditrapport geschreven door een mens met twee titels die werkzaam is bij een heel duur consultancy-huis en kom bij de zinsnede “in sommige gevallen moet de beveiliging wat stringenter”. Het bezorgt mij een rilling. Stop toch alsjeblieft met die twijfeltaal denk ik en pak mijn telefoon die met een piepje net heeft laten weten dat ik een nieuw bericht heb ontvangen.

In het eerste e-mailtje dat ik open, lees ik “Waarschijnlijk zijn 50 stuks…”

Nee! Hoezo “waarschijnlijk”? Kan je niet tellen en heb je het maar geschat? Even verderop blijkt dat er wel degelijk een telling en een hertelling is geweest. Het woord “waarschijnlijk” is alleen maar gebruikt uit gewoonte, als een schrijfstijl en gelukkig deed men zijn werk.

Laten we afspreken dat we “eigenlijk, hopelijk, in principe, in het algemeen, waarschijnlijk, tot op zekere hoogte en in sommige gevallen” niet meer gebruiken in bedrijfsvoering, correspondentie, rapporten en projectdocumentatie. Want het schrijven in twijfeltaal voegt niet toe. Het wekt enkel de indruk dat er slecht werk geleverd is, dat er onzekerheden zijn of vaagheden.

We doen ons werk goed en beschrijven dit zoals het hoort. Akkoord?

Kennisvermenigvuldiging

Kennisdeling is eigenlijk kennisvermenigvuldiging maar wat maakt het uit hoe het genoemd wordt, als het maar veelvuldig wordt gedaan. Een van de beste plekken is de koffiehoek. Daar wordt veel uitgewisseld.

Ga daar eens empathisch luisteren en jouw kennis wordt aangevuld. Soms wordt alleen je moppenkabinet opgeleukt en lach je even smakelijk maar veel vaker pik je andere zaken op. Hele feitelijke dingen zoals vertragingen in teams die nog niet vermeld zijn op een Jira-bord en daar mogelijk ook nooit op vermeld gaan worden. Toch fijn om dit te weten als het jouw taak is om samen een project succes te realiseren.

Als je de specialist aan het woord hebt gehoord in de koffiehoek dan hoef je geen ticket meer in te schieten bij een helpdesk. Je weet al hoe het moet. Specialisten zijn gigantisch druk maar zijn regelmatig te vinden in de koffiehoek.

Dezelfde koffiehoek is ook een prima plek om te peilen in hoeverre jouw kennisvermenigvuldiging al gelukt is. Wie weet van jouw project? Hebben zij ook gekozen om jouw project een succes te laten worden? Kennen ze de doelstellingen, de beoogde opbrengsten, de nieuwe technieken?

Denk nou niet dat ik alleen maar sta te koffieleuten, maar zoals ieder mens moet ik ook drinken en dan combineer ik graag het aangename met het nuttige. Ik deel en daarmee vermenigvuldig ik kennis.