Archive for the ‘process management’ Category

Effectief beheersen van transities door onzekerheid om te vormen tot kracht

1 July, 2017

Als ik om mij heen kijk, zie ik vele agile initiatieven. Iedereen in een agile transitie verkeert op enig moment in extase (ziet een mogelijke toekomst), verwachting (van een direct resultaat), of (veelel grote mate van) onzekerheid (“waar zijn wij/zij in hemelsnaam aan begonnen!”).

De transitie teams zijn zeer wel in staat om extase en verwachtingen te managen. Het omgaan en effectief gebruiken van onzekerheid is iets wat de meeste transitie teams (nog) niet beheersen.

In deze blog ga ik in op welke manier je onzekerheid tot kracht kunt omvormen.

Onzekerheid
Onzekerheid komt in vele gedaanten. Het is ook een belangrijke oorzaak waarom transities in meer of mindere mate falen. Het kost energie en tijd. Denk bv aan al die momenten waarop mensen met elkaar in gesprek gaan over de transitie en hun perceptie ervan. Deze gesprekken en eruit volgende ideeën en mentale modellen, frustreren en zorgen voor onrust en tegenwerking. De energie loopt bijna letterlijk weg.

De frustratie komt onder andere voort uit het feit dat (het lijkt) dat het transitie team de gevoelde impact van de transitie en de mentale gevolgen hiervan, niet lijkt te zien, niet lijkt te willen zien, of (mogelijk nog frustrerender) er niets aan te willen doen.

Het transitie team heeft ook veel onzekerheid. Immers, zij hebben een complexe organisatie, die zij op een juiste manier, anders willen gaan laten werken.

Er bestaan voor deze transities geen best practices. Voor iedere organisatie wordt succes bepaald door andere factoren. Geen organisatie is hetzelfde, heeft dezelfde processen en veeeeeel belangrijker, geen organisatie bestaat uit dezelfde mensen!

Dit heeft tot gevolg dat het transitie team wel verschillende mogelijke manieren van aanpak heeft, maar het niet in staat is op voorhand te bepalen, welke aanpak tot welk resultaat zal leiden.

Dus misschien ligt de grootste onzekerheid wel bij het transitie team. Simpel en alleen omdat iedereen wel verwacht dat wat zij doen, het (enige) juiste is.

Alhoewel het transitie team feitelijk zou moeten zeggen,

wij weten het ook niet, wij hopen met deze aanpak het beste resultaat te bereiken, maar zeker zijn we er niet van”, 

zeggen zij

Wij hebben goed nagedacht. Onze aanpak is de enige juiste. Als jullie je best doen en precies doen wat wij zeggen, komt alles goed”

Over onzekerheid gesproken!  Hopelijk lezen zij deze blog ook ….

Onderliggende problemen
Onduidelijk doel
In agile transities is het doel nogal vaag. Meer flow, meer responsiveness, De business gaat ook ‘scrummen’ zijn niet bepaald termen wat voor een ieder helder is wat dit in de praktijk betekent.

Geen vertrouwen in de transitie het het transitie team
Door het ontbreken van vertrouwen zal er weinig feedback zijn mbt de ingezette transitie. Hierdoor heeft het transitie team geen of onvoldoende mogelijkheid de ingezette transitie aan te passen en genomen besluiten zodanig te vormen naar de zich veranderende werkelijkheid op de ‘transitie-werkvloer’. Er dreigt dus een (gapend) gat tussen de transitie leidinggevenden en de mensen op de werkvloer.

Mentale modellen
Veelal werkt de organisatie die de verandering in gang zet al jaren op een min of meer succesvolle waterval aanpak. De hele organisatie is ingericht de falende aspecten van de waterval aanpak (veel her-werk; silo-vorming, zware governance teams, etc) voortvarend te lijf te gaan. Deze groepen worden met Agile aanpak deels overbodig, of gaan in de teams/projecten op. Ongeloof, onzekerheid en tegenwerking borrelt langzaam maar zeker op.

Heb ik nog een baan straks?
Doordat agile manier van werken vaak betekent dat er minder afdelingen en mensen nodig zijn voor betere kwaliteit en meer opleveringen, ontstaat vanzelf onrust. Heb ik straks nog een baan? en zo ja, hoe ziet mijn nieuwe rol er dan uit? Ga ik minder verdienen? Moet ik meer uren maken? Hoe en waar ga ik dan op worden afgerekend? Ben ik voldoende opgeleid?

Mijn management Agile? laat me niet lachen!
In een organisatie die groot is geworden met command en control structuren, en nu een Agile transitie start, is de vraag zeker gerechtvaardigd, of het huidige management de verandering wel aankan. Zijn zij in staat de agile mind te verinnerlijken. Zijn zij in staat verantwoordelijkheid en autoriteit die daarmee gepaard gaat lost te laten en naar lagere niveaus over te laten?

Omgaan met de onderliggende problemen
Door de mensen een kanaal te geven hun ideeën, ervaringen en bezorgdheden te uiten, pakken we hierboven beschreven onderliggende problemen aan. Door deze uitingen serieus te nemen en input te laten zijn voor de transitie aanpak, ontstaat vertrouwen in de transitie. Maar nog veel belangrijker is dat de mensen, zich gehoord voelen en daardoor zichzelf deel gaan laten uitmaken van de transitie.

