Chef de projet ou Gestionnaire de projet ?

Quelle est la traduction de project manager en français: chef de projet ou gestionnaire de projet? Cela a des connotations très différentes.

L’image du chef est celle du leader, du meneur d’hommes, qui fait avancer les choses. L’image du gestionnaire rappelle celle d’un comptable ou d’un bureaucrate procédurier empêtré dans les fiches et les rapports.

Quand il faut choisir une traduction pour project manager, il n’est pas étonnant qu’au pays de Cyrano de Bergerac on préfère le panache du chef à la grisaille du gestionnaire. Mais il faut savoir que nos amis québécois traduisent généralement project manager par gestionnaire de projet.

Alors que faut-il en déduire sur le rôle de project manager: chef ou gestionnaire ?

Dans une entreprise, il y a un PDG et un DAF (directeur financier), donc un chef et un gestionnaire. Mais ce modèle est difficilement applicable à un projet standard qui verrait ses coûts fortement augmentés.

D’ailleurs dans les référentiels de gestion de projet, il n’y a que le rôle de chef de projet. On remarquera avec ironie qu’on parle de gestion de projet faite par un chef de projet. L’ambiguïté est réelle.

L’idéal serait d’avoir un chef-gestionnaire pour chaque projet. Mais cet idéal se heurte à une réalité. En plus du manque de temps pour tout faire ou de la difficulté à acquérir des compétences très différentes, c’est avant tout un problème de profil psychologique. La mentalité d’un chef n’est pas celle d’un gestionnaire et inversement. Trouver une personne avec les 2 profils relève donc de la gageure.

Dans les faits, les chefs de projet font généralement le choix d’être des chefs et beaucoup moins des gestionnaires. Cela permet d’assurer que le projet avance dans la bonne direction. Mais cela se fait au détriment du suivi de projet engendrant l’identification tardive des écarts et par voie de conséquence d’importants dépassements, voire l’arrêt total du projet.

Le PMBoK identifie pour ce rôle double de chef-gestionnaire 47 processus différents. 47 processus pour un seul rôle! Absurde, non?

Quelles solutions à ce problème de rôle double de chef-gestionnaire ?

Une première piste serait d’appliquer les principes du Lean à la gestion de projet, supprimer les processus inutiles ou étaler la charge avec du juste-à-temps par exemple.

Une deuxième piste serait de définir plusieurs rôles ou de déléguer certaines responsabilités à l’équipe, à l’instar d’approches agiles comme SCRUM.

Une troisième piste serait d’outiller et d’automatiser les processus du gestionnaire, et éviter les «moulinettes» maison à base de feuilles Excel. Notez au passage qu’il est bien plus facile d’automatiser la gestion que d’automatiser le travail d’un chef.

Voilà les idées qui ont inspiré le logiciel de gestion de projet TimePerformance pour permettre aux chefs de projet d’être de bons gestionnaires sans effort.

Et vous, avez-vous d’autres idées à proposer ?

Quel rôle pour les chefs de projet dans Scrum ?

La méthode Scrum définit 3 rôles. Celui de chef de projet n’en fait pas partie. Beaucoup en déduisent qu’il n’y a plus de chef de projet avec Scrum. Certains s’en inquiètent en se demandant ce que vont devenir les chefs de projet lors du passage à Scrum.

Dans Scrum, le «chef de projet» est le Product Owner

Le chef de projet est la personne à qui on donne une mission, un mandat, pour mener à bien un projet. On lui délègue des pouvoirs, des moyens et la responsabilité du succès du projet.

Mener à bien un projet signifie de livrer de la valeur tout en respectant un budget et des délais.

C’est aussi la mission du product owner.

Le product owner est le responsable du backlog produit. Il priorise les éléments et leur associe une valeur business. Il gère aussi le release backlog qui détermine les délais et le budget du projet. Il a aussi le pouvoir d’arrêter le projet lorsqu’il juge que le ROI est insuffisant. 

Ce qui change avec Scrum

Certaines fonctions dévolues traditionnellement au chef de projet sont déléguées à d’autres personnes.

Il n’y a plus de management d’équipe

Dans Scrum, l’équipe s’auto-organise et s’autogère à l’aide d’un facilitateur, le Scrum Master. Il n’y a donc plus de management hiérarchique.

La gestion de la qualité

Le Scrum Master est responsable du respect du processus de développement et des normes de qualités.

