Alternative à Asana pour la planification de projets

Là où la chronologie d’Asana cesse d’être un planning

La plupart des articles sur une alternative à Asana pour la planification de projets commencent en affirmant qu’Asana n’a pas de diagramme de Gantt. C’est faux, et partir d’une prémisse fausse est une mauvaise façon d’aider qui que ce soit à choisir un outil. Asana dispose d’une vue chronologie qui trace des barres sur un axe horizontal, les relie par des flèches, marque les jalons par des losanges et peut, sur demande, mettre en évidence le chemin critique. Pour une campagne, le lancement d’un produit ou un processus de recrutement, c’est une façon parfaitement raisonnable de planifier.

La vraie question est différente. Non pas si le diagramme existe, mais s’il repose sur un modèle de planification, c’est-à-dire un ensemble de règles que le système applique quand quelque chose bouge. Un diagramme sans modèle est l’image d’un plan. Un diagramme avec modèle est un plan. La différence n’apparaît que lorsque la réalité se met à pousser contre les dates, ce qui survient généralement la troisième semaine, pas le jour où le plan est approuvé.

Ce qu’Asana fait bien

Asana est vraiment bonne pour rendre le travail visible et pousser les gens à agir en conséquence. Les tâches ont des responsables, des commentaires et des échéances claires, la chronologie est facile à manipuler et les tâches dépendantes se décalent quand leur prédécesseur bouge. Les dépendances sont décrites dans un langage que personne n’a besoin d’apprendre, bloque et bloquée par, ce qui explique que les équipes adoptent l’outil en un après-midi. Pour dix personnes menant une campagne de huit semaines, ce n’est pas un compromis, c’est exactement la bonne dose d’outil pour la tâche. Toute comparaison qui prétend le contraire vend au lieu de conseiller.

Ce qui mérite d’être remarqué, c’est où se paie cette simplicité. Chaque capacité qu’Asana laisse hors de la chronologie en est une qui aurait rendu le produit plus difficile à apprendre, et pour la plupart de ses utilisateurs c’est le bon compromis. La question est de savoir ce qui arrive aux équipes pour lesquelles il ne l’est pas.

Le moment où le plan cesse de se recalculer tout seul

Le point de bascule arrive en silence. Un fournisseur confirme une livraison deux semaines plus tard que prévu, et le chef de projet déplace une tâche sur la chronologie. Le successeur immédiat suit, parce que ce lien est compris. Puis le chef remarque que la recette prévue après une période de durcissement obligatoire de deux semaines commence maintenant trop tôt, parce que l’écart entre ces tâches n’a jamais été une règle, seulement un espace vide sur un diagramme. La tâche du projet voisin qui devait démarrer après cette livraison ne bouge pas du tout, parce que les deux projets ne se connaissent pas. Une demi-heure plus tard, le chef fait glisser des barres à la main et compare les dates avec un tableur.

C’est le moment où un planning cesse d’être un modèle. Le plan n’est plus quelque chose que le système entretient, c’est quelque chose qu’une personne entretient, et cette personne devient le point de défaillance unique. Chaque replanification coûte des heures, chaque heure de replanification est une heure non consacrée au vrai problème, et après la troisième ou quatrième itération les gens cessent complètement de mettre le plan à jour parce que l’effort ne se justifie plus. Un plan abandonné est pire que pas de plan, car des rapports continuent d’en être générés. Nous décrivons à part ce que doit offrir une alternative à Asana pour un PMO.

Cinq signes que vous avez dépassé la planification d’Asana

Aucun de ces signes ne concerne la taille de l’équipe ni le budget. Ils concernent la forme du travail, c’est pourquoi une équipe d’ingénierie de douze personnes peut les rencontrer alors qu’un service marketing de soixante ne les rencontre jamais. Si deux ou plus décrivent vos projets, votre contrainte est la couche de planification, pas le nombre de fonctionnalités.

Vous planifiez en jours ouvrés, pas en jours calendaires. Une tâche de cinq jours commençant le jeudi devrait se terminer le mercredi suivant, et un jour férié au milieu devrait repousser la fin d’un jour de plus. Si vos durées incluent discrètement les week-ends, chaque estimation porte une erreur intégrée qui s’accumule sur un plan de plusieurs mois.

