Vous conviendrez sans avoir à beaucoup y réfléchir que les projets ont plus de chances de réussite avec des objectifs très clairs et un engagement fort du management. Avez-vous cependant remarqué qu’avec les approches Agile et hybride, la pression est d’autant plus importante sur les chefs de projets, qui doivent initier un projet sans signature formelle ?

Et Bien sûr, cette pression supplémentaire contribue à l’augmentation des risques !

Du temps où régnaient les projets prédictifs, « en cascade » ou « cycle en V », une très grande d’attention était portée à la charte projet, à sa revue par le sponsor et les parties prenantes et autres membres du comité de projet et à sa signature formelle par tous.

Cela n’empêchait pas les choses de changer et évoluer en cours de route. Des risques inattendus survenaient, les marchés et la concurrence bougeaient. Mais, au moins, chacun avait conscience de ce qui avait été agréé et signé.

La phase d’initialisation du projet est particulièrement critique pour sa réussite. Elle va donner un périmètre clair, des objectifs agréés et mesurables, des moyens définis et approuvés (ressources internes et externes) et des engagements de la part du top management.

La signature manuelle reflète un engagement fort qu’un simple retour de courriel d’approbation ou même votre relevé de décisions du comité de projet ne sauraient égaler.

En effet, avant d’apposer votre signature sur un document, il y a de grandes chances que vous l’ayez au minimum lu de manière attentive et demandé des clarifications ou corrections nécessaires. Certes, cela semble si rétrograde pour nos plus jeunes leaders mais aussi les plus âgés que peu de personnes oseront le revendiquer. Donc, même si  mon intime conviction reste qu’une signature manuelle a plus de valeur qu’une approbation électronique, opter pour la seconde est plus réaliste, surtout si vous rendez bien visible dans le document quelles sont les personnes qui l’ont approuvé.

Manuelles ou électroniques, les tentations de démarrer le projet sans signatures formelles sont fortes. Si vous êtes en approche adaptative-Agile ou hybride encore plus qu’avec les méthodes prédictives : Dates de livraison imposées, délais inflexibles, Minimum Viable Product évasifs, pression du management et des collègues, ou parfois la simple peur de laisser votre équipe inoccupée ou de vous faire piquer des contributeurs clés.

Essayons de regarder ces fausses bonnes raisons de se passer du formalisme de la signature officielle à tour de rôle…

1. Dates imposées et délais inflexibles

Si vous avez quelques années (ou, comme moi dizaines d’années) d’expérience en management de projet, l’une des leçons que vous avez déjà apprises à vos dépends est que la date imposée est toujours une mauvaise raison de s’affranchir de bien définir le périmètre, contenu et charte du projet. TOUJOURS !

Si l’injonction est du type : « Toute solution qui serait livrée après la saison commerciale qui démarre en Novembre ne nous intéresse pas ! » ; OK, l’une des dimensions, les délais, est figée mais vous avez encore les moyens de réussir le projet en jouant sur les 2 autres dimensions : le contenu (flexible à la baisse si nécessaire) et les moyens mobilisés (flexibles à la hausse).

Le manager de projet après avoir validé cette contrainte dure va parfois devoir faire des choix basés davantage sur des critères de disponibilité prévisionnelle que de mérite. Par exemple, certaines solutions techniques auraient pu mieux répondre aux besoins business mais semblent nécessiter trop de temps. Pour le contenu, voir le point 2. Cependant, n’en doutez pas, a posteriori, cette décision court-termiste imposée par la date butoir s’avèrera parfois futile sinon contreproductive mais dans l’instant, pas d’autre choix possible.

2. Minimum Viable Product (MVP) évasifs

L’approche Agile parce que mal comprise est une mauvaise excuse souvent brandie pour ne pas bien définir tous les besoins.

Bien sûr, il n’est pas nécessaire de bien définir tous les besoins qui ne feront pas partie du périmètre et contenu du MVP. Mais, pour ceux qui sont inclus, il faut les détailler et si possible en équipe resserrée avec les développeurs et utilisateurs, pas de passe-droit.

Le MVP doit être précis et clair sur qui sera inclus et aussi ce qui ne le sera pas pour cette version certes utilisable mais néanmoins incomplète du livrable final.

3. Pression du management et des collègues

Attention une fois de plus. Même quand ces pressions partent de convictions sincères des personnes, elles résultent trop souvent de vues partielles des besoins et de leurs priorités respectives. L’impact du contexte (l’écosystème) dans lequel la solution sera déployée ne peut être ignoré et les objectifs finaux du projet non plus.

Ces pressions sont parfois teintées de considérations plus terre à terre quant à la disponibilité des compétences requises pour chacun des besoins agréés et qui sont convoitées par d’autres projets ou initiatives plus opérationnelles. Il est toujours bénéfique de se donner le temps de comprendre et ne pas sous-estimer les luttes de pouvoir interne, les souhaits de développement de nouvelles compétences dans un département, les choix d’affectation déjà actés des ressources de l’entreprise.

On ne peut ignorer ces personnes et pressions mais elles ne doivent pas venir obscurcir notre vision et nous éloigner des critères agréés de choix de la meilleure solution pour votre projet.

4. Ressources disponibles clés

Le sentiment de devoir à tout prix utiliser les ressources disponibles et non affectées est très fort et assez légitime pour le management fonctionnel de l’entreprise.

Mais, du point de vue du projet, celui qu’exprime le manager de projet, quelques questions se posent :

• Ces ressources disponibles sont-elles les bonnes pour les besoins du projet ?

Elles peuvent être sous-qualifiées pour les tâches. Elles risquent aussi d’être surqualifiées car on ne souhaite pas voir partir ces experts même s’ils vont s’ennuyer ferme sur le projet.

• Possédons-nous toutes les compétences requises en se basant sur ces disponibilités ?

Soit les affectations actuelles peuvent être changées si votre projet est prioritaire, soit vous devrez aller en chercher d’autres à l’extérieur.

• Combien de temps faudra-t-il passer à recruter de nouvelles ressources ou bien à former celles qui sont capables de monter en compétences ?

Au final, quand bien même ces ressources clés seraient disponibles avec les bonnes compétences, est-ce une raison suffisante pour démarrer sans approbation formelle du projet ? NON !

En pratique, que faire ?

En fait, dans une petite organisation et avec des clients que l’on connait bien, avec une confiance réciproque forte bien établie entre toutes les parties prenantes du projet, il est possible de démarrer des projets de tailles réduites sans signature formelle.

Vous pouvez probablement les lancer en mode Agile avec une bonne idée du premier MVP, du résultat final cible et un engagement ferme sur le contenu et les ressources seulement sur les premières étapes. Celles-ci vont vous permettre de livrer de la valeur tout en apprenant.

Cependant, sur tout gros projet, y compris en approche Agile, cela vaut le coup de sécuriser les approbations de toutes les parties prenantes majeures avant de démarrer. Sinon, vous allez faire puis devoir défaire tout ou partie pour les refaire (si vous en avez encore les moyens).

“Si vous ne prenez pas le temps maintenant de bien faire les choses, dites-moi quand vous prendrez le temps de les refaire ! Car, n’ayez aucun doute, il vous faudra les refaire.”

Alors selon vous, les signatures formelles sur les projets restent-elles toujours aussi importantes avec l’avènement des approches Agile et hybrides ?