Résolution de problème : Feuille de relevé de données

Publié le 11 octobre 2014 par AdminArnaudBrossard
La feuille d'analyse de données

La feuille d’analyse de données

Définition

La feuille de relevé de données est un document structuré permettant de recueillir, de manière méthodique, des informations sur une situation ou un problème donné. Chaque feuille de relevé de données doit être spécifique à un recueil de données.

La feuille de relevé de données peut être utilisée aux différentes étapes d’une démarche projet ou d’une démarche qualité (lors de la définition du cahier des charges, lors de l’analyse d’un dysfonctionnement, etc.).

La feuille de relevé de données est un des outils de base de la gestion de projet et de la gestion de la qualité.

Objectifs de la feuille de relevé de données

Quantifier les événements et les caractéristiques du problème.

Collecter de façon systématique « sur le terrain » (en situation) toutes les informations (chiffrées ou non) nécessaires pour l’analyse à effectuer.

Recueillir méthodiquement les données.

Enregistrer les données pour disposer de l’information nécessaire à la prise de décision.

Synonymes et variantes

Synonymes : fiches d’acquisition de données, fiche de recueil de données

Variante : feuille de relevé et d’analyse de problème, questionnaire pour enquête

Conditions d’utilisation

Pré-requis : Avant d’utiliser ce type de feuille, il faut, au préalable, avoir identifié toutes les causes possibles du dysfonctionnement analysé.

La feuille de relevé de données est utilisée pour :

  • Mesurer un phénomène ;
  • Rechercher un lien entre des causes et des effets (causes de dysfonctionnement) ;
  • Mesurer l’efficacité de la (des) solution(s) mise(s) en oeuvre.

Conditions de réussite

Il faut synthétiser les différentes informations à réunir en mots clés, simples et clairs.

Il faut prévoir un espace disponible sur la fiche pour des types de données non prévues, plutôt que de rechercher l’exhaustivité des données mentionnées sur la feuille de relevé de données.

Il faut s’assurer que chaque personne chargée de la collecte des données comprend l’ensemble des renseignements demandés (idéalement construire la feuille de relevé avec les personnes concernées).

Il faut consacrer du temps à la mise en forme de la feuille de relevé de données pour atteindre l’objectif recherché.

Il faut s’assurer de l’adhésion des utilisateurs impliqués dans la collecte des données.

Description

Organisation à mettre en oeuvre :

  • Il faut lister toutes les informations à recueillir (par exemple : les temps de traitement) et les critères de classement (par exemple : par journée, ou bien : par type de processus).
  • Il faut définir le cadre et le lieu où s’effectuera ce recueil, et surtout qui s’en chargera.
  • Il faut définir l’échantillon des observations (constitution statistique ou recueil continu, prospectif ou rétrospectif, sur une période à déterminer).
  • Il informer et motiver toutes les personnes qui doivent participer au recueil attendu.

Réalisation

  • Etape 1 : Construire la feuille de relevé de données, de façon simple et compréhensible pour les utilisateurs.
  • Etape 2 : Tester la feuille de relevé de données sur quelques observations.
  • Etape 3 : Procéder au recueil de données.
  • Etape 4 : Effectuer le dépouillement et l’analyse des données recueillies
  • Etape 5 : Définir la ou les solutions à mettre en place
  • Etape 6 : Mettre en place la ou les solutions
  • Etape 7 : Vérifier que les solutions corrigent bien le problème rencontré
  • Etape 8 : Effectuer des corrections si nécessaire

 

Les autres outils qui peuvent être utilisés pour la résolution de problèmes.

Publié dans Résolution de problèmes | Marqué avec , , | Commentaires fermés sur Résolution de problème : Feuille de relevé de données

Les techniques de résolution de problèmes

Publié le 11 octobre 2014 par AdminArnaudBrossard
Les techniques de résolution de problèmes

Les techniques de résolution de problèmes

 Il est rare que pendant un projet, le chef de projet ne rencontre pas un certain nombre de problèmes. Ceux-ci peuvent être plus ou moins impactant pour le projet et plus ou moins difficile à traiter. Ceci étant, le chef de projet, ne doit jamais attendre pour traiter tous les problèmes qui se présentent à lui.

En effet :

  • Il est très rare que les problèmes se résolvent tout seuls
  • Un problème non traité peut en entraîner beaucoup d’autres et remettre en cause, au final, le projet
  • En tant que chef de projet, c’est à vous de traiter les problèmes

Pour traiter un problème, vous pouvez vous baser sur des techniques et méthodes qui vous sont propres mais vous pouvez aussi vous appuyer sur des techniques et méthodes éprouvées qui, lorsqu’elles sont bien maîtrisées, permettent de traiter tous les types de problèmes.

A travers une succession d’articles, je vais vous présenter les principales méthodes de résolution de problèmes qui sont les suivantes :

Publié dans Résolution de problèmes | Marqué avec , | Commentaires fermés sur Les techniques de résolution de problèmes

Le comité de pilotage et les réunions de suivi de projet

Publié le 28 septembre 2014 par AdminArnaudBrossard
Les réunions de pilotage et de suivi de projet

Les réunions de pilotage et de suivi de projet

Dans le cadre de la gestion des projets d’une certaine taille ou d’une certaine durée, il est d’habitude de mettre en place un comité de pilotage et des réunions de suivi de projet. Si ces deux instances peuvent paraître similaires, au premier abord, elles ont, dans la vie du projet, des objectifs bien différents.

Le comité de pilotage de projet

Ainsi, les réunions du comité de pilotage de projet sont des réunions qui ont pour but principal de  gérer le projet au niveau stratégique. L’objectif de ce comité de pilotage n’est donc pas de discuter de problématiques techniques de base du projet ou des problèmes du quotidien mais d’arbitrer sur les trois axes principaux du projet que sont les coûts, les délais et la qualité. Ces réunions du comité de pilotage du projet ont aussi pour but de permettre de lever les difficultés organisationnelles qui pourraient exister autour du projet. Elles permettent enfin de définir et valider les changements d’orientation du projet rendus nécessaires par l’évolution du contexte aussi bien au sein de l’équipe projet, que de l’entreprise ou alors de l’extérieur (évolution règlementaire, apparition d’un nouveau concurrent, etc.).

Les participants à ces réunions du comité de pilotage du projet sont, en-dehors du chef de projet, l’ensemble des décideurs concernés par la mise en oeuvre du projet ; que ce soit au niveau technique, au niveau fonctionnel, au niveau organisationnel ou encore au niveau commercial.

Tout l’art du chef de projet dans l’organisation d’une réunion du comité de pilotage consiste à :

  • Inviter tous les décideurs concernés par le projet en veillant à ne pas faire venir trop de personnes et surtout à inviter les personnes qui peuvent vraiment décider
  • Ne traiter que des sujets qui relèvent du niveau stratégique du projet
  • Ne pas multiplier les réunions du comité de pilotage mais les faire de manière régulière en fonction des besoins ou des évolutions du projet au niveau stratégique (exemples : changement d’orientation d’une partie du projet, augmentation importante des coûts, etc.). De manière assez générique, on peut considérer que, sur un projet sur plusieurs années, une réunion de ce type par trimestre est une bonne fréquence.

