Comment faire pour éviter qu’un projet informatique échoue ?

La gestion de projet informatique est bien loin d’être une science exacte. D’après une étude de 2018 du Standish Group Chaos Report, 31% des projets informatiques sont stoppés avant leur finalisation et ne sont jamais mis en ligne. Et 53% des projets informatiques explosent leurs prévisions budgétaires de 189%. Découvrez 4 pistes de réflexion peu connues mais très efficaces pour comprendre comment éviter de faire échouer un projet informatique.

Règle n°1 : ajouter des développeurs sur un projet en retard aura pour effet d’augmenter son retard

La loi de Brooks (1975) nous explique que rajouter des nouveaux développeurs à une équipe de développeurs d’un projet en retard aura pour effet d’accroître le retard sur le projet.

Pour quelles raisons intégrer une nouvelle personne sur un projet va accroître le retard du projet ?

• La communication va se complexifier au fur et à mesure que vous allez rajouter des ressources sur un projet.

• Cela va introduire de la perturbation dans l’équipe et c’est surtout cette raison-là qui va impacter le retard pris dans le projet. En effet, le nouveau développeur aura un temps de prise en main du projet, du contexte, de l’historique du projet, de découverte du code, il va consommer du temps des autres membres de l’équipe.

• La vélocité de l’équipe va se dégrader. Il va falloir attendre 4 à 6 itérations de 15 jours avec le nouveau développeur intégré dans l’équipe pour constater les effets bénéfiques de la nouvelle ressource au niveau global de l’équipe. Bien évidemment cela dépend de la complexité du projet, de son architecture, du niveau de compétences du nouvel arrivant et également de la capacité qu’on les membres de l’équipe à travailler ensemble etc.

Règle n°2 : ne pas charger au maximum l’équipe de développeurs

Un autre préjugé est le suivant : supprimer les temps morts va permettre d’augmenter la productivité.

D’après la théorie des files d’attente : quand le système est chargé à 100%, le délai de livraison explose. On pourrait remplacer le mot délai par « lead time ». En agile, le lead time correspond au délai durant lequel une story est traitée et finalisée (le lead time correspond au temps entre l’état de story créée et l’état de story finalisée).

Il faut savoir également que le lead time est proportionnel au coût du délai. Si le temps de livraison du logiciel tend vers l’infini alors il y a une perte de valeur au niveau de l’immobilisation de ce qui devait être livré en temps et en heure. En d’autres termes, plus le lead time augmente plus le logiciel perd de la valeur dans le temps. On pourrait également appeler ça un coût de non utilisation des fonctionnalités qui est bien proportionnel au lead time.

Si les développeurs sont chargés à 100% de leur capacité de développement,  alors le temps de réalisation d’une user story va tendre vers l’infini.

Pour qu’une équipe de développeurs fonctionnent de façon optimale, tous les membres composant l’équipe doit être à 80% du maximum de leur temps. Ce qu’il faut retenir de cela c’est que lorsqu’on décharge un système, on optimise son mode de fonctionnement.

Règle n°3 : préférer la gestion de projets en série plutôt qu’en parallèle

Mettre une personne sur plusieurs projets en même temps n’est pas forcément la méthode la plus productive à choisir. Peter Bergman (2010) déclare que le multitâches individuel tue la productivité.

En effet, le multitâches fait chuter la productivité de 40% et faire perdre 10 points au QI (quotient intellectuel).

Une étude de Rubenstein de Meyers and Evans dit que la gestion de projets en série (les uns après les autres) plutôt qu’en parallèle (en même temps) pourrait permettre de réduire les coûts jusqu’à 40% sur les projets les plus complexes.

Règle n°4 : penser que la maintenance informatique n’est pas une étape importante dans laquelle il faut investir beaucoup

On pense souvent à tort que la phase de maintenance d’un projet informatique est la phase dans laquelle on peut se permettre d’y affecter des compétences moins pointues et surtout moins coûteuses.

Cela est faux : plus le logiciel est de haute qualité plus la phase de maintenance augmentera en importance.

Quand un logiciel est très utilisé et sur une durée de vie longue, la phase de maintenance va être prépondérante dans toute la durée de vie du projet.

D’après Robert L. Glass (2002), l’activité de maintenance va consommer 40 à 80 % des coûts de fabrication d’un logiciel. C’est l’étape la plus importante de sa durée de vie. En effet, certains se reconnaîtront dans cette déclaration : la maintenance est plus complexe que la phase de développement.

Quand une équipe de développeurs reprend un projet en maintenance elle se retrouve confrontée à une situation beaucoup plus complexe qu’un projet from scratch. En effet, quand une équipe reprend un projet, elle doit comprendre le travail des anciens développeurs, comprendre le contexte du projet etc. La reprise d’un projet en maintenance demande bel et bien plus de compétences pointues qu’un projet qui démarre from scratch.

On remarque par conséquent qu’on a tendance à attribuer les meilleurs profils aux nouveaux projets démarrant de rien plutôt qu’aux projets de maintenance. Alors que c’est bel et bien les projets de maintenance qui requièrent les profils les plus pointus, et donc plus coûteux.

Vous souhaitez en savoir plus sur les offres de maintenance informatique proposées par Bocasay ? Contactez-nous dès aujourd’hui et découvrez comment nos équipes peuvent vous accompagner dans vos projets de maintenance.