Ne rien faire sans un objectif clair

Vous ne devriez rien faire à moins que cela soit motivé par un objectif clair. Imaginez deux mondes parallèles où tout est identique, sauf ce que vous envisagez : jusqu’à quel point seraient-ils différents ? La différence vaut-elle l’effort que vous investirez ?

Si vous n’avez pas d’objectif précis et ne faites que parce que tout le monde le fait ou que tout le monde dit que c’est important, alors :

• Votre cas n’aura peut-être pas un bénéfice réel, et vous ne pourrez donc rien en retirer, Ou
• Il peut toujours avoir des bénéfices potentiels dans votre cas, mais comme vous n’avez pas l’objectif en tête, votre façon de le faire ne vous aidera peut-être pas à en tirer des bénéfices.

Exemple : portefeuilles et programmes

Si vous êtes impliqué dans la sélection et le lancement de projets, vous devez vous concentrer sur les bénéfices et les problèmes qui sont censés être résolus avant le produit qui va concrétiser ces choses. L’exemple classique est celui du fabricant d’ascenseurs qui recevait autrefois des plaintes concernant la vitesse de leurs ascenseurs et qui lançait plusieurs projets pour augmenter la vitesse de ses ascenseurs sans succès. Cela a continué jusqu’à ce qu’ils décident de se concentrer sur le problème (ennui ou inconfort des gens) au lieu de la solution « naturelle » (ascenseurs plus rapides). Résultat : ils ont ajouté des miroirs aux ascenseurs, ce qui a tout simplement résolu le problème.

Rappelez-vous que la gestion de projet consiste principalement à bien faire les choses, alors que la gestion de portefeuille consiste à faire les bons choix. Peu importe la qualité de la gestion de vos projets, cela ne fonctionnera pas si vous choisissez les mauvais projets. Il s’agit d’avoir un objectif.

Exemple : le projet dans son ensemble

La flexibilité du produit varie selon les projets. Dans certains projets de développement informatique, le produit est totalement flexible et sa forme finale dépend du retour d’informations généré par les incréments du produit au cours du projet, ce qui nécessite une approche adaptative (Agile). Il s’agit pratiquement d’une combinaison des couches portefeuille, programme et projet, et doit faire l’objet d’une attention maximale à l’ultime objectif. C’est une bonne idée de documenter l’objectif et de le rendre accessible ; c’est l’un des buts visés par la « vision produit » utilisée dans certains types de projets tels que les projets Scrum. L’attention portée à la valeur commerciale dans les projets Agiles est leur moyen d’assurer l’alignement sur leur objectif.

Dans d’autres types de projets, où le produit est relativement fixe et qu’il existe d’autres mécanismes pour garantir que le produit identifié satisfera à l’objectif recherché, il est possible pour les membres de l’équipe de projet de déplacer une grande partie de leur attention du but vers le produit ( d’où le principe de «focus sur les produits» de PRINCE2^®), mais un minimum d’attention est nécessaire pour que le produit satisfasse à ce but, ce qui peut être fait en comparant les avantages prévus aux avantages escomptés (d’où le principe de «justification commerciale continue» et le thème «étude de rentabilité» dans PRINCE2^®).

Lorsque le projet est à réaliser pour des clients externes, le client a son propre objectif et votre entreprise a un objectif différent. Vous devez comprendre et utiliser les deux pour vraiment réussir.

Exemple : le suivi de projet

Garder l’objectif ultime en vue est nécessaire, mais il peut s’avérer trop abstrait pour la plupart des tâches quotidiennes. C’est pourquoi une hiérarchie d’indicateurs est nécessaire pour le rendre plus pratique. Tout d’abord, la justification et les bénéfices du projet sont définis en fonction de l’objectif ultime, puis vous aurez des objectifs explicites et implicites pour les variables du projet (par exemple, le temps, le coût et la qualité) afin de satisfaire la justification, ce qui à son tour satisfera le l’objectif ultime. Ce sont des objectifs de niveau inférieur qui sont utiles pour beaucoup de nos tâches quotidiennes.

En ce qui concerne le suivi, le contrôle de bas niveau du projet sera effectué en utilisant le plus bas niveau de variables, car il ne sera peut-être pas possible de suivre l’objectif ultime. Dans ce cas, vous devriez toujours avoir les objectifs en tête : quel est l’objectif du suivi ?

Une réponse normale et acceptable consiste à voir si nous sommes sur la bonne voie et, sinon, à déclencher une réaction qui nous ramènera sur la bonne voie ou ajustera les variables pour voir si ces ajustements peuvent toujours nous permettre d’atteindre l’objectif ultime. Par conséquent, nos mesures devraient vous permettre de traiter cet objectif de bas niveau, et les mesures appropriées sont des prévisions pour les variables à la fin ; c’est-à-dire, quand serions-nous en mesure de terminer le projet ? De quel budget aurions-nous besoin pour terminer le projet ? Etc.

Toutes les autres mesures, telles que les valeurs planifiées et réelles à ce jour, ne sont que des valeurs intermédiaires dont vous avez besoin pour calculer les prévisions, et non les valeurs finales que vous utilisez à des fins de gestion.

Exemple : les documents

Quelle que soit l’approche de développement que vous utilisez dans le projet, la planification est toujours nécessaire. La question importante est le niveau de détail de chaque type de plan. Si le plan n’est pas suffisamment détaillé, sa contribution sera négligeable et l’exécution du projet reposera davantage sur des décisions ad hoc que sur des décisions holistiques et intégrées. Par ailleurs, de nombreuses personnes essaient d’être prudentes et d’ajouter trop de détails à au plan, ce qui rend sa préparation et sa maintenance trop difficiles, et trop rigide pour les incertitudes du projet. Par conséquent, le plan devient irréaliste et inutile.