C’est l’équipe toute entière qui est responsable de la qualité du produit.

Le découpage technique du projet et les estimations

L’expertise technique est du ressort de l’équipe. C’est elle qui identifie les tâches et estime la charge de travail.

Les bénéfices de l’approche Scrum

Le fait de déléguer une partie de ses fonctions à d’autres personnes peut être vu comme une très bonne chose.

Le chef de projet est traditionnellement surchargé du fait de ses multiples tâches: gestion de l’équipe, contact client, planification, gestion des coûts, gestion des anomalies…

De plus, certaines responsabilités peuvent amener à des conflits d’intérêt. Par exemple, la recherche de réduction des délais et des coûts peut inciter à sacrifier la qualité du produit.

Enfin, le rôle traditionnel de chef de projet peut exiger des compétences très différentes (communication, expertise technique, négociateur, écoute client, gestionnaire, leadership). C’est pourquoi on trouve souvent des descriptions de poste de chef de projet qui ressemblent à celle d’un mouton à 5 pattes.

Conclusion

La mission essentielle du chef de projet vis-à-vis de l’entreprise est confiée au Product Owner. Il n’est pas le chef d’une équipe mais le titulaire d’un projet ou d’un produit qu’il incarne.

Les chefs de projet qui deviennent product owners verront  leur (sur)charge de travail diminuée et pourront se concentrer sur la création de valeur métier.

Par contre, le management d’équipe disparaît. Le concept de « chef de projet technique » ou de team leader n’a pas d’équivalent dans Scrum. C’est un réel problème pour les personnes avec ce type de profil. Une reconversion en Scrum Master n’est pas forcément possible dans la mesure où cela requiert un type de personnalité très différente de servant leadership et non de chef. Les autres choix sont d’aller vers l’expertise technique, en espérant que celle-ci soit reconnue à sa juste valeur, ou vers le fonctionnel pour devenir product owner.

La méthode de la chaîne critique

chaine critiqueSelon ses adeptes, la méthode de la Chaîne Critique permet de réduire les délais par 2, de diminuer les coûts et d’améliorer grandement le taux de réussite des projets.

Ces promesses ne sont pas vraiment nouvelles mais il est toujours intéressant d’étudier les différentes approches. Comment cette méthode s’insère-t-elle dans le macrocosme des méthodes de gestion de projet ?

Une alternative à la technique du Chemin Critique

La Chaîne Critique est une technique de planification et de suivi des délais, qui remplace avantageusement la technique du Chemin Critique.

Le principe est le même: prendre en compte les contraintes pour déterminer la durée minimale du projet et les tâches critiques pouvant impacter cette durée.

Les 2 principaux ajouts de la Chaîne Critique sont:

  1. la prise en compte des limitations en ressources ou en compétences (en plus des dépendances entre les tâches). On parle alors de chaîne critique pour la distinguer du chemin critique.
  2. la mise en place de tampons (buffers), c.-à-d. des réserves de temps, dans la chaîne critique et les chaînes secondaires.

Si l’intérêt du premier point va de soi, celui des tampons méritent quelques explications.

Les tampons remplacent les marges de délai qui sont prises traditionnellement au niveau de chaque tâche lors des estimations. Cette approche a les avantages suivants:

  • Eviter de consommer inutilement les marges de délai au niveau des tâches. En effet, la loi de Parkinson observe que le travail s’étale de façon à occuper tout le temps alloué pour la tâche. Ainsi les réserves de délai au niveau des tâches sont systématiquement consommées.
  • Visualiser et de maîtriser les marges de délai. La séparation de l’estimation de la durée des tâches  et des marges de sécurité permet de mieux visualiser ces dernières. Cela permet de palier la multiplication de marges prises par les différents acteurs du projet.
  • Un nouvel indicateur pour surveiller les délais. L’indice d’utilisation du tampon permet de visualiser le niveau des réserves de délai. Une alerte est levée lorsque le niveau global d’utilisation dépasse l’avancement réel (= sur-utilisation de la réserve).

Les tampons sont définis au niveau des chemins, critique et secondaires, définis par le réseau de dépendances entre les tâches.

Le tampon principal, appelé tampon projet, est celui placé sur la chaîne critique. C’est celui à surveiller en priorité.

