Comment engendrer le CHAOS à la DSI dans votre outil de gestion de projet lors de la saisie des temps passés ?

Commençons par rappeler à quoi correspondent les différentes notions de BUILD, CAPEX, CHANGE RUN, OPEX :

BUILD ou CAPEX : Il s’agit d’un investissement avec des activités de construction, de développement du système d’information ou d’activités Projet, Maintenance évolutive, …On attend un retour sur investissement à la suite de la mise en place d’activités de BUILD.

RUN ou OPEX : il s’agit des activités d’exploitation du système d’information (MCO : Maintien en condition opérationnelle, Maintenance corrective, Cout des infrastructures, Maintenance Logicielle, …)

Aujourd’hui, beaucoup de DSI s’appuient sur un modèle de gestion où se répartissent les activités entre le monde du Projet : BUILD, CAPEX, CHANGE et le Hors-projet : RUN, OPEX.

Ce découpage est souvent réalisé à la demande de la direction financière ou du contrôle de gestion, à des fins de consolidation et de reporting avec les autres entités de l’entreprise.

La structuration des activités est aussi un enjeu pour le manager à des fins d’analyses de l’activité de son équipe. Les indicateurs attendus par un responsable d’équipe et pour le contrôle de gestion, ne sont pas forcément les mêmes : Attention !

La mise en place de la répartition des activités entre le BUILD et le RUN, permet de connaitre les coûts en jours*hommes ou en Euros des activités récurrentes à la DSI.

Ce modèle permet d’établir le budget de la DSI et de le repartir entre les 2 postes BUILD ou RUN.

La répartition entre les activités projet et les activités récurrentes contribue à l’identification de risques quant à la maîtrise du système d’information.

Trop de Build = Perte de la maitrise de son SI !

Aussi, attention à éviter la construction de modèles complexes, ils ne seront pas pérennes et ils seront d’autant plus fastidieux à faire évoluer.

En général, le RUN représente le plus souvent 50% des coûts Informatiques et le BUILD 50% également.

Ensuite c’est toujours la même chanson, les dépenses du SI relatives aux coûts récurrents sont toujours trop élevés et généralement revus à la baisse en cours d’année, malgré la pression du Métier qui veut toujours plus de projets de transformation digitale et de Cloud ! L’arbitrage va consister en l’arrêt de certains projets et cet exercice est plus aisé si l’on dispose d’un outil de gestion de portefeuilles de projet, mais nous nous éloignons de notre sujet.

Concrètement sur le terrain, comment cela se passe-t-il ?

Vous avez un outil de PM/PPM dans lequel vous suivez l’ensemble de vos projets en cours et des projets potentiels à venir.

Chaque année dans l’outil vous rentrez le hors projet, c’est-à-dire le RUN avec un découpage en Projets (parfois dénommés « pseudo-projets ») et Activités avec parfois des budgets associés pour chacun de vos projets, voire pour chacune de vos activités de vos projets.

Ce découpage est souvent structuré par ce qu’attend le contrôle de gestion afin de pouvoir éditer des analyses qu’il remontera à la Direction.

On va retrouver par exemple un projet « Management » structuré lui-même en activités, Management de l’équipe A, Management de l’équipe B, … ou un projet par Management par équipe avec une activité par projet : Chacun son budget !

On y retrouvera aussi un projet « Formation », avec pour chaque activité, chaque formation prévue cette année.

Enfin, dans les DSI, on y retrouvera des projets de « support » et de « maintien en condition opérationnelle. » C’est à ce type de projet qu’il faut faire attention lorsque l’on les structure. Attention à la maille, surtout ne pas descendre trop finement sous peine d’enfer pour une personne qui devra saisir ses temps passés.

Cette structuration doit refléter l’activité d’une équipe. Le découpage de ce type de projet n’est pas là que pour servir de la donnée au contrôle de gestion. Elle permet aussi une analyse de l’activité par un responsable d’équipe.

Ce type de projet doit permettre à un responsable de piloter l’activité de son équipe et de permettre à chacun de saisir ses temps passés à la semaine en moins de 10/15 minutes. Si vous y passez plus de temps, c’est sans doute lié à un problème de structuration de vos projets RUN et des activités qui s’y trouvent.

Après des années passées sur le terrain à observer chez mes clients comment les projets étaient structurés, je suis aujourd’hui convaincu que le diable est dans le détail.

Saisir ses temps c’est déjà pénible, si en plus c’est compliqué, alors c’est sûr il y aura des réfractaires et potentiellement abandon de l’outil, alors que souvent ce dernier n’y est pour rien.

J’ai pu constater des projets de MCO (Maintenance en Condition Opérationnelle) structurés par ticket, avec des interfaces qui créait des activités sous le projet pour chaque ticket créé. Imaginez à la fin de l’année, le nombre d’activités sur le projet !

Imaginez une personne qui doit faire sa saisie et qui cherche son ticket pour pouvoir y pointer 1 heure, Imaginez les autres heures de la semaine à saisir ! Il est plus sain d’organiser autrement ce type de projet.

Pourquoi ne pas avoir des activités de type : MCO sujet A, MCO sujet B, …,

Ainsi, on sera capable de produire le coût de la MCO par périmètre, plutôt que de compter le nombre de tickets ouverts.

Non, un outil de PM/PPM n’est pas un outil de ticketing.

Pour que la complétude des saisies des temps passés se passe bien et tangente les 100%, il faut pouvoir la réaliser en moins de 10 minutes.

J’ai vu aussi le contraire, avec une équipe de chasseurs à complétude des saisies des temps passés, avec des personnes qui souhaitent saisir, mais qui n’ont ni projet, ni activité sur lesquels pointer.

Bref il y a un juste milieu à trouver, un peu de détail, mais pas trop et surtout rester à l’écoute des utilisateurs qui rencontrent des difficultés dans leurs saisie chaque fin de semaine, afin de pouvoir prendre les mesures adéquates si c’est possible et éviter à terme l’abandon de l’outil.