Timeboxing

Le Timeboxing est une technique de gestion du temps utilisée dans les méthodes agiles pour la planification et la maîtrise des délais. Cet article en rappelle le principe et souligne les différences avec les approches traditionnelles.

Un concept très simple

Le Timeboxing est une division du temps en périodes successives d’une durée égale et relativement courte. Pour un projet, la durée recommandée des périodes est entre 2 et 6 semaines.

Cette technique est utilisée dans le domaine du développement logiciel pour imposer des livraisons fréquentes et régulières. L’objectif est d’accélérer le cycle de développement et le feedback des utilisateurs. Il s’agit aussi de lutter contre les problèmes bien connus de gestion du temps (cf. effet tunnel, lois de Parkinson et de Hofstadter, syndrome de l’étudiant etc.).

Dans le cas du développement logiciel, chaque période se conclut par une livraison. Elle est assimilable à une boîte dans laquelle il faut faire entrer le maximum de nouvelles fonctionnalités. La taille de la boîte est imposée et correspond à la charge de travail réalisable pendant la période. Le principal enjeu de la planification consiste à optimiser l’espace de chaque boîte en fonction de la priorité de chaque fonctionnalité et du temps nécessaire pour la développer.

Différence avec l’approche traditionnelle

En général, les techniques agiles prennent le contrepied de l’approche traditionnelle. Le Timeboxing n’échappe pas à la règle.

Continuer la lecture de « Timeboxing »

Gestion de Programme: quelles différences avec la gestion de Projet ou de Portefeuille ?

En quoi un Programme est-il différent d’un Portefeuille de Projets ou d’un gros Projet avec des sous-projets ?

L’objet de cet article est de clarifier le concept de Programme en s’appuyant sur les définitions du PMI ou de l’OGC.

Définitions

Projet Entreprise temporaire, décidée en but de produire un résultat, produit ou service unique.
Programme Groupe de projets en rapport les uns avec les autres, gérés de manière coordonnée afin d’obtenir des gains et un contrôle supérieurs à ce qu’on aurait en les gérant indépendamment les uns des autres.
Portefeuille Ensemble de projets et de programmes qui sont regroupés afin de faciliter une gestion efficace dans l’atteinte des objectifs stratégiques.

Définitions du PMI librement traduites

portefeuille-programme

Différences Programme vs Gros Projet avec des sous-projets

Dans un projet avec des sous-projets, les liens entre les sous-projets sont plus forts que les liens entre les projets d’un programme. Notamment, dans un gros projet, chaque sous-projet ne peut exister en dehors de l’ensemble. Dans un programme, on peut imaginer que des projets puissent continuer même si le programme est remis en cause.

Concrètement, dans un programme, chaque projet a son propre Business Case, c.-à-d. sa propre justification. Dans le gros projet, il n’y a qu’un seul Business Case et les sous-projets sont créés afin de faciliter la gestion d’un projet très complexe.

Le programme a aussi son propre Business Case qui explicite les gains générés au niveau du programme et justifie la création de cette couche de management supplémentaire.

Différences Programme vs Portefeuille

Un portefeuille rassemble des projets qui n’ont pas forcément de rapport entre eux. Dans un programme, c’est justement le rapport existant – ou possible – entre les projets qui est la raison d’être du programme.

Le terme rapport est volontairement assez vague pour couvrir des situations diverses.

L’exemple évident de rapport entre les projets est la notion d’interdépendance (ex: le projet A utilise un résultat du projet B). Dans ce cas, le programme permet de renforcer le contrôle par une meilleure coordination entre les projets.

Mais un programme permet aussi de créer de nouveaux liens entre les projets afin de générer des bénéfices supplémentaires. Un programme permet de créer de nouvelles opportunités.

Par exemple, en réunissant plusieurs projets au sein d’un programme, on peut générer des offres combinées à plus grande valeur ajoutée. Sans programme, l’offre combinée risque de ressembler à un patchwork sans homogénéité.

De plus, la bonne coordination de plusieurs projets peut générer une valeur supplémentaire, par exemple en créant un effet d’annonce grâce à la sortie simultanée de plusieurs produits.

Enfin, le programme est aussi une source d’économies (par ex: passage d’appels d’offres plus importants, développements de composants réutilisables sur plusieurs projets, mutualisation des coûts publicitaires ou de communication etc.).

Le portefeuille et le programme ont des vocations très différentes. Le portefeuille est un outil de pilotage managérial. De son côté, le programme apporte une valeur business supplémentaire en plus d’être un outil de pilotage.

Quelles sont les techniques spécifiques de la gestion de programme ?

Il n’y en a pas vraiment car la gestion d’un programme empreinte tour à tour les techniques de la gestion de portefeuille de projets (alignement stratégique, sélection des projets, optimisation des ressources etc.) et toutes celles de la gestion de projets (risques, coûts, délais, qualités, communication etc.).

Les processus spécifiques à la gestion de programme sont:

  • ceux qui concernent l’initialisation du programme et la mise en place de la structure de management
  • ceux liés à la gestion des gains stratégiques (Benefits Management)

La gestion des gains stratégiques est sans doute l’élément le plus spécifique car c’est la raison d’être du programme.

Le programme se situe à cheval entre le portefeuille de projets et le gros projet. C’est pourquoi la frontière est souvent floue. Nous espérons que cet article vous aura apporté un nouvel éclairage. N’hésitez pas à nous laisser vos commentaires.

PS: Cet article a été écrit suite à la participation à la formation «Best Pratices in Program Management» de PMGS.

Les outils de gestion de projet mal aimés