Les réunions de suivi de projet

Contrairement aux réunions du comité de pilotage de projet, les réunions de suivi de projet ont pour but de traiter les problématiques projet au niveau opérationnel. L’objectif de ces réunions n’est donc pas de redéfinir le contenu du projet ou de prendre des décisions globales sur les coûts, les délais ou la qualité mais de permettre au projet de pouvoir avancer au quotidien.

Ces réunions réunissent généralement :

  • Des représentants de la maîtrise d’oeuvre
  • Des représentants de la maîtrise d’ouvrage
  • Des représentants du client  (si celui-ci n’est pas représenté par la maîtrise d’ouvrage)
  • Eventuellement d’autres intervenants en fonction des sujets à traiter (exemples : représentants des utilisateurs, services techniques annexes au projet, etc.)

Au niveau pratique, la fréquence de ce type de réunions est beaucoup plus importante que pour les réunions du comité de pilotage du projet. Ainsi, pour un projet sur plusieurs années, on peut considérer qu’une fréquence d’une réunion de suivi par mois est une bonne moyenne. Si nécessaire, le chef de projet ne devra pas hésiter à organiser des réunions plus fréquentes pour traiter certains points précis. L’objectif est de permettre au projet de continuer à avancer tout en évitant au maximum les retours en arrière ou les blocages suite à un manque d’informations ou à une mauvaise compréhension des informations transmises au projet.

Publié dans Réunion | Marqué avec , , | Commentaires fermés sur Le comité de pilotage et les réunions de suivi de projet

La réunion de lancement d’un projet

Publié le 21 septembre 2014 par AdminArnaudBrossard
La réunion de lancement d'un projet

La réunion de lancement d’un projet

La réunion de lancement d’un projet est un élément clés de sa réussite. De manière pratique, elle permet de :

  • Réunir l’ensemble des représentants des intervenants sur le projet, que ce soit du côté technique, du côté fonctionnel, du côté utilisateurs ou encore du côté commercial ou financier.
  • Faire que toutes les personnes présentes puissent se présenter les unes aux autres afin que chacun puisse bien identifier le rôle des uns et des autres et donc ses interlocuteurs potentiels.
  • Présenter, de manière claire et aussi concise que possible, les objectifs du projet ainsi que son planning général
  • Présenter l’organigramme de l’équipe projet
  • Définir les interactions des différents intervenants pendant l’ensemble du projet en les faisant apparaître sur les plannings de réalisation
  • Faire intervenir tous les participants afin que chacun puisse bien prendre sa place dans l’ensemble du projet. Sur ce point, vous devrez veiller à ce que chacun puisse s’exprimer notamment sur ses domaines de connaissance et de compétence.

Attention : Un travail important doit être réalisé en amont avant d’organiser la réunion de lancement du projet. En effet, celle-ci ne doit pas être l’occasion de remettre en cause l’intégralité du projet suite à une analyse préalable incomplète ou partielle. Elle ne doit pas non plus être l’occasion de déclencher des rivalités entre les participants suite à des définissons floues sur certains aspects du projet.

Ce qui est attendu à l’issue de cette réunion de lancement c’est :

  • Avoir un consensus sur le contenu, les délais et les grands principes de réalisation du projet.
  • Avoir une validation, par toutes les personnes présentes à la réunion, de l’implication des différents intervenants pendant le déroulement du projet et notamment au moment des phases clés du projet
  • Avoir une validation, par toutes les personnes présentes à la réunion, de la feuille de route du projet aussi bien au niveau de son organisation, de son planning que de son plan d’assurance qualité si celui-ci a été défini.
  • Ne plus avoir aucune zone d’ombre sur les grandes lignes du projet

Il est important de noter que la réunion de lancement de projet doit être considérée comme la réunion qui va légitimer et installer le projet et, par la même occasion, le chef de projet. C’est donc une réunion importante qu’il convient de bien préparer :

  • Au niveau de son ordre du jour qui doit être précis et complet pour arriver à couvrir l’ensemble du projet
  • Au niveau de sa durée qui doit être suffisamment longue pour permettre de faire le tour de l’ensemble des points à traiter, mais pas trop longue pour rester efficace. Pour un projet d’envergure moyenne (autour de 1000 jours.homme) avec un nombre restreint d’intervenants, ce type de réunion devrait avoir une durée comprise entre 2 et 4 heures.
  • Au niveau des personnes invitées qui doivent représenter l’équipe projet, les clients, les décideurs, les représentants des autres projets et services avec lesquels il existera des interactions pendant le déroulement du projet. Il faudra aussi veiller à inviter l’ensemble des personnes qui feront partie, pendant toute la durée du projet, du comité de pilotage du projet. Enfin, il faudra bien s’assurer de la présence d’un maximum de personne à la réunion de lancement. Et, si une personne ne peut pas être présente, voir dans quelle mesure elle ne pourrait pas être remplacée par une autre personne.
  • Au niveau des documents supports qui doivent être complets et disponibles pour tous les participants. Sur ce point, le chef de projet doit aussi veiller à intégrer, dans ses supports de réunion, les documents provenant d’autres intervenants et qui sont susceptible d’être présentés pendant la réunion.
  • Au niveau de l’environnement de la réunion (salle, etc.) et de l’accueil des participants qui doivent permettre de faciliter la mise en confiance de l’ensemble des personnes qui seront présentes.
  • Au niveau de la prise de note, pour la réalisation du compte-rendu, vous pouvez, en tant que chef de projet et organisateur de la réunion, prendre vous-même des notes, mais cette façon de faire ne facilite pas la fluidité des échanges pendant la réunion et peut vous faire perdre le fil de votre pensée. Vous pouvez aussi faire un enregistrement intégral de l’ensemble de la réunion à l’aide d’un dictaphone. Mais, dans ce cas, vous devrez veiller à demander, au préalable, l’autorisation d’effectuer cet enregistrement à l’ensemble des participants. Et, il est loin d’être sûr que cet accord soit facile à obtenir. La dernière solution, et la plus pertinente, consiste à vous faire accompagner d’une personne qui sera chargée de prendre des notes pendant toute la durée de la réunion ; cette personne ne devant pas participer aux échanges sauf pour éventuellement faire repréciser certaines décisions qui seraient prises pendant la réunion pour vérifier que tous les participants soient bien en phase sur ces décisions.

Cette réunion étant essentielle, il conviendra aussi de veiller à en faire un compte-rendu dans des délais aussi courts que possible. Celui-ci devra être envoyé, pour validation, à l’ensemble des participants et le chef de projet devra vérifier que cette validation s’effectue dans des délais raisonnables. À ce niveau, la solution la plus simple consiste à indiquer, dans le message d’accompagnement du compte-rendu, que celui-ci sera considéré comme validé si le destinataire ne fait pas de retour dans les x jours. Attention quand même à veiller à mettre un délai de retour raisonnable afin de réellement permettre aux différents intervenants de faire leurs retours. Si jamais, suite à un ou plusieurs retours, le compte-rendu était modifié, celui-ci devra être renvoyé, à nouveau, à tous les participants pour revalidation.

