Planification de capacité

Dans un monde où les entreprises sont constamment poussées à réaliser plus, la gestion des ressources devient un véritable casse-tête. La planification de capacité est un outil indispensable pour sortir la tête de l’eau.

Cet article rappelle pourquoi la planification de capacité est essentielle, quels en sont les bénéfices pour l’organisation, et présente comment cette fonctionnalité clé fonctionne dans timeperformance, le logiciel de gestion de portefeuille de projets en SaaS.

Pourquoi la planification de capacité

Avoir trop de projets en cours a des conséquences néfastes:

  • des retards importants sur les projets qui finissent par prendre 3 fois plus de temps que prévu
  • un épuisement des équipes avec à terme un turnover important.

A vouloir en faire plus, on en fait moins. C’est le paradoxe avec le fait de lancer trop de projets.

Or 2 puissants facteurs poussent les organisations à lancer trop de projets:

  1. des besoins toujours plus nombreux (compétitivité, nouvelles technologies, évolutions réglementaires etc…)
  2. la crainte de sous-utiliser les ressources disponibles

La planification de capacité permet de résister intelligemment à la pression du « trop de projets » et d’optimiser la productivité de l’organisation, tout en ménageant les équipes.

En quoi consiste la planification de capacité

La planification de la capacité consiste à comparer les ressources disponibles (la capacité) avec la charge de travail planifiée dans les projets (le plan de charge).

Grâce à cette comparaison, les managers peuvent prendre des décisions importantes:

  • Accepter de nouveaux projets s’il reste de la capacité
  • Refuser de nouveaux projets si la capacité maximale est atteinte
  • Prévoir des recrutements pour rééquilibrer

L’important est que ce type de décisions soit fondé sur des données chiffrées pour éviter les erreurs d’appréciation et les frustrations des demandeurs.

Comment ça marche en pratique

Dans timeperformance, le manager visualise les 2 courbes: celle de la capacité et le plan de charge. La capacité (à ne pas dépasser) est en rouge et, en vert, la charge de travail planifiée par l’ensemble des projets.

L’interprétation de ces courbes est simple: tant que la courbe verte reste en dessous de la courbe rouge, on est en capacité de faire ce qu’on a prévu.

Le manager a la possibilité d’inclure ou d’exclure des projets en cliquant sur la liste en bas pour étudier différents scénarios.

Si la courbe verte reste au-dessus de la courbe rouge malgré la désactivation des projets qu’il était possible de reporter, l’étude des 2 courbes permet de savoir combien et quand recruter.

Enfin, timeperformance permet aussi de visualiser le plan de charge d’une façon plus détaillée en le segmentant par priorité projet (cf. exemple ci-dessous), par statut des projets etc.

Comment les courbes sont calculées

Notons que l’étude de la capacité se fait profil par profil, c’est-à-dire par type de ressources ou par métier. Prenons l’exemple des « développeurs logiciels »…

Pour calculer la capacité, on considère le nombre de développeurs logiciels dans la DSI. Mais cela ne suffit pas.

En effet, il est rare que les collaborateurs soient exclusivement dédiés aux projets ou constamment disponibles. Le hors-projet (activités récurrentes, formation…) et les indisponibilités (congés…) sont des impondérables qui peuvent prendre une partie importante du temps des personnes. Les ignorer conduirait à largement surestimer la capacité à faire.

C’est pourquoi, dans timeperformance, on se concentre sur la capacité restante disponible pour les projets. Cette capacité se calcule comme le nombre de personnes avec le bon profil auquel on retranche les indisponibilités et surtout le hors-projet. Ainsi la courbe présentée ci-dessus de la capacité n’est pas une simple ligne horizontale.

Quant au plan de charge, il se calcule à partir des estimations et des plannings des projets préparés par les chefs de projet. Notons que les plannings de projet n’ont pas besoin d’être très détaillés.

timeperformance vs Excel

Étudier la capacité peut se faire dans Excel car c’est juste des chiffres ou des courbes. Le problème est que cette étude est nécessairement très grossière car la saisie manuelle d’informations est fastidieuse. De plus, maintenir à jour la feuille Excel avec les changements dans les projets ou les ressources est chronophage.