Certains écarts de votre plan relèvent de la physique, pas de la préférence. Le béton durcit, les revêtements sèchent, une période de validation s’écoule, un délai de préavis expire, un régulateur dispose de trente jours pour répondre. Ce ne sont pas des tâches que quelqu’un exécute, ce sont des intervalles qui doivent s’écouler entre deux tâches. Les équipes sans moyen de les exprimer inventent des tâches fictives appelées « en attente d’approbation », ce qui pollue la liste de tâches et induit en erreur chaque rapport bâti dessus.

Le planning d’un projet pilote celui d’un autre. Dès qu’une livraison du projet d’infrastructure conditionne le démarrage du projet de migration, et que les deux sont gérés séparément, quelqu’un garde cette dépendance en mémoire. La mémoire n’envoie pas de notifications et ne survit pas aux congés.

On vous demande de combien le projet a dérivé du plan initial. Non pas quelles sont les dates actuelles, mais comment elles se comparent à ce qui a été approuvé, et pourquoi. Sans planning de référence enregistré, la réponse honnête est que personne ne le sait, et la version qui circule dans la présentation du comité de pilotage est une reconstruction.

Le planning a besoin de plus de deux niveaux. Des phases contenant des étapes contenant des tâches, avec un avancement qui se cumule automatiquement vers le haut et des dates propres à chaque niveau. Une liste plate avec des en-têtes de section paraît similaire à l’écran et se comporte tout autrement quand le plan change. Nous examinons aussi quoi rechercher parmi les applications comme Asana.

Les types de dépendance et pourquoi leur sémantique décide du plan

Une dépendance n’est pas une ligne tracée entre deux barres. C’est une règle que le système applique chaque fois que l’une des extrémités bouge, et le type de relation est le contenu de cette règle. C’est la partie que la plupart des comparaisons d’outils sautent, car un tableau avec une coche à côté de « dépendances de tâches » masque la différence entre un système qui redessine des flèches et un système qui recalcule des dates. FlexiProject comme Asana prennent en charge les quatre types standard, la question intéressante est donc ce qui les entoure.

Bien saisir la sémantique n’est pas de la précision pour la précision. Elle décide si un chef de projet répond à la question « si cela glisse d’une semaine, quand finissons-nous » en trois secondes en regardant le diagramme, ou en trois heures en reconstruisant le plan. Là où plusieurs projets se disputent les mêmes personnes, cette différence décide si la replanification a seulement lieu.

FS, SS, FF et SF en pratique

Fin-début est la valeur par défaut partout et couvre l’essentiel du travail séquentiel : le mur doit être construit avant d’être peint. Début-début décrit un travail qui court en parallèle à partir d’un déclencheur commun, par exemple la documentation qui commence au moment où commence le développement et reste à peu près à son rythme. Fin-fin décrit un travail qui doit aboutir ensemble, comme la formation des utilisateurs qui doit être terminée le jour de la mise en production, quel que soit le moment où elle a commencé. Début-fin est rare et apparaît surtout dans les bascules, où l’ancien système ne peut être arrêté qu’une fois le nouveau en fonctionnement.

Quiconque construit des plannings sérieusement utilisera au moins les trois premiers, et les organisations projet matures utilisent les quatre pour modéliser la réalité avec précision au lieu de tout forcer dans une chaîne de liens fin-début. Si vous souhaitez un parcours plus approfondi avec des exemples travaillés, nous avons écrit séparément sur les types de dépendances de tâches dans un diagramme de Gantt.

Délai fixe : les jours qui doivent simplement passer

Dans FlexiProject, chaque relation peut porter un délai fixe exprimé en jours. La dépendance signifie alors « commence cette tâche quatre jours après la fin de la précédente », et ces quatre jours font partie de la règle au lieu d’être un écart estimé à l’œil sur le diagramme. Quand le prédécesseur bouge, le délai bouge avec lui, automatiquement et sans que personne se souvienne qu’il était là.

