La perception de la performance selon le style de gestion

Voir la version AMP

La perception de la performance varie selon le style de gestion. Il faut le souligner, l’évaluation de la performance est vraiment une question de perception. L’évaluation de la performance d’une équipe est en fait étroitement liée au style de gestion et aux priorités que celui-ci dicte; en développement logiciel comme dans toute autre activité d’ailleurs.

Tout gestionnaire souhaiterait avoir une évaluation objective de son équipe et de son département TI dans le cadre d’un projet de développement logiciel. Le terme « objectif » est la clé de l’énigme ici. Existe-t-il une méthode objective d’évaluer la performance d’un individu, d’une équipe, d’une entreprise ?

En fait, on ne compte plus les systèmes, méthodes et nomenclatures qui ont été développées depuis le début de l’ère industrielle afin d’évaluer la performance.

Ainsi, beaucoup d’entreprises se demandent si leur équipe de développement logiciel ou celle de leur consultant TI est performante. Étonnamment, il existe une méthode objective et universelle développée dans le cadre du système CMMI (Capability Maturity Model Integration) permettant d’évaluer la performance d’une équipe de développement logiciel.

Cette méthode d’évaluation, FFP (Full Functional Point), permet d’évaluer, de façon constante et indépendante de la technologie, l’effort nécessaire pour générer un livrable défini.  Cette évaluation, associée à la vélocité d’une équipe de développement logiciel permettra de mesurera performance. Cependant, dans les faits, cette méthode est aussi assujettie au style de gestion.

Nous développerons en détail les notions de FFP et de vélocité dans nos prochains billets; nous expliquerons dans ce billet-ci les deux principaux styles de gestion de projets en développement logiciel et comment ils influencent l’évaluation de la performance d’une équipe de développement.

En résumé, tout est question de gestion et de métriques.

Êtes-vous plus agile ou traditionnel ?

Quel type de gestionnaire êtes-vous ?  Agile ou traditionnel ?

En d’autres mots, dans le projet de développement logiciel (d’application) que vous lancez; qu’est qui a le plus d’importance ?  La valeur ou le plan ?

Considérant la représentation ci-dessous des deux styles de gestion, il n’y a pas de bonne ou mauvaise réponse à cette question !

gestion par valeur vs gestion par plan

La réalité est que dans les grandes entreprises, certains projets de grande envergure impliquent plusieurs départements et plusieurs intervenants. Dans ce cas de figure, nul doute que le plan est non seulement utile mais il est nécessaire.

Typiquement, dans un projet de développement logiciel de grande envergure tel que « la refonte d’une application de back-office critique », tous les départements bénéficiaires et / ou contributeurs présentent leurs requêtes et leurs contraintes. Et ils s’attendent à voir leurs requêtes comblées et réalisées puisque toutes les fonctionnalités demandées, petites ou grandes, sont considérées nécessaires par chaque requérant. Ainsi, toutes les fonctions requises et nécessaires dans le cadre du projet seront toutes intégrées au plan final.

Un projet de développement logiciel (d’application) est lancé avec l’objectif qu’il aura un impact positif sur l’ensemble des parties impliquées. Il sollicitera la coordination de plusieurs départements et mobilisera de nombreuses ressources à différentes périodes.  Sa réalisation demandera un effort collectif de collaboration. Incidemment, le plan engendre un effet mobilisateur et agit comme un outil de coordination auprès des différents intervenants.

Pour toutes ces raisons, il est primordial de réaliser le projet de développement logiciel dans sa totalité et ce, malgré les imprévus et leur impact sur les coûts et l’échéancier. Dans le style de gestion par « Plan », les coûts et le temps peuvent être variables alors que la finalité du projet est immuable.

En gestion par « Plan », l’évaluation de la performance de l’équipe se fera sur la base de l’atteinte des objectifs de coûts, de temps et d’échéancier, la portée (le livrable) quant à elle étant fixe. Oui, les coûts et le temps sont variables mais combien près des estimations initiales l’équipe a-t-elle été en mesure de livrer ? Telle est la question. Bien sûr, on dira que l’estimation initiale était fausse mais cela sera le sujet d’un prochain billet…

Quant à l’évaluation du projet, elle se fera sur la base de l’impact de l’application (les bénéfices) sur les différents départements impliqués, une fois le projet complété.

Dans le cadre d’un projet de moindre envergure ou encore au sein d’une PME, il serait plus avisé, considérant les restrictions imposées en termes de ressources et de coûts, d’opter pour une gestion de style « Agile » et de considérer comme priorité la valeur apportée par le projet, les retombées en termes de bénéfices pour l’entreprise.

Typiquement, dans le cadre d’un projet de développement Agile, toutes les fonctionnalités de l’application à développer seront évaluées en termes de valeur (bénéfice) apportée à l’entreprise selon différentes hiérarchies; par exemple, fonctionnalité critique, importante, utile, souhaitée, optionnelle, etc.

Ainsi, le projet auquel on attribuera une enveloppe budgétaire fixe et un échéancier de production déterminée s’entamera avec le développement des fonctions jugées critiques et importantes en priorité. Le projet Agile est piloté par la Valeur et non le Plan.

En gestion par « Valeur », l’évaluation de la performance de l’équipe se fera sur la base du nombre de fonctionnalités livrées dans le temps et le budget alloués qui sont fixes.  Quant à l’évaluation du projet, elle se fera donc sur la base des bénéfices obtenus (augmentation de la productivité, accès à l’intelligence d’affaires, réduction des coûts, etc.) grâce aux fonctionnalités livrées. À titre de référence, soulignons que les deux types de gestion appellent des outils de gestion de projet différents.

Par exemple, dans l’environnement Microsoft, le gestionnaire de projet par Plan s’appuiera sur un outil tel que Microsoft Project qui met l’emphase sur les tâches restantes à accomplir alors que le gestionnaire de projet par Valeur utilisera un outil tel que TFS (Team Foundation Server) qui met l’emphase sur les heures restantes à accomplir.

Conclusion

La perception de la performance est vraiment tributaire du style de gestion du Directeur de Projet, du Directeur de Département ou encore de la Direction; le fait est que le style de gestion dicte des priorités différentes, ce qui orientera l’évaluation de la performance.

Au final, allez-vous évaluer les coûts et le temps requis pour livrer le projet dans sa totalité, l’impact du projet final une fois complété ou encore la qualité de la valeur (les bénéfices) apportée à l’entreprise dans le temps alloué ?

Peut-être l’idéal serait de toujours être agile localement (dans l’exécution) sans jamais perdre de vue le plan, quel que soit le type d’entreprise ou l’envergure du projet de développement logiciel !

 

Bon projet,

 

Denis Paul & Michel

Laisser un commentaire

Votre adresse de courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *