Le processus de tests : étape clé d’un projet de Système d’Information 2 / 2

4
Le processus de tests : étape clé d'un projet de Système d’Information 2 / 2

Le processus de tests (ou qualification ou phase de recette) d’un projet de Système d’Information (SI) correspond à l’étape à l’issue de laquelle le client reconnaît que le produit livré par le fournisseur est conforme à la commande passée et aux attentes formulées par les utilisateurs, et qu’il est exploitable dans l’architecture des SI de l’entreprise.

Cette phase, dernière étape avant la mise à disposition des utilisateurs, vise au travers de multiples tests, à garantir le bon fonctionnement de la solution, et obtenir la satisfaction du client.

A ce titre, le processus de tests est une étape clé d’un projet de Système d’Information.

 

Pour cela, tel un « projet dans le projet », la phase de tests se décompose en 2 grandes étapes :

  • la préparation, permettant de bâtir une stratégie de tests basée sur les exigences fonctionnelles initialement collectées, et de planifier les différentes activités associées sans négliger la logistique nécessaire à une réalisation dans de bonnes conditions ;
  • la réalisation, dont l’objectif est de mener les tests prévus, d’identifier les anomalies et/ou demandes d’évolutions, et de les prioriser et les corriger en vue de la prochaine série de tests.

Après vous avoir présenté la phase de préparation des tests (ou qualification ou phase de recette) dans un premier article, nous vous proposons un second et dernier article pour présenter l’étape de réalisation des tests.

LA REALISATION DES TESTS

Quand le cahier de tests est fourni, que l’environnement de tests est opérationnel et doté de jeux de données pertinents, et enfin (surtout) que les développements ont été réalisés, les tests fonctionnels peuvent démarrer.

En théorie, une fois la recette d’usine (réalisée par le fournisseur du service) terminée et que le produit a été jugé conforme, il est livré au client pour test, sur un environnement dédié. Le client entame alors une phase de recette de son côté, avec sa propre méthodologie.

Exécution des tests

L’exécution des tests est généralement mixte : manuel et automatisé. Les tests manuels sont exécutés selon les scénarios prévus par une équipe de recette voire directement par la maîtrise d’ouvrage (membres de l’équipe projet ayant participés aux spécifications du besoin, utilisateurs finaux…), et les tests automatisés sont exécutés par des outils dédiés.

Les cahiers de recette sont alors actualisés avec les résultats des tests menés.

Si des anomalies sont détectées par les tests manuels ou automatisés, elles sont tout d’abord qualifiées (est-ce réellement une anomalie ou simplement une mauvaise utilisation d’une fonctionnalité ? est-ce une nouveauté non exprimée / une évolution souhaitée ?) et, le cas échéant, leur résolution est priorisée et prise en charge par les équipes de Maîtrise d’œuvre.

Validation de la conformité – VABF et VSR  (standard ITIL)

La phase de recette a pour but d’évaluer la capacité à basculer en production un Système d’information dans de bonnes conditions. Pour permettre cette évaluation, il est important de définir les critères et seuils attendus pour garantir une mise en production réussie :

  • Taux de couverture des fonctions ou des processus métiers
  • Taux de couverture des règles de gestion
  • Taux de réussite des tests
  • Nombre de défauts mineurs, majeurs et bloquants

Quand le client estime que le produit a atteint un niveau de conformité suffisant, il prononce la VABF (Vérification d’Aptitude au Bon Fonctionnement), qui permet de déployer le système sur une unité pilote de production. Généralement, une phase « d’hypercare » intervient après bascule en production. Cette phase vise à assurer un soutien renforcé aux clients durant la période de stabilisation, et ainsi garantir une transition en douceur entre la phase du projet et la phase opérationnelle.

Cette étape est gérée de façon relativement différente en fonction du contexte du projet, des exigences du client, etc.

Lorsque toutes les ajustements et corrections nécessaires ont été apportés, le client prononce la VSR (Vérification de Service Régulier), qui autorise la mise en exploitation globale de la solution. Le projet est alors terminé.

Nous avons donc :

  • VABF = Recette / tests de la solution sur un environnement de tests avant le passage en production ;
  • VSR = Support / Hypercare en Production jusqu’à la fin des ajustements post démarrage.

Le pilotage de la recette

Pour s’assurer du bon déroulement des tests et de la validation de la conformité de la solution avant la date de bascule en production, il convient d’assurer le pilotage de la phase de recette.

Ce pilotage se traduit notamment par :

  • la définition d’objectifs échéancés de réalisation des tests,
  • la définition des seuils de qualité souhaités à chaque phase du projet (recette unitaire, recette intégrée…), pouvant donner lieu à la signature de Procès-Verbaux,
  • la prise en compte et la planification d’une phase de corrections d’anomalies et de rejeu des tests « KO »
  • la définition et la formalisation du processus de réalisation des tests : disponibilité des jeux de données, mise à jour des cahiers de recette, récupération / centralisation des remarques / anomalies / évolutions identifiées, définition des priorités, suivi du traitement des anomalies / évolutions …
  • la définition et mise en œuvre d’indicateurs permettant de piloter l’avancement de la recette sur l’ensemble des fonctionnalités de la solution au regard des objectifs qualité et délais définis,
  • le pilotage de la recette avec des points périodiques d’avancement pour s’assurer que le planning de déroulement des tests est respecté, et pour mettre sous contrôle la correction des anomalies éventuelles.