Dit kanaal noem ik Oneteam.

De aspecten van het omvormen van de organisatie, het loslaten van oude patronen en het inslijten van nieuwe (agile gebaseerde) practices, laat ik in dit blog buiten beschouwing. Kern van het succes is de mensen die de transitie serieus te nemen. Deze mensen ervaren namelijk op dagelijkse basis het (onbedoelde) effect van ieder besluit.

Oneteam
Oneteam verzamelt ervaringen van mensen op een continue basis. Dit maakt dat wanneer je een idee hebt, of ergens last van hebt, je dit direct kunt delen. Het delen gebeurt door het vertellen/opschrijven van korte anekdotes. Wanneer blijkt dat het transitie team deze input, jouw input!, gebruikt om de transitie aan te passen, voel je je zekerder. Er ontstaat vertrouwen naar beide kanten. Er worden méér ervaringen van de werkvloer gedeeld, én de besluiten zijn constant in directe relatie met de feedback van eerdere besluiten. Er ontstaat een versterkende lus.

Door deze symbiose ontstaat een ware agile transitie. Door de constante Inspect & Adapt cycle groeit de organisatie naar constant nieuwe vormen. Iedere nieuwe vorm past net iets beter dan de vorige. De organisatie wordt lerend.

Oneteam opzet en resultaat
Oneteam bestaat in 2 vormen.

Richt je je eenmalig op een team, of een aantal teams, kun je volstaan met workshop(s).

In de workshop deelt het team ervaringen en ideeën. In een aantal vervolgstappen worden de persoonlijke ervaringen geanonimiseerd. Gedurende de stappen ontstaan thema’s waaraan acties worden gekoppeld. De acties worden in de transitie backlog geplaatst. doordat iedereen kan deelnemen is iedereen ook eigenaar van het resultaat en de acties.

Bij grote en langdurige transities is een tool effectiever. via een website en app kan iedereen in de transitie continu zijn of haar ervaringen en ideeën delen.

Zo ontstaat een rijke bron van relevante en continu veranderende beelden uit de transitie.

De feedback wordt óf door een separaat team óf in (grote) workshops geanalyseerd. Beide vormen maken het mogelijk gegevens vanuit verschillende perspectieven van betekenis te voorzien. Hiermee kan het transitie team bv bepalen welke welke impact bepaalde besluiten hebben. Voorbeelden van perspectieven: alle positieve anekdotes na een bepaalde datum door een bepaalde groep betrokkenen, of alle verbeter ideeën vanuit scrum teams. of alle negatieve feedback van externen. Doordat men de achterliggende anekdotes kan lezen, worden de analysis scherp en de vervolg acties pragmatisch en met een directe impact.

Succesvolle transities
Betekent dit dat met Oneteam iedere transitie succesvol wordt? Ik hoop van wel. Maar natuurlijk ligt het succes in de (verander)kracht van de organisatie, en in de competenties, daadkracht van de mensen in de transitie.

Wat Oneteam wel voor een transitie betekent:

  • een continue bron van rijke, relevante en betrouwbare informatie over de gang van zaken op de werkvloer
  • anonieme anekdotes, wat maakt dat mensen vrij zijn te delen wat zij willen. Ervaring leert dat deze anonimiteit nooit misbruikt wordt.
  • transparantie: van werkvloer naar het transitie team, en van transitie team naar de werkvloer
  • de mogelijkheid om mensen in een moeilijke, persoonlijke en onzekere tijd, hun gevoelens, ideeën en ervaringen op een zinnige manier te delen
  • onmisbare ondersteuning voor ieder transitie team
  • het voorkomen van ‘blind’ moeten navigeren tijdens transities
  • het uit kunnen voeren van experimenten; door de snelle en korte feedback lijnen, kan er kort op de bal worden gespeeld

Van onzekerheid tot kracht
Deze experimenten zijn in feite de kern en de manier waarop het transitie team onzekerheid omvormt tot kracht.

Agile betekent het onzekere omarmen en door middel van een aantal (liefst parallelle) experimenten, de organisatie snel te laten leren.

How to create flow.

24 March, 2017

Flow is the new buzz. Each of us knows exactly what flow is. And how it feels. It feels great! You probably have even experienced it yourself. Great!

But flow in relation with work?  That is something else. It needs planning,  and changing work habits.

But we can create flow in our work environment. We are able to let work items or information flow through our work processes. Just look at the car manufactures. Their assembly lines are a perfect example of flow. But it took them many years and hard work.

The good news is that we can also implement flow in creative work places. Whether we create fancy apps or provide services. In HR departments, DevOps teams, back office, marketing teams, they all are able to create flow in their delivery process

Below I explain how you can start to implement flow.

