Les projets IT échouent plus souvent que tout autre type — généralement parce que le périmètre est flou, que des dépendances ont été oubliées ou que la communication est trop faible. Avec Trupeer, vous pouvez gagner des heures sur la planification en commençant par un modèle gratuit de plan de projet IT, en le personnalisant avec votre identité de marque, puis en transformant le plan en mises à jour vidéo qui maintiennent l’alignement entre les parties prenantes techniques et métier.

Qu’est-ce qu’un plan de projet IT, et pourquoi les modèles génériques dérapent

Un plan de projet est le document qui indique ce qui sera livré, à quelle date, par qui, et ce qui doit être vrai pour que cela se produise. Chaque modèle qui se classe pour cette recherche vous donnera cela, généralement sous forme de liste de tâches avec des dates de début, des dates de fin, des responsables et une barre de Gantt.

La liste de tâches n’est pas le problème. Le problème, c’est l’ordre dans lequel vous la remplissez.

Les modèles génériques commencent par votre travail. Listez les tâches, estimez les durées, enchaînez-les, ajoutez des responsables, et la date de fin tombe en bas. Les dépendances sont ajoutées ensuite, dans une colonne, sous forme de note.

Les projets IT ne dérapent que rarement parce que ces estimations étaient fausses. Ils dérapent parce qu’un élément arrive, qui n’était jamais dans le plan et qu’on ne peut pas contester : un gel des changements couvrant la semaine de mise en production, une revue sécurité avec une file d’attente de six semaines, un prestataire dont les consultants de mise en œuvre sont réservés jusqu’à la fin du trimestre, une licence qui se renouvelle avant que le remplacement soit prêt, un audit qui verrouille l’environnement pendant un mois.

Aucun de ces éléments n’est un risque. Un risque est quelque chose qui pourrait arriver. Ce sont déjà des réalités le jour où vous commencez à planifier, et chacun d’eux est identifiable dès la première semaine si quelqu’un pose la question.

Donc ce modèle inverse l’ordre. Vous dessinez d’abord les dates que vous ne pouvez pas déplacer. Ensuite, vous découvrez à quel point la fenêtre restante est réellement large. Puis vous planifiez le travail à l’intérieur. La liste de tâches existe toujours, elle cesse simplement d’être la première chose que vous écrivez.

Comment personnaliser ce modèle dans Trupeer

Étape 1 : Ouvrir la section Modèles

Allez dans la section Modèles depuis la navigation principale.

Étape 2 : Sélectionner et ouvrir un modèle

Cliquez sur n’importe quel modèle avec lequel vous souhaitez travailler pour l’ouvrir.

Étape 3 : Développer l’affichage du modèle

Si nécessaire, développez l’affichage du modèle pour voir clairement la mise en page complète et les détails.

Étape 4 : Modifier le modèle

Cliquez sur Modifier pour commencer à apporter des changements au modèle sélectionné.

Dans l’éditeur, vous pouvez :

• Ajouter de nouvelles sections

• Définir ou mettre à jour des règles de mise en forme

• Ajouter un logo et ajuster sa position ainsi que les paramètres associés

Étape 5 : Enregistrer votre modèle personnalisé

Une fois tous les changements nécessaires effectués, cliquez sur Enregistrer pour stocker le modèle mis à jour comme le vôtre.

Étape 6 : Prévisualiser et affiner le modèle

Lorsque vous souhaitez voir à quoi ressemble votre modèle personnalisé, ouvrez la Prévisualisation.

À partir de l’écran de prévisualisation, vous pouvez continuer à effectuer des ajustements directement si nécessaire, afin de garantir que le modèle s’affiche exactement comme vous le souhaitez.

Avec un modèle de plan de projet IT, vous pouvez :

• Gagner du temps sur la planification : évitez la page blanche avec une structure conçue pour les initiatives IT.

• Gérer la complexité technique : des sections intégrées pour l’architecture, les dépendances et les risques.

• Rester fidèle à votre marque : appliquez votre logo, vos polices et vos couleurs grâce au brand kit de Trupeer.

• Aligner le métier et l’IT : transformez les plans techniques en mises à jour vidéo que les parties prenantes métier peuvent comprendre.