Dans timeperformance, la courbe de planification de la capacité est calculée automatiquement et en temps réel avec les données à jour issues des autres modules du logiciel. Il n’y a pas de ressaisie d’information. C’est donc un gain de temps et une garantie de fiabilité.

timeperformance vs autres logiciels de PPM

Les logiciels traditionnels de PPM (Sciforma, Planisware, Primavera…) reposent sur des planifications détaillées. C’est donc très lourd à mettre en œuvre et cela requiert une certaine stabilité des projets. C’est pourquoi beaucoup préféreront utiliser une feuille Excel à côté pour faire des choses plus simples.

Dans timeperformance, la planification de capacité se fonde sur des planifications qui peuvent être beaucoup moins détaillées, ce qui permet une mise en œuvre facile et plus souple.

Notons néanmoins que ces outils proposent des fonctions de planification de la capacité plus avancées, qui permettent par exemple de maximiser la valeur produite à ressource constante. Mais ces outils nécessitent une vraie expertise.

En résumé

La planification de capacité est l’outil de moyen-long terme de la gestion de ressources. Elle influe sur la constitution du portefeuille de projets en validant sa faisabilité. Elle permet aussi d’anticiper les recrutements dont le processus est généralement assez long.

La planification de capacité est le rempart au problème du « trop de projets » qui épuise les équipes et fait baisser la production de valeur.

timeperformance fournit cet outil indispensable d’une façon moins simpliste qu’une feuille Excel et moins compliquée que les logiciels traditionnels.

 

2 fausses bonnes idées pour sauver l’Agilité

Le titre provocateur « L’Agilité est morte » a envahi la blogosphère ces derniers temps avec des articles qui proposent toujours les mêmes solutions pour la sauver. L’ironie est que ces solutions pour sauver l’Agilité sont souvent les causes de son échec. Voici les 2 fausses bonnes idées les plus courantes.

Étendre l’Agilité à toute l’organisation

Il est couramment admis qu’une équipe agile, isolée et seule, ne peut pas fonctionner correctement si l’ensemble de l’organisation n’est pas elle-même agile et si l’ensemble du management n’est pas impliqué dans la transformation agile globale. Mais c’est une fausse bonne idée pour les raisons suivantes…

Toute transformation globale de l’organisation est une aventure à la fois coûteuse et extrêmement risquée. L’échec de la transformation globale est quasi certain. Cela aboutira au rejet de l’Agile. 

De plus, une transformation globale peut-elle être initiée avec une approche inventée dans le domaine informatique ? Même si le Digital a gagné en importance, une transformation d’une telle envergure ne peut être initiée qu’au niveau des Métiers. 

Enfin, il est utile de rappeler que l’Agilité, née dans les années 90, n’avait alors pas besoin d’une entreprise entièrement agile pour démontrer ses bénéfices. Les pionniers de l’Agilité ont prouvé que d’excellents résultats peuvent être obtenus sans un changement organisationnel global.

Plutôt que de prôner une transformation agile de l’ensemble de l’organisation, n’est-il pas plus judicieux de démontrer concrètement les bénéfices à petite échelle ?

Appliquer l’Agilité au-delà de l’Informatique

L’idée d’appliquer l’Agilité à d’autres domaines que l’informatique est séduisante. Si cela fonctionne pour l’IT, pourquoi pas ailleurs ?

En fait, rien ne garantit que cela marchera. Et en cas d’échec, c’est l’ensemble de l’approche agile qui pourrait être remise en question.

La première difficulté réside dans les spécificités de chaque domaine. Même dans  l’Informatique, l’Agilité n’est pas adaptée à tout. En effet, conçue pour le développement logiciel, l’Agilité n’est pas adaptée aux projets d’infrastructure.

La seconde difficulté est la résistance naturelle au changement. Les autres services de l’entreprise pourraient être satisfaits de leurs processus actuels et percevoir cette transformation initiée par l’informatique comme une intrusion indésirable.