Visualize your system to identify your bottleneck

    1. Identify Bottlenecks/constraints.
      • Draw a value stream map (VSM) to  visualize your system.
      • The VSM creates a common language to engage your stakeholders in your endeavor.
      • The value stream shows you the constraints. Probably you already knew the constrain (or had a good guess). But it is like handling risks, once they have been documented, they become somehow more real. This is also true for constraints.
        • Also good to realize is that you handle constraints with care. Even with more care then porcelain. It involves people. and the tricky thing is that people who are part of the constraint, became the constraint due to the system. Not of what they did or did not do!
  1. Eliminate constraints (not the people!)
    1. Exploit the constraint.
      • Let the constraint only work on the flow-impeding work.
      • Reduce the amount of incoming work using WIP limits to the level that the constraint is able to chew.
    2. Increase the constraint capacity.
    3. Find the next constraint.
  2. Ability to manage stakeholders that impact the constraint.
    1. The demand of work is defined outside your responsibility level. So in order to balance the demand with the available capacity, takes some diplomacy and persistence.
    2. Further downstream stakeholders are in need of your work items. They will claim your capacity is not fully used.
    3. Invite your stakeholders to some flow experience
      • Involving your stakeholders in a short Flow simulation workshop, combined with theoretical explanation on queuing theory may just do the trick to at least allow you to do an experiment with manage the work through WIP limts and other queuing theory techniques. (The Okaloa Flowlab simulations offer a range of different simulations that address all aspects of flow).

Some additional advice.

Start with flow simulations with some key stakeholders. They first need to understand the basic concepts of flow, queuing theory and WIP limits. This also let them experience the impact of WIP limits on the speed and reliability of their delivery requests.

On team level  create a stable input of work. Ensure that the teams grow into a stable delivery cadence. Use the team simulations to allow the team to experiment and experience flow in their own environment. You can use the actual work environment of a sprint to experiment with reducing WIP and allow the team to  become more stable and predictable in their  deliveries.

Next step is to let multiple teams that work to create flow of their combined teams. Run the cross team simulation as a start to have teams and product management experience and experiment addressing aligning capacity differences to a smooth delivery cadence.

Upstream, product management  (program or value stream level) implements a Kanban system that adheres to the same principles of flow as on team level. But here is one additional focus point.

Internal product management use WIP limits to effectively deliver a constant flow of work requests for the downstream teams.

From the perspective of the downstream teams product management takes care they have at all times sufficient work requests (options) available. This ensures that product management is never overstressed in producing sufficient work for the downstream delivery teams (quality, instable workloads up- and downstream). For the downstream  teams this means they have at all times sufficient work on their incoming backlog.  They are able to maintain a stable cadence.

For more information on  simulations  look at the available workshops in Europe on Okaloa. On May 19th we offer a public workshop  on the Okaloa Flowlab simulations in which we  specifically address implementing Flow or Kanban systems in SAFe environments and other scaling approaches.

 

Lean development: from safe-fail design to safe-fail experiment

24 April, 2012

Safe-fail design is tricky and almost impossible. Safe-fail experiments using the Cynefin-model and SenseMaker®-tool suite provide a much better solution.

Safe-fail-design is nearly impossible because the design-team takes early decisions which are only much later delivered to customers. When decisions are made early in the development life cycle, not all aspects, related to that decision are known. It is more then likely that issues pop up much later. Correction of faulty early design decisions becomes a costly, frustrating and sometimes technically tricky issue.

Safe-fail experiments work best in complex environments. Complex environments have many stakeholders, of which many have different backgrounds and therefore different needs, wishes and constraints. All these have to be incorporated somehow in the total set of requirements.
In this fast moving world, stakeholder needs, wishes and constraints, never stay the same for a long period of time. The designer(s) have to take this into account. But how?

As earlier mentioned, the Cynefin-model provides a solution placing design-problems in the complex domain. The linked solution of complex problems is to experiment on a small scale with different possible solutions. Those that work are continued and strengthened. Experiments that does not work are simply ended. Lean Development incorporates experimentation.
Using lean development, the complete development team designs, builds, tests and delivers a small (set of) functionality within 2 or 3 weeks. This way an environment for experimentation is created for the development team to find out if they actually do have a correct common understanding on the meaning of the needs, constraints and wishes of the stakeholders. This enables safe-fail experimentation.

This solves the first part of the problem. The team is able to deliver to the stakeholder that functionality that the team believes is exactly what the stakeholder needs. If it is not, the team has learned a valuable lesson against low cost. The stakeholder is content that the development team listens to his needs and that they take him seriously.

Now to the aspect of the huge amount of stakeholders and their variation. Additionally stakeholders may not be located near the development team, and they might speak different languages.
Also typically stakeholders do not know what they actually want to have. They do not know what is possible. And if they know all the aforementioned, they often lack the words to bring across exactly what they need to the design-team.

Story telling is a proven way to share information on a complex problem. By letting stakeholders tell their (vision and user)-stories, they focus on what is important and critical for them. Stakeholders add additional meaning to their requirement specs (through SenseMaking). This eanables the development team to identify and evaluate patterns that are present in the metadata to understand the requirements in the stories and priotize them. The software and the characterization process supports different languages.

Combined, the 2 approaches provide a solution for organizations to handle many critical stakeholders who move with their views and opinions in this fast emerging world.
Safe-fail experiments support functionality to emerge during development.

In a later blog I’ll describe how to get from a vision-level of user stories to a user story which a development/sprint team can deliver in one sprint.

5 tips voor gelukkige en efficiënte medewerkers

8 January, 2012

Iedereen kent ze, medewerkers die ogenschijnlijk veel werk verzetten en dit doen zonder veel over te werken. Zij zijn ook nog eens goedgehumeurd en komen en gaan met een glimlach. Het zijn de mensen die zowel gelukkig als efficiënt hun werk doen. Het zijn ook deze mensen die anderen in hun omgeving beter laten presteren.