• Standardiser d’un projet à l’autre : utilisez le même modèle pour chaque initiative IT.

• Atteindre des équipes internationales : traduisez les plans et les mises à jour en 65+ langues en un clic.

Les éléments non négociables, et où les trouver

Un élément non négociable est toute date ou durée fixée par quelqu’un qui ne dépend pas du projet. Vous ne pouvez pas la négocier dans le cadre du projet, et la découvrir tard la transforme d’une contrainte en crise.

Voici l’inventaire à préparer dès la première semaine. Posez à chaque responsable deux questions : quelle est votre date, et quel est votre délai de prise en compte.

Deux de ces éléments méritent une attention particulière, car ce sont ceux qu’on oublie le plus souvent. Les périodes de préavis dans les contrats sont des dates non négociables qui se situent avant la date de renouvellement : le délai réel est donc plus tôt que celui indiqué dans l’agenda. Et la qualité des données dans le système source est le seul élément non négociable dont la taille ne peut pas être évaluée à l’avance. Vous devez aller la mesurer, c’est pourquoi l’analyse des données source doit être faite dès la première semaine plutôt qu’au moment de la migration.

Dessinez-les sur un seul calendrier avant d’estimer quoi que ce soit. Ce que vous cherchez, c’est la forme de l’écart. Très souvent, l’écart est bien plus étroit que la durée du projet, et la discussion honnête sur le périmètre a lieu en semaine deux plutôt qu’au mois sept.

Ce qui doit figurer dans le plan

Une fois les éléments non négociables dessinés, le plan lui-même comporte douze sections. Copiez les titres, remplissez-les dans cet ordre.

1. Résumé. Une phrase : ce qui change, pour qui, et ce qui cesse d’être vrai ensuite.

2. Résultat et critères de réussite. Mesurables, et datés. Incluez au moins un critère concernant l’élément remplacé : par exemple, que le système historique n’a plus de trafic et n’entraîne plus de coût de licence à une date donnée. Les plans qui s’arrêtent à la mise en production sont la façon dont les entreprises finissent par payer deux systèmes.

3. Calendrier des contraintes. Le tableau des éléments non négociables ci-dessus, rempli, avec la fenêtre de livraison qui en résulte indiquée comme une plage de dates en toutes lettres.

4. Périmètre. Trois listes : inclus, exclus, et reportés. La liste des reportés est la plus utile, car c’est là que le périmètre va lorsqu’il est coupé, et cela évite la même discussion qui se répète quatre fois.

5. Phases et jalons. Les jalons sont des événements avec une réponse observable, par exemple « revue sécurité validée » ou « premier magasin en production », pas « phase de conception terminée ».

6. Découpage du travail. Tâches, responsables, estimations, séquençage. C’est la partie avec laquelle tous les autres modèles commencent.

7. Dépendances. Séparez l’interne de l’externe. Chaque dépendance externe doit avoir une personne nommée dans l’autre organisation et une date à laquelle elle s’est engagée, pas une date que vous avez supposée.

8. Environnements et données. Quels environnements existent, quelles données se trouvent dans chacun, comment les données de production sont protégées en test, et le résultat de l’analyse des données source.

9. Basculement et retour arrière. La séquence heure par heure pour le switch, le point de décision où vous vous arrêtez, qui prend cette décision, et comment vous revenez en arrière. Rédigez-le comme une procédure exécutable, c’est là qu’un modèle de méthode de procédure doit être utilisé.

10. Risques avec déclencheurs. Pas une matrice probabilité/impact. Chaque risque doit avoir un déclencheur observable et l’action qui se déclenche lorsque le déclencheur est constaté. « Le consultant du prestataire n’est pas confirmé avant le 12 mai » est un déclencheur. « Le prestataire pourrait être en retard » n’en est pas un.

11. Communication, formation et adoption. Qui est informé de quoi et quand, et ce qu’on attend des utilisateurs pour être capables de faire dès le jour un.

12. Gouvernance et clôture. Qui décide, qui escalade, à quoi ressemble un compte rendu de décision, et les conditions dans lesquelles le projet est déclaré terminé et remis à l’équipe d’exploitation.