IM Projet accompagne les entreprises dans le pilotage de la phase de recette des projets de Systèmes d’Informations (SI) pour garantir la capacité à évaluer les conditions de bascule en production selon le planning établi.

Le processus de tests : étape clé d’un projet de Système d’Information 1 / 2

4
Le processus de tests : étape clé d'un projet de Système d’Information 1 / 2

Le processus de tests (ou qualification ou phase de recette) d’un projet de Système d’Information (SI) correspond à l’étape à l’issue de laquelle le client reconnaît que le produit livré par le fournisseur est conforme à la commande passée et aux attentes formulées par les utilisateurs, et qu’il est exploitable dans l’architecture des SI de l’entreprise.

Cette phase, dernière étape avant la mise à disposition des utilisateurs, vise au travers de multiples tests, à garantir le bon fonctionnement de la solution, et obtenir la satisfaction du client.

A ce titre, le processus de tests est une étape clé d’un projet de Système d’Information.

Pour cela, tel un « projet dans le projet », la phase de tests se décompose en 2 grandes étapes :

  • la préparation, permettant de bâtir une stratégie de tests basée sur les exigences fonctionnelles initialement collectées, et de planifier les différentes activités associées sans négliger la logistique nécessaire à une réalisation dans de bonnes conditions ;
  • la réalisation, dont l’objectif est de mener les tests prévus, d’identifier les anomalies et/ou demandes d’évolutions, et de les prioriser et les corriger en vue de la prochaine série de tests.

Nous vous proposons un premier article pour présenter l’étape de préparation.

LA PREPARATION DE L’ETAPE DE TESTS

Toutes les directions informatiques ou métiers connaissent l’importance des tests, notamment pour garantir la mise en œuvre d’une solution de qualité et répondant aux besoins des utilisateurs. Aussi, négliger le temps et les ressources nécessaires à la préparation de la phase de recette revient à négliger l’importance de cette étape du projet.

Cette phase de préparation, réalisée très tôt dans le cycle de vie du projet, a pour objectif de poser les règles du jeu de la phase de recette et de s’assurer que toutes les conditions nécessaires à sa réussite sont réunies. La phase de préparation se décompose en deux étapes :

  1. La définition de la stratégie de tests ;
  2. La mise en œuvre des prérequis à la réalisation des tests.

La définition de la stratégie de tests :

La stratégie de tests vise à identifier l’ensemble des niveaux de tests à réaliser (tests unitaires, tests d’intégration, tests d’exploitation, tests de non régression, validation des données, rôles et autorisations, tests de performance, QI, QO, QP,…) et, pour chacun d’eux, à définir :

  • les objectifs,
  • les prérequis (organisationnels, techniques,…) à la réalisation des tests,
  • le planning de réalisation des tests,
  • les rôles et responsabilités,
  • les modalités de réalisation et de pilotage des tests,
  • les critères d’entrées et de sortie (d’un niveau de tests à l’autre)

Chaque intervenant a son propre vécu et vocabulaire (recette usine, FAT, VABF, end to end,…). Il est primordial, pour la réussite du projet, de formaliser et expliquer la stratégie de tests et ses différents termes.

La mise en œuvre des prérequis à la réalisation des tests :