Ce tampon projet est une réserve non négligeable puisque l’auteur de la méthode, Eliyahu M. Goldratt, recommande une réserve de 50% de la durée de la chaîne critique. Cela revient donc à ajouter 50% de délai par rapport à la durée minimale.

Enfin, la méthode recommande d’utiliser un système de compte à rebours pour avertir les personnes du démarrage prochain de leurs tâches pour qu’elles démarrent à temps.

Notre avis

Nous préférons rester prudents vis à vis des résultats fournis par les études faites sur les bénéfices d’une méthode par rapport à une autre. Comme pour les méthodes Agiles, ces études sont souvent commanditées par ceux qui y ont un intérêt; et l’interprétation des résultats nécessiterait de se pencher sérieusement sur la validité de l’étude.

Concernant la promesse de réduction des délais, les promoteurs de la méthode partent du postulat que les délais sont systématiquement multipliés par 2 du fait du cumule des marges. Ce postulat nous semble hasardeux et ne correspond pas à notre expérience dans l’informatique. Au contraire, les délais initiaux sont souvent optimistes du fait des nombreuses inconnues du projet ou des pressions exercées pour gagner l’affaire.

Quant à la réduction des coûts, elle ne peut venir que d’un meilleur déroulement du projet puisque la méthode ne s’intéresse qu’aux délais.

Ceci étant dit, nous considérons que la méthode de la chaîne critique propose des améliorations importantes par rapport à la technique du chemin critique et nous semble nettement supérieure. D’une part, la prise en compte des contraintes sur les ressources est essentielle; d’autre part l’idée des tampons (buffers) est excellente.

Notre avis est que la méthode de la chaîne critique devrait supplanter celle du chemin critique.

Avec la chaîne critique, les délais annoncés devraient être mieux respectés du fait d’une meilleure gestion des marges. Notons au passage que le délai prévu pour le projet calculé selon cette méthode est d’au moins une fois et demie supérieur à la durée calculée selon le chemin critique du fait du tampon projet et de la prise en compte de nouvelles contraintes. C’est donc aussi plus facile à respecter 😉 .

Du fait de la similarité des promesses, nous avions cru initialement à une nouvelle approche dans le prolongement de l’Agilité ou du Lean. En fait, c’est le contraire. Cette méthode s’inscrit totalement dans la démarche traditionnelle en allant encore plus loin dans la planification.

Le champ d’application de la chaîne critique est donc bien différent de ceux des méthodes agiles et du Lean.

Références:

https://fr.wikipedia.org/wiki/Méthode_de_la_chaîne_critique

http://www.chaine-critique.com/fr/La-methode-en-action-4.html

Version 5.5.5

  • Nouveau: gestion au niveau de chaque utilisateur du droit de création/suppression de projetCe droit se gère au niveau de la fiche d’un utilisateur.
  • Améliorations diversesSaisie de montant négatif pour les dépenses (ex: remboursements…), Affichage du nom de l’activité au survol dans le planning de service, option pour masquer les projets/méthodes archivés dans l’interface d’administration

Version 5.5.4

  • Nouveau: Possibilité d’anticiper la saisie des temps dans la feuille de temps

    Les contrôles qui empêchaient de saisir du temps dans le futur ont été désactivés suite à la demande d’utilisateurs.

  • Améliorations d’ergonomie, modifications du design de l’accueil et du tableau des tâches

Tutoriel – Créer un projet en 5 étapes

Voici en 5 étapes la création d’un projet dans TimePerformance.

1. Créez le projet

Dans l’accueil de TimePerformance, cliquez sur Créer un projet et remplissez le formulaire. Le projet apparaît dans l’accueil. Cliquez sur le projet pour aller dans l’interface de gestion de projet.

2. Créez le plan sous forme d’une feuille de route

La deuxième chose à faire consiste à définir la feuille de route du projet, i.e. sa roadmap. Pour cela, allez dans l’onglet Plan rubrique Feuille de route.

La création de la feuille de route consiste à découper le projet en étapes successives auxquelles sont associés des livrables. Consultez l’aide de la page pour plus de détails.

Exemple de feuille de route:

Feuille de route

Pour visualiser les délais et modifier les dates, il est conseillé d’utiliser le  diagramme de Gantt (onglet Plan).

gantt

3. Equipe et paramétrage des coûts

Pour ajouter des membres à l’équipe projet, allez dans l’onglet Préparation rubrique Equipe. Ajoutez des personnes en créant de nouveaux utilisateurs si nécessaire. Puis paramétrez le coût associé à chaque personne.