Il faut faire une distinction entre l’Agilité dans le développement logiciel et les autres formes d’Agilité dans d’autres domaines. L’Agilité dans le développement logiciel a de solides fondements et des réussites reconnues tandis que les autres formes ont besoin de faire leur preuve.

Faut-il sauver l’Agilité ?

L’Agilité n’étant pas une fin en soi, une question s’impose: faut-il sauver l’Agilité ?

En fait, l’Agilité n’a pas besoin d’être sauvée. Si cela fonctionne, tout va bien et la question de sa survie ne se pose pas. Si il n’y a pas de bénéfices évidents, il faut chercher une approche plus adaptée.

D’ailleurs, l’Agilité comme un tout unique n’existe pas. Il y a juste des interprétations de principes très généraux et des tentatives de mise en oeuvre de ces principes.

Pour toute organisation qui se lancerait dans une mise en oeuvre de l’Agilité, notre conseil serait de toujours commencer à petite échelle.

En conclusion, on peut dire que l’Agilité « solution miracle » est morte. Les tentatives pour la sauver en la faisant passer « à l’échelle » risquent d’aboutir à une déception encore plus grande. Mais ce serait dommage de ne plus en faire du tout…

 

Feuille de temps : Pourquoi saisir en heures plutôt qu’en jours

timetrackingContrairement à la plupart des outils, la saisie dans les feuilles de temps dans TimePerformance se fait en heures et non en jours.

La saisie en jours est une pratique répandue mais contre-productive. Elle pénalise l’opérationnel pour satisfaire des besoins comptables ou RH, enrobé dans un faux sentiment de simplicité.

Les problèmes de la saisie des temps en jours

La saisie des temps en jours consiste à saisir ses temps en demi-journées ou en quarts de journée pour arriver à un jour de travail par jour.

C’est la saisie la plus simple ? Faux.

En tout cas, c’est plus compliqué pour toutes les personnes qui saisissent – et cela en fait beaucoup – car cela ajoute une charge cognitive significative à une tâche déjà fastidieuse en elle-même.

Avec la saisie en jours, la personne qui saisit doit réfléchir à comment arrondir à la demi-journée son temps de travail, ce qui se complique si on a fait 3 choses différentes dans la journée (5 si on saisit en quarts de journée). Ce type de saisie impose artificiellement un nombre maximum trop petit de choses qu’on peut faire dans une journée. Il va donc falloir bidouiller pour coller au plus près de la réalité.

C’est plus compliqué à la saisie mais c’est aussi contre-productif. Continuer la lecture de « Feuille de temps : Pourquoi saisir en heures plutôt qu’en jours »

Définition de la gestion de projet pour une mise en oeuvre pragmatique

En matière de gestion de projet, il y a un énorme fossé entre la théorie et la pratique. Les méthodes et les référentiels sont trop compliqués pour être mis en oeuvre. En pratique, moins de 10% des techniques préconisées par ces méthodes sont utilisées.

Cet article est un retour à des choses simples: une définition concise et un framework simple pour une mise en oeuvre pragmatique de la gestion de projet.

Définition

Dans un projet, le plus important est de construire le produit. Néanmoins construire le produit n’est pas suffisant car les choses ne se font pas d’elles-mêmes.

Il est nécessaire de mettre en place de la coordination entre les acteurs du projet, un suivi de l’avancement, une gestion financière… c’est-à-dire une gestion de projet.

La gestion de projet est la discipline qui regroupe l’ensemble des activités « d’organisation » du projet qui s’ajoutent aux activités de « construction » du projet.

Les activités de gestion de projet sont nombreuses car organiser consiste à se préoccuper de tout.

Les activités de gestion de projet sont simples. La gestion d’un projet n’est pas la gestion d’une entreprise.

C’est le fait de penser à tout qui est compliqué. C’est pourquoi la gestion de projet demande méthode, discipline et un outil informatique.

Continuer la lecture de « Définition de la gestion de projet pour une mise en oeuvre pragmatique »

Structure du plan d’un projet

