Une transition numérique ? Pour quoi faire ?
Comment organiser cette transformation ? A quoi ça sert, je sais déjà ce que je veux.
De façon générale, un projet est comparable à un voyage. On sait intuitivement où on veut aller, quand et pourquoi. La métaphore du voyage nous permettra d’imager ce projet de transformation numérique.
Certains parlent de transformation digitale, et même si un chef de projet laisse son empreinte, on gardera le terme pour les empreintes digitales.
Le plus souvent, dans le langage courant, en parlant de cahier des charges, nous faisons référence à un cadrage.
Je veux que mon entreprise aille à Babel pour une conférence, c’est le pré-cadrage.
Je suis l’instigateur de notre besoin d’être présent à ce salon, je suis le sponsor.
Bien entendu, intervenir à cette conférence obéit à un contexte stratégique au sein de l’entreprise.
Les enjeux sont importants puisque nous devons nous faire connaître et développer notre réseau de contacts.
Pour cadrer ce besoin :
- J’ai un budget pour le trajet et les frais surplace, c’est le budget
- Je dois être présent le 15 du mois pour être présent au salon, c’est une contrainte forte
- Je connais les conférenciers de mon entreprise et le chauffeur (chef de projet, facilitateur) qui vont se joindre au voyage, ce sont les acteurs
Bien entendu les objectifs sont clairs et découlent des enjeux. Il s’agira de dispenser les conférences et enrichir le carnet d’adresses.
Je sais maintenant qui, quand, quoi … il manque le « comment ». Quel véhicule ? Utilisation des transports en commun ? Qui gère l’intendance et s’assure de coordonner toutes les actions pour s’assurer que l’on arrivera à bon port dans les temps (respect du cadrage). Si vous confiez votre planification à un GPS, le choix d’un itinéraire peut se faire avec un prestataire qui pilotera pour vous. Il tracera la route, planifiera le trajet pour arriver à une heure dite et un lieu dit. C’est le plan d’action, la planification.
Maintenant que tout est organisé, reste à piloter.
Lorsque tout est organisé, que tout le monde connaît son rôle et ses responsabilités, le trajet s’annonce serein et anticipé.
Le pilotage consistera donc à rester vigilant pour gérer les imprévus, et surtout de les voir venir avant qu’ils ne se produisent.
Le plus simple est de faire le point régulièrement et avec les bons interlocuteurs. Dans la voiture, l’équipe fait le point des étapes, des villes traversées. Ce sont des réunions projet.
Le trajet finit, la conférence passée, le départ pour le retour feront l’objet, par le pilote d’un suivi auprès de moi. Le chef de projet tient donc informé le sponsor que je suis lors de comités de pilotage. Je peux donc me porter garant du bon avancement du projet à mon directeur général en adéquation avec les objectifs initiaux.
Avec un peu de recul on se rend bien compte que les clefs du succès résident principalement sur la préparation et la communication entre l’organisateur du déplacement et le pilote de l’équipe.
Les différents éléments que nous venons de lister sont communs quelle que soit la méthode. Certains définissent le projet, d’autres sont les garants de connaissances métier et d’autres sont des coordinateurs.
Reste à savoir quelle méthode de conduite de projet nous allons utiliser. La réponse ne peut pas être unique et ce serait condescendant et dogmatique de ne jurer que par une seule méthode. Ce faisant, une lapalissade est de rigueur :
La bonne méthode est celle qui convient au contexte
Impact des contextes au cours de la vie d’un projet
La méthode doit permettre de s’adapter en prenant en compte les changements de priorisation. Afin de piloter, il faut évaluer les impacts, dont :
- L’évaluation de la charge
- Les délais de mise en œuvre
- La complexité du changement (impacts sur l’existant)
- Les risques
Les méthodes dites classiques comme les méthodes agiles ont toutes les deux fait leurs preuves.
Nous avons souvent tendance à ignorer qu’un contexte est d’autant plus vivant que la durée du projet est grande.
En clair, pour un projet long à mettre en œuvre, plus il faut le découper en petits projets ou versions. C’est une approche agile. Il faut prioriser sur les premières versions ce qui offrira le plus de valeurs ajoutées avec le “moindre effort” (à traduire “coûts”).
L’inconfort des méthodes agiles vient souvent de la sensation de ne pas maîtriser le coût. A l’extrême, un agiliste pourrait dire :
“Allouez une enveloppe et nous verrons ce que nous pourrons faire en première version”
Ce que le client entend :
“Du coup, je sais combien cela va me coûter sans savoir ce que je vais obtenir ?”
L’erreur principale vient du fait raisonner dans l’exhaustivité du besoin. Nous avons une tendance “jusqu’au-boutiste” qui nous pousse à raisonner par l’idéal or le contexte est mouvant. Les besoins du jour ne sont pas ceux de demain.
Une approche plus sage serait de structurer le besoin en le découpant en fonctionnalités priorisées.
La Version 1, aussi appelée MVP (Minimum Viable Product) permet de se concentrer sur la meilleure valeur ajoutée et raisonner en enveloppe budgétaire par période.