Publié dans Réunion | Marqué avec , | Commentaires fermés sur La réunion de lancement d’un projet

Analyse : La création d’une nouvelle fonction

Publié le 20 septembre 2014 par AdminArnaudBrossard
La création d'une nouvelle fonction

La création d’une nouvelle fonction

On vous demande de créer quelques chose de complètement neuf au sein de votre société, de créer une nouvelle fonction, et vous vous demander comment faire. Cet article va vous donner quelques trucs et astuces pour vous permettre de bien démarrer.

En premier lieu, vous devez commencer par réaliser une première étude rapide de ce qui vous est demandé pour être sûr de bien cerner les besoins, les attentes, les limites et les contraintes. Pour cela, rien de tel que d’utiliser la méthode QQOQCP (voir l’article Évaluation de la charge d’un projet : Utilisation du QQOQCP).

Une fois cette première étape réalisée,  je vous recommande de lancer une analyse sur la méthode de réalisation du projet en vous posant les questions suivantes :

  • Est-il possible de trouver, sur le marché, un ou plusieurs progiciels ou solutions techniques qui puissent répondre en partie ou en totalité à la problématique posée ? Si oui, quels seraient les coûts associés à sa mise en oeuvre et quelles seraient les contraintes et limites associées ?
  • Est-il possible de se baser, pour au moins une partie du projet, sur une solution déjà existante au sein de la société ? Si oui, dans quelle mesure et quelles seraient les contraintes et les limites associées ?
  • Quels seraient les coûts, les contraintes et les limites d’une solution entièrement développée en interne ?

Dans cette analyse, vous devrez à la fois étudier la partie réalisation et mise en place du projet mais aussi l’ensemble du cycle de vie du projet. Ceci est d’autant plus important que certaines contraintes ou limites, pour un type de solution, peuvent rendre celles-ci caduques ou alors très coûteuses dans le temps.

Une fois que vous aurez identifié la meilleure solution pour la réalisation du projet, vous devrez, en tant que chef de projet, vérifier que la demande correspond bien à un besoin réel de votre société. Et, pour cela, rien de tel que de calculer le retour sur investissement du projet.

Puis, vous pourrez vous lancer dans la création d’un premier planning pour le projet. Ceci vous permettra de finaliser votre analyse initiale et vous donnera une vue complète et globale du projet.

Pendant le déroulement de toutes ces étapes, il ne faudra pas non plus hésiter à réaliser, si nécessaire, des réunions de cadrages pour bien cerner tous les contours du projet, mais aussi pour vérifier votre bonne compréhension des demandes et des attentes de vos clients. Pour qu’une réunion de cadrage soit efficace, vous devrez la préparer comme toute autre réunion en prenant soin d’avoir un ordre du jour précis, mais surtout en s’assurant que les personnes clés, capables d’apporter des réponses à vos questions seront bien présentes lors de la réunion.

Une fois que vous serez en possessession de toutes ces informations, vous pourrez organiser, avec les représentants des clients et les décideurs du projet, la première « vraie » réunion qui sera l’occasion de valider le démarrage effectif du projet. Cette réunion, c’est ce qu’on appelle la réunion de lancement du projet que je vous présenterai plus en détail dans un autre article.

 

Publié dans Analyse | Marqué avec , | Commentaires fermés sur Analyse : La création d’une nouvelle fonction

Analyse : La refonte d’une application

Publié le 16 septembre 2014 par AdminArnaudBrossard
Analyse : La refonte d'une application

Analyse : La refonte d’une application

On vous a confié la charge d’un projet qui consiste à refondre une application ou un système informatique déjà existant et vous vous demandez comment aborder le sujet au mieux.

Tout d’abord, il vous faut commencer par bien comprendre le type de refonte qu’on vous demande :

  • Une refonte à l’identique, c’est-à-dire sans évolution majeure. Ce type de refonte correspond souvent à un changement de technologies lié à des problèmes d’obsolescence ou à des problèmes de performances.
  • Une refonte « évolutive », c’est-à-dire avec reprise de l’existant mais aussi avec intégration d’évolutions fonctionnelles ou techniques.

Une fois le type de refonte déterminé, vous devrez aussi définir le périmètre de la refonte ; c’est-à-dire déterminer :

  • Si c’est l’ensemble de l’application ou du système qui doit être refondu ou si c’est seulement une partie.
  • Si l’application ou le système doit s’intégrer avec de nouvelles applications ou systèmes ou s’il doit rester à l’identique au niveau de son environnement d’utilisation.

Pour l’application ou le système informatique, quel que soit le type de refonte, vous devrez, dans tous les cas, identifier, aussi bien sur le plan technique que sur le plan fonctionnel :

  • Les points forts ; c’est-à-dire les points qui donnent pleinement satisfaction aux utilisateurs et au client
  • Les points d’amélioration, appelés communément points faibles ; c’est-à-dire les points qui ne donnent pas satisfaction aux utilisateurs et au client
  • Les points manquants ; c’est-à-dire ce qui manque dans l’application. Dans le cas d’une refonte à l’identique, vous devrez uniquement vous concentrer sur les principaux points qui permettraient d’augmenter la productivité ou les performances. Pour une refonte évolutive, vous devrez essayer d’identifier, du moins au départ, le maximum de points.

Il est important de bien garder à l’esprit que l’analyse doit être effectuée aussi bien du point de vue de l’utilisateur final que du client. En effet, si on prend l’exemple de la refonte évolutive d’un site e-commerce, l’évolution peut aussi bien porter sur la partie utilisateur pour améliorer le fonctionnement du site du point de vue des acheteurs ou alors sur la partie back-office c’est-à-dire toute la partie technique qui est à destination du client (en l’occurrence du vendeur dans notre exemple).

Le cadre de votre projet étant défini, il vous faut maintenant vous lancer dans votre analyse proprement dite. Pour cela, il existe plusieurs techniques que vous pouvez utiliser :

  • Analyse documentaire : Cette technique consiste à étudier toute la documentation existante. Elle a pour objectif de vous permettre de déterminer l’ensemble des fonctionnalités existantes avec leur interaction les unes avec les autres. Elle vous permet aussi d’avoir une première vision globale de l’application ou du système à refondre. Bien évidemment, cette technique n’est réellement utile que si la documentation existante est à jour et est complète. Dans le cas contraire, cette technique ne vous donnera qu’une idée générale et probablement biaisée de la réalité.
  • Analyse de fonctionnement : Cette technique consiste à utiliser ou à faire utiliser, par un des membres de l’équipe projet, l’application ou le système pour en déterminer le fonctionnement mais aussi identifier, principalement, ses points forts et ses points faibles. Cette analyse de fonctionnement donne des résultats particulièrement intéressants lorsque les personnes qui réalisent cette analyse ne connaissaient pas l’application auparavant.
  • Analyse des usages : Cette technique consiste à étudier l’utilisation de l’application ou du système par les utilisateurs et le client dans leur quotidien. De manière pratique, cette analyse s’apparente à un audit des usages que nous décrirons plus en détail dans un autre article.
  • Analyse des attentes : Cette technique consiste à réaliser des interviews auprès des utilisateurs et du client pour connaître leur ressenti et leurs attentes par rapport à l’application ou au système. Ce type d’analyse se fait principalement à travers des interviews de différentes personnes qui connaissent et utilisent l’application ou le système au quotidien. En fonction du type de refonte demandée, cette analyse devra plus ou moins être poussée. Ainsi, dans le cas d’une refonte sans évolution, vous n’aurez pas besoin d’approfondir les points sur les fonctionnalités manquantes ou sur les nouvelles fonctionnalités souhaitées.

Une fois toutes les informations recueillies, vous devrez en faire une synthèse pour être en mesure de finaliser le cahier des charges fonctionnel de votre projet. La question qui se pose souvent ici est de savoir qui doit écrire le contenu du cahier des charges : les utilisateurs, le client, l’équipe projet ou un analyste externe. En fait, il n’y a pas de réponse absolue, tout dépend du contexte de réalisation du projet. Ainsi, si les utilisateurs ou le client ne sont pas en mesure ou en capacité d’établir un cahier des charges fonctionnels, l’équipe projet devra prendre en charge cette tâche. Si, dans votre entreprise, il existe un service de type AMOA (Assistance à Maîtrise d’OuvrAge), alors ce sera, probablement, à celui-ci à écrire le cahier des charges. L’important dans tout cela est de bien savoir qui va écrire le cahier des charges, sous quelle forme et dans quels délais.

Dans un prochain article, nous verrons comment formaliser un cahier des charges et surtout comment le faire valider.

Publié dans Analyse | Marqué avec , | Commentaires fermés sur Analyse : La refonte d’une application

Réalisation : Méthodes agiles ou méthodes classiques

Publié le 14 septembre 2014 par AdminArnaudBrossard
Méthodes agiles - Méthodes classiques

Méthodes agiles – Méthodes classiques

Aujourd’hui, lorsqu’on démarre un projet informatique, un chef de projet a, à sa disposition, plusieurs types de méthodes de développement. En-dehors du fait d’être connue ou pas du chef de projet et de l’équipe projet, chacune de ces méthodes présente des avantages et des inconvénients qu’il convient de connaître pour faire le choix le plus pertinent pour la réussite du projet.

Dans cet article, nous n’allons pas faire une présentation exhaustive de toutes les méthodes de développement existantes. En fait, nous allons nous concentrer sur les deux grandes familles de méthodes existantes aujourd’hui : l’approche classique avec le fameux cycle en V et l’approche agile avec des méthodes comme SCRUM.

L’approche classique

L’utilisation de l’approche classique et du cycle en V remonte aux origines de l’informatique. En fait, cette approche est calquée sur les méthodes de gestion de projets dans l’industrie lourde utilisée dans les années 50-60 où il était indispensable que les différentes tâches du projet se succèdent étant donné le manque de souplesse dans la réalisation de certaines tâches.

Maintenant, il faut reconnaître que c’est une méthode assez simple à mettre en oeuvre et très efficace dans la pratique. En effet, le fait qu’elle soit constituée de phases successives permet, d’une certaine manière, de sécuriser la réalisation de l’ensemble du projet, chaque phase ne commençant qu’à partir du moment où la phase précédente est finalisée ou quasiment finalisée.

Les différentes phases du « cycle en V » sont, dans l’ordre :

  • L’expression des besoins : Cette phase consiste à recueillir l’ensemble des besoins des utilisateurs.
  • Les spécifications fonctionnelles : Cette phase consiste à définir, de manière aussi précise que possible, toutes les fonctions et contraintes associées qui se retrouveront dans la réalisation finale
  • Les spécifications techniques : Cette phase consiste à définir, de manière aussi précise que possible, les réponses techniques qui seront apportées à chaque spécification fonctionnelle
  • Le développement/la réalisation : Cette phase correspond à la réalisation technique du projet
  • Les tests unitaires : Cette phase consiste à valider la réalisation technique par rapport aux spécifications techniques
  • Les tests d’intégration : Cette phase consiste à valider la réalisation technique par rapport aux spécifications fonctionnelles
  • La recette applicative : Cette phase consiste à valider la réalisation technique avec les utilisateurs.

Si le cycle en V est rassurant à utiliser dans le sens où il marque bien un début, une fin et une progression, son application dans les faits est souvent assez différente.

Ainsi, si vous réalisez un projet en lots, vous pourrez alors intégrer chaque lot dans un « cycle en V » et votre projet pourra être vu, au final, comme une succession de « cycles en V ». Mais, il est aussi fort probable que vous ayez été en mesure de lancer plusieurs lots en parallèle et dans ce cas, vous allez devoir superposer vos « cycles en V ».

De plus, une fois le projet livré, il est probable que celui-ci reçoit des demandes d’évolutions sous la forme d’une maintenance corrective ou sous la forme d’un nouveau projet. Et, dans ce cas, vous vous retrouverez à gérer de nouveaux « cycles en V ».

Enfin, une fois la phase de recette applicative terminée, il vous faudra vous occuper de la mise en production et en exploitation de votre projet et donc prendre en charge et gérer d’autres tâches qui ne font pas partie du « cycle en V ».

Aussi, si de manière générale, on parle de « cycle en V », ceci relève d’un abus de langage, car ce n’est pas un véritable cycle figé et absolu. En fait, il vaut mieux parler de méthode en V ; ce qui permet d’envisager son utilisation dans d’autres cadres.

De manière générale, les trois principaux avantages de la méthode en V sont :

  • Une méthode connue de tous (ou presque) et simple à mettre en oeuvre.
  • Une méthode qui peut convenir à tous les types de projets.
  • Une méthode qui dispose d’un formalisme bien défini qui facilite le suivi du projet.

Les trois principaux inconvénients de la méthode en V sont :

  • Les besoins des utilisateurs doivent être clairement connus et énoncés dès le début du projet sinon il est impossible de réaliser les spécifications fonctionnelles et techniques
  • Des difficultés dans la prise en compte des évolutions des demandes des utilisateurs pendant la réalisation du projet (la remise à jour des spécifications alors qu’on est dans la phase de réalisation ne sera jamais simple à gérer).
  • Un nécessaire formalisme assez poussé pour réussir.

L’approche agile

Les méthodes agiles sont des méthodes qui sont apparues, il y a de cela de nombreuses années, pour principalement s’affranchir de la « rigidité » de la méthode en V notamment au niveau de la prise en compte des besoins des utilisateurs.