À en croire M. Yves Cavarec, secrétaire chapître du PMI Ile-de-France, les progiciels de gestion de projet sont perçus par les chefs de projets comme lourds, inadaptés ou contraignants.

En effet, dans une interview sur Microsoft TechNet, M. Cavarec fait un sombre constat en énonçant les 4 situations suivantes rencontrées dans les entreprises:

  1. le chef de projet «qui a l’habitude de gérer ses projets en toute transparence mais sans forcément utiliser des outils», pour lesquels l’utilisation d’un outil serait une contrainte.
  2. le chef de projet «qui va se dépêcher de mettre à jour sa planification dans l’outil de planification quelques jours [avant] ou la veille d’une revue de projet», ce qui correspond à un détournement de la finalité de l’outil.
  3. «l’utilisation parallèle des outils de gestion de projet et puis d’autres outils [tableur, traitement de texte etc.]. Pourquoi ? parce que l’outil n’est manifestement pas adapté à l’usage.»
  4. «le chef de projet est assommé par un ensemble de demandes. On lui demande de mettre à jour une planification dans un outil. on lui demande de mettre à jour un fichier Excel [etc…]. Il passe beaucoup de temps à faire de l’administratif alors [qu’il a bien d’autres fonctions]. L’aspect administratif de la gestion de projet prend le pas sur le reste.»

Chez Time Performance, nous partageons ce constat et c’est ce qui nous a poussé à envisager la gestion de projet autrement. De là est venue l’idée d’une Gestion de Projet 2.0 et d’un outil différent qui réunit l’essentiel de la gestion de projet dans un seul logiciel, simple et dont le reporting est totalement automatisé.

Sans être la panacée, TimePerformance garantit un excellent rapport entre la valeur ajoutée pour le chef de projet et le temps qu’il passe dans l’outil.

Cliquez ici pour voir l’interview sur le site Microsoft TechNet

Version 2.7

  • TimePerformance est maintenant disponible en 3 versions: Free Edition, Essential Edition et Performance Edition.La Performance Edition correspond à la version de TimePerformance existante. Les 2 autres versions sont des versions allégées de la Performance Edition.
  • La méthode est dorénavant optionnelle pour un projet.Le choix d’une méthode d’un projet est facultatif et se fait postérieurement à la création du projet dans la rubrique Méthode de l’onglet Paramètres.
  • Evolution dans le mode de calcul des coûts réels forfaitairesPrécédemment, lorsqu’un coût fixe (par exemple de 5000€) était rattaché à un objectif, il n’était pris en compte dans le coût réel qu’à la clôture de l’objectif. Dans cette version, le coût réel prend en compte le coût fixe proportionnellement à l’avancement saisi de l’objectif (par exemple: pour un avancement de 50% et un coût fixe de 5000€, cela fera un coût réel de 2500€).
  • Améliorations diverses:Edition des tâches dans la feuille de temps, Visualisation des utilisateurs avec une licence dans le module d’Administration, Ajout de la date limite dans l’export des tâches…

Version 2.6

Cette version introduit le suivi de portefeuille de projets:

  • Suivi de portefeuille de projetsCréez un portefeuille puis ajoutez-y des projets pour obtenir une vue consolidée multi-projet avec un Plan de charge, un Gantt, un Rapport d’avancement et un diagramme des Jalons.

Plan de charge consolidé au niveau du portefeuille de projets

plan de charge consolidé au niveau du portefeuille de projetsRapport d’avancement consolidé au niveau du portefeuille de projets

rapport d'avancement consolidé au niveau du portefeuille de projets

Mise à jour 2.5.2

  • Création du rôle Observateur sur un projet

    En ajoutant un utilisateur à la liste des observateurs du projet, le chef de projet l’autorise à consulter le tableau de bord du projet (à l’exception de la partie management de l’équipe).
    Des observateurs potentiels d’un projet sont le client du projet ou un manager de service.
    La gestion des observateurs est située dans l’onglet Équipe de l’interface de management de projet.

  • Plan de Charge disponible pour une phase ou pour une étape
  • Possibilité d’envoyer un e-mail à un membre de l’équipe sur une de ses tâches à partir du tableau des tâches (cliquer sur le nom de l’utilisateur dans le détail de la tâche) ou de la consultation de la liste de tâche (bouton droit sur la tâche pour faire apparaître le menu).
  • Export des objectifs plus complet (planification et estimations finales)
  • Remplacement du menu contextuel par un lien direct pour éditer un utilisateur, un projet ou une méthode dans l’interface d’administration.
  • Changement de terminologie dans l’interface: le terme Étape remplace le terme Itération.

5 autres idées fausses à propos des Méthodes Agiles

De plus en plus d’équipes revendiquent une démarche Agile pour échapper aux lourdeurs des méthodes traditionnelles. Mais connaissent-elles réellement les implications de l’Agilité ?

Suite au précédent article, 5 idées fausses à propos des Méthodes Agiles, nous vous proposons un 2ème opus avec 5 nouveaux préjugés sur l’Agilité.

Idée fausse n°6: les Méthodes Agiles, c’est la liberté de faire à sa façon

Equipe en « autogestion », remise en cause du rôle de chef de projet, redistribution des responsabilités, suppression des aspects contractuels, pas de planification détaillée, absence ou presque de documents, communication principalement verbale…

Tous ces éléments, qui séduisent les équipes, ont un petit goût de liberté et d’émancipation, qui risque d’être mal perçu par le management traditionnel.

Cependant il serait faux de considérer que l’Agilité est synonyme d’absence de règles, de contraintes et de structures.

Continuer la lecture de « 5 autres idées fausses à propos des Méthodes Agiles »