Hun tegenpool kent ook iedereen. Je ziet ze vaak bij het koffieautomaat de gang van zaken van giftigecommentaar voorzien. Zij ontnemen anderen de lust en energie in het werk. Ze zijn de intriganten van uw team of onderneming.

Gelukkig is de gemiddelde medewerker niet zo extreem negatief. Maar ook niet echt positief. En dat is jammer. Want positief ingestelde mensen zijn blij, vriendelijk, energiek,  klantgericht, collegiaal en bereid tot leren. Dit artikel geeft enkele praktisch tips over hoe medewerkers gelukkiger én efficiënter te laten zijn.

Nog even iets over gelukkig zijn. Gelukkige mensen zijn mensen die best wel eens balen of teleurgesteld zijn. Maar zij herstellen snel van een tegenslag, en blijven hier niet in hangen. Als iets mislukt is, denken ze na op welke andere manier ze dit toch kunnen realiseren. Zij blijven niet hangen in wrok, en zoeken de oorzaak niet standaard buiten zichzelf. Zij beseffen dat dezelfde (re)acties, dezelfde resultaten opleveren. Na een mislukking proberen ze iets anders waardoor er een ander resulaat ontstaat. Kortom gelukkige mensen zijn vaak ook effectieve mensen.

Mensen gelukkig en efficiënt maken is onmogelijk. Mensen gelukkig en efficiënt laten worden is wel zeer goed mogelijk.  Ik geef een aantal tips die iedereen direct kan toepassen. Let wel, je hoeft geen directeur of manager te zijn om dit toe te passen. Begin gewoon in je eigen team.

1.  Wees zélf gelukkig en efficient.

Medewerkers prikken feilloos door loze woorden.  Dus wanneer je anderen gelukkiger en efficienter wilt maken, moet je zelf  gelukkig en efficient zijn. Je kunt hiervoor ook een bestaand rolmodel in de eigen organisatie gebruiken. Maar besef dat als je zelf niet de nodige stappen zet en laat zien dat je hier actief aan werkt, mensen niet zullen volgen. Mensen volgen actie, geen woorden.

2. Maak al aanwezige gelukkige en efficiënte medewerkers meer zichtbaar.

Dit is een variant op successen vieren. Medewerkers die gelukkig en efficient zijn in hun werk en anderen hiermee ondersteunen, zijn de ambassadeurs van de nieuwe manier van werken. Zij coachen anderen en u laat zich ook zichtbaar door hen coachen.

3.    Creëer een leeromgeving.

Kinderen leren door spel en het maken van fouten. Uw medewerkers leren te zien wat er is misgegaan door het analyseren van fouten.

Systeemfouten zijn er vaak de oorzaak van dat medewerkers fouten maken. Dit soort fouten vinden en oplossen is zeer efficient. Het voorkomt dat meerdere medewerkers (dezelfde) fouten maken. Daarnaast levert het ook een emotionele winst op omdat persoonlijke fouten op systeemniveau worden geaddresseerd. Dit geeft ruimte aan creativiteit en leren.

Straf (minder bonus, een reprimandum of ontslag) ontneemt iedere medewerker de lust om te leren. Fouten maken wordt zoveel mogelijk vermeden. Er ontstaat een cultuur van angst en starheid. In plaats van een mogelijk probleem snel te duiden, zullen medewerkers dit nalaten in de hoop dat iemand anders de dupe wordt.

4.    Creëer een omgeving waar mensen elkaar écht kennen.

Werken in een omgeving waar je je collega’s kent werkt stimulerend. Het is fijn te weten dat jouw zwakte de kracht van iemand anders is, zodat je hulp kunt vragen wanneer dit nodig is. Ook maakt het leren mogelijk. Wanneer collega’s bijvoorbeeld weten dat iemand thuis problemen heeft, zullen zij hun collega waar mogelijk helpen om te zorgen dat het team er niet onder lijdt.

Het kennen van collega’s heeft ook positieve resultaten over afdelingen heen.

In veel bedrijven zijn afdelingen fysiek en procesmatig gescheiden. Informatie wordt op 1 plek verwerkt en daarna doorgestuurd naar een andere afdeling. Veelal weten collega’s van verschillen afdelingen niet op welke manier hun informatie verderop in de procesketen wordt verwerkt. Door mensen van verschillende afdelingen met elkaar in contact te brengen zullen zij elkaar sneller betrekken in het ‘leanen’ van gegevensverwerking. Zo onstaat een geoptimaliseerde informatiestroom én zijn medewerkers effectiever, trots en dus gelukkiger.

5.   Evalueer regelmatig.

Leren is blijvend kijken naar wat goed ging en wat anders en beter kan. Het leuke van leren is dat het nooit ophoudt. Er bestaat geen perfecte manier van werken. Zodra een stap is geperfectioneerd, komen andere stappen in het vizier om te verbeteren.

Zelfevaluatie is een van de meest effectieve (in termen van kosten en opbrengsten) manieren om de eigen manier van werken continu te verbeteren.

Bovenstaande 5 stappen zijn een eerste aanzet voor positieve gedragsverandering. Het is een traject waarin doen en voorbeeldgedrag, en niet KPI’s en extern opgelegde richtlijnen, resultaten opleveren.

 

 