Cette méthode a surtout pris son envol avec l’explosion des développements web pour lesquels il fallait produire de nouvelles applications sans se baser sur un existant et sans savoir vraiment comment serait l’application finale. On partait d’une idée générale et au fur et à mesure de réalisations successives, on arrivait à l’idée finale.

En fait, les méthodes dites agiles s’apparentent à des méthodes itératives dans lesquelles les fonctionnalités et donc les besoins des utilisateurs seraient affinés au niveau de chaque itération.

La mise en place de ce type de méthode nécessite d’avoir :

  • Une équipe projet capable de travailler sans cahier des charges bien défini
  • Des animateurs de projets, aussi bien au niveau technique qu’au niveau fonctionnel, capable d’entraîner l’équipe projet et surtout capable de faire évoluer rapidement le projet en fonction des besoins et des attentes des utilisateurs.
  • Une réactivité très forte des utilisateurs pour apporter des compléments d’informations à l’équipe projet.
  • Une forte capacité à se remettre en cause régulièrement pour, éventuellement, revoir complètement certaines parties déjà réalisées.
  • Le découpage du projet en phases courtes (de 1 à 4 semaines) représentant chacune un « run » avec des objectifs fonctionnels à atteindre ; le travail réalisé devant être finalisé et testé lorsqu’on arrive à la fin de chaque « run ».

De manière générale, on recommande souvent à ce que l’équipe projet soit totalement isolée des autres équipes informatiques et fonctionnelles de l’entreprise afin que celle-ci n’ait pas d’interférences avec l’extérieur qui remettraient en cause la réalisation des différents « runs ».

De manière pratique, ce type de fonctionnement n’a aucun intérêt si le projet est bien défini dès le départ ; c’est-à-dire s’il dispose d’un cahier des charges complet. De même, pour les projets ayant de nombreuses contraintes dès le départ, ce type de méthode fonctionne généralement assez mal, car la réactivité attendue sera beaucoup trop contrainte.

De manière générale, les trois principaux avantages de la méthode en V sont :

  • Une méthode adaptée aux projets contenant une partie d’incertitudes sur les besoins réels des utilisateurs.
  • Une méthode qui permet de rapidement avoir des résultats et donc de rapidement pouvoir se positionner sur la suite du projet.
  • Une méthode qui bien adaptée aux nouveaux projets.

Les trois principaux inconvénients de la méthode en V sont :

  • Une méthode qui nécessite d’avoir une équipe projet apte à la mettre en oeuvre
  • Une méthode qui repose énormément sur les capacités des personnes qui vont animer le projet.
  • Une méthode qui ne s’adapte pas très bien aux projets de maintenance ou d’évolution fonctionnelle d’un existant

Au final méthode en V ou méthode agile ?

La réponse la plus simple consiste à dire que si le contenu du projet est bien défini, la méthode en V est la méthode la plus pertinente. Si le contenu du projet est plus vague et s’il est possible d’avoir une équipe projet adaptée alors, la méthode agile sera la plus pertinente. Maintenant, il ne faut pas être complètement dogmatique pour une méthode ou une autre. En fait, il faut savoir parfois faire des mélanges entre les différentes méthodes en fonction des tâches à réaliser et des personnes concernées dans l’équipe projet. De cette manière, il devient possible d’avoir les avantages des deux méthodes tout en limitant leurs inconvénients.

Publié dans Réalisation | Marqué avec , , , | Commentaires fermés sur Réalisation : Méthodes agiles ou méthodes classiques

L’évaluation de la charge d’un projet : trucs et astuces

Publié le 13 septembre 2014 par AdminArnaudBrossard
Evaluation trucs et astuces

Evaluation de la charge d’un projet : trucs et astuces

Savoir faire une bonne évaluation d’un projet nécessite toujours beaucoup d’expertise, un gros travail d’analyse et surtout une bonne connaissance du contenu du projet. Mais, il existe aussi un certain nombre de trucs et astuces qui vous permettent de gagner du temps et rendre votre évaluation encore plus fiable et pertinente.

Astuce 1 : Quel outil utiliser ?

Faire une évaluation de charge à la main n’est jamais une opération simple car toute modification va nécessiter un temps important de remise à jour. Aussi, il est préférable d’utiliser des outils informatiques pour vous faciliter la tâche. Parmi ces outils, un des outils les plus répandus et assez efficace pour ce type de travail est Microsoft Project.

Astuce 2 : Gantt, Pert, MPM, etc. ?

La modélisation de l’enchaînement des différentes tâches d’un projet peut se faire à l’aide de différentes méthodes plus ou moins adaptées au contexte du projet. Mais, s’il faut ne retenir qu’une seule méthode, simple et valable pour tous les types de projets, ce serait les diagrammes de Gantt.

Maintenant, si vous voulez aller plus loin dans la qualité de vos analyses il vous faudra apprendre à utiliser les diagrammes de PERT. En effet, ceux-ci permettent, à travers, par exemple, l’introduction de dates de réalisation au plus tôt et de dates de réalisation au plus tard de mieux tenir compte des incertitudes pouvant exister sur un projet mais aussi pour mieux voir toutes les marges de manoeuvres possibles pour le chef de projet.

Astuce 3 : Faire ou pas intervenir les contraintes sur les personnes dans la conception des diagrammes de Gantt ?

Pour faire une bonne évaluation, il convient de prendre en compte un maximum de contraintes et notamment celles sur les ressources humaines qui sont, par nature, source d’un niveau important d’incertitudes (congés, maladie, départ, etc.). Aussi, il est toujours intéressant de les rentrer comme contraintes lors de la conception des diagrammes de Gantt du projet. Si pour les ressources humaines non permutables, comme l’existence d’un seul designer dans l’équipe projet, il est important de les prendre en compte de manière individuelle et aussi précisément que possible, pour les ressources permutables (10 développeurs Java de même niveau dans l’équipe projet), il n’est pas nécessaire d’aller à ce niveau de détail et définir des profils génériques et largement suffisant.

Maintenant, vous pouvez aussi ne pas faire intervenir les contraintes sur les personnes dans la conception de vos diagrammes de Gantt, mais dans ce cas, cela signifie que vous devrez intégrer une partie de ces problématiques au niveau de l’évaluation de chaque tâche. Cela pourra se faire soit à travers un allongement de la durée de chaque tâche soit à travers la gestion d’un calendrier de jours ouvrés prenant en compte, de manière générique, les congés et les possibles absences des membres de l’équipe projet.

Pour le reste de cet article, nous allons nous limiter aux diagrammes de Gantt de manière à garder une approche assez simple.

Astuce 4 : Comment placer les tâches sur les diagrammes de Gantt ?

