La Marge Chute et Vous n'Avez pas Six Mois pour Découvrir Pourquoi

Menez un sprint de six semaines qui diagnostique la cause racine de bout en bout et teste une solution directement dans l'opération, avec un point de contrôle go/no-go à la semaine deux afin qu'une mauvaise direction soit repérée tôt plutôt que découverte à la fin d'un engagement de six semaines. La vitesse vient du fait de travailler dans l'opération elle-même plutôt que dans une structure de projet séparée qui doit rendre compte de résultats avant que quoi que ce soit puisse changer.

Commencez par une analyse du processus de bout en bout et des entretiens avec ceux qui font le travail, ils savent presque toujours où ça se casse, même si personne ne le leur a jamais formellement demandé. L'érosion de la marge est rarement un mystère pour ceux les plus proches du processus ; c'est généralement un mystère pour la direction précisément parce que l'information ne remonte pas à travers les niveaux de reporting qui la feraient sinon émerger.

Parcourez le processus phase par phase, en prêtant une attention particulière aux transmissions entre services, où l'appropriation disparaît souvent et où personne n'est pleinement responsable de ce qui se passe dans cet espace. La plupart des problèmes de performance qui semblent complexes de loin se concentrent sur un ou deux points de transmission spécifiques une fois que le processus est réellement cartographié étape par étape plutôt que revu service par service isolément.

Un cycle limité dans le temps diagnostic-solution-exécution-ancrage, avec un point de contrôle go/no-go à la deuxième semaine et une solution ou un business case défini à la fin, structuré pour que l'équipe sache dans les deux premières semaines si la direction choisie fonctionne. Les quatre phases s'exécutent dans l'ordre mais restent strictement limitées dans le temps, empêchant le sprint de silencieusement s'étendre vers le type de projet de plusieurs mois qu'il est spécifiquement conçu pour éviter.

Les processus standardisables et les transmissions cassées peuvent être entièrement résolus ; les problèmes d'architecture de systèmes ou de conception organisationnelle produisent typiquement un plan solide et un business case au lieu d'une solution finie, car ces changements nécessitent généralement des investissements et des échéances qu'une fenêtre de six semaines ne peut pas livrer de façon responsable. Savoir dans quelle catégorie tombe un problème avant de commencer permet au sprint de promettre un résultat spécifique et honnête plutôt qu'ouvert.

Limitez le problème à ce qu'un sprint de six semaines peut vraiment livrer, et dites dès le début lequel des deux résultats s'applique, une solution fonctionnelle ou un business case entièrement chiffré, plutôt que de laisser le périmètre du projet s'étendre vers quelque chose de plus long et ouvert une fois lancé. La plupart des problèmes opérationnels n'ont pas vraiment besoin de six mois d'analyse pour être compris ; ils ont besoin de six semaines de travail concentré, dans l'opération.

Cartographiez le processus de bout en bout entre services, le point de transmission révèle souvent le vrai problème, pas chaque service séparément, car le récit de chacun est souvent exact pour sa propre partie du processus tout en manquant ce qui se passe dans le vide entre eux. Aucun service n'a tort ; les deux décrivent simplement la partie de l'éléphant qu'ils peuvent réellement voir.

Oui, résolvez d'abord le problème opérationnel urgent avec un sprint ; le travail de stratégie n'aide qu'une fois qu'il y a de l'espace pour regarder au-delà de ce trimestre, et une équipe dirigeante qui éteint un incendie opérationnel actif a rarement la capacité de vraiment s'engager sur des questions stratégiques à long terme. Ordonner le sprint avant le travail de stratégie fait souvent émerger des réalités opérationnelles qui devraient réellement informer la stratégie qui suit.

Résolvez d'abord le goulot d'étranglement du processus et les échecs de transmission, souvent la vraie contrainte, pas les effectifs, car beaucoup de problèmes de productivité qui ressemblent à un manque de personnel sont en réalité un processus qui joue contre ceux qui essaient de l'exécuter. Ajouter des effectifs à un processus cassé ne fait généralement que produire plus de sortie qui passe par le même goulot d'étranglement, sans vraiment résoudre la contrainte sous-jacente.

Parcourez toute la chaîne étape par étape, y compris chaque transmission, plutôt que de revoir les services isolément, car le goulot d'étranglement a une probabilité disproportionnément élevée de se trouver précisément là où la responsabilité passe d'une équipe à une autre. Une revue service par service trouve généralement que chacun fonctionne relativement bien selon ses propres termes, précisément pourquoi elle manque souvent la vraie contrainte.

Pour les problèmes trop structurels pour six semaines, le sprint lui-même produit comme résultat le business case entièrement élaboré, avec effort, ressources, risque et une date de début définie, plutôt que de laisser ce travail à quelqu'un d'autre plus tard avec moins de connaissance directe du problème. Ainsi, les six semaines produisent quand même quelque chose d'immédiatement utilisable, même si la solution elle-même nécessite plus de temps à mettre en œuvre.

Terminez par un plan d'ancrage qui nomme un responsable, une méthode de mesure, et une réponse si la performance recule, car une amélioration qui ne se maintient que tant qu'il y a une attention externe dessus n'est pas vraiment une amélioration, c'est un état temporaire. Le plan d'ancrage transforme une solution de six semaines en un changement durable, plutôt qu'en un résultat qui s'inverse silencieusement quelques mois plus tard une fois l'attention de tous déplacée ailleurs.

Des sessions courtes et intensives qui testent immédiatement la faisabilité des directions de solution, avec des expérimentations à petite échelle avant un déploiement complet, plutôt qu'une longue phase d'analyse suivie d'un seul grand déploiement sans possibilité de corriger le cap. Tester les directions à petite échelle en premier signifie qu'une approche défectueuse est repérée pendant qu'il est encore bon marché de la changer, plutôt qu'après son déploiement dans toute l'opération.

Diagnostiquez d'abord la vraie cause racine, courir après des symptômes sur plusieurs fronts à la fois se résume souvent à une ou deux vraies causes, ce qui signifie que la longue liste de ce qui semble cassé cache souvent une liste bien plus courte de vrais problèmes. Résoudre la cause racine résout généralement plusieurs symptômes apparemment séparés à la fois, un bien meilleur usage de la capacité limitée que de traiter chaque symptôme comme un problème indépendant.

Définissez la méthode de mesure comme partie du plan d'ancrage à la fin du sprint, liée à l'énoncé initial du problème, afin que le succès soit jugé par rapport à ce qui était concrètement cassé, pas un sentiment général que les choses vont mieux. Une méthode de mesure décidée à l'avance, avant de mettre en œuvre la solution, élimine aussi la tentation de choisir rétrospectivement la métrique qui s'avère la plus favorable.