L’effet métier est que les contraintes technologiques cessent de vivre dans la tête des gens. Une période de durcissement, une fenêtre d’examen réglementaire, une quarantaine obligatoire entre lots de production ou un délai de préavis contractuel devient partie de la logique du plan. Personne n’a à créer une fausse tâche pour garder l’espace ouvert, personne n’a à expliquer à un collègue pourquoi deux barres ne doivent pas être rapprochées, et aucune replanification ne peut supprimer discrètement une contrainte qu’imposent la physique ou un contrat. Dans les projets où une séquence manquée signifie une reprise et non un courriel en retard, c’est la différence entre un plan digne de confiance et un plan qu’il faut vérifier deux fois.

Relations dures : quand le lien ne doit pas être rompu

FlexiProject distingue en outre les relations dures, marquées dans le panneau de la tâche par deux anneaux entrelacés. Une relation dure signifie que l’élément lié ne peut pas être éloigné à la main de son prédécesseur. Le système ne laissera pas un utilisateur rompre discrètement la séquence en déplaçant une barre sur le diagramme, ce qui semble restrictif jusqu’à ce que vous ayez vu un planning se dégrader au fil de six mois d’ajustements manuels bien intentionnés.

Cela compte surtout là où un planning est un document partagé et non le fichier d’une seule personne. Dans un grand projet, plusieurs personnes modifient le plan, et chacune a une raison locale de déplacer quelque chose. Une relation dure encode la différence entre une séquence qui est une hypothèse de planification, donc ouverte à la discussion, et une séquence qui est une contrainte dure, donc non. Le chef de projet cesse de surveiller le plan à la main et commence à s’y fier, ce qui est tout l’intérêt d’un logiciel de planification dès le départ.

Les dépendances entre projets : la couche qu’Asana n’a pas

À l’intérieur d’un seul projet, les dépendances sont une commodité. Entre projets, elles font la différence entre un programme et un dossier de plans sans lien. Dans FlexiProject, une relation peut connecter une tâche d’un projet à une tâche d’un autre, de sorte que la livraison d’infrastructure qui conditionne une migration est un lien que le système connaît et non une note dans le compte rendu de réunion de quelqu’un. Quand la date d’un côté bouge, les tâches dépendantes de l’autre projet sont recalculées et leurs responsables sont notifiés.

La conséquence pratique apparaît dans la prise de décision, pas sur le diagramme. Avant d’approuver un changement dans un projet, un responsable de programme peut voir comment ce changement se propage dans les projets restants, comparer le planning avant et après et juger du coût réel d’un oui. Sans cela, le coût remonte des semaines plus tard sous forme d’une série de surprises séparées, chacune ressemblant à un problème local et traitée comme tel. Les programmes pluriannuels sont précisément là où cela s’accumule, car une décision de deux semaines prise à la légère au troisième mois peut déplacer une date de mise en service au vingtième.

Toutes les tâches d’un programme sont en outre visibles sur un unique diagramme de Gantt partagé, si bien qu’un responsable de programme voit les liens en un seul endroit au lieu de les reconstituer à partir de rapports d’avancement. Les équipes qui en ont besoin le découvrent généralement à la dure, après avoir d’abord tenté de coordonner la même chose avec une réunion récurrente. Si votre organisation va dans cette direction, notre logiciel de gestion de programmes de projets explique comment les programmes sont structurés.

Le modèle sous le diagramme de Gantt

Les relations sont la partie la plus visible du modèle de planification, mais pas tout le modèle. Quatre autres mécanismes décident si un diagramme se comporte comme un plan, et ce sont eux qui séparent un logiciel de diagramme de Gantt d’un widget de chronologie. Aucun d’eux n’est exotique. Tous sont de ces choses qui ne vous manquent qu’une fois que vous en avez besoin.

WBS illimité et avancement qui se cumule tout seul

Les projets d’une même organisation varient énormément en taille, d’un gain rapide de deux semaines à un investissement en capital sur plusieurs années, et une structure rigide unique ne peut servir les deux. FlexiProject ne pose aucune limite à la profondeur de la structure des tâches, si bien qu’un projet peut être découpé en phases, étapes, tâches et jalons aussi bas que nécessaire. Un petit projet peut rester plat avec une poignée de tâches, tandis qu’un projet d’investissement peut porter une structure de découpage du travail à plusieurs niveaux, et les deux utilisent la même interface.