Quelques petites règles à respecter :

  • Identifier les tâches les plus « risquées » pour le projet (en matière de délai, de coût ou de qualité) et voir dans quelle mesure il est possible de les placer en premier.
  • Maximiser le nombre de tâches qui seront réalisées en parallèle en tenant compte des ressources humaines que vous avez à disposition dans votre projet.
  • Minimiser les temps d’attente entre la réalisation des tâches (les personnes affectées au projet doivent toujours avoir des tâches à réaliser)
  • Tenir compte des réunions, des formations et des congés des personnes travaillant sur le projet car ceux-ci peuvent avoir un impact important sur les délais de réalisation du projet
  • Essayer de tenir compte, autant que possible, dans l’agencement des tâches, des possibles perturbations pouvant survenir au niveau des ressources humaines affectées au projet (départ, maladie, etc.) de manière à limiter leur impact sur le projet.
  • Intégrer, dans votre planning, toutes les contraintes liées à la mise à disposition de ressources pour votre projet (contraintes liées à du matériel ou à des personnes) et planifier les tâches pour limiter les dépendances de votre projet par rapport à ces contraintes externes.
  • Si cela s’avère utile, par exemple lorsque le projet est dépendant d’un autre projet, vous pouvez aussi intégrer des tâches liées à ces autres projets dans vos diagrammes de Gantt ou les contraintes, associées à cet autre projet, qui peuvent avoir un impact sur votre projet.

Astuce 5 : Quels éléments importants identifier sur vos diagrammes de Gantt ?

Lors de la création de vos diagrammes de Gantt, vous devrez veiller à placer l’ensemble des tâches du projet de manière à :

  • Identifier le ou les chemins critiques c’est-à-dire les chemins pour lesquels tout retard entraînera un retard général du projet ou une inactivité pour les autres membres de l’équipe projet. Pour rappel, un chemin est défini comme une succession de tâches entre la date de début du projet ou du lot associé au diagramme de Gantt et la date de fin du projet ou du lot sur ce même diagramme de Gantt. Si possible, il faut essayer de minimiser le nombre de contraintes associées au chemin critique.
  • Identifier les tâches critiques, c’est-à-dire les tâches à marge nulle située sur le chemin critique et voir dans quelle mesure il est possible de les rendre moins critiques éventuellement en les réalisant à un autre moment du projet ou en changeant l’organisation des différentes tâches les unes par rapport aux autres.

Astuce 6 : Des diagrammes juste pour l’évaluation du projet ?

Tous les diagrammes que vous allez réaliser ne devront pas uniquement servir juste pour l’évaluation initiale du projet. Ils devront aussi être utilisé, au quotidien, pendant toute la durée de réalisation du projet pour vérifier que celui-ci se déroule comme prévu mais aussi pour replanifier les tâches restantes si certaines tâches mettent moins ou plus de temps pour être réalisées. L’utilisation pendant le projet va aussi vous permettre d’agir au plus tôt dans le cas où certaines difficultés ne permettraient pas de livrer le projet dans les délais.

Astuce 7 : J’utilise des méthodes agiles, dois-je évaluer le projet de la même manière ?

Pour un certain nombre de personnes, le fait de mettre en oeuvre des méthodes agiles, pour la réalisation du projet, leur fait penser qu’il n’est pas utile de réaliser une évaluation du projet comme pour un projet classique. En fait, ceci n’est que partiellement vrai.

En effet, de manière simplifiée, on peut dire qu’un projet agile est l’équivalent d’un projet classique qui serait constitué d’une succession de lots dont les contenus ne sont généralement pas définis à l’avance. Ceci étant, chaque lot, chaque « run » pour reprendre le vocabulaire utilisé par les méthodes agiles, lorsqu’il est lancé est défini avec un objectif bien précis et sera réalisé par des ressources bien déterminées. A ce titre, il peut être évalué comme un autre projet. Ceci étant, il faudra prendre en compte, dans l’évaluation des différentes tâches, les incertitudes liées à la réalisation de chaque tâche. Et, si nécessaire, il faudra prévoir plusieurs chemins de réalisation (plusieurs successions de tâches) possibles pour la réalisation du lot (du « run »).

Se lancer dans un projet avec une méthodologie agile sans faire d’évaluation préalable, même simplifiée, revient en pratique à dénaturer tout l’intérêt des méthodes agiles. En effet, si on définit, pour un « run », un contenu irréalisable, alors le projet risque de vite déraper et ne plus profiter des avantages apportés par les méthodes agiles. Et ceci, sans compter l’image désastreuse que risque d’avoir rapidement l’équipe projet vis-à-vis de l’extérieur.

Donc, s’il ne faut qu’un bon conseil : n’hésitez pas à faire une évaluation « classique » quelle que soit la méthode utilisée par le projet.

Publié dans Evaluation | Marqué avec , | Commentaires fermés sur L’évaluation de la charge d’un projet : trucs et astuces

L’évaluation de la charge d’un projet : utilisation du QQOQCP

Publié le 11 septembre 2014 par AdminArnaudBrossard
Evaluation d'un projet avec la méthode QQOQCP

Evaluation d’un projet avec la méthode QQOQCP

Avant de pouvoir faire l’évaluation d’un projet, il faut commencer par l’analyser ; c’est-à-dire par bien comprendre son contexte, ses objectifs et ses contraintes. Mais, existe-t-il une technique fiable, sûre et universelle pour réaliser cette analyse et, si oui, quelle est-elle ?

Avec l’expérience, tous les chefs de projet vous diront que la réponse à cette question est non. Ceci étant, il existe ce qu’on peut appeler des trucs et astuces pour réaliser au mieux cette analyse et cette première évaluation.

Avant toute chose, il est indispensable que votre analyse commence par une bonne compréhension des objectifs du projet, car si vous ne savez pas où le projet doit aller, vous aurez beaucoup de mal à le conduire et à le gérer. Pour cela, il existe un outil, issu des techniques de résolution de problèmes, simple et pratique à mettre en œuvre, une fois adapté : l’analyse de type QQOQCP :

  • Qui ?
  • Quoi ?
  • Où ?
  • Quand ?
  • Comment ?
  • Pourquoi ?

Mais que recouvrent ces différentes questions ?

En fait, elles contiennent encore de nombreuses autres questions qui permettront, au chef de projet, de bien cerner celui-ci. Vous trouverez ci-dessous quelques exemples de ces autres questions que vous pourrez vous-même compléter au fur et à mesure de vos prochaines expériences en matière de gestion de projet.

Répondre au Qui ?

Qui est le client du projet ?

  • Quels sont les décideurs sur le projet ? Si vous ne savez pas qui peut décider au niveau du client, il ne sera pas facile de faire avancer votre projet lorsque des difficultés ou des problèmes surgiront.
  • Quels sont les interlocuteurs du client sur le projet ? L’idéal ici est d’arriver à déterminer les personnes ressources nécessaires pour couvrir tous les domaines, en lien avec le projet, dans lesquels le client devra interagir avec le projet. Ces personnes ressources doivent être compétentes mais doivent être aussi en mesure de pouvoir apporter des réponses, dans leur domaine d’action, à toutes les questions que pourrait se poser le chef de projet pendant le déroulement du projet.

