We are continually faced by great opportunities brilliantly disguised as insoluble problems.

Lee Iacocca

Principles of Software Engineering Management
Tom Gilb

Bij Bol.com

If we ever value performance over joy, we will  become great machines and poor human beings.

Paul Coelho

Makers
De Nieuwe Industriële Revolutie
Chris Anderson

Bij Bol.com of Managementboek.nl

Every failure brings with it the seed of an equivalent success.

Napoleon Hill

Tijdens een training kwam het model van Patrick Lencioni aan de orde waarin hij de vijf fundamenten beschrijft die nodig zijn voor een succesvol team:

1. Resultaat.

2. Verantwoordelijkheid.

3. Betrokkenheid.

4. Openheid.

5. Vertrouwen.

Lencioni visualiseerde zijn model in de vorm van een piramide, waarbij vertrouwen de basis vormt en je - laag-voor-laag - uiteindelijk tot resultaat kunt komen.

Interessant genoeg zag ik de vijf lagen van de piramide terug in een interview tussen de nerveuze BBC-journalist Chris Stark met de 29-jarige actrice Mila Kunis.

Chris deelt in het begin dat hij eigenlijk ontzettend nerveus is (vertrouwen). Mila pakt dit goed op en benadrukt meerdere keren dat hij het hardstikke goed doet (openheid). Er ontstaat een geanimeerd gesprek tussen de twee, dat eigenlijk neerkomt op een dappere poging van Chris om Mila uit te nodigen voor een date. Hij vindt haar niet alleen 'hot', maar wil de kans ook niet voorbij laten gaan om indruk te maken op zijn vrienden.

Chris checkt een aantal keren bij zijn eindredacteur of hij niet moet beginnen met het échte interview. Mila is betrokken genoeg om te snappen dat er ook 'resultaten' geboekt moeten worden. Ze neemt haar verantwoordelijkheid door alvast de antwoorden op vragen die haar het meest gesteld zijn over haar nieuwe filmrol.

Zie ook:

• 5 frustraties van teamwork volgens Patrick Lencioni
• Vertrouwen als basis met Patrick Lencioni
• De vijf frustraties van teamwork (boekentip)

To succeed in life we must stay within our strength zone but move out of our comfort zone.

John Maxwell

Volgens Basile Lemaire is het vaak lastig binnen projecten requirements goed te prioriteren. "Bestaande methodieken zijn omslachtig of onnodig complex. Een ander probleem is dat prioriteiten vaak worden bepaald vanuit een it-perspectief in plaats vanuit de bedrijfsvoering. Helaas komt het ook vaak voor dat degene die het hardste roept, bepaalt wat een ‘must’ is." Lemaire ontwikkelde een instrument voor het prioriteren van requirements: het Bulk & Gedonder kwadrant.

Omdat binnen business analyse de MoSCow-methodiek vaak gebruik wordt voor het prioriteren van requirements, gaat Lemaire uitgebreid in op de nadelen van deze methode. Voor wie MoSCow nog niet kent, het is een acroniem van vier categorieën waarin - in dit geval - requirements worden ingedeeld:

1. Must have: requirement is noodzakelijk voor projectsucces.

2. Should have: requirement is belangrijk maar minder tijdkritisch als de must-have, of er is een ‘workaround’ om in de werkpraktijk toch aan het requirement te kunnen voldoen.

3. Could have: requirement is niet belangrijk voor projectsucces; mee te nemen als het weinig kost en wel veel oplevert.

4. Won’t have: requirement draagt weinig bij aan projectsucces of is weinig rendabel en wordt in ieder geval niet nu geïmplementeerd.

Lemaire beoordeelt MoSCoW als een prima methode (eenvoudig, prioriteren vanuit bedrijfsvoering), maar onderkent drie mogelijke nadelen:

1. Het is lastig te bepalen te bepalen in hoeverre een requirement bijdraagt aan succes. In de praktijk bestaat daarbij het risico dat het aan grootste deel van de requirements een must-have wordt toegekend; iedereen wil zeker stellen dat zijn wens wordt meegenomen.

