Archive for the ‘CMMI’ Category

How to address project complexity

5 April, 2012

In an earlier blog I wrote on complexity in project management and the Cynefin© model.
Target of this blog is to deepen the understanding in applying Cynefin©–based approaches to complex projects.

My appliance of Cynefin© is pragmatic. As I am not a theorist, I might get things wrong, as long as it works for projects.

A problem is either simple, complicated, complex or chaotic. A fifth type is disorder, which stands for such problems of which we can’t tell in what domain the problem belongs. In this blog I don’t address disorder problems.

The figure below is a graphic representation of the Cynefin© model from Wikipedia.


Simple problems are characterized by a known and well established cause-effect. Don’t waste any time, just plan de corrective action as you know it’s outcome.
E.g. if a team member lacks experience in a specific task, you send him to a course or training, or assign an on-the-job coach.

When developing simple software functionality, any development type will do (e.g. waterfall or iterative).

Complicated problems cannot be solved in the same manner as simple problems. For this an expert or team of experts analyze the problem to provide a solution. A typical complicated problem is how to structure known data in a database or set up a project in a stable problem domain. The project knows its stakeholders. Once the set of requirements are defined they are more or less stable. Project, organization and customer are confident in a positive result.

Regarding software functionality, also complicated problems may be addressed by any development type. Although here the risk for change and (upfront) unknown additional problems, might call for a iterative based development. Iterative based development enables emerging functionality, thus reducing late and fundamental changes in design and code.

When projects face complexity as well as many and largely unknown and varying requirements, both customer and organization are faced with a big uncertainty and risk regarding the outcome of the project. The high level work breakdown structure is largely based on expected work to be done. Estimations on effort, resources and needed time to determine project costs is at this point a major guessing game.

Typical for these large projects is that only at the end of the project, both project, customer and organization are able to explain how and why the project evolved as it did. Project outcome emerged from running the project. Prediction up front was not possible.

These projects are typically located in the complex domain with a probe-sense-respond approach.  In practice this means that at project outset, the objective is provided together with the why. Then the project set’s out to identify the major business value and starts working on these.

In order to identify as much needs, wishes and constraints as possible a narrative approach can be applied. In this initial narrative phase the project sets up a website where all stakeholders are invited to share their stories. The stories are provided a title and provided additional meaning (or signifying). Note that up front it is not known how many narratives or requirements are necessary. This is only know in retrospect.

The stories form the basis on which the project defines a detailed set of requirements. Because in these types of projects many requirements emerge only during project execution, these basic set of stories are continuously revisited at regular intervals.

In software development typical iterative approaches with high level of stakeholder involvement is used for these types of projects. It becomes directly very clear that both on the stakeholders side as well as on the organizational side, embracing slow-growing certainty and emerging understanding of project deliverables, is critical for success.

In the complex domain project outcome emerges from project execution. The problem domain is known and understood. Complexity is based on the fact that at the outset, not all needs, wishes and constraints are known. Even stronger, perhaps not all stakeholders are at that point known.

Projects in the chaotic domain are projects in an unknown uncharted domain. There not yet any experts to tell the project what is the best approach. So the defined approached is act-sense-respond. Just start working in any direction, ensure the involved cost, time and risks are limited. At regular intervals the result is evaluated. Positive outcomes are strengthened or continued. Negative results are stopped.
Slow but certain the project learns and builds expertise. Both customer and organization support and learn with the project.

For both the customer and organization, the challenge is how to fund these types of projects. I will get back later in this aspect. I’ll also address the use of narrative in requirements definition in a later blog.

Warning. As in all models it is important not to follow the model but to understand it. Applicability works as long as it works for you.

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.