Un exemple concret, et ce que cela a coûté

Ashmore Retail, quatre-vingt-quatre magasins et trois centres de distribution, a planifié en février le remplacement du système de gestion d’entrepôt dans les trois centres de distribution. Neuf mois de travail, mise en production prévue à la mi-novembre, décrite dans le deck de lancement comme arrivant confortablement avant la période de pic.

Deux éléments non négociables existaient le jour de ce lancement. Les deux étaient publiés. Aucun n’était dans le plan.

Le premier était le gel des changements. Les opérations retail le publient chaque janvier et il court du 1er novembre au 15 janvier, couvrant la période de pic. Aucun changement de production, de quelque nature que ce soit, n’est autorisé pendant ces onze semaines.

Le second était le contrat historique. Il a été renouvelé le 31 décembre pour douze mois supplémentaires, pour un montant de cent quatre-vingt-six mille livres, avec un préavis de quatre-vingt-dix jours requis, ce qui a ramené la date réelle au 2 octobre.

Le projet s’est déroulé conformément au plan pendant le printemps. La revue sécurité a pris quatre semaines au lieu des deux annoncées dans le SLA. Les consultants de mise en œuvre du prestataire n’étaient pas disponibles avant octobre, car ils avaient été sollicités en juillet. Les deux décalages ont été absorbés en déplaçant la mise en production de la mi-novembre à la fin novembre, ce que personne n’a signalé, car personne ne regardait le calendrier de gel.

Le gel a été mis en évidence lors d’une réunion du change advisory board début septembre. Une mise en production en novembre n’était pas possible, et la prochaine fenêtre exploitable a ouvert le 16 janvier.

Il restait alors un choix à faire avant le 2 octobre. Donner un préavis sur le contrat historique et démarrer à partir du 1er janvier sans support sur le système dont toute l’entreprise dépendait, ou le laisser se renouveler et payer un an d’un système qu’ils avaient prévu de mettre hors service en novembre.

Ils l’ont laissé se renouveler. Le nouveau système est passé en production le 4 mars. Le contrat historique a été utilisé pendant neuf semaines sur ses cinquante-deux semaines, soit environ trente-deux mille livres de valeur contre une facture de cent quatre-vingt-six mille livres. Environ cent cinquante-quatre mille livres n’ont rien acheté.

La partie instructive est que le projet n’a jamais été en retard au sens où les gens l’entendent quand ils disent « en retard ». Le travail a été réalisé à un niveau raisonnable et à un rythme raisonnable. Ce qui a mal tourné, c’est que la fenêtre était six semaines plus étroite que ce que tout le monde avait dessiné, et les deux dates qui la définissaient étaient déjà dans un calendrier publié et dans un contrat signé depuis avant même l’existence du projet.

Si le calendrier des contraintes avait été dessiné en février, la séquence aurait été évidente. Mise en production avant le 1er novembre, en remontant à travers une revue sécurité de quatre semaines qui en faisait en réalité six, un parcours achats de six semaines et des consultants qui avaient besoin d’un préavis d’un trimestre : cela signifiait que le contrat prestataire devait être signé à la mi-avril. Il a été signé en juillet. Le projet n’avait pas besoin d’aller plus vite. Il avait besoin de démarrer ses dépendances non négociables onze semaines plus tôt.

Cinq formes de projet IT, et quelles sections portent le poids

Des listes de vingt modèles de projets IT sont courantes dans cette recherche, couvrant tout, de la mise en œuvre ITSM aux mises à niveau d’infrastructure, jusqu’à la création d’un PMO. En pratique, elles se résument à cinq formes, et la forme vous indique quelles sections ci-dessus méritent le détail.

Remplacement. Remplacer un système en cours par un autre. Inclut WMS, ERP, outils ITSM, plateformes de help desk, systèmes RH. Les sections 3, 9 et 2 portent le poids, car les parties difficiles sont la fenêtre, le basculement et la preuve que l’ancien système est réellement hors service.

Mise en œuvre. Quelque chose de nouveau sans prédécesseur. Inclut la gestion SLA, les programmes de gouvernance IT et de conformité, la gestion des actifs, la gestion des connaissances. Les sections 11 et 2 portent le poids, car rien n’était cassé avant : l’adoption est donc la seule chose qui le rend réel. Notre guide de mise en œuvre de digital adoption approfondit ce point.