Co Chi faciliteert verandertrajecten voor professionals, teams en organisaties. Medewerkers worden daardoor gelukkiger en effcienter. De verandertrajecten hebben een korte, gefixeerde doorlooptijd.

Neem voor meer informative contact op met Arno Korpershoek: 06 50 828 718.

Wat CMMI consultants (nog) niet weten over CMMI programma’s (3/3).

24 May, 2011

CMMI verbeterprogramma’s worden geassocieerd met geen of moeizaam verkregen resultaten. De meeste initiatieven (meer dan de helft) worden in verband met te weinig resultaten tussentijds gestopt. Hierdoor gaat veel geld én vertrouwen in veranderprogramma’s verloren. Tevens nemen de CMMI initiatieven die wel succesvol zijn al snel 1,5 tot 2 jaar in beslag waardoor bedrijven wel 2 keer nadenken voordat zij aan CMMI gebaseerde verbeterinitiatieven beginnen.

In een reeks van 3 artikelen bespreek ik de oorzaken van de slechte en moeizaam verkregen resultaten en mogelijke alternatieven. Want ook met CMMI zijn snelle resultaten te boeken. In het eerste artikel heb ik de verkeerde manieren van aanpak besproken. In het tweede artikel besprak ik de manieren om die verkeerde manieren van aanpak te vermijden en in dit 3de artikel bespreek ik alternatieve manieren van aanpak.

Kort nog eens de verkeerde standaard manieren van aanpak.

  1. (Te) weinig ervaring leidt tot onsamenhangende en complexe processen.
  2. Bij ‘onzorgvuldig overnemen’ van CMMI proceseisen ontstaan processen die elkaar overlappen en tegenspreken.
  3. CMMI proceseisen worden niet altijd juist afgestemd op de specifieke bedrijfsdoelstellingen waardoor processen snel te complex worden.
  4. Het weglaten van het gedragscomponent in veranderprogramma’s kan zorgen voor weerstand bij invoering.
  5. Bij onvoldoende focus en vrijmaken van de veranderaars krijgen verbeterprogramma’s onvoldoende focus en snelheid.
  6. Door het negeren van intern aanwezige kennis en ervaring wordt de weerstand groter.

Alternatieve aanpak voor een snellere resultaat

Mijn alternatieve aanpak behelst een 4-stappenplan. De stappen in hoofdlijnen zijn als volgt:

1  De zelf-analyse

Weet wie je bent, waar je goed in bent, waar je dingen laat liggen en waar je naar toe wilt.

a. Maak een interne analyse van de huidige situatie. Definieer wat er niet goed gaat. Omschrijf de manier van werken in een perfecte situatie (organisatie-doelstellingen) en de stappen om daar te komen. Onderzoek bij elk probleem of dit echt de oorzaak is of slechts een symptoom van een dieper liggend probleem.

b. Voer een externe evaluatie uit op basis van het CMMI model. Ga hierbij uit van alle ML2 én ML3 processen. De brede scope zorgt voor een zorgvuldig beeld van de huidige situatie.

c. Betrek, indien mogelijk, organisatie onderdelen van buiten de eigen organisatie én betrek klanten. Dit verhoogt de kans op zinvolle feedback en leermomenten. Hoe zien anderen jouw organisatie en de manier waarop je hen behandelt?

d. Combineer de resultaten van beide analyses. Het meest zinvol zijn die bevindingen van de externe adviseur die niet bij de interne analyse naar boven zijn gekomen. Dit is de blinde vlek van de organisatie waar veel te winnen is.

2  Maak een stappenplan

Kies, prioritiseer, betrek interne mensen (kennis & ervaring).

a. Stel op basis van de bevindingen een WBS op. Parameters voor decompositie:

i. prioriteit voor de organisatie (niet te baseren op CMMI niveaus maar op organisatiedoelstellingen en klanten feedback).

ii.doorlooptijd (alles met een looptijd langer dan 2 weken verder uitwerken) of mate van complexiteit (lastige onderwerpen eerst).

iii. oplijnen verbeteronderwerpen met belangrijke klantprojecten. (een klantproject kan in zo’n kritieke fase zitten dat afleiding een te groot risico vormt).

b. Informeer en betrek de “randen”. Hier zit bruikbare kennis die problemen bij implementatie kunnen voorkomen. Typische randen zijn commerciële afdelingen, klanten, testgroepen en onderhoudteams, etc.

Tip: een senior medewerker (geen manager) levert de meest toegevoegde waarde.

c. Betrek ook disciplines als HR, IT, vormgeving en etc. om de wijzigingen voor implementatie passend te krijgen naar de huidige werkomgeving. Zo worden persoonlijke jaardoelstellingen aangepast wanneer projectmedewerkers niet of minder inzetbaar zijn voor klant projecten.

Tip: deelname aan het verbeterprogramma levert ‘bonuspunten’ op!

d. Het stappenplan wordt in fases/sprints/timeboxes ingedeeld van telkens 1 maand. De structuur per fase is altijd gelijk; de te realiseren veranderingen uitwerken, kennis en mensen betrekken en (indien nodig) trainen en communicatie plannen

i. Week 1: uitwerken en trainen.

ii. Week 2 & 3: de feitelijke realisatie. Met een betrokken team zijn processen snel te bouwen. Vaak is het een kwestie van aanscherpen en ‘snijden’ wat er al is!

iii. Week 4: communicatie, training, eerste implementatie (piloting) en acceptatie.