La meilleure façon de décider du niveau de détail du plan est d’avoir un objectif en tête ou de considérer tous les éléments déterminants du plan. Par exemple, si vous envisagez d’ajouter une ressource au plan, vous devez avoir un objectif : comment allez-vous l’utiliser ? Comment cela aiderait-il le projet ? Quel effort sera nécessaire pour l’intégrer, cela en vaut-il la peine ?

Il s’agit parfois de décider si vous souhaitez inclure un élément dans vos plans, et parfois de choisir votre façon de planifier ou de préparer quelque chose. Prenez une étude de rentabilité, une charte de projet ou un rapport : vous devez toujours vous demander pourquoi vous préparez ce document et en quoi il peut aider le projet. La recherche d’un «exemplaire» est le contraire de faire quelque chose basé sur un objectif.

Exemple : le rapport sur l’état du projet

Il est courant d’avoir des rapports d’état très longs dans de nombreux projets. Sur la base de ces Principes Quasi Universels (NUP - Nearly Universal Principles), nous devrions nous demander quel est l’objectif du rapport et comment nous pouvons atteindre cet objectif, indépendamment de ce que la plupart des gens peuvent faire.

Cela peut, dans de nombreux cas, nous amener à préparer des rapports très simples d’une page que les parties prenantes lisent et comprennent vraiment au lieu de longs rapports. C’est aussi cela faire attention à l’objectif.

Cependant, si vous préparez des rapports d’une page, certaines personnes peuvent vous objecter et penser que vous ne disposez pas d’un système de suivi « approprié ». Cela crée pratiquement un second objectif pour vous (outre le premier objectif, qui consiste à aider les parties prenantes à comprendre le statut du projet), et pour le satisfaire, vous pouvez simplement créer un second type de rapport très long. Cependant, vous ne combinerez pas cela avec le premier rapport, car ces deux objectifs ne sont pas les mêmes.

Exemple : les études de rentabilité et la charte de projet

Préparer des documents tels qu’une étude de rentabilité et une charte de projet est généralement une nécessité fastidieuse, infructueuse et bureaucratique pour la plupart des gens, alors que ces documents ont tous des objectifs valables qui s’appliquent à la plupart des projets. Si vous essayez de trouver un “modèle” et remplissez le modèle, le travail est simplement inutile, alors que vous pouvez plutôt vérifier le but réel de ces documents, voir comment et s’ils peuvent être utiles dans votre projet, puis préparer le document comme vous le souhaitez, rien que pour satisfaire ces objectifs : c’est le bon document.

Pendant que vous réfléchissez à la manière dont vous pouvez préparer les documents pour répondre à leurs objectifs, vous pouvez ne pas penser à tous les scénarios et rater quelque chose. Pour éviter cela, vous pouvez vérifier ce que suggèrent PRINCE2^®, Guide PMBOK^®, P3.express et DSDM^®, puis évaluer ces suggestions en fonction des objectifs visés.

Exemple : le suivi post-projet

Bien que le projet ait un objectif précis et que nous puissions en tenir compte tout au long du projet, sa réalisation est principalement évaluée sur la base de prévisions établies au cours du projet, et nous ne devons pas l’oublier une fois le projet terminé. Il est important de vérifier la réalisation des objectifs une fois le projet terminé, car :

• nous pouvons voir comment les objectifs ultimes sont atteints et en tirer des enseignements pour les projets futurs, et

• Parfois, les objectifs ne sont atteints que si nous réalisons quelques tâches supplémentaires après l’achèvement du projet, et comprendre la nécessité de ces tâches supplémentaires requiert un suivi.

Le suivi post-projet est une étape nécessaire si vous êtes axé sur les objectifs. C’est principalement la responsabilité des systèmes de gestion de programme et de portefeuille, et comme la plupart des entreprises n’ont pas de tels niveaux de gestion, cette étape est généralement négligée. C’est pourquoi P3.express et DSDM^® ajoutent cette étape à leurs méthodologies de gestion de projet.

Exemple : la simplicité

Le monde est complexe et chaotique, mais nos modèles sont des approximations abstraites reflétant partiellement le monde. Par conséquent, ils peuvent être simples. D’un autre côté, les systèmes simples fonctionnent généralement mieux, car nous pouvons nous concentrer sur l’usage principale.

Nombre d’entre nous essaient d’obtenir de bons résultats en rajoutant de la complexité à nos systèmes, espérant que cela corresponde à la complexité du monde, même si cela rend le système difficile à utiliser et nous empêche généralement d’atteindre l’objectif recherché.

Exemple : L’adaptation

Les projets ne sont pas les mêmes. Un logiciel de diffusion de musique en ligne impose des conditions très différentes de celles qui seront utilisées pour l’équipement d’un hôpital ou pour un avion dont la vie peut dépendre, ou d’un logiciel qui sera utilisé dans un satellite où il est supposé fonctionner pendant de nombreuses années sans se planter, et ces logiciels sont tous différents de la construction d’une maison de vacances, d’une centrale anti-incendie et d’une usine de traitement.

Une fois que vous avez les objectifs en tête, vous comprendrez mieux comment adapter les systèmes et la documentation à différents projets.

▼ PDF