Migration ou mise à niveau sur place. Même système, nouvelle version, nouvel hôte ou nouvelle région. Inclut la virtualisation, la consolidation, la migration vers le cloud, les mises à niveau de base de données. Les sections 8 et 9 portent le poids, car le retour arrière est toute la partie décisive.

Construction. Développement logiciel et automatisation des processus. La section 4 porte le poids, car le périmètre est la variable qui bouge, et les critères d’acceptation sont ce qui l’empêche de bouger discrètement.

Programme et assurance. Mise en place du PMO, audits IT, gestion de portefeuille, gestion des risques, conformité sécurité. La section 12 porte le poids, car la livrable est une preuve et un sign-off plutôt qu’un système opérationnel, et les jalons sont des dates de revue définies par quelqu’un d’autre.

Si votre projet ne correspond pas clairement à l’une de ces formes, il s’agit généralement de deux projets qui ont reçu un seul nom.

Construire le plan en une journée

Matin : dessinez les éléments non négociables. Envoyez les deux questions à chaque responsable dans le tableau, relancez d’abord le prestataire et les réponses sécurité, car ce sont celles qui ont les délais les plus longs, puis mettez toutes les dates que vous récupérez sur un seul calendrier. Indiquez la fenêtre qui en résulte en une phrase.

Après-midi : rédigez les sections 1, 2 et 4, puis les jalons. Laissez le découpage détaillé du travail à l’équipe de livraison pour qu’elle le complète pendant la semaine. Un plan est utile dès que la fenêtre et le périmètre sont convenus, et il ne devient pas plus utile parce qu’il contient quatre cents lignes.

Passez-le en revue par rapport à la fenêtre à chaque réunion de gouvernance. La seule question qui vaut la peine d’être posée n’est pas « sommes-nous dans les temps ? », mais « un élément non négociable a-t-il bougé ? ». Les gels sont prolongés, les audits sont reprogrammés, et les prestataires perdent des consultants. Ces changements redessinent le plan d’une manière qu’une tâche décalée ne fait jamais.

Ce qu’il faut laisser de côté

Un diagramme de Gantt de chaque tâche n’a pas sa place dans le document de plan. Il appartient à l’outil avec lequel vous planifiez, et le dupliquer dans un document crée deux versions qui divergent en l’espace de deux semaines.

Un registre complet des risques avec des scores n’a pas non plus sa place ici. Conservez les risques qui ont des déclencheurs et des dates, et mettez le reste dans le registre.

Les procédures détaillées sur la façon dont le travail est réalisé doivent figurer dans un IT SOP, et la description de ce que vous avez construit doit figurer dans IT documentation plutôt que dans le plan. La passation à l’équipe d’exploitation mérite d’être planifiée correctement : c’est précisément l’objectif d’un knowledge transfer SOP.

Quand arrêter d’utiliser un document et passer à un logiciel

Un document est le bon contenant tant que le plan fait l’objet de discussions, ce qui correspond à la majeure partie du premier mois. Il cesse d’être le bon contenant lorsque trois choses deviennent vraies en même temps : plus de trente tâches sont en cours, plus de quatre personnes mettent à jour le statut, et les dépendances entre tâches commencent à changer chaque semaine.

À ce moment-là, transférez le découpage du travail dans un logiciel de planification et conservez le document pour les sections 1 à 5 et 12, qui sont les parties lues par des personnes qui n’ouvriront jamais l’outil. Le document conserve l’accord. L’outil conserve le calendrier.

Transformer le plan en quelque chose que l’équipe de livraison suit réellement

Le plan est lu lors du lancement et lors de la réunion de pilotage. Le runbook de basculement est lu à deux heures du matin par quelqu’un qui n’était présent à aucune des deux réunions.

Trupeer AI transforme un enregistrement d’écran en processus documenté : ainsi, les étapes de basculement de la section 9 et les tâches du jour un de la section 11 deviennent des walkthroughs de vos systèmes réels plutôt que des paragraphes qui les décrivent. Enregistrez la séquence une fois, et vous obtenez un guide pas à pas, une vidéo et un document dans votre knowledge base, avec votre branding.