Qui seront les utilisateurs ?

  • Quel est le type d’utilisateurs ciblés ? Utilisateurs techniques, utilisateurs fonctionnels, grand public, public masculin, public féminin, jeunes, seniors, etc. ? Connaître le type d’utilisateurs permet d’orienter l’ergonomie, l’aspect visuel et le fonctionnement de l’application pour tenir compte des contraintes et attentes associées à chaque type de public.
  • Doit-on prendre en compte des déficiences physiques ? Si oui, sous quelle forme et avec quel niveau de contraintes ?
  • Combien de personnes utiliseront le projet au final (quel dimensionnement prévoir pour le passage en production) ?

Répondre au Quoi ?

Nouveau ou pas ?

  • Le projet est-il un nouveau projet ou remplace-t-il un existant ? Dans ce cas, dispose-t-on de toutes les informations sur le système existant ?
  • Le projet est-il l’évolution d’un système existant ? Si oui, est-il un ajout pur ou comprend-t-il une refonte partielle de l’existant et dans quelle mesure ?

Quelles sont les données traitées ?

  • Quelles seront les données informatiques traitées par le projet ?
  • Le projet fonctionne-t-il en totale autonomie sans liens avec d’autres systèmes ? Si ce n’est pas le cas, quels sont les autres systèmes concernés, et quelles sont les personnes de référence sur lesquelles le projet pourra s’appuyer pour traiter les liens avec ces autres systèmes
  • Que prend-t-on comme informations en entrée ? Prend-t-on des données provenant d’autres systèmes informatiques ? Si oui, quels systèmes, quelles informations, quand, comment, sous quelle forme et avec quelles contraintes ? Prend-t-on des données provenant des utilisateurs (l’application ne sert-elle qu’à visualiser de l’information aux utilisateurs ou permet-elle aussi d’en saisir) ?
  • Que donne-t-on comme informations en sortie ? Envoie-t-on des informations à d’autres systèmes informatiques ? Si oui à quels systèmes, quelles informations, quand, comment, sous quelle forme et avec quelles contraintes ?

Quel sera le contexte général d’utilisation ?

  • Quelles sont les règles légales qui s’appliquent au contexte d’utilisation du projet (exemple : CNIL, droits des affaires, etc.) ?
  • Quelles sont les règles de sécurité qui s’appliquent au contexte d’utilisation du projet (milieu de la santé, application militaire) ?
  • Quelles sont les contraintes de fonctionnement que doit respecter le projet (temps maximum d’indisponibilité, tolérance aux pannes, etc.) ? Exemples : contrainte pour un programme servant à l’atterrissage d’un avion, système informatique d’un cœur artificiel, etc.
  • Quelles sont les règles internes, du client, qui doivent absolument être respectées par le projet (règles de codage, processus de validation, etc.) ?

Répondre au Où ?

Où sera utilisé le projet ?

  • Uniquement au sein de l’entreprise ou aussi à l’extérieur ? Avec un accès sécurisé ou sans accès sécurisé ? Avec un système d’identification fort ou pas ?
  • Dans un seul pays ou dans plusieurs pays ? Si oui, faudra-t-il gérer plusieurs langues ? Faudra-t-il prendre en compte les différences culturelles (exemple : code couleur, façon d’entrer les informations, etc.) ? Faudra-t-il gérer les différents créneaux horaires ?
  • Faudra-t-il tenir compte de contraintes horaires pour pouvoir effectuer certains traitements ?

Sur quels systèmes techniques sera utilisé le projet ?

  • Le projet nécessitera-t-il un seul « ordinateur » pour fonctionner en production ou plusieurs (solution centralisée ou répartie) ?
  • Est-ce une application en temps réel ou pas ? Si oui, quelles sont les contraintes associées ?
  • Est-ce une application embarquée ou pas ? Si oui, quelles sont les contraintes (puissance de calcul disponible, taille mémoire, résistance aux vibrations, etc.) ?
  • Le projet se basera-t-il sur un réseau informatique ou pas ?
  • Quelles plateformes sont concernées par le projet ? Doit-on développer pour Windows, Mac, Linux, processeurs ARM ou autres ? Doit-on prévoir une version pour tablettes ou téléphones portables et les deux versions seront-elles identiques ? Doit-on avoir des fonctionnalités différentes pour chaque plateforme utilisée ? Doit-on prévoir des bases de données embarquées ?

Répondre au Quand ?

Quand le projet doit être livré ?

  • Quand doit démarrer le projet ?
  • La date de livraison est-elle imposée ?
  • La date de livraison est-elle liée avec la livraison d’autres projets ?
  • La date de livraison est-elle liée avec des impératifs légaux ?

Un passage en production sous quelle forme ?

  • Peut-on livrer le projet en plusieurs lots et donc en plusieurs fois ? Si oui, dispose-t-on des dates prévues pour les différentes livraisons ainsi que les contenus attendus pour chaque livraison ou doit-on les déterminer ?
  • Peut-on envisager de déployer, après recettage, l’application auprès d’un nombre limité d’utilisateurs pour effectuer une étape de validation supplémentaire ? Si oui, sous quelle forme et pendant quelle durée ?
  • La montée en puissance sera-t-elle progressive (une partie des utilisateurs au début) ou immédiate (tous les utilisateurs dès le début) ? Et quel sera le calendrier de cette montée en charge ?

Répondre au Comment ?

Quels seront les moyens financiers alloués au projet ?

  • Quels moyens financiers globaux seront alloués au projet ?
  • Quelle sera l’autonomie de gestion du chef de projet sur les moyens financiers ?
  • Le budget est-il fixe est définitif ou est-il évolutif et, si oui, dans quelle mesure et avec quelles contraintes ?

Quels seront les moyens humains alloués au projet ?

  • Quelles sont les compétences nécessaires pour la bonne réalisation du projet ?
  • Combien de personnes pour l’équipe projet ?
  • Combien de ressources chez le client, pendant la durée du projet, et avec quelle disponibilité ?
  • Pourra-t-on choisir l’équipe projet ou celle-ci est-elle imposée ?
  • Les personnes de l’équipe projet se connaissent-elles ?
  • Les personnes de l’équipe projet sont-elles localisées sur plusieurs pays ? Parlent-elles la même langue ? Ont-elles l’habitude de travailler dans un contexte international ?
  • Quelles sont les compétences des personnes de l’équipe projet ?
  • Doit-on envisager une formation des personnes de l’équipe projet avant le démarrage du projet ?
  • Pourra-t-on faire appel à de l’expertise ou à des ressources externes ?
  • Le chef de projet aura-t-il « autorité » sur toutes les personnes de l’équipe projet ?