La mise en œuvre des prérequis à la réalisation des tests vise à garantir les moyens nécessaires à la réalisation des tests prévus :

  • un (des) environnement(s) opérationnel(s) disponible(s),
  • les ressources nécessaires (au pilotage et à la réalisation des tests) :
    • quantifiées par profil,
    • formées,
    • mobilisées selon le planning défini
  • des cahiers de recette formalisant
    • les modalités de tests (environnements, terminaux [smartphone, laptop, etc.], navigateurs,
    • les populations et cas de tests à dérouler,
    • l’ordonnancement et la description des tests à mener,
    • le résultat attendu et les seuils de validation des tests
  • des jeux de données / d’essais représentatifs de ce qui sera rencontré en production,
  • des outils opérationnels permettant le pilotage de la réalisation et le suivi de la qualité des tests

L’alimentation des cahiers de recette doit, idéalement, être réalisée au fur et à mesure que les spécifications fonctionnelles sont réalisées / validées. En effet, les cas de test se fondent sur les configurations d’utilisation de l’application, et ces configurations d’utilisation sont identifiés, formalisés et documentés en phase de spécification fonctionnelle.

La recette doit être industrialisée, c’est à dire reposer sur des process clairement établis et documentés, et permettre de produire des résultats d’avancement (rapports de tests, création d’entrées dans un outil de ticketting, etc.) et de niveau de qualité (en termes de performances, de qualité des données, de respect des spécifications, d’interface homme-machine, etc…).

Cette étape de préparation de la recette n’est pas aussi simple qu’elle n’y parait, et est souvent négligée. Elle permet de :

  • structurer la recette, pour éviter le désordre qui coûte de l’argent,
  • garantir l’exhaustivité et la bonne réalisation des tests, pour éliminer le stress lié à l’incertitude.

IM Projet accompagne les entreprises dans la démarche de structuration et de planification de cette étape cruciale des projets de Système d’Information (SI).

Fusions-Acquisitions : des projets comme les autres

4
Fusions-Acquisitions : des projets comme les autres

Les fusions-acquisitions s’accélèrent

Pour la première fois en 2021, le marché mondial des fusions-acquisitions a passé la barre des 5 000 milliards de dollars (4 410 milliards d’euros), atteignant un montant total de 5 650 milliards de dollars selon Dealogic. Cette tendance est partie pour durer en 2023.

La décision des entreprises de reprendre un concurrent ou une activité complémentaire, répond souvent à un besoin d’internationalisation, de développement rapide et de réduction des coûts, appuyé par la pression concurrentielle.

Cette décision est souvent prise avec le soutien de banques d’affaires et de cabinets de conseil en stratégie (voir étapes 1 et 2 du schéma ci-dessous). Mais que faire une fois la décision prise pour réussir l’acquisition et la fusion ?

Les conditions de la réussite : une approche en mode projet

Les opérations de fusions, quel que soit le type d’activité, font appel à de nombreuses compétences : RH, IT, économiques et financières, marketing et commerciales, techniques, … De plus la décision de l’acquisition est prise sur la base d’un business plan qui définit les grandes lignes d’un plan de transformation, les objectifs en termes de délais, de coûts, de performance et de retour sur investissement.

Quoi de plus logique pour conduire ce plan de transformation et atteindre les objectifs fixés que de se mettre en ordre de marche via une structure projet :

  • Une Direction de Projet structurée et mobilisée
  • Une organisation spécifique regroupant les expertises nécessaires à mener les actions
  • Une gouvernance projet adaptée aux enjeux de la fusion
  • Un plan d’actions défini sous forme de plannings selon différents niveaux de détail, en fonction des populations concernées, du niveau décisionnel à l’opérationnel
  • Un dispositif de contrôle de l’avancement régulier pour mettre en place au plus tôt les actions correctives en cas de dérive éventuelle
  • Un reporting axé sur le traitement des points critiques et la prise de décisions

IM Projet : le PMO de vos projets de fusions-acquisitions

Dans les opérations de fusions-acquisitions, il est nécessaire de mobiliser des compétences métiers clés, indispensables pour réaliser ou piloter les actions de transformation. La mise en place d’un PMO externe, au-delà d’une meilleure maitrise de l’avancement, permet de pleinement mobiliser ces ressources internes sur leur fonction et sur des actions à forte valeur ajoutée qu’elles seules peuvent réaliser.

Dès confirmation de votre décision d’acquisition, n’hésitez pas à contacter IM Projet qui pourra vous accompagner dans l’organisation, la planification et le pilotage de votre projet.

Son expérience sur ce type de projet, et son approche collaborative, où les référentiels projet sont construits avec la participation active de toutes les parties prenantes, permettent de fiabiliser l’information, de bâtir un plan d’actions structuré et exhaustif, et d’apporter une dynamique de pilotage indispensable pour réussir ce type de projet.

IM Projet peut aussi vous accompagner dans la préparation de la séparation de vos activités (adaptation du SI notamment) au préalable d’une vente : Carve Out.

YposKesi reinforces its skill in project management with the support of IM Projet

4
YposKesi reinforces its skill in project management with the support of IM Projet

Early 2022, Yposkesi launched an initiative to improve the management of its projects. It started with the rationalization of its project’s portfolio with the selection of key projects, the implementation of a “Portfolio Steering Committee” and basic tools to have an overview of the progress of the projects. This organization eases arbitrations between projects to fit with the company priorities and development strategy.

Following this initiative, Yposkesi performed, with the support of IM Projet, training in project management for most of its employees. The objectives of this training were:

  • To present good practices in project management, methodologies, and simple tools;
  • To develop a stronger project management culture within Yposkesi;
  • To share methods and a common vocabulary in project management.

All levels of responsibility (executive committee, project managers, work package managers, …) attended the training from June to October 2022.

To do so, IM Projet prepared a tailored training combining Yposkesi procedures, tools, and best practices in project management and the know-how of IM Projet. IM Projet regularly performs training sessions in project management for its clients, based on its operational experience of PMO (Project Management Officer) assignments in various fields.

Yposkesi is now better armed to drive its projects, internal or business projects as a CDMO for cell and gene therapy viral vector manufacturing.

About Yposkesi

Yposkesi, a SK pharmteco company, is one of Europe’s largest Contract Development and Manufacturing Organizations (CDMO) for cell and gene therapy viral vector manufacturing. A trusted partner for biotech and pharmaceutical companies seeking to advance clinical trials and commercialize new Advanced Therapy Medicinal Products (ATMPs), Yposkesi offers a full range of services in lentiviral vectors and AAV (Adeno-Associated Virus) cGMP manufacturing.

About IM Projet

IM Projet is a consulting company specialized in project management. Created in 1989, IM Projet has a 25M€ turn over, 160 engineers, is located in France (Lyon, Paris, Marseille and Bordeaux), Switzerland (Geneva) and Monaco. IM Projet works on any kind of projects: industrial projects (factory construction, renovation or site extension, new products development), buildings, transportation and urban development, information systems.

Gestion de Projet : « Cycle en V » ou « Agile » ? 3 / 3

4
Gestion de Projet : « Cycle en V » ou « Agile » ? 3 / 3

Vous devez mener un projet et vous entendez parler de méthodes « Agile » et « Cycle en V » … mais vous ne savez pas quelle méthode employer, celle qui fera de votre projet une réussite ?

 

Les uns vous diront que la méthode dite du « Cycle en V » est une méthode sérieuse et rigoureuse, incontournable pour mener un projet complexe faisant intervenir de multiples acteurs et compétences.

Les autres vous assureront que les méthodes Agiles sont miraculeuses et vous permettront d’aller plus vite avec une garantie de résultat.

La réalité est beaucoup plus nuancée, et la méthode à adopter dépend de plusieurs critères comme le type de produit à réaliser, l’environnement au sein duquel vous allez travailler, les équipes auxquelles vous pouvez faire appel…

 

Suite aux descriptions de la méthodologie du Cycle en V et de l’approche « Agile », en particulier « Scrum », réalisées dans nos deux premiers articles :

vous trouverez dans ce dernier article un éclairage sur le choix de la méthodologie projet à appliquer.

3- Que choisir : « Cycle en V » ou « Agile » ?

Tout dépend du type de projet, des équipes et de l’organisation au sein de laquelle s’inscrit le projet.

« Projet » vs « Produit » :

Là où le « Cycle en V » privilégie une méthode rigoureuse de gestion de projet, Scrum se contente d’être un cadre de travail (« framework ») orienté sur l’adéquation du produit final au besoin du client / des utilisateurs, notamment au travers de présentations du produit et de feedbacks client réguliers pour permettre un ajustement constant du produit.

Ainsi :

  • avec le « Cycle en V », le produit livré répondra à l’expression de besoin définie en début de projet, et il sera nécessaire d’attendre la recette finale pour envisager des modifications du produit ;
  • avec Scrum le produit imaginé en début de projet ne sera pas le produit livré dans 6 ou 12 mois, afin de s’adapter à l’évolution des besoins exprimés par le client / les utilisateurs.

A ce titre, l’approche Scrum ne pourra pas être appliquée au développement de tout type de produit. Il est, par exemple, difficilement envisageable de récupérer sa nouvelle voiture chez le concessionnaire avec des ouvertures de vitres manuelles, en attendant un rappel du véhicule par le concessionnaire pour vous installer les vitre électriques 6 mois plus tard…

Vitesse de réalisation identique :

Certaines entreprises imaginent l’agilité comme une approche permettant de développer un produit beaucoup plus vite… Mais l’agilité et Scrum ne sont pas des « méthodes miracles » permettant d’augmenter la productivité des équipes. Même si l’attrait d’une nouvelle approche peut être source de motivations pour certains, la productivité restera en théorie identique en appliquant Scrum ou le « Cycle en V ».

Ce que permettent l’Agilité et le Scrum est une mise à disposition régulière de fonctionnalités à forte valeur ajoutée, même si la première livraison du produit est incomplète. Cela permet d’obtenir des retours du client / des utilisateurs pour ajuster au plus tôt le produit aux besoins, et d’éviter un produit « obsolète » lors de sa mise en production.

Scrum, une approche simple à comprendre, mais difficile à maîtriser :

Comme précisé précédemment, Scrum se contente d’être un cadre de travail (« framework ») fixant des valeurs et des principes de fonctionnement, mais laisse une liberté dans la gestion de certains aspects du projet, comme la documentation et la qualité technique, sans pour autant les renier. En conséquence, beaucoup d’équipes profitent de cette liberté pour limiter au maximum la documentation et la qualité technique afin de livrer au plus vite… Cela constitue une erreur importante d’interprétation de Scrum, car l’agilité n’a pas pour but de livrer tout au plus vite, mais de livrer régulièrement des fonctionnalités à forte valeur ajoutée, de qualité, et permettant d’être appréciées par le client / les utilisateurs afin de réaliser des ajustements constants (produit évolutif et maintenable). Ainsi, livrer au plus vite en omettant une documentation de qualité (rédigée au fur et à mesure) et une qualité technique irréprochable est l’inverse des principes prônés par l’Agilité.

Scrum, une approche en ligne avec son temps :

Scrum propose une véritable souplesse dans la création d’un produit et de son évolution.

Aujourd’hui, l’accélération du time-to-market est devenue vitale pour un grand nombre d’entreprises. Scrum ne permet pas de livrer le produit final complet plus vite, mais de livrer le minimum acceptable pour lancer le produit, alors que le produit développé en « Cycle en V » ne sera livré que dans sa version finale, complète.

Par ailleurs, Scrum favorise, voire valorise, la communication et l’échange au sein de l’équipe projet en autonomie, dans le respect, et dans une approche d’amélioration continue. Avec l’approche Scrum, l’erreur n’est pas perçue comme négative, mais comme l’opportunité de s’améliorer. En effet, les équipes peuvent rectifier la trajectoire dès l’itération suivante, et ainsi faciliter l’acceptation de l’erreur, qui aura un coût peu significatif.

Ainsi, la souplesse permettant d’adapter rapidement le produit aux besoins et la volonté de collaborer dans un climat de respect et de confiance, au service du produit, font de Scrum, une approche à la mode !

Conclusion :

Scrum propose une approche plus adaptée au contexte actuel qui exige de la réactivité et de la souplesse, mais n’est pas adaptée à tout type de développement de produit, où la méthode du « Cycle en V » reste une référence.

D’autre part, l’esprit du « framework » Scrum est simple à comprendre, mais complexe à mettre en œuvre selon l’organisation et la culture des Entreprises.

Enfin, il est faux de penser que Scrum permet d’accélérer le développement d’un produit : Scrum permet de mettre à disposition régulièrement des fonctionnalités à forte valeur ajoutée, en livrant le minimum acceptable pour lancer le produit, puis en ajustant le produit en fonction des retours du client / des utilisateurs.

En conséquence :

  • Si vous disposez de peu de visibilité sur le besoin précis ou le produit cible et que vous avez la capacité de mobiliser des équipes pluridisciplinaires dans un environnement favorisant la communication et la confiance, vous avez tout intérêt à opter pour une approche Agile.
  • Si votre client ou vous-même possédez une totale maîtrise du produit cible ou du projet, et que vous avez besoin de mobiliser des équipes aux compétences spécifiques, diverses, et que vous pouvez difficilement réunir de manière régulière, vous avez tout intérêt à opter pour une le « cycle en V », qui permet des économies d’échelle intéressantes en traitant l’ensemble du périmètre du projet.

Ainsi, de plus en plus de projets visent à adopter une approche « hybride » entre le Cycle en V et l’Agilité, par la mise en œuvre d’un cycle en V décomposé en plusieurs lots de fonctionnalités homogènes et pouvant être livrés rapidement et régulièrement. Cette démarche permet de mener des projets « contractuellement verrouillés » tout en donnant de la visibilité rapidement et fréquemment sur le produit final. Dans ce contexte, des ajustements au plus tôt sont possibles, tout en restant dans le cadre contractuel fixé des fonctionnalités attendues du produit.

Quelle que soit l’approche de gestion de projet, elle doit être mise en œuvre avec rigueur. Un appui à la Direction de Projet par un accompagnement sur la formation, la mise en œuvre, et le respect de ces méthodes permet de sécuriser les objectifs du projet.

Un bon PMO dans votre dispositif projet répond à ce besoin d’accompagnement.

Gestion de Projet : « Cycle en V » ou « Agile » ? 2 / 3

4
Gestion de Projet : « Cycle en V » ou « Agile » ? 2 / 3

Vous devez mener un projet et vous entendez parler de méthodes « Agile » et « Cycle en V » … mais vous ne savez pas quelle méthode employer, celle qui fera de votre projet une réussite ?

 Les uns vous diront que la méthode dite du « Cycle en V » est une méthode sérieuse et rigoureuse, incontournable pour mener un projet complexe faisant intervenir de multiples acteurs et compétences.

Les autres vous assureront que les méthodes Agiles sont miraculeuses et vous permettront d’aller plus vite avec une garantie de résultat.

La réalité est beaucoup plus nuancée, et la méthode à adopter dépend de plusieurs critères comme le type de produit à réaliser, l’environnement au sein duquel vous allez travailler, les équipes auxquelles vous pouvez faire appel…

 Pour éclairer votre choix, nous vous proposons une série de 3 articles afin de présenter ces deux « méthodes », puis de dresser leurs avantages et inconvénients.

Au regard des avantages et inconvénients du cycle en V présentés dans le premier article, plusieurs alternatives existent, dont l’approche « Agile ».

2- L’Agilité, et en particulier Scrum

Il est de plus en plus courant d’entendre parler de méthodes Agiles. En opposition, entre autres, au modèle en cascade et au Cycle en V, elles se caractérisent par un processus :

  • itératif : répétition d’un cycle d’opérations (contrairement au modèle séquentiel et linéaire). Le projet est affiné au fur et à mesure de chaque itération ;
  • incrémental : construction du produit morceau par morceau jusqu’au rendu final.

Inspirées fortement du Lean Management (élimination des gaspillages, encouragement à l’apprentissage et aux changements, responsabilisation des équipes), il existe plusieurs méthodes Agiles (Kanban, XP et SAFe, …), parmi lesquelles la méthode Scrum rencontre une grande popularité depuis quelques années, puisqu’elle couvre plus de la moitié des projets utilisant l’Agilité.

Le « Framework » Scrum est défini par le « Scrum Guide », et notamment par :

  • des équipes autonomes composées de 10 personnes maximum chacune, autour de 3 rôles :
    • le Product Owner (garant du produit),
    • le Scrum Master (garant de la méthode),
    • l’équipe de réalisation (les développeurs) ;
  • un découpage du temps en sprints, ou cycles de développement ;
  • un découpage des tâches en besoins, fonctionnalités à développer (« user stories » par exemple);
  • des réunions rythmant les sprints, appelées cérémonies Scrum

Ainsi, l’Agilité, et en particulier le Framework Scrum :

  • s’appuie sur un processus itératif et incrémental :
    • avantage : permet d’être plus réactif vis-à-vis des besoins utilisateur, et de maximiser la valeur produite afin de répondre aux exigences de ces mêmes utilisateurs, même si elles évoluent,
    • inconvénient : difficile de concilier avec une contractualisation classique (entre un éditeur de solution informatique et son client par exemple) ;
  • met l’accent sur les individus et leurs interactions, sur des produits toujours opérationnels, et sur la collaboration et l’adaptation au changement :
    • avantage : communication plus fluide pour réaliser un produit adapté au client et opérationnel,
    • inconvénient : ne valorise pas la production de documentation, pourtant utile en cas d’évolution dans les équipes et dans un contexte de changement fréquent du produit ;
  • s’appuie sur des équipes autonomes :
    • avantage : responsabilisation et engagement de chaque membre d’équipes,
    • inconvénient : pas simple à mettre en œuvre selon les Entreprises, puisque cela nécessite une forte culture de confiance et de respect au sein de l’organisation, et une importante adaptabilité et implication au sein des équipes.

Ainsi, même si la méthode Scrum rencontre une forte popularité ces dernières années, et encore plus après les années d’incertitudes connues lors de la crise sanitaire en 2020 et 2021, son utilisation ne vous garantit pas la réussite de vos projets.

Pour accompagner les équipes dans l’application de l’agilité et en particulier du « Framework Scrum », le Scrum Master joue un rôle essentiel. En effet, il tient à la fois un rôle de facilitateur, de coach et de protecteur des « équipes Scrum » :

  • Il aide l’équipe et son environnement à pratiquer l’agilité ;
  • Il s’assure que les instances agiles (Daily Stand-up Meeting, Rétrospective, Planification de sprint…) sont tenues et efficaces ;
  • Il accompagne l’équipe et l’aide à surmonter les obstacles qu’elle rencontre
  • Il travaille avec le Product Owner (responsable de la vision Produit) dans l’élaboration des histoires utilisateurs / dans la description des fonctionnalités attendues.

Pour ce faire, le Scrum Master se doit d’aider tout un chacun, l’équipe et l’organisation, à comprendre la théorie et la pratique Scrum. Ainsi, il est, avant tout, un véritable leader au service de l’équipe Scrum et de l’ensemble de l’organisation.

Un bon PMO formé à la méthodologie Scrum peut tenir ce rôle de Scrum Master.

Gestion de Projet : « Cycle en V » ou « Agile » ? 1 / 3

4
Gestion de Projet : « Cycle en V » ou « Agile » ? 1 / 3

Vous devez mener un projet et vous entendez parler de méthodes « Agile » et « Cycle en V » … mais vous ne savez pas quelle méthode employer, celle qui fera de votre projet une réussite ?

 Les uns vous diront que la méthode dite du « Cycle en V » est une méthode sérieuse et rigoureuse, incontournable pour mener un projet complexe faisant intervenir de multiples acteurs et compétences.

Les autres vous assureront que les méthodes Agiles sont miraculeuses et vous permettront d’aller plus vite avec une garantie de résultat.

La réalité est beaucoup plus nuancée, et la méthode à adopter dépend de plusieurs critères comme le type de produit à réaliser, l’environnement au sein duquel vous allez travailler, les équipes auxquelles vous pouvez faire appel…

 Pour éclairer votre choix, nous vous proposons une série de 3 articles afin de présenter ces deux « méthodes », puis de dresser leurs avantages et inconvénients.

1- Le Cycle en V

Inspiré du modèle en cascade (ou Waterfall), le cycle en V se définit comme un modèle de gestion de projet séquentiel, composé :

  • d’une phase descendante regroupant les étapes de conception : expression des besoins -étude de faisabilité, définition des spécifications (fonctionnelles), conception générale/architecturale, conception détaillée ;
  • d’une étape de mise en œuvre / de réalisation (fabrication, travaux, paramétrage ou codage informatique) ;
  • d’une phase ascendante regroupant les étapes de validation : tests unitaires (de chaque composant ou fonctionnalité), tests d’intégration (vérification du fonctionnement du système cible), tests de validation des spécifications fonctionnelles du produit, test d’acceptation par le client (conformité à l’expression des besoins).

Ainsi, le cycle en V :

  • s’appuie sur une démarche séquentielle et linéaire :
    • avantage : approche intuitive, simple à mettre en pratique, et ne nécessitant peu de formation ou prérequis particuliers pour son application,
    • inconvénient : retour en arrière très difficile, même si des problèmes conceptuels sont identifiés lors de la phase de réalisation et de validation. Ce manque de souplesse fait courir le risque que le produit dans sa version finale ne soit pas adapté aux besoins actualisés au cours du projet, ou implique une dérive planning et/ou coûts ;
  • s’appuie à chaque étape de la partie ascendante sur une documentation produite lors de l’étape de la partie descendante :
    • avantage : permet d’apporter plus de précisions et de pertinence à la phase de tests ainsi que de faciliter le transfert vers des équipes d’exploitation
    • inconvénient : nécessite une documentation fournie et détaillée, perçue par certains comme une lourde perte de temps, et favorisant parfois le cloisonnement des rôles et le manque de communication ;
  • est adapté aux projets complexes et d’envergure (enjeux, budgets) :
    • avantage : facilite la gestion contractuelle avec les intégrateurs et éditeurs,
    • inconvénient : tolère mal les changements, et reste moins adapté aux projets nécessitant une forte réactivité / des ajustements fréquents entre la conception et la réalisation des activités, sans vision précise du produit cible (exemple : projet de développement logiciel ou application mobile).

Pour accompagner les équipes dans l’application de cette méthodologie projet, les entreprises font souvent appel à un PMO (Project Management Officer) pour permettre à la Direction de Projet de :

  • minimiser les risques projet, notamment par son expertise en gestion de projets et ses expériences acquises au cours de projets similaires ;
  • s’appuyer sur des informations formalisées / documentées, garantissant ainsi toute traçabilité ;
  • se focaliser sur les prises de décisions structurantes et ainsi remplir pleinement ses obligations.

Un bon PMO dans votre dispositif projet vous apporte la méthode et le savoir-être nécessaires à la maîtrise et au respect des objectifs du projet, notamment dans le cadre de la mise en œuvre du « Cycle en V ».

Abécédaire de gestion de projet

4
Abécédaire de gestion de projet

Parler le même langage...

Partager un vocabulaire commun est capital dans le management de projet. IM Projet, à travers ses différentes expériences, partage avec vous certains termes les plus souvent utilisés.

Abécédaire de gestion de projet

A : Agile – Méthodologie de gestion de projet basée sur une approche itérative et incrémentale. Les objectifs sont fixés sur le court terme et sont révisés à chaque itération afin d’apporter au produit livré le plus de valeur possible et ainsi répondre au plus vite au besoin des utilisateurs

B : Budget – Ensemble des coûts prévisionnels (humains / matériels) associés à votre projet pour une période et un périmètre fixé.

C : Chemin critique – Enchaînement des tâches de votre planning n’ayant aucune marge entre elles. Un retard d’une de ces tâches entrainera un retard de votre projet.

D : Dates – Composante essentielle de votre planning, elle est aussi indispensable pour un bon pilotage afin de donner et de partager des objectifs de réalisation communs.

E : Equipe – Regroupement de différentes personnes dédiées temporairement à la réalisation d’un projet.

F : Feedback – Ce terme anglais utilisé en France consiste à fournir un retour à une personne ou une équipe qui réalise une action, que ce soit de manière positive ou négative. Ces retours sont importants pour la progression et le bien être des intervenants.

G : Gouvernance – Organisation des instances de pilotage et d’arbitrage. Précise les objectifs et les participants de chaque instance ainsi que les documents attendus (en entrée et en sortie).

H : Hypothèses (de planification) – Document regroupant l’ensemble des informations prises en compte dans la définition de votre planning (périodes considérées comme non travaillées, adhérences ou contraintes entre certaines activités, jalons de passage imposés, etc.).

I : Imprévu – Généralement courant dans la vie d’un projet, l’imprévu est un évènement non identifié en amont pouvant impacter d’une bonne comme d’une mauvaise manière votre projet.

J : Jalons – Dates clés permettant de passer d’une activité ou d’une phase à une autre. Un jalon est une référence du projet servant au pilotage qui permet d’éviter « l’effet tunnel ».

K : KPI (Key Performance Indicators en anglais, ou Indicateurs Clés de Performance en français) – Indicateurs / Métriques permettant de piloter l’avancement et de donner l’état de santé de votre projet.

L : Lean Project – Méthode collaborative inspirée de l’industrie consistant à optimiser les activités d’un projet (Eliminer les gaspillages et le superflu, centrer les activités sur la création de valeur, faire de l’amélioration continue). IM Projet travaille selon cette méthode depuis sa création en 1989.

M : Marge – Temps disponible entre chaque activité du projet.  La marge peut être utilisée sans impact sur l’échéance finale du planning global.

N : Niveaux de planification – Long, moyen, court terme. Stratégique ou opérationnel. Directeur ou détaillé. Le niveau de planification est défini en fonction des informations que nous souhaitons afficher, du cadre de son utilisation (qui le consulte ? et à quelle occasion ?) et des échéances concernées.

O : OBS (Organisation Breakdown Structure – Organigramme des responsabilités) – Organigramme qui identifie les personnes en charge de chaque fonction ou domaine du projet. Représente également le lien hiérarchique / fonctionnel entre les acteurs au sein du projet.

P : PMO (Project Management Office ou Officer) – L’intervenant indispensable pour mettre en place tous les référentiels nécessaires au pilotage du projet et « battre la cadence » afin de respecter les objectifs fixés. Le PMO permet de faire baisser le niveau de « stress » sur le projet en facilitant la coordination des intervenants. IM Projet est une société de service délivrant ce type de prestation.

Q : Qualité – Conformité aux attentes ou aux exigences définies pour le produit, le projet et/ou par l’organisation.

R : Risque – Evénement ou suite d’événements susceptibles de compromettre la réalisation d’objectifs définis. Un risque peut avoir une ou plusieurs causes. Il est qualifié par une gravité et une probabilité d’apparition.

S : Suivi – Indispensable au pilotage d’un projet, le suivi permet de s’assurer que ce qui doit être fait est fait ou le sera dans le temps défini.

T : Tableau de bord – Présentation globale et synthétique de la situation du projet et des différents éléments le composant. Généralement utilisé à des fins de reporting au niveau de la direction et des sponsors du projet.

U : Unique – Selon le Project Management Institute (PMI), un projet est toute activité réalisée une seule fois, doté d’un début et d’une fin déterminée et qui vise à créer un produit ou un savoir unique.

V : Cycle en V – Modèle d’organisation des activités d’un projet composé d’une phase dite “descendante”, qui va de l’expression du besoin à sa réalisation, et d’une phase dite “ascendante”, qui va des tests à la mise en service du produit.

W : WBS (Work Breakdown Structure) – Décomposition du projet en sous-ensembles cohérents (par phasage, grandes fonctionnalités, ensembles géographiques, entités, …). Il représente la manière dont le projet sera réalisé. Il correspond à la structure du planning.

X : XPM (Extreme Project Management) – Méthodologie de gestion de projet qui permet de la flexibilité face à l’évolution des besoins. Il est ainsi possible de modifier le plan de projet, le budget et même le livrable final pour tenir compte des changements et ce quel que soit l’état d’avancement du projet.

Y : Year to date – Période qui débute du début de l’année, ou d’une date à préciser selon le contexte, jusqu’au présent jour, exclu. L’expression anglaise signifie “Du début de l’année à aujourd’hui”.

Z : ZBS (Zone Breakdown Structure) – Liste des différentes zones concernées par le projet. Par exemple dans un projet de construction de bâtiment, les parties communes sont une zone, les espaces verts également, les lots de parking en sont encore une autre, puis chaque logement individuel peut également être déclaré comme une zone.

L’importance du PBS dans les projets SI

4
L'importance du PBS dans les projets SI

PBS ? Kézaco ?

En tant qu’expert en gestion de projet, la notion de PBS (Product Breakdown Structure) vous parle. Pour les moins aguerris, un peu de vulgarisation. Le PBS correspond à la structuration de votre produit final :  décomposition détaillée des sujets à traiter.
Il représente donc le « QUOI » à réaliser, le périmètre du projet.

Sa formalisation permet de décrire de manière synthétique l’objet du projet et ainsi d’avoir un document de communication pour tous.

J’oubliais. Si nous voulons être un peu plus à la mode, le PBS correspond à votre Backlog si vous êtes dans une approche AGILE.

Super ! Et dans les projets SI, ça me sert à quoi ?

Les projets de Systèmes d’Information sont par essence « immatériels » et une source importante d’échec ou de retard résultent d’un périmètre flou ou mal partagé.

Formaliser un PBS sur un projet SI va permettre ainsi de minimiser ce flou et d’aligner les visions de chacun des intervenants du projet.

Son croisement avec votre WBS (Work Breakdown Structure ou encore Organigramme des Tâches) vous garantit de ne rien oublier dans la planification. Le WBS est la structure du planning et permet de répondre à la question : comment fait-on ce projet ? Il est bien plus facile à construire si le PBS est fix(g)é au préalable.

Un PBS bien construit va rapidement vous servir de ligne directrice pour planifier vos activités de conception (atelier / workshop /…), de réalisation, de recette et de formation.

Sur des projets matériels de type Bâtiment ou construction industrielle, vous remarquerez rapidement physiquement qu’il vous manque un local, un équipement, …

Dans un projet SI, le PBS permet de bien définir le périmètre fonctionnel. S’appuyer sur le PBS permet de mieux contrôler un avancement physique « immatériel ».

Comment je le construis ?

Pour le construire, appuyez-vous sur votre PMO. Son expertise en gestion de projet l’amènera à poser les bonnes questions qui permettront d’élaborer un PBS exhaustif et pertinent, en impliquant activement les parties prenantes du projet

Projets SI RH

ANNÉE DE RESALISATION:

2016 – 2017

DATE DE RÉALISATION:

2 fois 5 mois

BUDGET DU PROJET:

11.4KM$

ARCHITECTE :

M. Lorem ipsum

Photo SiRH4
4
Projets SI RH

HR Evolution : Modernisation du SI RH

Le Groupe Eiffage a décidé de lancer un programme d’évolution de son Système d’Information de Paie et de Gestion Administrative (GA) : HR Evolution.

Ce programme prévoit la mise en œuvre de deux solutions permettant de répondre à ses ambitions :

  • solution de Paie – GAP – GT : GXP Link d’ADP,
  • solution de Core HR : Workday.

Le Programme

Ce programme vise à :

  • sécuriser la Paie du Groupe,
  • améliorer la fiabilité des données,
  • bénéficier d’un référentiel RH unique Groupe,
  • offrir aux collaborateurs et managers un service de qualité et une nouvelle expérience utilisateur,
  • gérer de manière complète le cycle de vie du collaborateur,
  • supprimer les saisies manuelles,
  • répondre aux ambitions internationales du Groupe.

L’objectif est d’atteindre ces résultats pour fin 2018, soit 2 ans après le choix des solutions.

Le respect de la méthodologie de co-construction des référentiels projet pour créer une dynamique

IM Projet a intégré dans son approche les méthodes de mise en oeuvre propres à chaque éditeur en respectant 3 étapes :

  • analyse organisationnelle : phase visant à cadrer les objectifs, à structurer le projet et à définir l’organisation adéquate,
  • mise en place des référentiels : construction du référentiel délai (planning directeur),
  • Pilotage : contrôle de l’avancement, remontée d’alerte, coordination,… afin de garantir le respect des objectifs,

Les étapes 1) et 2) sont réalisées en impliquant les intervenants clés du projet : MOA – métier – MOE – Intégrateurs. Cette méthode collaborative a deux objectifs :

  • Créer une dynamique de groupe : l’implication de toutes les parties facilite l’appropriation des règles à suivre pour atteindre l’objectif,
  • Obtenir des référentiels réalistes : qui mieux que les principaux réalisateurs peuvent s’engager sur les dates et la méthode à suivre pour atteindre l’objectif ?

Ces premières étapes se déroulent sur le 1er ou les 2 premiers mois selon la complexité et le niveau de maturité du projet.

Ces deux étapes ont également permis de bien intégrer les actions de la maîtrise d’ouvrage Eiffage (collecte de référentiels, mise à niveau des données, préparation recette,…) dans le programme afin d’être au rendez-vous souhaité par les intégrateurs.

Rendre simple la complexité

Ce type de programme dans un Groupe aux multiples entités et dans un délai volontariste est source de complexité.

IM Projet,par la structuration des différents chantiers (découpage en éléments concrets) permet de rendre le projet plus simple et manageable.

En multipliant les échanges avec les intervenants concernés et en formalisant de manière claire les restitutions de réunions, IM Projet :

  • dépassionne les débats,
  • rend concret le travail à réaliser,
  • met en place une dynamique de pilotage.

Les travaux réalisés sur le chantier “interfaces et reprise de données” en est un bel exemple :

  • deux intégrateurs,
  • des MOE multiples selon les systèmes,
  • des MOA multiples selon les systèmes, …