e. In deze fase van plannenmakerij is het essentieel dat het opsplitsen in fases juist gebeurt. Elkaar opvolgende verbeterstappen moeten aanvullend werken.

f. Er is per fase slechts 1 verbeterteam met 1 specifiek onderwerp. Er zijn dus geen parallelle teams. Parallelle teams leiden namelijk al snel tot een (te) complex verbeterprogramma.

g. Start de eerste maand met een charme offensief. Vertel over de doelstellingen, plannen, opzet, de betrokkenen en de manier waarop medewerkers het resultaat mede zullen bepalen. In deze eerste fase worden mensen ook getraind in samenwerken, feedback geven en ontvangen. Dit is het moment om mensen de mogelijkheid te geven zich ook in andere disciplines te bekwamen. Dit vergroot de acceptatie voor later en brengt een sfeer van enthousiasme en een verwachtingsvol uitkijken naar het echte werk dat later volgt.

h. Een belangrijke voorwaarde is het binden van deelnemers aan het verbeterprogramma; dat zij volledig inzetbaar zijn voor het verbeterprogramma. Dit betekent dat, afhankelijk van het verbeteronderwerp, strategische keuzes nodig zijn bij prioritisering van lopende en startende (klant) projecten. Dit zijn dé momenten waarop het management kan laten zien dat het veranderprogramma inderdaad belangrijk is voor de organisatie en niet alleen een papieren oefening is voor de (overbelaste) projecten.

3  Implementatie

Doe wat je hebt uitgestippeld en doe het met bezieling!

a. In de eerste week van iedere fase bepaalt men wat te bouwen.

b. De reikwijdte is hier een belangrijk aspect. Deze bepaalt vaak de uiteindelijke effectiviteit van de verandering. Hier geldt de regel dat té breed beter is dan te beperkt.

c. Veranderingen die een looptijd hebben van meer dan 2 weken worden opgesplitst. Het programma kan hier zijn flexibiliteit tonen door een fase op te rekken tot bv 2 maanden wanneer dit het resultaat verbetert en de complexiteit verkleint.

d. Op dit moment is de architectuur van het verbeterprogramma en de procesomgeving cruciaal. Hier is de hulp van een CMMI expert van belang om de zin en onzin van het model voor de organisatie (gerelateerd aan haar doelstellingen) te kunnen duiden. De architectuur helpt het verbeterprogramma te starten met het resultaat als referentiekader.

e. Gezien de opzet van het programma ligt een RUP of Agile-achtige aanpak voor de hand. Maar een standaard watervalaanpak werkt ook prima. Het is maar waar de organisatie zich het best bij voelt.

f. De feitelijke bouw van het geplande kan snel en efficiënt gaan door te focussen en continu de vragen te stellen: is dit nodig? waarom? waarom? waarom?

g. Een belangrijk aspect is ook dat de documentatie tijdig opgesteld wordt. Omdat het programma nog volop bezig is met de bouw is de kennis voor de documentatie nog vers. De documentatie wordt geschreven met de beheerders en gebruikers van het systeem in gedachten.

h. Week 4 is de week van communicatie (die tijdens de 2 bouwweken is opgesteld), training en eerste pilots.

i. Alle leeraspecten die in de 4de week worden opgedaan, gaan mee naar de volgende fase.

j. Iedere fase wordt formeel afgesloten met een bijeenkomst waarin men evalueert wat er is bereikt en het management zich committeert aan de komende fase(s).

4  Herhaal step 2, 3 en 4

Sta stil bij wat is opgeleverd, wat goed ging en waar het beter kon. En vooral, neem feedback van opgeleverde verbeteringen mee naar volgende fasen. Tijdens de eerste week van de volgende fase worden de volgende vragen beantwoord:

i. Welke verbeteringen zijn voor het verbeterproject van toepassing? Gebruik deze dan ook zelf!

ii. Evalueer architectuur en planning; zijn er aanpassingen nodig?

Dit is het 3de artikel in een reekst van 3. In het 1ste artikel ging ik in op foutieve manier van aanpak. In het 2de artikel besprak ik de manieren om de fouten te vermijden. In dit 3de artikel besprak ik een alternatieve aanpak voor CMMI gebaseerde verbeterprogramma’s.

Wat CMMI consultants (nog) niet weten over CMMI programma’s (2/3)

13 May, 2011

CMMI verbeterprogramma’s worden geassocieerd met geen of moeizaam verkregen resultaten. De meeste initiatieven (meer dan de helft) worden in verband met te weinig resultaten tussentijds gestopt. Hierdoor gaat veel geld én vertrouwen in veranderprogramma’s verloren. Tevens duren CMMI initiatieven die wel succesvol zijn al snel 1,5 tot 2 jaar. Het is wel duidelijk dat bedrijven dan 2 keer nadenken om CMMI gebaseerde verbeterinitiatieven te starten.

Dat snelle resultaten wel degelijk mogelijk zijn, bespreek ik in een serie van 3 artikelen. In het eerste artikel ging ik in op verkeerde manieren van aanpakken. In dit 2de artikel bespreek ik de manieren om die verkeerde aanpakken te vermijden. In het komende 3de artikel bespreek ik een alternatieve aanpak.