Dans TimePerformance, tous les projets ont un plan avec une structure standardisée reposant sur 3 concepts de base: les phases, les livrables et les tâches.

Il est important de bien comprendre cette structure. Cela facilite l’utilisation du logiciel. Mais surtout, cela aide à la planification et à la gestion de projet. En effet, cette structure est du simple bon sens et on la retrouve dans toutes les méthodes de gestion de projet (Scrum, Prince2, Cycle en V…).

Plan Projet à 3 niveaux

Les niveaux du plan d’un projet sont:

  • Niveau 1: Phasage
  • Niveau 2: Livrables
  • Niveau 3: Tâches

Cette structure à 3 niveaux est visible dans la feuille de route du projet comme dans l’exemple ci-dessous.

Le plan de ce projet prévoit qu’il se déroulera en 4 phases: Initialisation, Maquettage etc.. (niveau 1). Pendant la phase de « Maquettage », il y a 4 livrables à produire: Choix du CMS, Maquette du site… (niveau 2). Pour réaliser le livrable « Maquette du site », il y a 8 tâches à faire : réalisation de la Page référence client… (niveau 3).

La structure du plan d’un projet dans TP est donc la suivante:
Projet → Phasage → Livrables → Tâches

Voici le même plan sous forme d’un Gantt. Note: les tâches ne sont pas visibles.

Concepts

Les Phases et les Étapes

Un phasage de projet est indispensable dès que la durée d’un projet dépasse quelques semaines. Le phasage garantit la maîtrise de l’avancement et des délais grâce à la mise en place de jalons.

Continuer la lecture de « Structure du plan d’un projet »

Le mythe des Valeurs Agiles

Souvent il est fait référence aux 4 valeurs agiles du Manifeste Agile. Mais cette expression « valeurs agiles » est bien mal venue. Elle freine la compréhension et l’adoption de l’approche agile en lui conférant un statut de dogme. Or l’Agilité est tout sauf un dogme.

« Valeurs Agiles » est un terme dangereux

Dire que l’Agilité repose sur des valeurs génère automatiquement des résistances lors de sa mise en oeuvre.

L’entreprise a ses valeurs. Les individus ont leurs valeurs. En positionnant l’Agilité sur le plan des valeurs, on déclare la guerre aux valeurs existantes, donc aux individus et à la culture des entreprises.

Or l’objectif de l’Agilité n’est pas de révolutionner la culture des entreprises, ni de changer les gens.

Le Manifeste Agile commence par « Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. ». Il est facile de mettre tout le monde d’accord sur cet objectif quelles que soient leurs valeurs…

Un problème de traduction

Dans la traduction officielle du manifeste, on utilise le verbe valoriser et non le mot valeur.

Ces expériences nous ont amenés à valoriser :

  • Les individus et leurs interactions plus que les processus et les outils
  • Des logiciels opérationnels plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuelle
  • L’adaptation au changement plus que le suivi d’un plan

source: http://agilemanifesto.org/iso/fr/manifesto.html

On pourrait dire aussi donner plus d’importance à ceci plutôt que cela. Ce n’est pas une question de valeurs. C’est un choix de priorités.

Préceptes Agiles

Plutôt que de parler de « valeurs agiles », il vaudrait mieux dire les 4 préceptes agiles, c.-à-d. des « recommandations pratiques enseignées par l’expérience » (cf. Larousse).

Pour tous les « anciens développeurs » qui ont connu les méthodes et les processus lourds des années 90, les plannings de Gantt qui ne servent à rien, les spécifications incohérentes ou incomplètes, les projets au forfait qui tournent mal etc., les 4 pseudo-valeurs sont des recommandations pratiques issues des enseignements des erreurs du passé.

Et même si ce ne sont que de simples préceptes, ils s’opposent à la croyance dominante dans le monde de l’Entreprise. Cette croyance héritée du Taylorisme est que les méthodes et les processus seraient la clé de l’efficacité et de la réussite.

En s’opposant à cette croyance si largement admise, les préceptes agiles représentent un changement de paradigme. Ils sont donc déjà une mini-révolution.

