18-01-2024 14:07:41
Cette page possède des liens non-résolus. Il s'agit de pages sur lesquelles je suis occupé à travailler. Certaines illustrations pourraient aussi être manquantes. Je m'active à les intégrer.
Steering Committee — Comité de pilotage. Un comité consultatif généralement composé des parties prenantes (stakeholders) et/ou d'experts de haut niveau qui fournissent des conseils sur des questions clés telles que la politique et les objectifs de l'entreprise, le contrôle budgétaire, la stratégie de marketing, l'affectation des ressources et les décisions impliquant des dépenses importantes.
Articuler et maintenir des objectifs à grande échelle est l'une des tâches des cadres qui parrainent ou supervisent les équipes XP. Un autre travail pour les cadres qui parrainent ou supervisent des équipes XP consiste à surveiller, encourager et faciliter l'amélioration. Comme l'objectif d'XP est de faire du développement de logiciels exceptionnels la norme, les cadres ont le droit de voir non seulement de bons logiciels venir de l'équipe, mais aussi une amélioration continue. Les cadres sont libres de demander des explications sur n'importe quel aspect d'un projet XP. Les explications doivent avoir un sens. Si elles ne font pas sens, le cadre doit s'attendre à ce que l'équipe réfléchisse et fournisse une explication claire. Les cadres doivent attendre de l'équipe qu'elle fasse preuve d'honnêteté et qu'elle explique clairement les options possibles dans tout processus décisionnel. L'exécutif doit garder du recul face aux problèmes, en se concentrant sur les besoins réels de l'organisation et les exigences du projet, même lorsqu'il est confronté à la nécessité de réduire le champ d'application. Grâce à une communication fréquente et ouverte, lorsqu'une telle décision est nécessaire, l'exécutif dispose déjà des informations nécessaires pour prendre une décision en connaissance de cause
— Kent Beck and Cynthia Andres in Extreme Programming Explained
Les Sponsors sont ceux qui financent un projet. Ils veulent savoir ce que l'équipe du projet a déjà construit avec l'argent qui a été dépensé (et si le projet restera dans son enveloppe initiale), quelles sont les difficultés à venir qui peuvent compromettre la bonne fin du projet (et de quelle manière ils peuvent aider). Ils veulent savoir si la valeur commerciale qu'ils ont anticipée se matérialisera au moment où ils en auront besoin. Ils veulent savoir ce genre de choses de la manière la plus précise possible ! Le Release Train doit leur fournir cela ! Cela, et rien d'autre, car nous devons éviter le surtraitement, la surproduction et les stocks (voir lean-8-wastes). C'est l'objet du Comité de pilotage (SteerCo), qui est un lien formel entre la couche "Integration Layer" et la couche "Aspiration Layer", comme le suggère l'illustration suivante :
En plus du simple rapportage, il peut y avoir plusieurs avantages à organiser une véritable boucle de rétroaction de manière bidirectionnelle, qui est encore meilleure lorsqu'elle est organisée de manière systémique (à tout moment et partie intégrante du processus). La couche Integration Layer elle-même peut également distiller des informations utiles aux projets. C'est le cas lorsque des changements externes surviennent et modifient le contexte des projets, auquel cas le Release Train peut avoir besoin d'entrer dans le %RTH%. Un tel lien est présent dans L(i)VID
En général, il y a 5 sujets qui doivent être présentés pour tenir les sponsors/stakeholders informés de l'évolution du projet :
- Progrès rapporté à l'horizon du Release Train: the cycle-increment
- Budget, selon 5 angles complémentaires :
- Alloué
- Brûlé
- Estimated to complete
- Estimated at Completion
- Taux de brûlage (burn rate)
- Ressources/Recrutement
- Risques & Problèmes
- Plans pour la prochaine phase du projet
On peut présenter ceci plus visuellement :
Tout ceci est présenté avec un RAG global (Red, Amber, Green), une sorte de signal concentré qui indique la santé du projet, des feux de signalisation si vous voulez. Voici un exemple de tableau récapitulatif RAG où il est aisé de comparer la situation actuelle avec la situation antérieure et où la tendance de chaque indicateur est affichée :
Progrès : Ligne de temps et Jalons/Étapes
Ce que les Sponsors/Parties prenantes (stakeholders) veulent savoir est essentiellement une indication de tout retard (éventuel) encouru par les Release Trains. Dans la métaphore d'un train de valeur (Value Train), il n'y a pas de retard : le train part toujours à l'heure et arrive à l'heure également (c'est-à -dire que les cycle-increment et les sprints ont une durée fixe, 13 semaines pour le cycle et 2 semaines pour l'itération qui s'appliquent aux équipes, mais qui est en fait le cœur de tout le train). Cependant, tout le fret attendu n'arrive pas à destination, comprenez la portée : certains ont été chargés dans le train, d'autres non. C'est le paradigme le plus important des méthodes agiles : un scope variable ! Par conséquent, les progrès doivent être comptés dans le nombre de Features qui ont atteint leur Definition of Done of a Feature.
En 2004, Ron Jeffries a écrit un excellent article sur une mesure qui mène à l'agilité. C'est la mesure que L(i)VID recommande : Running Tested Features (RTF).
Ligne de temps
Être agile est souvent une question d'être "visuel". En étant visuel, nous exposons nos intentions, il est plus facile pour les autres de nous lire et de lire les informations que nous avons construites à leur intention (voir visual-project-management).
Les Sponsors/Parties prenantes (stakeholders) veulent être tenus au courant de l'avancement des projets qu'ils financent et ils convertissent automatiquement cet avancement en une ligne de temps : «où en sommes-nous par rapport à ce que nous avions prévu» est la question qui leur trotte dans la tête, même si cela semble bizarre à la plupart des agilistes.
Alors pourquoi ne pas les aider à construire la bonne image avec une ligne de temps préétablie qui peut être construite automatiquement (voir l'équipe Commando pour construire cela pour vous, avec l'aide du PMO le plus naturellement du monde.
Voici un exemple d'une telle ligne de temps (détaillée) avec un horizon d'environ 1 mois (voir 1-MONTH pour plus de détails) :
Compte tenu de son niveau de détail, ce calendrier ne répond peut-être pas vraiment aux besoins des Sponsors/Parties prenantes (Stakeholders). Si vous avez besoin d'une vue de plus haut niveau, essayez l'exemple de ligne de temps de 6 mois, qui est présenté ci-dessous..
Jalons/Étapes
Ce que les Sponsors souhaitent, c'est un horizon minimum de 6 mois, éventuellement étendu à un an ou même plus. Cela entre clairement en conflit avec le COU (Cone of Uncertainty), du moins dans une certaine mesure : tout ce qui se situe au-delà de six mois est très incertain (et devrait être considéré comme tel); tout ce qui se situe entre maintenant et trois mois présente une proportion croissante d'incertitude, mais les plans de haut niveau restent probablement valables et applicables avec quelques ajustements.
Valeur
Bien plus importante que le calendrier et les jalons, la notion de valeur (VUSI – Valuable and Usable Software Increment) ! Un Release Train est un train rempli de valeur transportée de l'usine à l'utilisateur final. Les utilisateurs finaux ne sont pas concernés par les délais, les coûts, etc. Ils veulent de la valeur ! ils veulent de l'utilité et ils la veulent vite; ils veulent engager/acheter des services et des produits qui les aideront à faire leurs propres JTBDs ! (VOIR ICI CLAYTON CHRISTENSEN SUR CE POINT ; FOURNIR UNE OU DEUX CITATIONS)
À mon humble avis, je pense que le BURN-UP est l'un des meilleurs moyens de présenter la valeur accumulée de manière visuelle :
Il ne faut jamais oublier que le tableau de combustion attendu par le Comité de pilotage concerne la valeur livrée, et non pas ce que le train a construit (ce qui est en fait ce que montre le tableau précédent), ou pour le dire autrement, même si le Comité de pilotage peut être intéressé par ce qu'un train a réussi à construire, il apprécie davantage ce que le train a livré !
Situation budgétaire
Comme nous l'avons déjà dit, la situation budgétaire est souvent examinée sous cinq angles. (voir thèmes d'un steerco):
Vous rencontrerez souvent des organisations qui comptent leurs budgets en jours/homme. Cela ne pose aucun problème lorsque ces organisations sont confrontées au même coût réel pour toutes leurs ressources. Le problème est que c'est rarement le cas, surtout dans le monde des services financiers. À cet égard, considérons l'histoire réelle suivante. Au cours d'un projet SEPA, l'équipe chargée de traiter la partie importante des paiements s'est aperçue qu'elle avait pris du retard. Comme c'est souvent le cas, elle a décidé d'embaucher du nouveau personnel, en l'occurrence principalement des externes en raison de l'urgence de la situation : après tout, elle avait le budget pour le faire. Elle s'est donc tournée vers le marché pour essayer de recruter un certain nombre de personnes hautement qualifiées pour quelques jours, des personnes qu'elle n'avait pas besoin de former en raison de leurs compétences intrinsèques dans le domaine des paiements. La banque a trouvé ces ressources auprès de l'un de ses fournisseurs préférés, un grand cabinet de conseil. Ce n'est qu'au bout de trois mois que le chef d'équipe s'est rendu compte que son budget avait considérablement diminué, principalement parce que le coût réel des personnes embauchées ne correspondait pas au taux journalier moyen calculé par la société. Cela a obligé le chef d'équipe à licencier la plupart des membres de l'équipe en l'espace d'une semaine, avec la conséquence prévisible de perdre beaucoup de connaissances L(i)VID a une préférence pour détailler le budget en argent réel : euros, dollars, …
Alloué
Il s'agit du budget consenti, toutes années agrégées pour les projets pluriannuels. Il se peut que la définition de "Alloué" soit propre à l'entreprise. C'est ce qui se passe quand, par exemple, le budget n'est libéré que par phase, une situation que j'ai bien des fois rencontrée.
Dans le cas d'un fonctionnement sur une base produit/service plutôt que projet (grande tendance de l'Agilité), et dans l'hypothèse où l'entreprise favorise le rassemblement d'équipes sur le long terme (long-lived teams) il s'agira probablement du budget annuel qui a été alloué au fonctionnement de l'équipe (plus moyens financiers additionnels consentis).
Brûlé (Actuals)
Il s'agit de la partie du budget qui est déjà dépensée. Dans un mode de fonctionnement à capacité fixe qui est aussi mon mode préféré (variations limitées de la capacité à la hausse ou à la baisse), les chiffres réels sont assez prévisibles : l'utilisation d'un Burndown Chart de budget fait alors des miracles puisque la dépense est généralement linéaire dans le temps. Il suffit alors d'avoir accès aux feuilles de prestations, de se baser sur un prix moyen journalier pour l'ensemble de l'équipe (que le Chef de Projet aura calculé préalablement), de remplir un petit tableau Excel (une habitude qui ponctue mes vendredis) avec une courbe d'extrapolation et vous savez précisément quand, sur la ligne de temps de votre projet, vous croiserez le moment où votre budget sera épuisé.
ETC: Estimated To Complete
Il s'agit du budget que nous estimons nécessaire pour mener à bien le projet (de maintenant à la fin). Là encore, dans un mode de capacité fixe, il devrait être assez facile d'estimer l'ETC sur la base des chiffres réels (actuals) et du Burning Rate.
EAC: Estimated at Completion
After you have summed the Actuals and the Estimated To Complete parts of the budget you obtain the %"l%EAC: Estimated At Completion%"r%. It should be entirely automatic. The EAC is the most important information for Sponsors, or to turn it differently, this is the info they're after!
Après avoir additionné les parties du budget réellement consommée et estimée pour terminer le projet, vous obtenez le EAC (Estimé à Terminer — Estimated at Completion).
Cela devrait être entièrement automatique. L'EAC est l'information la plus importante pour les Sponsors ate autres parties prenantes, ou pour le dire autrement, ils veulent savoir combien, au final, tout cela leur aura coûté !
Taux de brûlage (Burning Rate)
Le reste du texte provient d'articles précédents, écrits pour la plupart en anglais. Je dois le retraduire en français et l'amender pour publication sur L(i)VID. Ce travail est en cours.
Speed at which the budget is spent. Indication of the possibility to reach the end of the project with the remaining budget giving the present burning rate. Once again, in a fix-capacity mode where (most) resources are allocated to a single train, the burning rate is easily predictable and should not vary much once the train has started.
Global View of the Budgetary Situation
The more such report is automated, the better (it should be linked to %TW% and Project Expences). Here is a sample view of a global Budgetary Situation, completely automated in the Sentanai Project Management tool:
This view provides also an history that may be very interesting for the project and the Sponsors.
Resources / Staffing
TO BE ADAPTEDComme le train est censé fonctionner avec des équipes dédiées ayant une capacité fixe, l'obtention de ressources ne devrait pas poser trop de problèmes. Par conséquent, presque par nature, les problèmes de ressources n'atteignent normalement pas un Comité de pilotage, ce qui est très différent de ce qui se passe avec des ressources qui sont partagées entre plusieurs projets, ayant tous leur propre rythme, et ayant tous des retards possibles.
Dans le cas où vous travailleriez avec des ressources partagées, cela eput s'avérer plus compliqué et il se pourrait bien que les experts dont vous avez besoin rejoignent votre équipe avec retard. C'est la hantise de chaque Chef de Projet qui est souvent complètement aveugle sur les assignations de tâches allouées à ces ressources partagées. Il se pourrait même que vos ressources soient à confirmer de votre côté avec une forme de délai. En tout état de cause, et donc quelle que soit le modèle dans lequel vous opérez, il est indispensable d'avoir une vue détaillée des personnes allouées à votre projet pour les 3 prochains mois.
Usually the questions of resources do not reach the Comité de pilotage as they can be reported every day during the %SoS%, at which point they must be treated as point of attention or even impediments. It is the responsibility of the %RTE% to bring solutions (not only escalate).
In organizations transitioning to Agile, if the Release Train paradigm and the %-SoS% cannot solve resource availability issues, it may be interesting to think of setting up a quick meeting such as the %RAM% where all resource demanding parties strive to obtain consensus about the conflicting situations.
In the unlikely event that a problem of resources still reaches the level of the Comité de pilotage in projects handled in asset-mode (understand release train oriented), it means that it is that serious that the train itself could not solve it.
Risques et Problèmes (Risks and Issues)
To be continued
Plans pour l'immédiate prochaine phase
Rien de bien sorcier ! Servez-vous de la ligne de temps à horizon limité : de 1 mois à 3 mois. En voici un exemple :
Dès que vous disposez d'un modèle, il suffit de l'adapter pour chaque Steerco en fonction de ce qui s'est réellement produit et de ce que vous envisagez être l'avenir imémdiat. Un bon truc, lorsqu'on met à jour cet horizon, est de l'envisager sous l'angle du prochain Steerco.
CapEx / Opex
Dans le secteur de l'énergie, lors d'une implémentation de SalesForce, l'estimation du volume des données avait été bousculée par une implémentation technique discutable qui avait mené à une forme d'explosion des besoins de stockage. Comme la solution était "Cloud- based", les coûts avaient augmenté d'environ 1 million d'euros/an. Voilà un coût opérationnel intervenu en cours de projet qui n'impactait pas le coût du projet lui-même mais qui avait la fâcheuse tendance à raboter le budget futur de l'ensemble de l'IT puisque dépense récurrente annuelle.
En général, je ne rends pas compte de la situation CapEx / OpEx dans un streeco sauf …
… sauf si je considère que :
- La situation CapEx (CAPEX), et en particulier l'évaluation de la partie livrée (cà d, mise en production et activée, même partielle) permet de commencer à prendre en compte les amortissements car cette partie intéressera "Finances" ou …
- Quand la situation OpEx (OPEX) augmente en cours de projet,
ce qui est souvent inquiétant ou, du moins, qui devrait susciter
quelques interrogations car en effet, une partie OpEx qui augmente signifie
que les engagements récurrents sont plus que probablement en augmentation
également. J'ai connu deux situations qui illustrent ce phénomène :
- Dans le secteur de l'énergie, lors d'une implémentation de SalesForce, l'estimation du volume des données avait été bousculée par une implémentation technique discutable qui avait mené à une forme d'explosion des besoins de stockage. Comme la solution était "Cloud-based", les coûts avaient augmenté d'environ 1 million d'euros/an. Voilà un coût opérationnel intervenu en cours de projet qui n'impactait pas le coût du projet lui-même mais qui avait la fâcheuse tendance à raboter le budget futur de l'ensemble de l'IT puisque dépense récurrente annuelle.
- Dans le secteur public, ou assimilé, j'ai vécu une situation où un projet de modernisation avait induit des coûts de licence importants. Lorsqu'un nouveau CIO avait fait le calcul des engagements, il a découvert que son budget global était accaparé à environ 67% par des coûts opérationnels récurrents ce qui ne lui permettait plus de continuer le travail de modernisation entrepris par son prédécesseur.
En lien avec CapEx / Opex …
En rapport avec CapEx et OpEx, mais sans rapport avec le Steerco, je ne manque pas de rappeler aux parties prenantes (et particulièrement "Finance") le type de solution choisie : On-Premises ou Cloud-based.
En effet, la plupart des solutions Cloud-based réduisent considérablement le dépenses de type CapEx au profit de OpEx. Ce genre de dépenses est souvent couvert par des factures de "loyers" or ceux-ci se comptabilisent très différemment permettant même d'échapper aux amortissements.
Le PMO est d'une grande aide
The train %PMO% helps prepare the Comité de pilotage. Things like the budget and Risks & Issues can be entirely automated (one of the things the %COMMANDO% can take care of).
Le PMO aide à préparer le Comité de pilotage. Des choses comme le budget et les risques et problèmes peuvent être entièrement automatisées pourvu que les outils internes le permettent, ce qui est une des choses dont peut s'occuper une équipe COMMANDO.
Ceci m'amène tout naturellement à parler du degré d'automatisation permis par les outils mis en place. Pour bien illustrer mon propos, que je laisserai ouvert pour l'instant, il peut être intéressant de mettre en lumière une situation qui n'est pas si rare : la demande qui est faite aux Chefs de Projet de présenter les données exposées dans un Steerco de manière différente pour différentes audiences à différentes réunions : ici une présentation PowerPoint, là une feuille Excel, là -bas encore des versions papier A3, etc. C'est une complète aberration et une terrible perte de temps que j'associe volontiers aux mudas de Lean (lean- 8-wastes). Au contraire, on favorisera une présentation Steerco en contact direct avec les outils administratifs de la gestion de projet qu'il s'agisse de Clarity, de Planview, de Planisware, de MS-Project, de JIRA, …
J'ai personnellement connu ce genre de situation où, pour une grosse entreprise du secteur financier, je passais pas moins de 23h/semaine en réunions diverses et variées. Chaque semaine, je prenais part à 4 réunions où l'on me demandait quasiment les mêmes rapports : seule la présentation et le format changeaient. Chaque réunion exigeait environ 2 heures de préparation de documents. On en déduit donc que je passais 1 journée/semaine à fournir des documents identiques d'un point de vue contenu, mais différents en termes de présentation (ordre des parties, couleurs, et format de la présentation, Excel ici, PowerPoint là -bas). Si on examine froidement ces simples chiffres, on en infère une dépense annuelle entre 25k et 30k€, ce qui n'est pas négligeable.
An Idea of a Portfolio Information Radiator
Whatever the format can be, there is always some way to make the information visible for the ones who may need it.
For example, in an Insurance company, we have put in place what we called a Portfolio Kanban where all the information Management needed was synthetized:
To be continued
JE DOIS AUSSI MONTRER UN RAPPORT DE SENTANAI WEB QUE J'AVAIS FAIT POUR ING INFRA AVEC COURBE DE GAUSS JE DOIS AUSSI MONTRER UNE JAUGE D'ESSENCE COMME SUR LE GRAND PORTFOLIO BOARD DE GENERALI OU COMME SUR LE TABLEAU KANBAN DU PROJETThe %-RTE% Leads the Comité de pilotage
The person that chairs the Comité de pilotage is the %RTE%. The %-PMO% is there to assist the %-RTE%.
Don't Do If Not Needed
After some time you may observe that the Comité de pilotage becomes an empty gesture ceremony. This happens when the stakeholders (including of course the %-SPONSOR%s) become imbued with the culture of Agility, participating to the usual ceremonies, understand the importance of the %SYSD%, the %SD%,the %ACCD%, the %I+A%, the %RTPS% etc. having their say at any given time (see also %-RS%).
Lorsque cela devient la vie habituelle d'un train, toutes les parties prenantes sont tenues au courant du rythme du train, de ce qui va bien, de ce qui va mal, de ce que le train a fait avec l'argent qu'il a reçu, etc. Les rapports formels sont de moins en moins nécessaires, du moins en ce qui concerne les réunions. Bien sûr, il reste nécessaire de garder trace des procès-verbaux officiels afin que l'organisation puisse démontrer qu'elle respecte toutes les contraintes réglementaires (ce qui est une nécessité absolue dans les secteurs hautement régulés).
Pour vous aider : Un modèle PowerPoint
Sans aucune publicité aucune, voici un modèle de diapositives Powerpoint pour vos Steercos. Basez-vous sur le modèle, améliorez-le et/ou adaptez-le à votre besoin. Pour ma part, il s'agit d'un modèle que j'utilise depuis environ 15 ans. Il a subi de nombreuses adaptations liées au contexte spécifique que je rencontrais mais m'a TOUJOURS servi de canevas de base que j'ai mis à disposition sur LinkedIn : PowerPoint for a Steerco Meeting
Dans l'illustration qui suit, vous voyez une adaptation récente du modèle pour la mise en relation du budget et de la ligne de temps : la question principale de ce Steerco était l'atterrissage du projet et la nécessité de réaliser un ramp-down progressif de ressources externes, ramp-down parfaitement en ligne avec les prévisions et qui permettait (avec le modèle de Burndown Budget) de s'assurer que le budget restait bien dans les limites permises …
Pour vous aider : Un modèle de burndown budget
Comme indiqué plus haut, je me sers souvent d'un Burndown de budget pour anticiper le moment où le budget de mon projet atteindra le seuil fatidique de 0. Que vous travaillez à capacité fixe ou non, cette feuille Excel vous permet de projeter votre situation budgétaire dans l'avenir (courbe d'extrapolation). Je remplis donc cette feuille comme un rituel chaque vendredi : Budget Burndown. Il vous suffit de modifier la première colonne (budget restant) et la deuxième (dates à considérer) et vous obtenez une situation à jour instantanément.
Voici ce à quoi elle ressemble :