Steerco — Steering Committee — Comité de pilotage (COPIL)

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

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):

1. Alloué
2. Brûlé
3. Estimated to complete
4. Estimated at Completion
5. Taux de brûlage (Burn rate)

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

Comme 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

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 :
  1. 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.
  2. 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.
  On voit, au travers de ces deux situations distinctes, en quoi il peut être intéressant de suivre les évolutions OpEx afin de préserver les capacités futures de l'organisation. Quand ce genre de situation se présente, je joins à ma présentation Steerco de quoi susciter une prise de conscience.

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.

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 :