En parlant de préceptes agiles plutôt que de valeurs, on redonne à l’Agilité sa nature d’approche pragmatique de recherche d’efficacité qui ne menace pas les valeurs de l’entreprise.

 

Les différents types d’avancement

problemEn théorie, il est possible de définir plein de sortes d’avancement:

  • l’avancement physique
  • l’avancement en charge
  • l’avancement en coût
  • l’avancement en délai

En pratique, on saisit des avancements physiques (%) ou en charge (reste à faire) au niveau élémentaire du projet (tâches…).
L’outil de gestion de projet en déduit les avancements en coût et en délai du projet selon la technique de la valeur acquise.

Agilité: de l’auto-organisation vers l’auto-gestion

coaching PMA et gestion de projet 2.0La méthode Scrum et l’Agilité sont en train de bouleverser la culture des entreprises avec le principe de self-organizing team: une équipe auto-organisée qui n’a plus de manager et qui gère seule ses tâches. La justification d’une équipe auto-organisée est simple: responsabiliser et donner plus d’autonomie aux équipes.

Pour être tout à fait autonome, pourquoi une équipe projet ne gérerait-elle pas aussi son budget ? Une sorte d’auto-gestion…

Coûts, budget, ROI et rentabilité sont des termes absents des méthodes Agiles. De tous les leviers qui influencent les décisions dans une entreprise, l’aspect financier est sans doute le plus puissant. Il a le pouvoir de vie et de mort sur les projets. L’ignorer, c’est prendre un risque.

La proposition est d’intégrer la gestion des coûts et du budget dans le fonctionnement des équipes agiles. 

Concrètement, en quoi consisterait l’autogestion ?

Pour les équipes auto-organisées, cela consiste simplement à ajouter 2 ou 3 indicateurs financiers à leur « radiateur d’information » et à utiliser ces informations dans leur communication externe et pour la prise de certaines décisions.

Par exemple, avec l’autogestion, le backlog produit Scrum montre une liste de fonctionnalités avec un budget associé – Fonctionnalité X 11500€, Fonctionnalité Y 23200€… – comme pour les options d’une voiture neuve. C’est beaucoup plus concret pour le Product Owner et les utilisateurs que les estimations en Story Points qui sont artificiels et relatifs à cette équipe.

Autre illustration: en mode autogestion, l’équipe sait justifier financièrement auprès du management certains choix :

  • investissement pour gagner en productivité (équipement, logiciel…),
  • choix de faire un développement interne ou l’achat d’un composant sur étagère,
  • appel à un prestataire, à la sous-traitance pour des compétences spécifiques
  • recrutement

Avec un logiciel comme TimePerformance, la gestion financière d’un projet se fait toute seule.

Les bénéfices business

  1. Faire coïncider les enjeux réels de l’entreprise avec ceux des équipes projet, aligner les objectifs du management et des équipes
  2. Sensibiliser les équipes à l’importance de la maîtrise budgétaire et de la rentabilité (notamment pour sociétés de service)
  3. Accélérer les prises de décisions d’investissement pour gagner en productivité
  4. Intégrer les impacts financiers dans les choix techniques

Les obstacles: le management et le tabou de l’argent

Cela ne sera pas facile de faire admettre aux managers qu’ils doivent déléguer une partie de leurs prérogatives, la gestion des coûts et des budgets. Comme nous l’avons dit, l’aspect financier en entreprise est le vrai pouvoir.

Mais un manager intelligent verra dans cette délégation une opportunité pour se défaire de tâches administratives de gestion financière pour se tourner vers des missions à plus forte valeur ajoutée: le pilotage, la recherche d’opportunités, le développement de la vision, l’amélioration de la relation client, la conduite du changement, l’amélioration des processus…

Comment surmonter les obstacles

C’est très simple: faîtes-le. C’est à dire gérez les coûts et le budget même si on ne vous le demande pas. Cela ne demande aucun effort avec un logiciel comme TimePerformance. Et il n’est pas besoin d’avoir des chiffres exacts, car ce qui compte est l’ordre de grandeur.

