Stop Scope Creep Running Away With Your Project

http://www.projectsmart.co.uk/stop-scope-creep-running-away-with-your-project.html

Duncan Haughey, PMP

La dérive de contenu est une des raisons les plus communes pour laquelle les projets dépassent leur budget et livrent en retard. Souvent acceptés avec les meilleures intentions, les changements de contenu pendant un projet sont des événements négatifs qu’il vaut mieux éviter.

La plupart des chefs de projet se sont trouvés dans le cas où le client demande quelque chose à l’extérieur du périmètre accepté et s’attend à la voir incluse sans frais supplémentaires. En fait, ils agissent probablement comme si cela avait toujours fait partie du contenu.

La définition des limites d’un projet est difficile, mais sans une définition claire vous vous dirigez vers des problèmes.

Qu’est-ce que le contenu de projet ?

La description du contenu est ce qu’un chef de projet s’engage à livrer tôt dans la vie d’un projet. Le contenu est défini pendant la phase d’analyse des besoins d’un projet. Travaillant étroitement avec le client et les utilisateurs, le chef de projet identifie ce qui est nécessaire pour atteindre les objectifs de projet. Le contenu de projet est enregistré dans la documentation de projet et agréé avec toutes les parties prenantes affectées.

Qu’est-ce qui cause la dérive de contenu ?

Les causes majeures de dérive de contenu sont :

• Pauvre analyse des besoins.
• Implication trop tardive des utilisateurs.
• Sous-estimation de la complexité du projet.
• Manque de contrôle des changements.
• « Sur » qualité.

Jetons un coup d’œil à chacune plus en détail :

Pauvre analyse des besoins

Le Problème :

Les clients ne savent pas toujours exactement ce qu’ils veulent et ont souvent seulement une vague idée. Le Syndrome « Je le saurai quand je le verrai ». L’échec de passer assez de temps à rassembler des besoins du business (ou assumer que l’on sait ce qui est nécessaire) peut mener à un besoin de ressources supplémentaires, un accroissement des coûts et des allongements de durées quand de nouveaux besoin apparaissent; en bref, une dérive de contenu.

La Solution :

Assurez que vous comprenez la vision de projet et passez du temps à documenter et agréer les objectifs de projet avec le client. Produisez un document de d’initiation de projet qui décrit les produits à livrer et le résultat. C’est une bonne idée de documenter ce qui est hors périmètre, aussi bien que ce qui est dans le périmètre, pour une absolue clarté. Agréez ce document avec le client, passez du temps pour le revoir en détail et demandez-leur de le signer. Ne poursuivez pas sans un accord ferme.

Implication trop tardive des utilisateurs

Le Problème :

Penser de vous savez ce que veulent les utilisateurs ou leurs besoins est une sérieuse erreur. Il est important de les impliquer dans les phases d’analyse des besoins et de conception. Plus ils ont d’engagement au début du projet, plus probablement cela vous évitera une dérive de contenu.

La Solution :

Impliquez vos utilisateurs depuis le début du projet, leur permettant de participer aux phases d’analyse des besoins et de conception; incorporez leurs suggestions et idées. Dans un projet de développement logiciel, documentez comment les utilisateurs interagiront avec le logiciel et développez des scénarios de test à utiliser plus tard. Agréez l’analyse des besoins et la conception avec toutes les parties prenantes du projet avant de démarrer la phase d’exécution.

Sous-estimation de la Complexité du Projet

Le Problème :

Le succès ou l’échec d’un projet peuvent souvent être prévus en regardant si des projets semblables ont été réussis par le passé.

Beaucoup de projets se heurtent aux problèmes parce qu’ils sont nouveaux dans leur industrie et n’ont jamais été réalisés auparavant. Personne ne sait à quoi s’attendre, il n’y a aucune leçon apprise et personne à qui demander. Dans ces circonstances, une dérive de contenu peut difficilement être évitée, causant des dépassements budgétaires et une livraison en retard.

La Solution :