L’avancement n’est saisi qu’au niveau des tâches individuelles. L’avancement d’étape et l’avancement global du projet sont calculés automatiquement à partir des tâches en dessous, si bien que personne n’a à penser à mettre à jour les agrégats avant qu’un rapport ne sorte. Cela ressemble à une petite commodité et c’est en réalité un mécanisme de qualité des données : le statut au niveau du portefeuille est dérivé des mêmes chiffres que l’équipe maintient au quotidien, et non d’un résumé tapé à la hâte la veille d’un comité de pilotage.

Un calendrier de travail plutôt que des dates calendaires brutes

Un planning qui compte les week-ends comme du temps de travail produit des dates fausses dès le premier jour. FlexiProject calcule les durées par rapport à un calendrier de travail, si bien qu’une tâche exprimée en jours ouvrés tombe là où elle tombe réellement une fois pris en compte les week-ends et les jours fériés. La même logique sous-tend les modèles réutilisables : les tâches d’un modèle portent une durée en jours ouvrés et un ensemble de dépendances au lieu de dates fixes, si bien que saisir une date de début de projet génère tout le planning automatiquement.

Pour une organisation qui mène des projets similaires de façon répétée, c’est là que le temps de planification s’effondre. Au lieu de reconstruire un plan à partir de zéro et de re-dériver chaque date, un chef de projet part d’une structure approuvée et ajuste ce qui est vraiment différent dans ce cas. Notre module de modèles de projet existe précisément pour ce schéma, et c’est aussi pourquoi les modèles bâtis par un PMO expérimenté conservent leur valeur pendant des années.

Planning de référence et écart par rapport au plan

Une fois un plan approuvé, FlexiProject l’enregistre comme planning de référence. Le diagramme de Gantt montre alors le plan initial à côté du planning actuel, si bien que chaque écart est visible immédiatement au lieu d’être déduit. Le système prévoit aussi la date d’achèvement du projet par rapport à celle approuvée, ce qui est généralement le seul chiffre qu’un conseil de direction veut vraiment.

La valeur ici tient moins à la mesure qu’à la qualité de la conversation. Un chef de projet capable de montrer ce qui a été approuvé, quelle est la situation maintenant et quelle décision a causé l’écart est dans une position différente de celui qui ne peut que rapporter les dates actuelles. La discussion passe de la question de savoir si le projet est en retard à celle de quoi faire de la cause précise, qui est la seule version de cette conversation qui se termine par une décision.

Chemin critique et marge

FlexiProject identifie le chemin critique automatiquement et le marque en rouge sur le diagramme de Gantt, si bien qu’un chef de projet sait immédiatement quelles tâches méritent attention. L’usage pratique est dans le tri. Un glissement de deux jours sur une tâche critique est un glissement de deux jours pour tout le projet, tandis qu’un glissement de deux jours sur une tâche avec dix jours de marge est du bruit. Sans cette distinction, chaque retard est escaladé avec la même urgence, ce qui apprend à tout le monde à ignorer les escalades.

Avec plusieurs flux en parallèle, par exemple des travaux menés à côté du montage et de la documentation, le chemin critique est ce qui empêche un responsable d’optimiser le mauvais. Si le concept est nouveau pour votre équipe, nous avons traité plus en profondeur ce qu’est le chemin critique et comment le gérer. Nous montrons également à quoi ressemble la gestion des risques du projet en pratique.

Les ressources sur le diagramme de Gantt : temps et capacité planifiés ensemble

Un planning qui ignore qui est disponible est une liste de souhaits. FlexiProject affiche la charge des ressources directement depuis le diagramme de Gantt, si bien qu’un chef de projet voit d’un coup d’œil quelles personnes sont surchargées sur une période donnée et lesquelles ont encore de la capacité. Les tâches peuvent être déplacées le long de la chronologie tout en observant la charge changer, ce qui transforme la replanification en simulation plutôt qu’en supposition : le plan est optimisé avant d’être approuvé, pas après que quelqu’un se plaint.