Puis glissez subrepticement au hasard des conversations ou des réunions quelques indicateurs montrant que vous maîtrisez les aspects financiers du projet. Et peut-être que petit à petit on vous fera confiance et on vous confiera plus de responsabilité.

Sachez enfin que cette délégation de la gestion du budget et des coûts n’a rien d’exceptionnel. En fait, elle est pratiquée partout ailleurs que dans l’Informatique. Un chef de produit Marketing a un budget. Un chef de chantier dans le BTP gère un budget et des coûts. Dans le PMBoK, la gestion financière du projet est indissociable de la gestion de projet.

Il y a fort à parier que si les équipes agiles se mettent à parler budget et rentabilité de leurs projets dans les réunions, l’Agilité ne risquera plus de passer pour un « truc » de développeur auprès du management.

Bien utiliser le diagramme de Gantt

Chaplin Modern Times
A l’origine, le diagramme de Gantt est un outil d’organisation scientifique du travail inventé au début du 20ème siècle pour améliorer la productivité des chaînes de montage dans les usines.

Quelques décennies plus tard, le Gantt a été utilisé avec succès pour gérer de grands projets d’infrastructure avant de devenir une icône de la gestion de projet. C’est aujourd’hui un outil incontournable du chef de projet. Et pourtant, il convient de l’utiliser avec discernement…

Si tous les projets ont un besoin de planification et de respect des délais, ils ne s’apparentent pas tous à du travail à la chaîne, ni à des grands projets de construction.

Dans le développement informatique, combien de diagrammes de Gantt finissent sans suite ? Environ 99%…

Le piège est de faire un Gantt par habitude sans se poser la question de l’utilité de ce qui n’est au final qu’une technique parmi d’autres. A quoi sert  le Gantt ? Quels problèmes résout-il ? Y a-t-il des conditions à son utilisation ?

Diagramme de Gantt et Planification

Diagramme de Gantt

Le Gantt permet de visualiser simplement les délais, l’ensemble des tâches et leur séquencement.

Mais c’est une erreur de commencer la planification du projet dans un Gantt. 

En effet, dans le Gantt, il y a tout: la définition du périmètre du projet, la décomposition en tâches et leur ordonnancement, l’estimation des charges et le calcul des durées, les affectations, la disponibilité des ressources… C’est trop d’un coup. La planification d’un projet requiert un processus d’analyse qu’il est dangereux de court-circuité…

La construction du Gantt est la dernière étape du processus de planification. Il permet de calculer les délais et d’optimiser les ressources.

Le Gantt peut être utilisé à un niveau macroscopique pour visualiser le projet et les délais. Mais pour cela, il existe d’autres outils plus simples de visualisation comme la ligne de temps.

Dans la suite de l’article, on considère uniquement le cas de l’utilisation du Gantt pour une planification détaillée jusqu’aux tâches des équipes.

Un outil indispensable pour…

Le Gantt est nécessaire pour gérer le séquencement des tâches lorsque les interdépendances sont fortes. Sur un chantier de construction, ces interdépendances sont très nombreuses et incontournables. (Il faut couler les fondations avant de pouvoir monter les murs…) Un outil pour les gérer est indispensable.

Le Gantt est aussi nécessaire lorsque les intervenants sur le projet sont nombreux. Il permet de construire les calendriers d’intervention, de répartir les tâches et de coordonner les équipes.

Sur un chantier de construction, il y a plusieurs équipes (terrassiers, électriciens, plombiers..) qui n’interviennent qu’à des moments précis, se croisent et donc communiquent peu entre elles; d’où l’importance d’une planification précise.

Mais un outil complexe

Pour un projet de taille moyenne avec une équipe de 6 personnes sur 1 an, on atteint très vite le millier de tâches à ordonnancer et à gérer. Même avec un bon logiciel, c’est un travail fastidieux.

Planifier avec un Gantt nécessite un effort important de la part du chef de projet. Il peut même être nécessaire de déléguer la planification à un expert.

Mais les enjeux du chapitre précédent peuvent justifier ce travail important de planification.

Quand ne pas utiliser le Gantt…

