Lorsque l’on a travaillé plusieurs années dans la gestion de projet, il n’est pas nécessaire de nous convaincre de la valeur qu’elle apporte à l’entreprise.
Néanmoins, il y a encore et toujours des questionnements concernant l’utilité des chefs de projet, de la structure de projet, notamment pour les « petits » projets.
Lorsque les initiatives sont de courtes durée et proches des activités quotidiennes des Opérations, il est pertinent de se demander : faut-il envisager un projet et un chef de projet ?
Voyons donc les différences entre le RUN (Opérations) et le BUILD (Projets), rappelons la valeur ajoutée par un projet et un chef de projet, et examinons les critères pour catégoriser les initiatives et activités ainsi que le moment approprié pour mettre en place un projet.
Différence entre le RUN (Opérations) et le BUILD (Projets)
Examinons d'abord la différence entre le RUN (Opérations) et le BUILD (Projets).
Prenons l’exemple de l’Informatique, et le raisonnement est valable dans d’autres domaines.
Dans une entreprise, nous avons basiquement deux fonctions :
1) Opérations (RUN)
Les opérations, appelée RUN, consiste à maintenir les systèmes et équipements en bon fonctionnement.
Ce sont des tâches quotidiennes nécessaires pour maintenir en marche les systèmes et les processus d'une organisation, y compris :
- La surveillance
- La maintenance
- La résolution de problèmes
- La gestion des incidents
Un incident est résolu par une correction rapide, parfois appelée Fix. C’est urgent, car la bonne opération de l’organisation en dépend.
- Cela rentre dans le cadre du BAU (Business As Usual).
- Les équipes Opérations et Support sont dédiées à traiter ce genre de sujet.
- C’est une correction réalisée très rapidement dans un cadre Opérations.
Lorsqu’un incident est récurrent, on a affaire à un problème.
Parfois, la solution définitive n’est pas immédiate.
Elle nécessite une analyse de la situation et demande une solution plus élaborée.
En fonction de l’urgence et de la taille de la correction, on peut se poser la question si cela doit être fait :
- Par les équipes support
- Ou sous la forme d’un projet
2) Projets (BUILD)
Et vous avez les équipes dites « Projets », encore appelées BUILD.
Ce sont ici les activités liées aux Projets, Programmes et Portefeuilles.
Le sujet aujourd’hui est de savoir quand nous devons créer une structure projet, et quand les activités peuvent être effectuées de manière autonome.
Cela dépend d’une part du type d’activité, mais aussi du degré de maturité des organisations en termes de méthodologie de gestion de projet, de gestion de service informatique et de gouvernance.
Quand mettre en place un projet vs opérations ?
Dans un monde idéal ou stable, tout se passe bien.
Les systèmes, services et produits fonctionnent correctement et produisent ce pourquoi ils ont été conçus.
Dans la réalité, cela ne se passe pas exactement comme cela :
- Des incidents se produisent. S’ils sont récurrents, on les appellera ensuite des problèmes.
- Dans le cadre d’une approche Kaizen, d’amélioration continue, on cherchera à toujours faire mieux et donc améliorer les systèmes, produits et services.
- Enfin, on peut vouloir faire quelque chose de nouveau, innover.
Voici quelques exemples pour mieux comprendre :
Qu'en est-il des améliorations ?
Très souvent, des améliorations possibles sont mises en avant par :
- Le retour d’expérience utilisateur.
- L’observation du fonctionnement des systèmes, produits et services.
Rien à voir avec la correction d’incident ou de problème, tout simplement une amélioration.
On peut également avoir des demandes d’un point de vue légal :
- Changement d’un calcul d’impôt ou de taxe.
- Changement d’une règle de sécurité.
- Nouvelle réglementation.
Tout ceci implique des changements qui devront être étudiés, organisés et exécutés.
Dans ce cas, la première analyse penche vers une structure projet.
Une petite correction ou amélioration qui doit être faite à grande échelle peut rapidement devenir complexe.
L’analyse de l’activité ponctuelle peut être très simple, mais le facteur échelle va rapidement demander une analyse plus complexe.
Qu’apporte un projet, un chef de projet ?
Non, ce n’est pas de la provocation.
Pour pouvoir convaincre de la valeur apportée par une structure projet et l’action d’un chef de projet, il est bon de revoir les bases, pour parfois accepter que cela n’est pas nécessaire.
1) Valeur ajoutée
Une structure projet permet essentiellement d’ajouter de la valeur dans les sujets suivants :
- Planification : possibilité d’avoir une vision globale des activités, d’élaborer un plan d’action, d’estimer la durée et d’accompagner l’exécution
- Coordination : à partir du moment où plusieurs personnes travaillent ensemble, on arrive rapidement à la nécessité d’organiser le travail des équipes.
- Communication : Le chef de projet est le point de contact principal pour toutes les parties prenantes du projet, y compris les membres de l'équipe, les clients et les fournisseurs. Il est responsable de la communication efficace entre toutes les parties prenantes.
- Gestion des coûts : toute activité implique un coût, et il est indispensable d’avoir une estimation des coûts et un suivi.
- Qualité : Définition des normes de qualité, mise en place de processus de contrôle de la qualité et garantie que les livrables répondent aux normes de qualité.
2) Gouvernance et coûts supplémentaires
La mise en place d’un projet implique suivre une méthodologie, si légère qu’elle soit, une gouvernance et l'affectation d'un chef de projet.
Cela implique donc des délais et des coûts supplémentaires.
Les détracteurs de l’utilisation d’un projet diront que c’est lourd, lent et cher et que cela n’apporte pas grand-chose ; autant exécuter directement.
Si projet il y a, il est nécessaire d’en définir le périmètre, la durée et le budget.
De plus, il faut que le tout soit approuvé pour que l’on puisse commencer dans de bonnes conditions.
Tout ceci implique du temps, de l’énergie et de l’argent.
Du fait de la présence du chef de projet, un projet coûte plus cher que la somme des activités, services et matériels pour répondre à la demande.
Dans certains cas, on peut se demander si la présence de coordination et de suivi est vraiment nécessaire, soit pour des activités simples, soit pour des équipes autonomes et responsables.
Un exemple intéressant : les déménagements de bureau !
Très souvent, il est considéré qu’un déménagement de bureau ne demande pas de structure projet :
Il suffit de faire une demande d’accès internet et téléphonique, préparer les tables et les points réseau (ou le Wi-Fi), et chaque personne déménage son propre ordinateur !
Dans la pratique et dès que l’on a une dizaine de personnes à déménager, il est préférable d’avoir un chef de projet pour coordonner la chose :
- Confirmer le bon fonctionnement de l’accès internet et du réseau,
- S’occuper des périphériques (imprimantes, salle de Visio…)
- Coordonner le déménagement.
Quand tout se passe bien, excellent ; mais au moindre problème, s'il n’y a personne à qui faire appel, cela peut créer des heures, voire des jours d’indisponibilité !
Project or not project, that is the question !
L’objectif d’une organisation est de produire de la valeur par l'intermédiaire de produits et de services, de manière efficace.
On doit donc s’interroger sur la meilleure manière de produire une amélioration sur un système, produit ou service.
1) Les Opérations, le RUN
Nous sommes d’accord que la correction d’erreurs, d’incidents qui portent préjudice à l’opération de l’organisation doivent être exécutées de manière rapide et immédiate, par une structure opérationnelle de support efficace.
C’est le RUN, le Business as Usual.
Pas de débat.
Ce genre d’activité doit suivre des procédures de gestion de changement, très bien décrites dans les frameworks décrits par le CobIT ou ITIL.
2) Les nouveautés, les déploiements de nouveaux services et produits
D’un autre côté, vouloir développer un nouveau produit ou un nouveau service « de zéro » est clairement l’objectif d’un projet.
Nous parlons ici de :
- Plusieurs mois de travail
- Equipe de plusieurs personnes
- La valeur à délivrer
- Des budgets
- Des plannings à suivre
Ici non plus, pas de débat : nous parlons de projet !
3) Patch, améliorations « petits » projets
Abordons maintenant ce qu’il y a entre les deux, et qui crée parfois des polémiques :
- A partir de quand mettons-nous en place une structure de projet ?
- Et quand ce n’est pas un projet, mais ce n’est pas une activité BAU non plus, comment fait-on?
Certaines activités initialement RUN comme les petites mises à jour, des corrections importantes peuvent s’avérer plus complexes et demander une étude préalable et de la coordination.
Certaines activités, clairement définies comme projet, sont tellement simples, maîtrisées que l’on peut se demander l’utilité d’une approche projet.
À la frontière entre le BUILD et le RUN, on doit donc se poser des questions et définir des critères de décision.
4) Notion de « petits projets »
On peut appeler « petit projet » des activités ayant les caractéristiques suivantes :
- Effort de moins de 200-300 heures
- Affecte un seul système ou composant
- Technologie maîtrisée
- Coût modique (< 20 000 €) par exemple
- Équipe d’au maximum 3 ou 4 personnes
- Durée totale inférieure à un mois.
Qu'est-ce que cela implique ?
- Documentation minimale, correspondant à une brève description du périmètre, un plan d’action, un plan de test et des critères d’acceptation.
- Pas de chef de projet formellement affecté ; on peut imaginer une structure dans laquelle une personne est responsable de dizaines d’activités de la sorte, n’intervenant que si nécessaire.
- Un processus d’approbation, d’exécution et d’acceptation rapide et efficace.
5) Comment sélectionner ?
Une fois les concepts de RUN, « petits projets » et BUILD clairement décrits et identifiés, il faut mettre en place la gouvernance et communiquer le concept.
Idéalement, toute demande, que cela soit la solution d’un incident, une petite amélioration, ou un « gros » projet, devrait être fait par une seule « porte d’entrée ».
Un ensemble simple de critères doivent pouvoir orienter la demande vers la gouvernance correspondante.
Ensuite, le demandeur devrait être fréquemment informé de l’état d’avancement de sa demande.
Conclusion
Pour des raisons de bon sens, d’efficacité et d’optimisation des coûts, tout ne peut pas systématiquement faire l’objet d’un projet.
Il est donc important de clairement séparer les activités RUN (Opérations) du BUILD (Projets) et définir le plus clairement possible la distinction entre les deux.
Et ceci en ce qui concerne certaines activités plus complexes que des simples corrections, mais n’ayant pas la taille suffisante pour être classifiée comme projet.
Les critères définis ci-dessus sont des exemples, et la réflexion doit être faite pour chaque organisation, en fonction de la technologie, de la taille de l'organisation et du degré de maturité en termes de gestion de projet et d'opérations.
Un point essentiel : on peut alléger l’approche en ne suivant pas complètement une méthodo de projet ; néanmoins il sera toujours nécessaire de structurer l’approche et la tendance alors sera de suivre des frameworks plus opérationnels tels que ITIL, DevOps ou CobIT.