Kort nog eens de verkeerde standaard manieren van aanpak

  1. (Te) weinig ervaring leidt tot onsamenhangende en complexe processen.
  2. Bij ‘onzorgvuldig overnemen’ van CMMI proceseisen ontstaan processen die elkaar overlappen en tegenspreken.
  3. CMMI proceseisen worden niet altijd juist afgestemd op de specifieke bedrijfsdoelstellingen waardoor processen snel te complex zijn.
  4. Het weglaten van de gedragscomponent in veranderprogramma’s draagt bij tot weerstand bij invoering.
  5. Door onvoldoende focus en vrijmaken van de veranderaars krijgen verbeterprogramma’s onvoldoende focus en snelheid.
  6. Door het negeren van intern aanwezige kennis en ervaring wordt de weerstand groter.

Hoe bovenstaande fouten vermeden kunnen worden

1

Geef voldoende aandacht aan het verankeren van CMMI kennis in de organisatie. Denk hierbij eerder aan werkbezoeken aan succesvolle CMMI verbeterprogramma’s dan aan dure externe advisering. Let hierbij op de manier waarop CMMI proceseisen zijn vertaald naar processen.

Wanneer een adviseur wordt ingehuurd, zorg dan dat kennisoverdracht het belangrijkste aspect is. Focus binnen deze kennisoverdracht op de diepere kennis, achtergrond en filosofie achter het model. Dit helpt uw team de juiste balans te vinden tussen CMMI eisen en bedrijfsdoelstellingen.

Het is evident dat de CMMI advisering van voldoende (bewezen) kwaliteit moet zijn.

Door daarnaast de focus van het programma (en de basis van het verbetermateriaal) niet op het CMMI model zelf, maar op de eigen manier van werken en de aanwezige kennis en ervaring te leggen, wordt het verbeterprogramma een zelflerende organisatie die op eigen kracht leert te verbreden en fouten te voorkomen.

2

‘Blind’ CMMI proceseisen in eigen processen is niet effectief. Het gebeurt soms dat CMMI practices bijna letterlijk zijn overgenomen in de organisatie processen. Dan ontstaat een kopie van de CMMI procesgebieden.

De meest optimale uitgangspositie blijft de eigen huidige manier van werken en de prioritisering op basis van organisatiedoelstellingen. Deze vormen de structuur van het verbeterprogramma. Deskundig CMMI advies vertelt waar in het model informatie is te vinden over de verschillende verbeteraspecten. Het CMMI model ondersteunt nu in plaats van dat het dicteert.

3

Het uitgaan van eigen praktische onvolkomenheden, organisatiedoelstellingen en feedback van klanten en aangrenzende organisatie afdelingen zorgt dat de manier waarop CMMI best practices worden vertaald in eigen processen passend is. CMMI practices zijn toepasbaar in iedere context. De manier van toepassen, verschilt per omgeving waarin de processen werken. Zo zal de mate van beheer van configuration items waar besturingssystemen voor de luchtvaartindustrie worden gebouwd meer strikt zijn dan bij de bouw van een database programma in een grootwinkel bedrijf.

4

Het gedragscomponent wordt op de volgende manier vorm gegeven:

  • de manier van communiceren.
    • communiceer vroegtijdig mogelijke veranderingen;
    • laat de communicatie 2 kanten op werken. Input van de medewerker levert een schat aan informatie op (die vaak niet door externe informatie is te overtreffen);
    • pas de communicatie aan op de werkzaamheden en verantwoordelijkheden van medewerkers;
    • gebruik eigen terminologie en vermijd zoveel mogelijke specifieke CMMI termen; en
    • gebruik in de naam van het verbeterprogramma ook zeker niet CMMI; refereer aan de eigen organisatie doelstellingen.
  • een passende beloning voor het meewerken in het verbeterprogramma.
    • het opnemen van veranderdoelstellingen in persoonlijke targets maakt dat de veranderdoelstellingen serieuzer worden genomen tijdens het prioritiseren van werkzaamheden; en
    • neem de organisatiedoelstelling als richtpunt van de veranderdoelstellingen. Een veranderdoelstelling zoals CMMI ML2 zorgt dat er verkeerde keuzes worden gemaakt tijdens het veranderprogramma. De ervaring leert dat de procedures meer aan het CMMI model worden toegeschreven dan aan de noden van de eigen medewerkers. De focus komt te liggen op het pleasen van de CMMI appraisal in plaats van het realiseren van de de eigen organisatiedoelstellingen.

5

Dedicated teams die hun tijd kort maar volledig kunnen inzetten in het verbeteren van de manier van werken, zijn effectiever, meer tevreden en meer betrokken dan wanneer medewerkers hun bijdrage op deeltijdbasis doen. De focus komt bij deeltijd-deelname te vaak op de klantenprojecten te liggen. Dit als gevolg van een korte-termijn visie.

Verder is imbedding van het verbeterprogramma in de bestaande projectportfolio cruciaal. Dit zorgt voor voldoende managementattentie en ondersteunt de juiste prioritisering van het veranderprogramma met betrekking tot de organisatiedoelstellingen.

6

Zie hiervoor ook punt 3. Extern advies is soms nodig maar veelal is de benodigde kennis al aanwezig. Betrek daarom eigen medewerkers met gezag binnen de eigen kring in het veranderprogramma; dit verzekert de input van waardevolle informatie en vermindert de mate van weerstand bij invoering. Gebruik deze kennis ook bij het opstellen van de communicatiemiddelen en -inhoud.