team

Parmi les options présentes dans la page Unités de l’onglet Préparation, les 2 paramètres essentiels sont le nombre d’heures de travail effectif dans une journée et le taux journalier ou horaire moyen (TJM). Renseignez le taux pour le Profil par défaut afin que les charges estimées en heures ou en jours-hommes soient converties en coût.

paramétrage unités

4. Visualisez le résultat

Allez dans le Cockpit. Le diagramme de la Valeur Acquise montre la trajectoire prévue et permettra de suivre l’avancement. Le burndown chart montre le reste à faire.

Tableau de bord du projet

Le plan de charge  dans l’onglet Plan permet de visualiser le nombre de personnes nécessaires pour le projet.

plan de charge du projet

5. Créez des tâches pour commencer le travail

Dès que l’équipe a pris connaissance de la feuille de route, les personnes peuvent créer des tâches en les rattachant aux livrables définis à l’étape 2 de ce tutoriel.

Les tâches sont créées au choix dans:

  • le tableau des tâches du projet, qui contient les tâches de toute l’équipe,
  • les listes de tâches individuelles
  • les feuilles de temps individuelles.

tableau des tâches

Bonus: la Check-list intégrée

Pour guider le chef de projet dans la création du projet, une check-list intégrée est disponible sur la page d’accueil du projet. La check-list reprend les points essentiels de la création d’un projet et de son suivi.

La check-list est mise automatiquement à jour en fonction des informations saisies. Chaque item de la liste est un lien vers la page pour réaliser l’action correspondante.

checklist

Gestion de projet 2.0

Voilà plusieurs années que la vague 2.0 a atteint le monde de l’entreprise, d’abord par ses technologies (Web 2.0, Virtualisation, SaaS, Cloud Computing…), puis par ses valeurs (Collaboratif, Agilité, Lean…).

La gestion de projet traditionnelle doit elle-aussi s’adapter et passer à l’ère du 2.0, qui se définit par : la simplicité, la légèreté et une plus large collaboration sur fond de technologies.

Il s’agit d’une transformation majeure de la gestion de projet. L’approche traditionnelle de la gestion de projet, fondée sur les processus, le contrôle et la planification rigoureuse, convient de moins en moins à notre époque moderne, à un environnement changeant, aux besoins en retours sur investissement rapides et à la mentalité des équipes.

Cette transformation a déjà été initiée depuis plus de 10 ans par la vague de l’Agilité et du Lean. Aujourd’hui, ces approches sont reconnues par les organisations professionnelles. Ainsi le P.M.I., auteur du fameux référentiel de gestion traditionnelle de projet PMBoK, propose désormais une certification Agile. La transformation de la gestion de projet est donc solidement engagée.

Pour les entreprises, cette transformation est le moyen de gagner en compétitivité en améliorant la performance des équipes grâce à une collaboration plus efficace, fondée sur la confiance et la responsabilisation. Voici une analogie avec la transformation du Web vers le 2.0 qui a eu lieu sur Internet dans les années 2000.

Continuer la lecture de « Gestion de projet 2.0 »

Initiation à la Valeur Acquise (Earned Value)

En gestion de projet, la technique standard de suivi de projet s’appelle la Valeur Acquise. Sa principale mission est la mesure des écarts par rapport au plan, et donc la maîtrise du projet. Cette technique fait partie intégrante des référentiels méthodologiques (PMBoK, IPMA…). En anglais, son nom est Earned Value Management (EVM).

Objectif de la Valeur Acquise: Maîtriser les écarts de coût et de délai

Une bonne gestion de projet passe nécessairement par la maîtrise des écarts.

Voyons ensemble comment le diagramme de la Valeur Acquise nous permet de visualiser facilement les écarts.

Valeur Acquise - courbe en S

Capture d’écran de TimePerformance, le logiciel de gestion de projets par la valeur acquise.

Sur ce diagramme, on y trouve 3 courbes.

  • La courbe bleue représente le plan.
  • La courbe verte représente l’avancement réel.
  • La courbe rouge représente le coût réel (hors la partie en pointillés).

Les positions relatives des courbes montrent les écarts de coût et de délai du projet.

La courbe verte est au-dessus de la courbe bleue. Donc l’avancement est supérieur au plan. Le projet est donc en avance (écart de délai).

