Il existe un mythe dans les cercles de planification selon lequel plus de détails sont meilleurs et plus précis. Dans la planification des ressources, cela ressemble à d'énormes feuilles de calcul avec les noms des personnes affectées à des projets spécifiques au fil des mois ou des semaines pendant au moins un an. Si on peut planifier autant de détails aussi loin, ça doit être précis, non ? Eh bien, pas si vite. Cette approche présente trois problèmes principaux :
- Il faut beaucoup de temps pour créer et modifier ces feuilles de calcul.
Si vous voulez voir ce qui se passe si vous réalisez les projets A, B et D au lieu de C, E et F, vous finirez probablement par brûler l'huile de minuit pour y parvenir. Et j'espère que vous ne vous tromperez pas dans les formules de cette feuille de calcul pendant que vous y êtes. Et si plusieurs personnes accèdent à cette feuille de calcul, essayez de ne pas vous marcher sur les pieds (ou les rangs) des autres. Si vous gérez les ressources d'un grand groupe, cela devient rapidement lourd et conduit au redoutable syndrome de paralysie par analyse. - Ces grandes feuilles de calcul font qu'il est très difficile de voir la forêt pour les arbres.
Bien sûr, il existe des onglets de résumé dans la feuille de calcul, mais vous ne pouvez pas jouer avec ces résumés. Vous devez revenir au détail à partir duquel ils sont enroulés pour voir comment la forêt pourrait changer si vous modifiez certains de ces arbres. Disons que la vue "forêt" vous montre les résumés départementaux à travers les projets. Cela vous laissera quand même plusieurs lignes dans l'onglet résumé pour arriver à la ligne de fond qui montre si ce département ou ce groupe est en surcapacité. Et s'ils le sont, c'est le retour aux fiches de détails pour trouver comment le changer. - Vous essayez de résoudre le mauvais problème !
Le niveau "forêt" s'occupe principalement d'approuver les bons projets qui correspondent à la capacité disponible. Il ne s'agit pas d'un problème utilisateur par utilisateur, mais d'un problème de capacité à plus grande échelle. Si vous avez un département informatique de 500 personnes, par exemple, vous voulez vraiment voir une répartition de ces 500 personnes en groupes logiques et ensuite sélectionner les projets qui correspondent à ces groupes.
L'orateur invité à notre prochain webcast destiné aux clients de l'Entreprise Agile, le 10 novembre, le Dr. Klaus Leopold, a publié un livre en 2018 intitulé " Rethinking Agile : Why Agile Teams Have Nothing To Do With Business Agility " qui aborde ce sujet de manière très intéressante, dans un contexte légèrement différent. Il a décrit et réparti les différents types de planification et d'exécution en trois "niveaux de vol". Ces niveaux de vol peuvent également s'appliquer à la planification des ressources. Je vous laisse lire le livre pour en avoir une compréhension complète, mais voici comment je les applique à la planification des ressources.
Stratégie. Coordination. Opération.
"Flight Level 3" est le niveau stratégique et est analogue à un avion en croisière à 30,000 pieds. Si vous pilotez un avion à cette altitude, vous ne vous attendez pas à voir des individus au sol. La plupart du temps, vous voyez de vastes paysages avec des villes, des autoroutes et des fermes. Vous n'avez pas besoin de voir les individus au sol pour savoir où faire voler l'avion, vous avez juste besoin de ce paysage plus large. En termes de planification des ressources, cela peut correspondre à des départements ou à de grandes équipes. Plus de détails que l'ensemble du groupe informatique de 500 personnes dans son ensemble, mais certainement moins que chacune des 500 personnes. La clé ici est le problème que nous résolvons - s'assurer que nous ne surchargeons pas la capacité du système. C'est ça ! Pas qui fera le travail, pas quels rôles sont impliqués - assurons-nous simplement de ne pas surcharger le système.
"Niveau de vol 2" est la coordination à une altitude plus modérée comme 15,000 pieds pour rester dans l'analogie avec un avion. À ce niveau, nous nous attendons à voir plus de détails, mais toujours pas les individus sur le terrain. Pour la planification des ressources, il peut s'agir de rôles tels que chef de projet, analyste commercial, ingénieur. Notez que je n'inclus pas ces types basés sur le rôle au niveau de vol 3. Ici, nous résolvons la question de la disponibilité des ressources critiques. Si nous avons effectué la planification du niveau de vol 3 et que le système global n'est pas surchargé, alors nous trouverons déjà beaucoup moins de contention pour les ressources. Cependant, il peut encore y avoir des surcharges pour des ressources critiques telles que les chefs de projet ou des types spécifiques d'ingénieurs. Je considère que ce niveau consiste à trouver les bons types de personnes pour les bons projets.
"Flight Level 1" est opérationnel, une très basse altitude de 5,000 pieds et moins où les objets individuels sont clairement visibles et distinguables. Nous cherchons maintenant à savoir qui fera le travail. Ceci est du ressort des chefs de projet qui assignent le travail ou des propriétaires de produits qui donnent la priorité aux histoires que les individus doivent tirer.
Planification de la capacité des ressources - Ne surchargez pas le système
Les niveaux de vol étant décrits, plongeons un peu plus profondément dans le niveau de vol 3 - la planification de la capacité des ressources. Rappelez-vous, l'objectif ici est simplement de et non de surcharger le système de travail et de réduire les décisions stratégiques en fonction de ce qui rentrera dans le tuyau de la capacité.
La première chose à faire est de déterminer la capacité réelle de vos tuyaux. Si vous faites du département informatique de 500 personnes un tuyau unique, vous pouvez sélectionner des projets qui entrent dans le cadre de sa capacité de 20,000 heures par semaine. Et vous pourriez sélectionner beaucoup trop de projets Web et laisser les ingénieurs réseau se tourner les pouces.
Si vous êtes un atelier Agile, ce sera beaucoup plus facile. Vous utilisez déjà Teams. Si votre entreprise est grande, il se peut qu'il y ait des départements d'ingénierie composés de plusieurs équipes et vous pouvez choisir d'utiliser soit la capacité des équipes, soit celle des départements. Et cela peut être exprimé en story points, en mois-personnes, en jours ou en sprints. Ce qui est bien avec les équipes Agile, c'est qu'elles sont déjà équilibrées. Une équipe typique peut être composée d'un maître de mêlée, d'un testeur et de quatre ingénieurs. Si ce ratio ne fonctionne pas, la composition de l'équipe peut être ajustée de manière à ce que les histoires s'enchaînent sans heurts et que vous puissiez cibler des initiatives ou des projets sur une équipe et savoir quelle quantité rentrera dans leur tuyau.
Agile teams work great for software only projects, but PMOs manage a broad range of work, which often needs infrastructure resources, subject matter experts (SMEs), and project management. Now how do we divide up that 500-person IT department? One way is to develop virtual capacity teams. Individual resources are usually specialized in most large IT departments. Thus, infrastructure projects will have PMs that only manage infrastructure, specialized business analysts, and of course network engineers and admins. Maintaining third-party software applications will also find specialized project management and engineering resources. That 500-person shop can probably be broken down into a dozen or so minimally overlapping virtual capacity teams.
Bien entendu, aujourd'hui, vous menez probablement des projets à la fois en cascade et agiles, de sorte qu'un hybride de ce qui précède est tout à fait probable.
Maintenant que nous avons abstrait une véritable vue de planification 30,000 pieds pour la capacité, nous pouvons sélectionner le travail. Au lieu de sélectionner les 20 meilleurs projets sur 100 proposés, nous pouvons sélectionner les 10 meilleurs projets Web, les cinq meilleurs projets d'infrastructure, et ainsi de suite. Et, vous pouvez glisser quelques petits projets Web dans la capacité restante. Très probablement, ces projets 20 supérieurs deviennent 30 lorsqu'ils sont alignés avec leurs tuyaux de capacité. Bien sûr, si vous devez modifier le plan, c'est aussi simple que de changer la composition des projets dans chacune des douzaines d'équipes de capacité - et non de changer les projets attribués à chacune de ces 500 personnes.
En fin de compte, tout se résume à résoudre le bon problème au bon niveau de planification. Dans l'ensemble, les problèmes de capacité des ressources sont un problème de "niveau de vol 3". Non seulement l'important n'est pas dans les détails, mais trop de détails empêcheront l'agilité de l'entreprise et la prise de décisions judicieuses que nous recherchons tous. Vous passerez plus de temps à mettre à jour les détails qu'à vous assurer du bon déroulement des projets !
