Analyse critique des méthodes de planification, de suivi, et d'évaluation des interventions dans le secteur agricole en RDC, cas du Programme de Relance de l'Agriculture dans la Province Orientale(PRAPO )

2.6. Comment suivre les indicateurs

Un suivi rigoureux du projet s'appuie sur un relevé régulier des mesures. Le choix des indicateurs est déterminé, si cela n'a été fait au niveau de l'organisation, à chaque début de projet. Leur pertinence doit être appréciée en fonction de la taille et de la maturité de l'équipe projet, de la demande du client, du comité de pilotage et du comité de projet, des enjeux du projet pour l'entreprise, des risques identifiés, de l'environnement contractuel du projet ou encore des outils utilisés.

Ainsi, le chef de projet et l'équipe déterminent les éléments qui doivent figurer dans leur tableau de bord, outil indispensable de pilotage du projet. La collecte des informations ne peut se faire que sur la base d'un consensus au sein de l'équipe. Il se peut que tout le monde ne joue pas le jeu, en particulier dans une équipe traditionnelle, qui n'a pas été sensibilisée à la notion de performance et de résultats collectifs. Qui ne s'est pas senti « fliqué », en devant fournir précisément le détail de ses heures consommées ?

La collecte est par conséquent souvent laborieuse, souvent manuelle ou peu automatisée, la consolidation se révélant, de surcroît, souvent lourde. Par exemple, chaque membre de l'équipe doit préciser, pour chaque activité dont il a la responsabilité, si elle a démarré, a avancé ou est terminée, et estime le « reste à faire » associé à ce pointage. Au final, le chef de projet doit avoir une visibilité sur les activités qui auraient dû démarrer, celles qui auraient dû se terminer, les activités supplémentaires qui se sont avérées nécessaires.

Un effort significatif doit, par conséquent, être consacré à la sensibilisation des équipes pour fournir cette information. Il est idéal de recueillir les informations de l'équipe quotidiennement. En effet, cela ne prend que quelques minutes pour faire le point sur le travail effectué et fournir une information fiable. Et ce, quelle que soit l'approche adoptée pour conduire le projet. Cela prendra davantage de temps le vendredi soir ou le lundi matin, pour se remémorer le travail réalisé et le temps passé sur la semaine qui s'est écoulée, avec des données qui ne pourront être qu'approximatives.

2.7. La stratégie de Tests

Un chef de projet doit, avec son équipe, se poser deux questions : « Comment s'assurer que le produit est conforme aux attentes du client ? » et « Appliquons-nous les bonnes pratiques pour livrer un produit de qualité ? ». À partir de là, il doit définir quelle stratégie de test, vérification et validation doit être mise en place.

Il faut définir la stratégie en amont du projet afin de déterminer l'organisation à mettre en place, les outils à installer ou les ressources à prévoir. Bien évidemment, elle « colle » aussi à l'approche retenue quant au déroulement du projet. Deux approches, radicalement différentes, sont envisageables : l'une, traditionnelle, consiste à mener tous les tests d'intégration et de validation en fin de cycle de vie par une équipe dédiée ; l'autre, agile, intègre les activités de tests au développement du produit.

1. Traditionnellement, la recherche de défauts s'effectue dans une phase dédiée après la phase de développement ; les défauts sont enregistrés dans un outil consacré à la gestion des anomalies, puis corrigés par la suite ; certains défauts peuvent être détectés dans le cycle de développement, mais ils sont généralement corrigés ultérieurement. Le raisonnement qui sous-tend cette approche est le suivant : pour tester, il faut avoir codé ; afin de ne pas perdre de temps en tests inutiles menés sur des versions intermédiaires de l'application, qu'il faudrait rejouer à nouveau, cette activité est planifiée en fin de projet. L'inconvénient en est que, si l'on a pris du retard dès le début du projet, la phase de tests sera sacrifiée, faute de temps et de budget, les tests bâclés, les failles rapidement « colmatées » et le produit final mis en production dans un état de qualité plus ou moins satisfaisant.

2. Il en va tout autrement avec la stratégie agile puisqu'on intègre le test dès le démarrage du projet, et non dans une phase dédiée. En effet, on considère que la détection et la correction tardives des défauts coûtent beaucoup plus cher que lorsqu'ils sont détectés à leur source (principes du pair-programming). La recherche de défauts est initialisée dès les premiers développements et est permanente tout au long du projet ; la correction des défauts est une activité parallèle aux développements, qui s'effectue dans chaque itération; cela répond à l'objectif de disposer d'une application toujours opérationnelle, même en cours de réalisation.^76(*)

* ⁷⁶V é r o n i q u e Me s s a g e r Rota ; op.cit.p155