La courbe rouge est au-dessus de la courbe verte. Donc le coût réel est supérieur à l’avancement réel. Le projet est donc en surcoût (écart de coût).

Remarque: Le diagramme de la valeur acquise est aussi connu sous le nom de Courbe en S pour sa forme caractéristique.

Qu’est-ce que la Valeur Acquise ?

La valeur acquise, c’est la courbe verte, c.-à-d. l’avancement réel du projet. On appelle «valeur acquise» l’avancement réel quand il est valorisé en euros. L’intérêt de valoriser l’avancement en euros est de pouvoir comparer sa valeur par rapport au budget (le plan) et au coût réel.

Le principe de la Valeur Acquise, c’est simplement de donner une valeur en euros à l’avancement réel pour le comparer à un budget et à un coût réel.

A partir des 3 valeurs, valeur acquise, budget à date et le coût réel, la technique de la valeur acquise fournit des formules simples pour calculer des écarts et des indices de performances.

Le + de la Valeur Acquise: la prédiction à terme

Le fait d’avoir calculé les écarts sur le projet permet de faire des prédictions par extrapolation. Dans la technique de la valeur acquise, on s’intéresse à prédire le point d’atterrissage du projet, ce qu’on appelle l’estimé à terme.

Dans le diagramme ci-dessus, la prévision est représentée par la partie en pointillés de la courbe rouge.

La technique de la valeur acquise prédit dans l’exemple que le projet se terminera 3 semaines en avance avec un surcoût de 10%.

Comment calculer la Valeur Acquise ? Comment valoriser un avancement ?

Le principe du calcul est simple: chaque élément du projet a un poids qui correspond à son montant dans le budget. Ainsi, à chaque fois qu’une tâche est terminée ou qu’un livrable est achevé, le montant du budget prévu pour cette tâche ou ce livrable s’ajoute à la valeur acquise du projet.

Malgré sa simplicité – ou plutôt grâce à sa simplicité – cette technique est très efficace et facile à utiliser. Elle fournit des informations essentielles au pilotage.

Le seul réel obstacle à la démocratisation de la valeur acquise est la lourdeur des calculs. Ils sont fastidieux du fait de la volumétrie des données et de la nécessité d’historiser les valeurs. De plus, la prise en compte des changements en cours de projet constitue un réel challenge pour la mise à jour des courbes. Sans outillage suffisant, la mise en œuvre de la valeur acquise devient rapidement un casse-tête pour le chef de projet.

Sur ce dernier point, nous vous invitons à essayer gratuitement notre logiciel de gestion de projets, qui est la solution la plus simple et la plus facile pour bénéficier de la technique de la valeur acquise.

Quelles solutions au scope creep

Le scope creep – ou dérive du contenu – est un fléau bien connu des projets informatiques, qui engendre surcoûts et retards importants. Chaque méthode de gestion de projet apporte à ce problème une réponse spécifique.

L’approche traditionnelle cherche à lutter contre la dérive du contenu en ajoutant plus de contrôle, plus de préparation, plus d’implication…

De son côté, l’approche agile considère les modifications de spécification comme un phénomène naturel de maturation du projet.

Dans le tableau ci-dessous, nous avons fait une comparaison entre les solutions de l’approche traditionnelle et celles de l’approche agile en nous basant sur l’article «comment empêcher que la dérive de contenu n’emporte au loin votre projet» qui identifie 5 causes à la dérive du contenu:

  1. Pauvre analyse des besoins
  2. Implication trop tardives des utilisateurs
  3. Sous-estimation de la complexité du projet
  4. Manque de contrôle du changement
  5. Sur-qualité
Causes Approche traditionnelle Approche agile
Pauvre analyse des besoins Passer plus de temps en réflexion et en préparation, meilleures spécifications des besoins, documentation exhaustive… Travailler par petits bouts (incréments), c’est plus simple. De plus, une meilleure compréhension de la part des développeurs et des utilisateurs des besoins réels est facilité par des livraisons et des démos fréquentes.
Implication trop tardives des utilisateurs Plus d’implication, plus de réunions, plus de documentations, développements de scénarios de test, plus de processus de validation… Dans SCRUM, il y a forcément une démo avec les utilisateurs en fin de Sprint (ie tous les 15 jours).
Sous-estimation de la complexité du projet Ajouter des provisions pour aléas, ajouter de la marge dans le planning, prévoir des ressources supplémentaires… Travailler par petits incréments réduit la complexité et favorise la recherche de solutions simples.
Manque de contrôle du changement Plus de processus (formulaire, validation, registre, analyse d’impact) Pendant une itération (Sprint) aucun changement n’est accepté, pour le reste on en discute pendant le planning de la prochaine itération avec le représentant des utilisateurs et du sponsor.
Sur-qualité Plus de management et de communication sur les enjeux L’équipe s’engage à livrer un produit fini tous les 15 jours (pas le temps de traîner). Chaque membre de l’équipe annonce ce qu’il va faire dans la journée (SCRUM) ce qui est aussi une forme d’engagement.

Il n’y a pas d’approche meilleure que l’autre, mais simplement des objectifs différents liés à des contraintes – souvent financières – différentes. L’approche traditionnelle est plus adaptée dans le cadre d’un engagement de résultat (mode forfait) tandis que l’approche Agile sera plus adaptée pour optimiser la valeur business avec un engagement limité de moyens. (Ce dernier point est souvent débattu.)

Mais la vraie question derrière le problème de la dérive du contenu est: Comment définit-on la réussite d’un projet ?

Est-ce le fait d’avoir respecté un engagement de délais et de coûts défini au début du projet ou d’avoir un client et des utilisateurs satisfaits à la fin du projet ? Ce n’est pas la même chose…

Suivi des temps = flicage ?

La mise en place du suivi des temps déclenche souvent une réaction épidermique de la part des équipes, qui suspectent leur management de vouloir les surveiller, voire de vouloir les espionner. Le suivi des temps est-il une forme de « flicage »?

Le suivi des temps ne sert pas à «fliquer». En effet, il repose entièrement sur une action volontaire de la personne concernée.

A l’inverse, pour faire du «flicage», il faudrait un vrai système de surveillance avec des logiciels qui espionnent à l’insu des personnes.

Le suivi des temps est généralement réalisé sur la base d’une déclaration de bonne foi sans aucune forme de vérification. On fait confiance aux gens pour déclarer leurs temps, et ceux qui veulent «tricher» peuvent donc le faire en toute impunité.

A quoi sert le suivi des temps ?

En premier lieu, le suivi des temps sert à comptabiliser.

Comptabiliser sert à donner de la visibilité au management et est la base d’une bonne gestion. Ce n’est peut-être pas « fun », mais c’est nécessaire, surtout dans un environnement professionnel.

On peut réussir des projets sans gestion, mais c’est risqué. On peut aussi faire de la comptabilisation implicite, comme dans SCRUM, mais cela implique certaines contraintes pas toujours faciles à respecter (taille de l’équipe constante, durée des sprints identiques etc.).

En général, le suivi des temps reste le brique de base de la comptabilité du projet, indispensable à sa gestion et à son pilotage.

Le suivi des temps peut aussi être utilisé par les premiers concernés, ceux qui suivent leur temps.

A l’instar du sportif qui recherche la performance et surveille son chrono, suivre son temps permet de mieux se connaître dans sa façon de travailler et de s’améliorer. Un exemple évident de potentiel d’amélioration concerne l’estimation des futures tâches.

Cette utilité du suivi des temps est vraie au niveau de l’individu mais aussi au niveau de toute l’équipe.

Dans un article précédent, nous avons fait un petit retour d’expérience sur ce que le suivi des temps peut apporter à une équipe de développement logiciel en mode agile.

Les 2 mauvaises raisons de ne pas suivre son temps

Raison n°1: Invoquer le manque de temps.

Ceci est un prétexte car le suivi des temps ne prend que quelques minutes par semaine. La vraie raison est qu’on n’en a pas envie car ce n’est pas une activité plaisante, bien que nécessaire. Dans ce cas, le manager doit rappeler l’intérêt et la nécessité, à mettre en comparaison du faible effort à produire.

Raison n°2: Crier au flicage.

Ceci traduit un climat de méfiance et de peur. Dans ce cas, il faut rétablir rapidement un climat de confiance.

Conclusion

Le suivi des temps n’est donc pas du flicage mais simplement une bonne pratique de gestion, voire d’autogestion. C’est une affaire de discipline personnelle et de transparence vis à vis du management. Cela peut aussi devenir un moyen d’apprentissage et d’amélioration, individuel et en équipe.