Ces types de besoins de projet exigent d’avoir un degré de provisions pour aléas. Incluez certaines marges dans votre plan de projet afin de prévoir pour des problèmes et des événements imprévus et augmentez le budget pour représenter les ressources supplémentaires qui pourraient être nécessaires. Cependant, n’exagérez pas, être significativement en dessous du budget et livrer plus tôt est souvent considéré négativement.

Manque de Contrôle des Changements

Le Problème :

Vous pouvez vous attendre à un certain degré de risque de dérive du contenu dans la plupart des projets, donc il est important de concevoir un processus pour manager ces changements. Un processus simple consistant à documenter, considérer, approuver et trouver les ressources peut être conduit.

La Solution :

Introduisez un formulaire de contrôle des changements et un journal/registre des changements dès le début du projet. Expliquez leur utilisation au client et à l’équipe projet. Une requête de changement formellement écrite vous permettra d’évaluer le bénéfice business de tout changement et de rechercher son approbation éventuelle avant de l’inclure en tant qu’addition au contenu. Attachez un coût et une durée à chaque changement pour que le client comprenne bien son impact. Demander au client de passer par un processus formel aide à s’assurer qu’il y a une valeur claire pour le changement recherché.

« sur » qualité (Gold Plating)

Le Problème :

« Gold Plating » est le terme donné à la pratique d’excéder le contenu ou la qualité d’un projet en pensant que cela ajoute de la valeur. Dans des projets de développement logiciels, il n’est pas inhabituel pour des développeurs d’ajouter de nouvelles fonctionnalités croyant qu’elles augmenteront la satisfaction du client. Ces changements consomment du temps et du budget et ne garantissent pas d’augmenter la satisfaction client.

La Solution :

Assurez-vous que tous les membres de l’équipe sont pleinement conscients du contenu du projet et concentré sur livrer cela et rien de plus. Assurez-vous que le cahier des charges est suffisamment détaillé pour éviter toute ambiguïté qui pourrait mener à du travail inutile.

Récompensez des membres de l’équipe pour livrer selon la spécification, à l’heure et dans le budget. Précisez que des fonctionnalités non documentées ne devraient pas être ajoutées, mais passées par le processus de contrôle des changements.

S’il y a du temps et qu’il reste de l’argent à la fin du projet, laissez le client décider que faire.

Résumé

Pour récapituler, assurez-vous que vous positionnez correctement les attentes au début du projet, travaillez étroitement avec les utilisateurs pour définir clairement ce qui est dans et hors du périmètre. Enregistrez-le dans le document d’initiation de projet. Cependant, ne supposez pas que le client lira et comprendra ce document. Passez du temps avec le client à le revoir pas à pas et à vous assurer qu’ils comprennent et acceptent le contenu. Ne continuez pas sans accord ferme.

Souvent il n’est pas possible d’éviter que le contenu augmente pendant un projet, particulièrement s’il y a une bonne raison business de le faire. Cependant, il doit être géré correctement. Concevez un processus de contrôle des changements pour vous assurer que tous les changements sont correctement documentés, considérés, approuvés et approvisionnés en ressources. Note : Si le budget et la durée sont augmentés avec le contenu, habituellement, on ne considère pas le changement comme une dérive de contenu.

Alternativement, vous pouvez vouloir empêcher que des changements soient ajoutés petit à petit pendant le projet et pouvez décider de les documenter mais pour une phase ultérieure. Cela permet à la phase acceptée d’être livrée à l’heure et dans le budget et aux changements d’être managés et dotés en ressources séparément.

Si vous considérez que seulement 32 % ¹ de tous les projets réussissent pleinement; alors vous êtes mieux lotis à dépenser votre temps à livrer par rapport aux besoins acceptés en début du projet et à éviter la « sur » qualité.

La dérive de contenu cause beaucoup d’échecs de projet; en prenant quelques mesures simples vous pouvez vous assurer qu’elle n’affecte pas les vôtres.

¹ The Standish Group International, Inc. CHAOS Summary 2009. Boston, MA 02109: The Standish Group International, Inc., 2009.

http://www.standishgroup.com/newsroom/chaos_2009.php