Cela comble une lacune qui apparaît constamment dans les organisations menant plusieurs projets avec les mêmes personnes. Planifier un nouveau projet, c’est savoir si les spécialistes dont il a besoin sont déjà engagés ailleurs, et dans la plupart des entreprises cette vérification se fait à la main, dans un tableur, avec un délai assez long pour rendre la réponse obsolète. Quand la capacité est dans la même vue que les dates, l’arbitrage entre finir plus tôt et surcharger une équipe cesse d’être invisible jusqu’à ce que quelqu’un démissionne.

Les retards remontent avec la même franchise. Les tâches en retard sont surlignées en rouge, si bien qu’ouvrir le projet suffit à voir où une intervention est nécessaire, sans générer d’abord un rapport. Pour les organisations qui veulent aller plus loin et gérer la disponibilité sur l’ensemble du portefeuille, notre logiciel de gestion des ressources traite la charge au-delà d’un seul projet.

FlexiProject et Asana : les capacités de planification comparées

Le tableau ci-dessous est volontairement étroit. Il ne couvre que la planification et accorde à Asana chaque capacité qu’elle possède réellement, car une comparaison qui sous-estime un concurrent est inutile pour qui la lit. La collaboration, l’automatisation des flux et les intégrations sont une autre conversation, et sur plusieurs d’entre elles Asana est le produit le plus fort.

Lisez le tableau comme une description d’intention et non comme un score. Asana est conçue pour que n’importe qui puisse planifier sans formation, et chaque capacité ci-dessus qu’elle omet en est une qui rendrait le produit plus difficile à apprendre. FlexiProject accepte un démarrage un peu plus raide en échange d’un planning qui garde sa forme sous pression. Quel arbitrage est le bon dépend entièrement de savoir si vos projets sanctionnent un plan imprécis.

Sortir un planning d’Asana sans perdre le plan

La partie mécanique d’une migration prend moins de temps qu’on ne le pense. Un planning s’importe depuis un fichier Excel ou un fichier Microsoft Project, apportant les tâches, les responsables, les attributs disponibles et, quand elle existe, la structure des dépendances, si bien que les organisations assises sur des années de plans historiques n’ont pas à les retaper. Les exports vont dans l’autre sens vers Excel, Microsoft Project XML, PDF et PNG, ce qui compte quand un prestataire ou un auditeur insiste sur un format précis.

La partie qui mérite une vraie réflexion, c’est le remodelage. Un plan bâti dans Asana l’a été sous les contraintes d’Asana, ce qui signifie que les périodes d’attente sont probablement de fausses tâches, la séquence probablement une chaîne de liens fin-début et la structure de phases probablement des en-têtes de section. Recopier cela fidèlement reproduit la limitation dans un système qui ne l’a plus. La meilleure approche est de prendre un projet représentatif, de reconstruire sa logique correctement avec les bons types de relation, des délais fixes là où les intervalles sont obligatoires et des relations dures là où la séquence n’est pas négociable, et d’utiliser le résultat comme modèle pour tout le reste.

Pour la première passe, il y a un raccourci à connaître. FlexiProject peut générer un brouillon de planning à partir d’une description des objectifs et exigences du projet, produisant des tâches, des jalons, des dépendances et un diagramme de Gantt qu’un chef de projet édite ensuite au lieu de le construire à partir de rien. Cela ne remplacera pas le jugement d’un planificateur expérimenté, mais cela supprime le problème de la page blanche, où la plupart des efforts de replanification s’enlisent. Pour un parcours structuré, nous avons écrit sur comment construire un planning de projet étape par étape. À part, nous détaillons ce qu’est un vrai contrôle du budget de projet.

Questions fréquentes

Asana prend-elle en charge les quatre types de dépendance ?

Oui. Asana prend en charge fin-début, fin-fin, début-début et début-fin, avec fin-début par défaut. Les affirmations selon lesquelles Asana n’offrirait qu’un seul type de dépendance apparaissent dans plusieurs articles de comparaison et sont dépassées. Les lacunes significatives de la planification d’Asana sont ailleurs : dans les délais fixes, les relations dures, les calendriers de travail, les plannings de référence et les liens entre projets.

