Faire une bonne estimation

Lire cet

article

de blog

Faire une bonne estimation du coût d’un projet web passe par une timeline bien étudiée.

Publié le 29 mars 2016

0 commentaire Categories : Blog Ecrit par : Cloé Legoubé

Estimer le cout d’un projet de création ou de refonte d’un site internet n’est pas chose aisée. En effet, lorsqu’on sait qu’en moyenne, 38% des projets informatiques (incluant donc les projets web) atteignent leurs objectifs initiaux, 33% aboutissent à un échec et 29% sont purement et simplement abandonnés, selon le Standish Group, il y a […]

Faire une bonne estimation

Estimer le cout d’un projet de création ou de refonte d’un site internet n’est pas chose aisée. En effet, lorsqu’on sait qu’en moyenne, 38% des projets informatiques (incluant donc les projets web) atteignent leurs objectifs initiaux, 33% aboutissent à un échec et 29% sont purement et simplement abandonnés, selon le Standish Group, il y a de quoi se remettre en question. Pour qu’un projet aboutisse, il faut donc commencer par faire une bonne estimation du temps et des coûts. Nous allons donc vous donner les clefs pour une bonne estimation et analyser la décomposition d’un projet.

 

Estimer le nombre d’heures allouées

Dans un premier temps, il s’agit d’estimer un certain nombre de variables.

  1. Estimation par les experts du métier : les développeurs

Les bonnes pratiques veulent qu’au moins 3 développeurs travaillant sur un projet commun réalisent chacun une estimation indépendante. Le but étant de pouvoir comparer leurs estimations et d’avoir un regard expert sur le projet afin d’être le plus précis possible. Si les résultats des estimations sont trop éloignés les uns des autres, il faut alors réunir les développeurs, discuter des divergences et vérifier que le travail demandé a été compris par tous. Après leurs ajustements, une nouvelle comparaison est ensuite établie pour être le plus précis possible. De là, une juste estimation peut donc être calculée en retenant la moyenne des heures de développement estimées par les développeurs. Pour les calculs suivants, nous appellerons cette moyenne : D.

  1. Estimation du temps de management du projet

A l’estimation des heures de développement, il faut aussi ajouter les heures de management de projet, appelées «  facteur PM » pour Project Manager. En effet, certains spécialistes estiment que pour 1h de développement il faut compter 15 minutes de management du projet, soit PM = 0.25 x D, PM représentant le temps passé par les managers de projets.

  1. Estimation du risque

Notre étude met aussi en lumière un autre facteur : le facteur de risque ou d’incertitude face aux imprévus liés au projet. Plus le projet est entouré de zones d’ombres et nous parait flou, plus le risque est élevé. En effet, certains projets sont plus ou moins clairs. Nous pouvons le mesurer par exemple si le cahier des charges vous semble clair et précis, si votre interlocuteur sait précisément ce qu’il veut et qu’il sait de quoi il parle, cela dépend aussi de sa disponibilité à vous répondre si vous avez besoin d’éclaircissements sur un point en particulier. Vous pouvez aussi mesurer le facteur de risque en fonction de la confiance que vous donnez à vos collaborateurs et du taux d’absentéisme et de professionnalisme de vos développeurs. Pour mesurer le risque, vous devez prendre en compte le temps et les ressources utilisées  pour faire aboutir le projet. Le risque R se mesure de 0 à 5 et sera multiplié par le temps de travail estimé puis multiplié par 0.1.

Pour faire notre calcul, nous devons donc additionner les heures de développement et le temps de travail du project manager (D + PM). Nous obtenons ainsi l’estimation du temps de travail.

Ensuite, on multiplie le temps de travail par le facteur de risque : (D+ Pm) x R, on obtient le temps de développement additionnel qu’il faudra ajouter à notre estimation finale :

Temps de développement additionnel = [(D+ Pm) x R] x0.1

Pour ajuster votre estimation, il est important de demander aux développeurs d’estimer à quel point ils sont incertains de leurs estimations et quelles en sont les raisons. Vous pouvez ainsi plus facilement vous faire une idée du facteur de risque et des retards qui peuvent être engendrés. Ces incertitudes viennent souvent cependant d’éléments inconnus du projet.

Pour mettre toutes les chances de votre cote, n’hésitez pas à solliciter le client pour qu’il puisse vous éclairer sur ces zones d’ombres. Cela permettra ainsi aux développeurs de réduire le risque et d’ajuster leurs estimations.

Nous savons, cependant, que ce facteur est très aléatoire et il peut s’agir de facteurs qui ne sont simplement pas contrôlables, engendrant un risque élevé et augmentant le temps global estimé.

 

Estimer les ressources utilisées

Comme nous avons pu l’évoquer dans l’estimation du nombre d’heures qui seront allouées au projet, il faut aussi prendre en compte les ressources et notamment les ressources humaines. En effet, il est important d’analyser les ressources dont vous aurez besoin pour réaliser les fonctionnalités définies ou les livrables (en langage informatique). Vous pouvez ainsi aligner vos ressources avec le calendrier du projet préétabli, prévoir les étapes du projet (ou jalons) et évaluer le coût du projet.Cela aide les gestionnaires de projet à planifier quels sont les livrables pour chaque sprint (ou découpage d’un projet en boîtes de temps pouvant durer entre quelques heures et un mois, avec une préférence pour deux semaines). Par exemple, s’ils savent qu’ils ne disposent que d’un seul développeur sur le premier sprint qui doit durer 2 semaines, ils ont donc 80 heures de travail à utiliser et savent qu’ils peuvent planifier X quantité de produits livrables pour ce premier sprint. Le nombre de livrables étant calculé en fonction de notre précédente estimation des heures de travail par livrable.

Cette étape permet également de se pencher sur les jours féries, les rendez-vous déjà pris et les périodes de vacances prévues par les équipes de développement. Il faut prendre en compte toutes les dates sensibles et en tenir compte dans la planification globale du projet. D’autre part, dans certaines agences, les développeurs sont souvent amenés à travailler sur plusieurs projets en même temps, il faut donc s’assurer de leur disponibilité pour les inclure dans la timeline.

Dans le cas d’un contrat signé et figé, il faudra ajouter de nouvelles ressources (développeurs) pour combler le manque de ressources dû aux dates sensibles identifiées, et s’il n’y a aucun développeur disponible, prévenir le client qu’il faudra réduire la portée de son projet afin de ne pas dépasser son budget.

 

Cette approche semble être à l’heure actuelle la plus pertinente pour appréhender et présenter au client un projet viable avec une échéance cohérente. Elle permet de mieux respecter les délais ainsi que le budget établi en évitant au maximum les frustrations du client en cas d’imprévus car ils seront réduits.

Il faut toutefois rester vigilant, et toujours améliorer le processus afin d’aller encore plus loin dans la précision des estimations.

Laisser un commentaire

Votre adresse email ne sera pas publiée

Pour écrire votre message, vous pouvez utiliser ces attributs et tags HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>