2. Risico van ‘trade-offs’ of compromissen: ik ga mee met jouw must-have voor dit requirement als jij meegaat met mijn must-have voor dat requirement.

3. Risico dat de stakeholder die het hardst roept of het meeste macht uitoefent, bepaalt wat de must-haves zijn. De vraag is dan in hoeverre het gaat om bedrijfsbelangen of om zijn belangen.

Deze nadelen pleiten - aldus Lemaire - voor "een methodiek die vanuit de bedrijfsvoering op een eenvoudige, transparante manier kan prioriteren terwijl eventueel ‘machtsmisbruik’ wordt tegengegaan": het Bulk & Gedonder-kwadrant.

Het Kwadrant gaat uit van afbreukrisico: wat zijn de consequenties wanneer er niet aan een requirement wordt voldaan? Per requirement wordt de prioriteit
bepaald. Het prioriteren geschiedt met stakeholders vanuit de bedrijfsvoering zoals klanten, gebruikers, proceseigenaren en functioneel beheerders. It-risico’s worden in principe als irrelevant beschouwd. Een risico is namelijk pas een risico als een bedrijfsproces in gevaar komt. Dat daar mogelijk een it-probleem
aan ten grondslag ligt, is belangrijk voor je implementatie en oplossing maar niet voor je prioritering.

De prioritering vindt plaats aan de hand van twee assen, de Bulk-as en de Gedonder-as. De Bulk-as: als aan dit requirement niet wordt voldaan, hebben daar (onacceptabel) veel eindgebruikers last van. De Gedonder-as: als aan dit requirement niet wordt voldaan, volgt escalatie (‘komt er gedonder van’).

Op basis van de twee assen kunnen vier kwadranten worden onderkend, die staan voor een prioriteit 1, prioriteit 2 of prioriteit 3:

1. Prio 1: requirement moet correct geïmplementeerd en grondig getest zijn. Indien het (nog) niet correct geïmplementeerd, is de consequentie dat de volgende projectfase, of de in productiename, moet worden uitgesteldust have: requirement is noodzakelijk voor projectsucces.

2. Prio 2: requirement moet in principe correct geïmplementeerd zijn. De opdrachtgever kan er bij tijdsdruk echter voor kiezen dat pas in een volgende projectfase of release aan het requirement moet zijn voldaan.

3. Prio 3: requirement mag onder tijdsdruk of bij budgetbeperkingen sneuvelen; hier gaat men vanuit de bedrijfsvoering geen (serieuze) last van hebben.

Prioriteren volgens het Bulk en Gedonder-kwadrant heeft twee belangrijke voordelen. Allereerst zal een stakeholder, wanneer hij graag wil dat een requirement een hogere prioriteit krijgt, moeten kunnen aantonen dat, door niet te voldoen aan dat requirement, de gebruikerspopulatie er last van kan hebben of dat de zaak gaat escaleren. Aangeven dat iets een must is op basis van machtspositie of hard roepen, gaat nu niet op.

"Een ander voordeel is dat er geen reden is om over prioriteiten te onderhandelen en compromissen te sluiten; het is nu duidelijk waar de werkelijke risico’s liggen als het gaat om het behalen van succes. De ervaring leert dat stakeholders met elkaar goed in staat zijn te bepalen wanneer er sprake is van onacceptabel veel gebruikers op de Bulk-as. Tevens zijn ze in staat een hele reële inschatting te maken wanneer er sprake is van escalatie. Door het groepsproces ontstaat een open discussie over consequenties, projectdoelstellingen en het behalen van de business case."

Lemaire geeft aan dat de verdeling van de requirements over de drie verschillende prioriteiten vaak als volgt is: 50% van de requirements heeft prioriteit 2, prioriteit 1 en 3 geldt voor elk 25% van de requirements.

Bron: Bulk en Gedonder-kwadrant kan uitkomst bieden, Basile Lemaire, in: Computable 07/10/2011

If you're never scared or embarrassed or hurt, it means you never take any chances.

Julia Sorel