Peut-on définir un temps de délai entre les tâches dans Asana ?

Non. Asana ne permet pas d’attacher un délai fixe à une dépendance, si bien qu’un intervalle obligatoire entre deux tâches doit être représenté autrement, généralement par un espace vide sur la chronologie ou une tâche fictive. Les deux contournements se cassent dès que le prédécesseur bouge, car aucun n’emporte le délai avec lui. Dans FlexiProject, le délai est une propriété de la relation elle-même et s’exprime en jours.

Asana a-t-elle un planning de référence de projet ?

Non. Asana ne stocke pas de version approuvée du planning pour comparaison, si bien qu’il n’y a pas de moyen intégré de voir de combien le plan actuel a dérivé de ce qui a été convenu au départ. Les équipes qui en ont besoin gardent généralement un instantané dans un tableur, qui répond à la question une fois puis devient obsolète. FlexiProject conserve le plan approuvé comme planning de référence et l’affiche à côté du planning actuel sur le diagramme de Gantt.

Peut-on lier des tâches de deux projets différents ?

Pas dans Asana. Les dépendances restent à l’intérieur d’un seul projet, si bien qu’une séquence entre projets doit être coordonnée par des personnes plutôt que maintenue par le système. FlexiProject permet une relation entre des tâches appartenant à des projets différents, recalcule les dates dépendantes quand l’un des côtés bouge et notifie les responsables concernés, ce qui est l’exigence de base pour gérer un programme plutôt qu’un ensemble de projets en parallèle.

FlexiProject est-il plus difficile à utiliser qu’Asana ?

Il demande plus au début et moins ensuite. Asana est conçue pour que quelqu’un puisse planifier dès le premier jour, en partie en laissant de côté les concepts décrits dans cet article. FlexiProject attend d’un chef de projet qu’il comprenne les types de relation, les calendriers de travail et les plannings de référence, et en retour maintient le plan au lieu de demander à une personne de le maintenir. Les équipes aux projets simples trouveront Asana plus rapide. Les équipes dont les projets sanctionnent un plan inexact trouvent généralement l’inverse.

Choisir une alternative à Asana pour la planification de projets n’est pas vraiment un choix entre deux outils. C’est une décision sur le point de savoir si vos projets ont besoin d’un plan qu’une personne entretient ou d’un plan qu’un système entretient, et cela dépend de ce que coûte le fait que les dates soient fausses. Si une date glissée signifie une réunion reprogrammée, Asana est une bonne réponse et ajouter une machinerie de planification ne ferait que ralentir l’équipe. Si une date glissée signifie des prestataires inactifs, une fenêtre réglementaire manquée, une reprise sur une ligne de production ou une clause de pénalité, alors le modèle sous le diagramme n’est pas un détail. C’est le produit.

Ce qui change avec un modèle de planification complet est plus petit que ne le suggère une liste de fonctionnalités et plus grand que ça n’en a l’air. Les relations portent des délais fixes, si bien que les intervalles obligatoires font partie du plan au lieu de la mémoire de quelqu’un. Les relations dures tiennent les séquences qui ne sont pas ouvertes à la négociation. Les dépendances traversent les projets, si bien qu’un programme se comporte comme un programme. Un calendrier de travail fait que les durées signifient ce qu’elles disent, un planning de référence rend l’écart visible, et le chemin critique dit quels retards comptent vraiment. Séparément, cela ressemble à des raffinements. Ensemble, c’est la différence entre replanifier en quelques minutes et replanifier sur tout un week-end.

Si vous voulez voir les deux produits côte à côte sur l’ensemble du périmètre et pas seulement le planning, y compris les budgets, les risques, les chartes de projet et la gouvernance de portefeuille, nous avons préparé une comparaison détaillée de FlexiProject et Asana. Et si vos projets poussent déjà contre les limites décrites ici, l’étape suivante la plus utile est d’en prendre un, de reconstruire son planning correctement et de voir combien de travail manuel disparaît.