Enregistrez-le. Mettez-le en marque. Traduisez-le. Trupeerisez-le.

Pour le travail d’adoption de la section 11, change management et training videos couvrent le déploiement, et documentation conserve le plan, le runbook et le contenu de passation ensemble. Les instructions de configuration se trouvent dans le document template setup guide.

Questions fréquentes

Existe-t-il un modèle gratuit de plan de projet IT dans Excel ?

Pas sous forme de fichier chez nous, et il vaut mieux être clair sur l’échange. Excel est réellement le meilleur contenant pour le découpage du travail de la section 6, car les dates, les dépendances et les regroupements appartiennent à des cellules. Construisez cette feuille vous-même avec des colonnes pour tâche, responsable, début, fin, dépendance, statut et indicateur d’élément non négociable. Conservez les sections 1 à 5, 9 et 12 sous forme de document, car elles font l’objet de discussions en texte, et personne ne négocie le périmètre dans un tableur.

Existe-t-il une version Word, ou un téléchargement gratuit en fichier Word ?

La structure en douze sections ci-dessus est écrite pour être copiée directement dans Word ou Google Docs. Collez les titres, conservez la numérotation et remplissez-les dans l’ordre indiqué. Il n’y a pas de téléchargement verrouillé, ce qui signifie aussi qu’il n’y a pas de formulaire entre vous et la structure.

Existe-t-il une version PDF ?

Collez les sections dans votre éditeur et exportez en PDF lorsque le plan est validé. Un plan vaut la peine d’être figé en PDF au moment où il est approuvé, et vaut la peine d’être conservé modifiable avant cela : exporter votre propre copie au bon moment est donc mieux que de partir d’un fichier fixe.

Existe-t-il une version PPT pour le deck de lancement ?

Le deck est un document différent, avec un rôle différent. Six slides suffisent généralement : le résultat, la fenêtre de livraison issue de votre calendrier des contraintes, le périmètre inclus et exclu, les jalons, les dépendances externes nommées, et qui décide de quoi. Ne mettez pas le découpage du travail dans le deck. Personne ne lit une barre de Gantt sur un projecteur.

Puis-je le télécharger gratuitement ?

La structure, le tableau des éléments non négociables et l’exemple concret sont gratuits et sans restriction. Utilisez-les, modifiez-les, puis mettez-les dans votre propre bibliothèque de modèles sous votre nom.

Un plan de livraison de projet est-il identique à un plan de projet ?

Assez proche pour que la distinction ne serve presque jamais. Lorsque les organisations les séparent, le plan de projet couvre toute la vie du projet, y compris le business case et la clôture, tandis que le plan de livraison ne couvre que la partie construction et mise en production. Si votre gouvernance demande les deux, rédigez le plan ci-dessus et traitez les sections 5 à 9 comme le plan de livraison.

Ai-je besoin aussi d’un modèle séparé de rapport de gestion de projet ?

Oui, et gardez-le beaucoup plus court que ce que vous imaginez. Un rapport de statut qui répète le plan est ignoré au bout d’un mois. Renseignez quatre éléments : un élément non négociable a-t-il bougé, la fenêtre est-elle toujours assez large, quelle décision avez-vous besoin de ce groupe aujourd’hui, et quel déclencheur est apparu dans la liste des risques depuis la dernière fois.

À quel niveau de détail faut-il un plan de projet IT ?

Suffisamment détaillé pour qu’une nouvelle personne puisse comprendre ce qui se passe ensuite, et pas plus. En pratique, le document de plan dure environ huit à quinze pages pour un projet de neuf mois, dont la plupart sont les sections 8 et 9. Si le document est plus long que le runbook de basculement, l’équilibre est mauvais.

À quelle fréquence faut-il mettre à jour le plan ?

Les sections 6 et 7 changent chaque semaine et doivent être là où votre équipe travaille déjà. Les sections 1 à 5 doivent changer rarement, et chaque modification doit être approuvée par quelqu’un. Si votre section périmètre est modifiée discrètement chaque semaine, vous n’avez pas un plan : vous avez un journal.