Betrek ook junior medewerkers; dit biedt hen de mogelijkheid snel te groeien en zij hebben een frisse kijk op de manier van werken binnen de organisatie. Zijn nemen als het ware nog een stuk van hun vorige omgeving mee.

Betrek ook andere afdelingen dan alleen de ontwikkelafdelingen bij het veranderprogramma. Dit zorgt dat werkproducten van het verbeterprogramma ook door deze afdelingen gemakkelijker geaccepteerd en gebruikt worden. Op die manier ontstaat een keten-breed verbeterresultaat, wat uiteindelijk de organisatie ten goede komt en de effectiviteit van het veranderprogramma met 66% doet toenemen.

Daarnaast levert het betrekken van verschillende stakeholders (denk ook aan de externe of interne klanten) ook waardevolle informatie op over hoe de eigen ontwikkelafdeling door anderen wordt ervaren. Dit maakt dat de organisatie nog meer rendement kan halen uit verbeterprogramma.

Dit is het 2de artikel in een reekst van 3. In het eerste artikel ging ik in op verkeerde manier van aanpak. In dit 2de artikel bespreek ik de manieren om die verkeerde aanpak te vermijden. In het komende 3de artikel bespreek ik een alternatieve aanpak voor CMMI gebaseerde verbeterprogramma’s.

Wat CMMI consultants (nog) niet weten over CMMI programma’s.

2 May, 2011

CMMI verbeterprogramma’s worden geassocieerd met geen of moeizaam verkregen resultaten. De meeste initiatieven (meer dan de helft) worden in verband met te weinig resultaten tussentijds gestopt. Hierdoor gaat veel geld én vertrouwen in verander-programma’s verloren. Tevens nemen de CMMI initiatieven die wel succesvol zijn al snel 1,5 tot 2 jaar in beslag waardoor bedrijven wel 2 keer nadenken voordat zij aan CMMI gebaseerde verbeterinitiatieven beginnen.

Dat is erg jammer, want snel resultaat is wel degelijk mogelijk!

In de komende 3 artikelen bespreek ik de oorzaken van de slechte en moeizaam verkregen resultaten en mogelijke alternatieven. Want ook met CMMI zijn snelle resultaten te boeken. In dit eerste artikel ga ik in op foute manier van aanpakken. In het 2de artikel bespreek ik de manieren om die fouten te vermijden en in het 3de artikel bespreek ik een alternatieve aanpak.

Eens een lang traject, altijd een lang traject

Het hierboven geschetste beeld van langlopende en dus dure CMMI verbetertrajecten, is hardnekkig. Ook formele ervaringcijfers ondersteunen dit beeld. Dat is jammer. In mijn beleving beperkt het de potentie van CMMI verbetertrajecten om bij bedrijven snelle en effectieve verbeteringen door te voeren.

Foute standaard manieren van aanpakken

Hieronder volgt een aantal oorzaken die het beeld van dure en lange verbetertrajecten veroorzaken.

  1. Veel consultants hebben (te) weinig ervaring in het vertalen van de theoretische CMMI beginselen in bruikbare processen. De onderliggende samenhang wordt onvoldoende herkend. Dit leidt tot onsamenhangende en (te) complexe processen en procedures.
  2. In het CMMI model komen bepaalde onderwerpen in verschillende procesgebieden terug. Bij ‘onzorgvuldig overnemen’ van proceseisen uit het model ontstaat een set van processen die elkaar overlappen en elkaar deels kunnen en zullen tegenspreken.
  3. Verbeterprogramma’s worden gestart vanuit de gedachte dat het CMMI model de waarheid bevat en niets anders dan de waarheid. Nu staat er veel zinnigs in het model, maar niet alles is in alle situaties en project- en bedrijfsomgevingen toepasbaar of nodig. Kernbegrip van het model is dan ook een “business objectives”. Hiermee wordt bedoeld dat feitelijke implementatie van proceseisen en de mate van rigiditeit afhankelijk is van de omgeving waarbinnen de processen fungeren.
  4. Verbeterprogramma’s worden geformuleerd rond project management en engineeringaspecten. De gedragscomponent waarin de medewerkers worden begeleid in het omgaan met de komende veranderingen, is vrijwel altijd afwezig. Dit leidt tot weerstand tijdens de implementatie van de processen die niet meer is te corrigeren.
  5. Trekkers en uitvoerders van de veranderprogramma’s krijgen deze opdracht meestal bovenop al bestaande verantwoordelijkheden. Als dan ook nog eens de beoordeling van medewerkers niet op te realiseren verbeteringen wordt gebaseerd, zal het verandertraject niet de benodigde aandacht en prioriteit krijgen. Doelstellingen worden niet gehaald en worden veelvuldig aangepast of uitgesteld. Het geloof in een succesvol resultaat zal langzaam maar zeker afnemen en op een bepaald moment helemaal verdwijnen.
  6. Als laatste noem ik het negeren van al aanwezige kennis, processen en ervaring in project- en lijnorganisatie. Dure extern ingekochte kennis, ervaring en processen worden hoger ingeschat dan de interne kennis en processen. Ook dit component roept weerstand op tegen de ‘externe processen’.

In het 2de artikel bespreek ik manieren om bovenstaande problemen te vermijden.