Quels seront les moyens « techniques » alloués au projet ?

  • Quel est le matériel qui sera mis à disposition du projet pendant la phase de réalisation ?
  • Quel est le matériel qui sera mis à disposition du projet pendant la phase de test et de recettage ?
  • Quel est le matériel qui sera mis à disposition du projet pour la mise en production ?
  • Doit-on réutiliser du matériel existant ? Si oui, avec quelles contraintes ?
  • Les outils informatiques ou langages de développement, à utiliser par le projet, sont-ils imposés ? Si la réponse est non, quelle est la marge de manœuvre du chef de projet pour les choisir ? Si la réponse est oui, quels sont ces outils et ces langages ?
  • Où sera l’équipe projet pendant les différentes phases du projet (un seul lieu géographique, plusieurs lieux géographiques, plusieurs bureaux, etc.)

Répondre au Pourquoi ?

Pourquoi le projet est-il lancé ?

  • Le projet est-il une réponse à une contrainte légale ?
  • Qu’attend le client de son projet (gains financiers, image de marque, etc.) ?
  • Est-ce que la non-réalisation du projet peut mettre en péril la survie du client (de la société) et éventuellement du prestataire qui réalise une partie ou la totalité du projet ?
Publié dans Evaluation | Marqué avec , | Commentaires fermés sur L’évaluation de la charge d’un projet : utilisation du QQOQCP

Le plan d’assurance qualité (PAQ) : Objectifs

Publié le 10 septembre 2014 par AdminArnaudBrossard
Le plan d'assurance qualité d'un projet

Le plan d’assurance qualité d’un projet

Dans le cadre de la gestion de projets d’une certaines importance ou dans le cadre de la réalisation d’une prestation auprès d’un client externe, il est souvent nécessaire de bien définir, dès le lancement du projet, les « règles » de fonctionnement du projet. C’est l’objectif de la mise en place Plan d’Assurance Qualité (PAQ).

Dans la suite de cet article, je vais essayer de vous présenter, de manière synthétique, le contenu et l’utilisation possible d’un Plan d’Assurance Qualité (PAQ).

Généralités

Le Plan Assurance Qualité (PAQ) définit les dispositions spécifiques prises par l’équipe projet et le client pour garantir la conformité des produits livrés avec les exigences spécifiées dans le cadre de la réalisation du projet.

Le rôle du Plan Assurance Qualité (PAQ) consiste à décrire :

  • Ce que l’on veut faire (les objectifs),
  • Le périmètre et les limites de la prestation,
  • Comment le faire,
  • Quand le faire,
  • Qui en a la responsabilité,
  • Qui va le faire,
  • Les moyens humains et matériels à mettre en œuvre,
  • Comment mesurer les résultats.

Le Plan Assurance Qualité est régulièrement actualisé en fonction des remarques et constatations faites au cours de la mise en pratique des procédures. Il n’est pas un document figé, mais un cadre organisationnel destiné à servir de document de référence à l’ensemble des intervenants, et à soutenir en permanence la gestion de la qualité.

Le Plan Assurance Qualité est un élément constitutif de la réalisation du projet. Les versions ultérieures, une fois approuvées l’équipe projet et le client, viendront se substituer à celle-ci au fur et à mesure de l’avancement u projet.

De manière générale, le Plan d’Assurance Qualité (PAQ) sera constitué d’un document couvrant la phase de « réalisation » de la prestation et évoluant au fur et à mesure de l’avancement de la phase prenant en compte :

  • Les dispositions générales sur l’organisation du projet et ce en termes de structures, outils, méthodes, documentation, cycle de vie, lotissement et jalonnement ;
  • Les dispositions particulières pour réceptionner les livrables (documents et produits logiciels).

Le Plan d’Assurance Qualité (PAQ) sera aussi constitué des dispositions adoptées pour mesurer la qualité intrinsèque des livrables par la définition de facteurs et critères mesurables de qualité.

Le Plan d’Assurance Qualité d’un projet spécifie les dispositions arrêtées entre l’équipe projet et le client pour garantir qu’une démarche qualitative sera associée à la réalisation du projet.

Cette démarche qualitative anticipe ce qui doit être fait tant au niveau organisationnel et structurel que sur les moyens techniques et ressources humaines à mettre en œuvre pour réussir, dans le cadre de la prestation, la prise en compte de développements Java dans les délais négociés conjointement entre les parties.

Objectifs du Plan d’Assurance Qualité

Le Plan d’Assurance Qualité (PAQ)  est le référentiel de l’assurance qualité du projet et est, en tant que tel, utilisé pour contrôler que toutes les dispositions prévues ont bien été mises en œuvre et réalisées.

Le Plan d’Assurance Qualité (PAQ) s’articule donc autour de trois types de préoccupations :

  • La production : outils, normes, méthodes, procédures et standards nécessaires à la bonne fin du projet considéré ;
  • Le management : organisation des travaux, mesures d’avancement, information des partenaires, l’ensemble articulé autour de la prise en compte des sept composantes du management de projet (Produit, Acteurs, Processus, Délais, Coûts, Performances et Cohérence globale) ;
  • L’organisation et l’animation du PAQ : ses caractéristiques, son champ d’action, ses acteurs, ses objets, ses procédures, sa mise en œuvre, son évolution et ses mesures de suivi.

Champ d’application du Plan d’Assurance Qualité

Le champ d’application d’un Plan d’Assurance Qualité (PAQ) couvre le suivi de la mise en œuvre des composantes d’un management de projet informatique et les conditions de leur mise en œuvre de manière cohérente :

  • Le détail des objectifs qualité des composantes « Produit » et « Processus » concerne la conduite, pour le maître d’œuvre, des tâches de spécifications fonctionnelles détaillées, du prototypage, de l’ergonomie et de la conception technique ;
  • Le détail des objectifs qualité concernant la composante « Acteurs » concerne l’organisation proprement dite du projet au travers des définitions des rôles et responsabilités, des principales tâches associées à chacun des rôles et des ressources humaines mises en œuvre ainsi que de la définition des méthodes, normes, outils et standards ;
  • Le détail des objectifs qualité concernant les composantes « Délai » et « Coûts » concerne la production d’une planification prévisionnelle et des coûts associés ainsi que des procédures de maîtrise et de réactualisation de l’ensemble durant le déroulement de la phase de conception détaillée ;
  • Le détail des objectifs qualité concernant la composante « Performances » concerne le management proprement dit de la qualité au travers des procédures de vérification du produit, des procédures de traitement des modifications, des procédures de réception, de l’identification et de la traçabilité des produits logiciels et de la maîtrise des jeux documentaires (responsabilités particulières, règles d’approbation, de diffusion et d’archivage).

Le Plan d’Assurance Qualité (PAQ) couvre également :

  • Les règles d’organisation du projet,
  • Les règles d’organisation du travail réparti entre maîtrise d’œuvre et maîtrise d’ouvrage,
  • Les règles de gestion de la documentation associée aux spécifications fonctionnelles détaillées, au prototypage, à l’ergonomie et à la conception technique.

Il engage tous les acteurs du projet aussi bien au niveau de l’équipe projet qu’au niveau du client.

Publié dans Document, Plan d'Assurance Qualité | Marqué avec , | Commentaires fermés sur Le plan d’assurance qualité (PAQ) : Objectifs