Matrice de priorisation des projets : classer, puis décider

Le CRM arrive en tête du classement. Une obligation de conformité obtient moins de points. Faut-il pour autant la reporter ? Une matrice utile à la DSI doit montrer les critères, les contraintes et les conséquences du choix. Le total aide à discuter ; il ne décide pas quels projets peuvent démarrer.

Télécharger une matrice remplie et modifiable

Télécharger la matrice de priorisation des projets (Excel). Accès libre : paramètres, projets, capacité, décision et mode d’emploi. L’exemple est fictif. Remplace les notes, poids, sources et estimations avant de l’utiliser pour ton portefeuille.

Séparer recevabilité et priorité

Une demande recevable a un sponsor, un résultat attendu, une échéance expliquée et une première estimation. Si ces éléments manquent, la bonne décision peut être d’instruire la demande. Lui attribuer artificiellement zéro mélange une absence de données avec une absence de valeur.

Le guide de qualification des demandes prépare cette première étape. La matrice intervient ensuite : comparer les projets instruits en rendant les désaccords explicites. Une obligation ou une dépendance est examinée séparément du score.

Choisir les critères avant de connaître le gagnant

Pour cet exemple, quatre critères sont notés de 0 à 5 : valeur attendue, alignement stratégique, urgence justifiée et confiance dans les informations. Les poids illustratifs sont 40, 30, 20 et 10. Ce ne sont pas des poids universels : la direction les adapte à ses décisions et note pourquoi.

Le score sur 100 vaut la somme des notes multipliées par leurs poids, divisée par la somme des poids, puis multipliée par 20. Une note manquante affiche « À renseigner » dans le fichier. Ne compense pas un doute en ajoutant des décimales : une précision de calcul ne rend pas l’hypothèse plus fiable.

Lire un classement sans oublier les obligations

Le CRM est premier, l’automatisation deuxième. La conformité reste pourtant à traiter si son obligation est confirmée. Demande aux sponsors de valider les critères et leurs preuves avant de discuter les projets. Si une pondération change, conserve le motif et compare les deux classements.

Confronter le choix à chaque équipe

Après run et engagements existants, Data dispose de 20 jours, Sécurité IT de 10 et QA de 18. Les trois demandes réunies exigent 22 / 10 / 21 jours. Accepter les trois produit donc deux goulots. Ni le score, ni la capacité totale additionnée ne les suppriment.

Conformité + CRM consomment 14 / 8 / 15 jours : marges 6 / 2 / 3. Conformité + automatisation consomment 12 / 9 / 14 : marges 8 / 1 / 4. Les deux options laissent une marge, mais ne créent pas les mêmes résultats métier. Le cas capacitaire détaille ces conséquences.

Consigner le lancement, le report ou l’instruction

Dans l’exemple, les sponsors retiennent conformité + CRM et reportent l’automatisation. Ce choix traduit une priorité validée, pas un automatisme du tableur. La décision indique le décideur, la date, le motif, le projet reporté et la condition de réexamen. Le journal rempli du fichier est modifiable.

Fais confirmer la dépendance Data avant recette QA et la contrainte réglementaire. Si une estimation change ou si le coût du report devient inacceptable, rouvre les options. Conserve aussi le scénario écarté : il explique ce que la direction a accepté de perdre ou de décaler.

Passer d’un fichier à une décision partagée

Le fichier permet de préparer un arbitrage. Quand plusieurs directions actualisent demandes, capacités et décisions, vérifie comment ton outil conserve leur cohérence. Dans une démo AirSaas, fais qualifier une demande, comparer les options et retrouver le motif du report. Ne suppose pas qu’un score reproduit automatiquement votre processus de décision.