Le Gantt est utile pour planifier dans le détail. Or construire un planning détaillé et calculer des délais n’ont de sens que si:

  • l’ensemble du contenu du projet est connu à l’avance
  • les estimations sont relativement fiables

Dans certains projets, le périmètre flou, les inconnues et les aléas rendent toute velléité de planifier dans le détail futile.

Notamment, dans le domaine du développement informatique, les projets avec ces caractéristiques sont le cas général. Ceci est à l’origine du mouvement Agile et de son énorme succès. Gérer un projet Agile avec un Gantt est donc une hérésie.

Dans certains domaines, les problèmes adressés par le Gantt, séquencement des tâches et gestion complexe d’équipes, sont mineurs.

Toujours dans le développement logiciel, il n’y a pas de problème de séquencement des tâches car il y a peu de contraintes fortes dans l’ordre pour faire les choses. Il n’y a pas non plus de gros problème de gestion des équipes (solution simple de gestion des ressources).

Dans ces contextes, l’utilisation du Gantt génère un travail important avec des replanifications perpétuelles et ne résout aucun des problèmes majeurs.  Ceci explique l’abandon rapide du Gantt observé si souvent.

Exemples concrets

Voici 2 projets « informatiques » avec des enjeux très différents, donc un besoin d’outil différent.

Type de Projet Déménagement de salle serveurs Développement d’un logiciel
Problématique Réduire la durée de coupure de service (optimisation des délais) Répondre aux besoins des utilisateurs, intégration aux SI, ergonomie, apporter de la valeur… Problématiques variées où les délais sont une variable parmi d’autres.
Contenu du projet Parfaitement connu (équipement actuel) Cahier des charges ou spécifications qui vont évoluer, solution à peine ébauchée…
Estimation de la charge de travail Facile, déjà fait Marge d’erreur importante du fait de la nouveauté et des inconnues, nécessite d’acquérir plus de connaissances sur le problème et d’expérience dans les technologies ou le fonctionnel
Ordonnancement des tâches Important, nombreuses règles à respecter dans le montage ou le démontage des équipements. Pas important. Grande flexibilité.
Coordination des équipes Au moins 2 équipes distinctes très spécialisées (déménageurs et administrateurs réseaux) qui doivent se coordonner avec des délais courts Une seule équipeImpossible de prédire en détail le travail à faire du fait des nombreuses inconnues du projet.
Conclusion Utilisation du Gantt recommandée Se focaliser sur le périmètre du projet, l’architecture, les technologies, l’ergonomie, les risques… plutôt que sur le séquencement des tâches dans un Gantt.

Conclusion

Le contexte idéal pour l’utilisation du Gantt se définit par:

  • Le contenu du projet est défini avec un grand niveau de détail
  • Les charges de travail peuvent être estimées avec une bonne précision
  • Les dépendances entre les tâches sont des contraintes fortes
  • La coordination et la gestion des équipes sont complexes

Le diagramme de Gantt est un puissant outil d’optimisation du travail plutôt réservé à des experts de la planification.

Mais diagramme de Gantt et gestion de projet ne sont pas synonymes. S’il n’y a pas les conditions pour utiliser le Gantt, ni de valeur à le faire, il vaut mieux s’en passer.

Équipe pluridisciplinaire SCRUM: avantages et inconvénients

La méthode Scrum a introduit le concept d’équipe pluridisciplinaire (cross-functional team).

Une équipe pluridisciplinaire Scrum est une équipe pluridisciplinaire dont les membres sont eux-mêmes pluridisciplinaires.

L’avantage évident est de faciliter la collaboration inter-discipline. Mais cela ne serait pas suffisant pour justifier la contrainte supplémentaire de devoir trouver les « bons profils ».

Quel est l’avantage d’une telle équipe par rapport à une équipe pluridisciplinaire classique où chaque membre à un rôle précis ?

L’avantage souvent méconnu est de pouvoir affecter les personnes à 100% sur un projet.

Continuer la lecture de « Équipe pluridisciplinaire SCRUM: avantages et inconvénients »