Why Transformation Efforts Fail?

Thanks to a push email from Harvard Business Review, and discussions around ongoing transformation efforts, I read again an old article from John Kotter: Leading Change: Why Transformation Efforts Fail.

The first lesson is that change is not an event, it’s a process. The second lesson is that change takes time, and not following the change process could create an illusion of speed, but will result in failure.

If we study successful or unsuccessful changes attempt using the 8 steps proposed by Kotter, we could learn a lot on what we could improve in the future.

One aspect that is not directly covered in the 8 steps is what is called “Your organization”.

I learned from successful (and unsuccessful) changes, that defining “The Organization” is crucial. It will define who is part of the core group, and more importantly, who is part of the core group from the start.

Let’s say that in your organization, you have several teams that need to work together to deliver a product or a service, and you observe that they are struggling to deliver, they could even engage in politics and blame game.

If you engage with team A and team B. That could be, for example, because they are at the beginning of the production process, or for other reason, as you will always find great justification for what you did and cannot undo. I am smiling there, at myself, please don’t be offended.

You could work with those teams on step 1, and establish a sense of urgency. You could work on step 2, and form a group that will lead the change.

Now that you learned more on the production process, you can clearly see that team C, plays a crucial role, and needs to be involved.

As you are yourself driven by the sense of urgency, you could decide to involve team C for step 3. You could rationalize this shortcut as much as you can, but it will cause you a lot of troubles.

The best option is to go back to step 1, and work with team A, B and C on establishing a sense of urgency, and continue the process from there. Until that restart, Team C will not see the same crises, or potential crises, they will not see the same causes, and they will not want their future to be dictated by other teams.

 

Header picture is from Ryan McGuire.

The Dream Team Nightmare

ptdream-smallÊtes-vous prêt à vivre une aventure agile ?

C’est la promesse du dernier livre de Portia Tung : The Dream Team Nightmare !
Le livre est publié par les “Pragmatic Programmers” ce qui est un gage de qualité. La prise de contact avec l’ouvrage (et avec l’aventure) est simple et rapide.

Je me pose encore bien sur quelques questions sur les parties de l’ouvrage que je n’ai pas exploré… Et oui en fonction de vos choix, vous serez amené vers la page correspondante !

Le livre est rempli d’enseignements pour ceux qui veulent aider leur équipe à aller vers l’agile !

Bravo et merci à Portia !

Vous pouvez retrouver Portia Tung sur Agile Adventures

 

Compétences distribuées ?

Les propositions d’optimisation des organisations reposent souvent sur un regroupement des compétences au sein de centre de service agissant pour le compte de l’ensemble de l’organisation. L’atteinte de la « taille critique » pour conduire une activité est le principal argument utilisé pour justifier cette proposition. Cette taille permettant de se doter des compétences variées – voire rares – sans avoir besoin de chercher le « mouton à cinq pattes » pour le seul poste à pourvoir de l’organisation.

De plus, la localisation en un même lieu des compétences nécessaires pour rendre le service pour l’ensemble de l’organisation est la solution retenue dans la plupart des cas. La conséquence de ce choix, est que les humains qui portent ces compétences vont devoir changer de lieux de vie, éventualité qu’une partie d’entre eux va accueillir avec joie et que d’autres redoutent ou rejettent pour des motifs qui, pris individuellement sont tout aussi rationnels que le choix de localisation.

Une autre option à cette localisation géographique unique, pourrait être la gestion des compétences distribuées sur le territoire, évolution importante de l’approche managériale d’une activité qui peut-être permise par une utilisation appropriée des technologies actuelles.

D’autres avantages peuvent apparaître et sont mis en avant par certains, comme par ce responsable du développement informatique d’un projet important, qui me racontait récemment en faisant le bilan de son projet, qu’il aurait finalement préféré que son équipe de développement soit répartie dans plusieurs lieux plutôt que localisée dans le même bureau. Cela aurait rendu obligatoire la formalisation de la communication via les outils partagés :

  • Les rapports avec les métiers donneurs d’ordre auraient ainsi été modifiés car ils auraient pu mieux percevoir l’impact de leurs décisions (ou non décision) sur les équipes de développement ;
  • Les difficultés rencontrées auraient été visibles de tous et l’entre aide dans l’équipe pour leurs résolutions auraient pu s’installer plus facilement ;
  • L’intégration de nouveaux membres à l’équipe aurait été facilitée par l’existence de cette histoire accessible du projet ;
  • La publication des travaux réalisés de façon continue aurait exercée une pression bénéfique sur chacun des membres de l’équipe améliorant la qualité et la productivité ;
  • Le projet aurait également eu la possibilité de séduire d’autres métiers dans l’organisation, et ainsi trouver de nouveaux budgets pour son évolution.

Une vision éventuellement utilisable pour d’autres métiers que le développement informatique permettant de combiner les notions de centre de service et une distribution géographique étendue.