Vous voudrez toujours savoir exactement ce que vous devez accomplir avant de vous mettre à la tâche. Vous disposez de plusieurs membres d’équipe, et vous devez savoir exactement ce qu’ils feront pour atteindre les objectifs du projet. Vous occuper du processus de planification de la portée est la toute première chose que vous faites pour gérer votre portée. Planifier la portée du projet, c’est définir tous les travaux nécessaires pour atteindre avec succès les objectifs du projet. Au moment d’entreprendre un projet, il est important d’avoir une idée claire de tout le travail qui doit être effectué et, à mesure que le projet progresse, de tenir cette portée à jour dans le plan de gestion de la portée du projet.
Définir la portée
Vous avez déjà défini clairement les objectifs quantifiables du projet, mais vous devez maintenant planifier davantage et mettre par écrit tous les produits livrables intermédiaires et finaux que vous et votre équipe produirez au cours du projet. Les livrables comprennent tout ce que vous et votre équipe produisez dans le cadre du projet (c’est-à-dire tout ce que votre projet permettra de livrer). Les livrables de votre projet sont tous les produits ou les services que vous et votre équipe produisez pour le client ou le promoteur. Il s’agit de tous les documents intermédiaires, du plan, du calendrier, du budget, du schéma directeur et tout ce qui sera fait en cours de route, y compris tous les documents de gestion de projet que vous élaborez. Les livrables du projet sont des résultats tangibles, des résultats mesurables ou des éléments particuliers qui doivent être produits pour que le projet ou une phase du projet soit considéré comme achevé. Les livrables intermédiaires, comme les objectifs, doivent être précis et vérifiables.
Tous les livrables doivent être décrits avec un niveau de détail suffisant pour qu’ils puissent être différenciés des livrables connexes. Par exemple :
- Un avion bimoteur par rapport à un avion monomoteur
- Un marqueur rouge par rapport à un marqueur vert
- Un rapport journalier par rapport à un rapport hebdomadaire
- Une solution ministérielle par rapport à une solution d’entreprise
L’une des principales tâches du gestionnaire de projet consiste à consigner avec précision les livrables dans le cadre du projet, puis à gérer le projet de manière à ce que ces derniers soient produits conformément aux critères convenus. Les livrables sont les résultats de chaque phase de développement, décrits de manière quantifiable.
Exigences du projet
Après avoir définis tous les livrables, le gestionnaire de projet doit consigner toutes les exigences du projet. Les exigences décrivent les caractéristiques du livrable final, qu’il s’agisse d’un produit ou d’un service. Elles décrivent la fonctionnalité du livrable final ou les conditions précises auxquelles le livrable final doit satisfaire afin d’atteindre les objectifs du projet. Une exigence est un objectif qui doit être atteint. Les exigences du projet, définies dans le plan de la portée, décrivent ce qu’un projet doit accomplir et comment il est censé être créé et mis en œuvre. Les exigences répondent aux questions suivantes concernant l’état actuel et l’état futur des activités : qui, quoi, où, quand, combien et comment fonctionne un processus opérationnel?
Les exigences peuvent comprendre des attributs tels que les dimensions, la facilité d’utilisation, la couleur, les ingrédients particuliers, et ainsi de suite. Si nous reprenons l’exemple de l’entreprise qui produit du lait de poule pour les Fêtes, l’un des principaux produits livrables est la boîte qui contient le lait de poule. Les exigences relatives à ce livrable peuvent comprendre la conception de la boîte, les images qui figureront sur la boîte, le choix des couleurs, etc.
Les exigences qui précisent à quoi doit ressembler le livrable final du projet et sa fonction. Les exigences doivent être mesurables, testables, liées à des besoins ou à des occasions commerciales cernés et suffisamment définis pour la conception du système. Elles peuvent être divisées en six catégories de base : exigences fonctionnelles, exigences non fonctionnelles, exigences techniques, exigences commerciales, exigences de l’utilisateur et exigences réglementaires.
Exigences fonctionnelles
Les exigences fonctionnelles décrivent les caractéristiques du livrable final dans un langage ordinaire et non technique. Elles doivent être compréhensibles pour les clients, et ces derniers doivent participer directement à leur élaboration. Les exigences fonctionnelles sont ce que vous voulez que le livrable fasse.
Exemple : achat de véhicules
Si vous achetez des véhicules pour une entreprise, votre exigence fonctionnelle pourrait être la suivante : « Les véhicules devraient pouvoir transporter jusqu’à une tonne de matériel d’un entrepôt à un magasin. »
Exemple : achat d’un système informatique
Pour un système informatique, vous pouvez définir ce que le système doit faire : « Le système doit consigner tous les détails de la commande d’un client. »
Ce qu’il faut retenir, c’est qu’il faut préciser ce que l’on veut et non pas la manière dont cela sera réalisé.
Exigences non fonctionnelles
Les exigences non fonctionnelles précisent les critères qui peuvent servir à évaluer le produit ou le service final fourni par votre projet. Il s’agit de restrictions ou de contraintes à imposer au livrable et à la manière de le construire. Leur objectif est de limiter le nombre de solutions qui répondront à un ensemble d’exigences. Si l’on reprend l’exemple des véhicules, l’exigence fonctionnelle est la suivante : un véhicule doit transporter une charge d’un entrepôt à un magasin. Sans aucune contrainte, les solutions proposées peuvent déboucher sur un camion de petite ou de grande taille. Les exigences non fonctionnelles peuvent être divisées en deux types : rendement et développement.
Pour limiter les types de solutions, vous pouvez inclure ces contraintes de rendement :
- Les camions achetés doivent être fabriqués en Amérique en raison des incitatifs gouvernementaux.
- La zone de chargement doit être couverte.
- La zone de chargement doit avoir une hauteur d’au moins trois mètres.
De même, pour l’exemple du système informatique, vous pouvez préciser des valeurs pour les types génériques de contraintes de rendement :
- Le temps de réponse des renseignements est affiché à l’écran pour l’utilisateur.
- Le nombre d’heures pendant lesquelles un système doit être accessible.
- Le nombre d’enregistrements qu’un système doit pouvoir contenir.
- La capacité du système doit pouvoir être augmentée à même ce dernier.
- La durée de conservation d’un document à des fins de vérification.
Pour l’exemple des dossiers clients, les contraintes pourraient être les suivantes :
- Le système doit être accessible de 9 h à 17 h du lundi au vendredi.
- Le système doit pouvoir contenir 100 000 dossiers de clients au départ.
- Le système doit pouvoir ajouter 10 000 dossiers par année pendant dix ans.
- Un dossier doit être pleinement accessible dans le système pendant au moins sept ans .
Un point important de ces exemples est qu’ils limitent le nombre de solutions pouvant vous être proposées par le développeur. En plus des contraintes de rendement, vous pouvez inclure des contraintes de développement.
Il existe trois grands types de contraintes de développement non fonctionnelles :
- Échéancier : Moment où un produit livrable doit être livré.
- Ressources : Somme d’argent disponible pour mettre au point le livrable.
- Qualité : Toutes les normes à respecter pour élaborer le livrable, les méthodes de développement, etc.
Exigences techniques
Les exigences techniques découlent des exigences fonctionnelles et visent à répondre aux questions suivantes : comment le problème sera-t-il résolu cette fois-ci et le sera-t-il d’un point de vue technologique et/ou procédural? Elles précisent comment le système doit être conçu et mis en œuvre pour fournir les fonctionnalités et les caractéristiques opérationnelles requises.
Dans le cadre d’un projet de logiciel par exemple, les exigences fonctionnelles peuvent préciser qu’un système de base de données sera mis au point pour permettre d’accéder à des données financières par l’entremise d’un terminal à distance. Les exigences techniques correspondantes précisent les éléments de données requis, le langage dans lequel le système de gestion de la base de données sera conçu (connaissances détenues à l’interne), le matériel qui hébergera le système (infrastructure existante), les protocoles de télécommunication qui devraient être utilisés, etc.
Exigences opérationnelles
Les exigences opérationnelles sont les besoins de l’organisme promoteur, toujours du point de vue de la gestion. Les exigences opérationnelles sont des énoncés sur la raison d’être du projet. Elles décrivent généralement les résultats généraux et la satisfaction des besoins de l’entreprise, plutôt que les fonctions spécifiques que le système doit exécuter. Ces exigences découlent de la vision du produit qui, à son tour, est guidée par les buts et les objectifs de la mission (ou de l’entreprise).
Exigences de l’utilisateur
Les exigences de l’utilisateur décrivent ce que les utilisateurs doivent faire avec le système ou le produit. L’accent est mis sur l’expérience que vit l’utilisateur lorsqu’il utilise le système dans tous les scénarios. Ces exigences constituent la base des phases de développement de l’interface utilisateur et de conception des cas de test du système.
Exigences réglementaires
Les exigences réglementaires peuvent être internes ou externes et ne sont généralement pas négociables. Il s’agit des restrictions, des autorisations et des lois applicables à un produit ou à une entreprise qui sont imposées par le gouvernement.
Exemple d’exigences
Les guichets automatiques bancaires (GAB) peuvent servir à illustrer un large éventail de besoins (figure 9.1). Quelles sont les caractéristiques physiques de ces machines, et quelles fonctions exécutent-elles pour les clients de la banque? Pourquoi les banques ont-elles mis ces systèmes en place? Quelles sont les exigences opérationnelles globales?
Voici un exemple possible de chaque type d’exigence qui pourrait s’appliquer au guichet automatique bancaire externe d’une banque.
- Exigence fonctionnelle du GAB : Le système permettra à l’utilisateur de choisir d’obtenir ou non un reçu de transaction sur papier avant d’effectuer une transaction.
- Exigence non fonctionnelle du GAB : Tous les affichages seront en blanc, en police Arial de 14 points sur fond noir.
- Exigence technique du GAB : Le système de GAB se connectera directement à la base de données existante du client.
- Exigence de l’utilisateur du GAB : Le système permettra d’effectuer un retrait ordinaire à partir d’un compte personnel, de l’ouverture de session à l’encaissement, en moins de deux minutes.
- Exigence opérationnelle du GAB : En offrant un service de qualité supérieure à nos clients au détail, le réseau de GAB de la Banque Monumentale nous permettra d’augmenter les revenus des frais de service associés de 10 % par année sur une base continue.
- Exigence réglementaire du GAB : Tous les GAB seront connectés à des sources d’alimentation électriques ordinaires dans le territoire municipal et seront alimentés par une source d’alimentation sans interruption approuvée par l’entreprise.
La définition efficace des exigences est l’une des tâches les plus difficiles que doivent accomplir les gestionnaires de projet. Des exigences mal définies garantissent des résultats médiocres.
La consignation des exigences va bien au-delà de la simple rédaction des exigences telles que l’utilisateur les perçoit; elle doit couvrir non seulement les décisions qui ont été prises, mais aussi les raisons de celles-ci. Il est essentiel de comprendre le raisonnement suivi pour parvenir à une décision afin d’éviter les répétitions. Par exemple, le fait qu’un élément particulier ait été exclu parce qu’il n’est tout simplement pas réalisable doit être consigné. Autrement, des heures de travail pourraient être gaspillées, et des travaux pourraient être accomplis de nouveau si un intervenant demande que la fonctionnalité soit rétablie pendant le développement ou les essais.
Une fois les exigences consignées, demandez aux intervenants de confirmer leurs exigences par une signature.
Si le gestionnaire de projet est chargé de veiller à la consignation des exigences, cela ne signifie pas qu’il s’est acquitté de cette tâche. Le gestionnaire de projet sollicite l’aide de tous les intervenants (analystes opérationnels, analystes des exigences, responsables des processus opérationnels, clients et autres membres de l’équipe) pour mener les discussions, les séances de remue-méninges et les entretiens, et pour consigner et approuver par une signature les exigences. Le gestionnaire de projet n’est responsable que de la mise en place du processus et de sa facilitation. Si le gestionnaire de projet estime que la qualité du document est douteuse, il doit suspendre le processus d’élaboration.
Le gestionnaire de projet évalue les exigences, les ajoute à la bibliothèque de documents du projet et les utilise pour établir le plan du projet.
Rudiments des exigences logicielles
Cette section fait référence aux exigences du « logiciel » parce qu’elle concerne les problèmes à traiter par le logiciel. Une exigence logicielle est une propriété que doit présenter un logiciel développé ou adapté pour résoudre un problème particulier. Le problème peut consister à automatiser une partie de la tâche d’une personne qui utilisera le logiciel, à soutenir les processus opérationnels de l’organisation qui a commandé le logiciel, à corriger les lacunes d’un logiciel existant, à contrôler un appareil, etc. Le fonctionnement des utilisateurs, des processus opérationnels et des appareils est généralement complexe. Par conséquent, les exigences relatives à un logiciel particulier découlent généralement d’une combinaison complexe d’exigences formulées par différentes personnes à différents échelons d’une organisation et de l’environnement dans lequel le logiciel sera utilisé.
Une propriété essentielle de toutes les exigences logicielles est qu’elles soient vérifiables. Il peut être difficile ou coûteux de vérifier certaines exigences logicielles. Par exemple, la vérification de l’exigence de capacité de traitement d’un centre d’appels peut nécessiter le développement d’un logiciel de simulation. Le personnel chargé des exigences logicielles et de la qualité des logiciels doit s’assurer que les exigences peuvent être vérifiées dans les limites des ressources disponibles.
Les exigences ont d’autres attributs qui s’ajoutent aux propriétés comportementales qu’elles expriment. Parmi les exemples les plus courants, citons le classement des priorités, qui permet de faire des compromis dans un contexte de ressources limitées, et la valeur de l’état d’avancement, qui permet de suivre l’évolution du projet. En règle générale, les exigences logicielles sont désignées de manière unique afin qu’elles puissent faire l’objet d’une surveillance tout au long du cycle de vie du logiciel.
Exigences de mesure
D’un point de vue pratique, il est généralement utile d’avoir une idée du volume des exigences pour un produit logiciel particulier. Ce chiffre est utile pour évaluer l’importance d’une modification des exigences, pour estimer le coût d’une tâche de développement ou de maintenance, ou simplement pour être utilisé comme dénominateur dans d’autres mesures (voir le tableau 9.1).
| Propriété | Mesure |
|---|---|
| Vitesse | Transactions traitées/seconde Temps de réponse de l’utilisateur/de l’événement Temps de rafraîchissement de l’écran |
| Taille | Kilo-octets Nombre de puces de mémoire vive |
| Facilité d’utilisation | Temps d’apprentissage Nombre de d’encadrés d’aide |
| Fiabilité | Durée moyenne de fonctionnement avant défaillance Probabilité d’indisponibilité Taux d’occurrence des défaillances Disponibilité |
| Robustesse | Temps de redémarrage après une défaillance Pourcentage d’événements à l’origine de la défaillance Probabilité de corruption des données en cas de défaillance |
| Portabilité | Pourcentage d’instructions dépendantes cibles Nombre de systèmes cibles |
Éléments relatifs à la portée
Le gestionnaire de projet réunit les données initiales du projet en se fondant sur la charte de projet. Les renseignements généraux sur le lieu de travail de l’intervenant, les règles et le modèle opérationnel existants, etc. aident à créer la vision du produit/service final et, par conséquent, la portée du projet (voir la figure 9.2).
Techniques
Les gestionnaires de projet chevronnés ont assurément accès à un plus grand répertoire de techniques de planification de la portée. Un gestionnaire de projet expérimenté peut mettre à profit ses expériences passées avec des projets similaires pour déterminer le travail qu’il est possible de réaliser de manière réaliste, compte tenu des contraintes de temps et de coût, pour un projet en cours. Il est également indispensable de posséder des compétences en matière de communication et de négociation. Les gestionnaires de projet doivent informer les intervenants des répercussions de certaines exigences sur le projet. La complexification d’un projet peut nécessiter plus de personnel, de temps et/ou d’argent. Elle peut également avoir une incidence sur la qualité du projet. Certains aspects du projet peuvent être irréalisables; les intervenants devront être mis au courant afin d’ajuster leur vision ou de se préparer aux défis futurs.
Le rassemblement des exigences fait partie du processus de définition de la portée et peut être effectué à l’aide d’une ou de plusieurs des techniques suivantes :
- Entretiens
- Groupes de discussion
- Animation de séances de développement conjoint d’applications (DCA)
- Techniques pour favoriser la créativité en groupe : remue-méninges, groupes nominaux, méthode Delphi, arbre conceptuel, diagramme d’affinité
- Prototypage
- Observation
- Questions et sondages
- Techniques de prise de décision en groupe : unanimité, majorité, pluralité, dictature
Matrice de traçabilité des exigences
La matrice de traçabilité des exigences est un tableau qui lie les exigences à leur origine et les retrace tout au long du cycle de vie du projet. La mise en œuvre d’une matrice de traçabilité des exigences permet de s’assurer que chaque exigence apporte une valeur ajoutée à l’entreprise en la liant aux objectifs de l’entreprise et du projet. Elle permet de suivre les exigences tout au long du cycle de vie du projet, ce qui contribue à garantir que les exigences approuvées lors de la consignation des exigences sont livrées à la fin du projet. Enfin, elle fournit une structure pour gérer les modifications de la portée du produit. Ce processus comprend notamment le suivi des éléments suivants :
- Exigences relatives aux besoins, aux occasions, aux buts et aux objectifs opérationnels
- Exigences relatives aux objectifs du projet
- Exigences relatives à la portée du projet/aux livrables de la structure de répartition du travail
- Exigences relatives à la conception des produits
- Exigences relatives à l’élaboration des produits
- Exigences relatives à la stratégie et aux scénarios d’essai
- Des exigences globales à des exigences plus détaillées
Les attributs associés à chaque exigence peuvent être consignés dans la matrice de traçabilité des exigences. Ces attributs aident à définir des renseignements importants relatifs à l’exigence. Les attributs habituellement utilisés dans la matrice de traçabilité des exigences peuvent comprendre un identifiant unique, une description textuelle de l’exigence, la justification de l’inclusion, le propriétaire, la source, la priorité, la version, l’état actuel (comme actif, annulé, différé, ajouté, approuvé) et la date d’achèvement. Les attributs supplémentaires qui aident à veiller à ce que l’exigence satisfasse les intervenants peuvent comprendre la stabilité, la complexité et les critères d’acceptation.
Champs de la matrice
Les éléments ci-dessous ne sont que des suggestions et peuvent varier en fonction des exigences de l’organisation et du projet.
- Numéro d’identification unique contenant la catégorie générale de l’exigence (p. ex. SYSADM) et un numéro attribué dans un ordre croissant (p. ex. 1.0, 1.1, 1.2)
- Énoncé de l’exigence
- Source de l’exigence (conférence, tableau de contrôle de la configuration, attribution de tâches, etc.)
- Numéro du paragraphe de spécification des exigences du logiciel/des exigences fonctionnelles contenant l’exigence
- Numéro du paragraphe de spécification de la conception contenant l’exigence
- Module du programme contenant l’exigence
- Spécification d’essai contenant l’essai de l’exigence
- Numéro(s) du dossier d’essai dans le cadre duquel l’exigence doit être testée (facultatif)
- Vérification des essais réussis des exigences
- Champ Modification (si une exigence a été modifiée, éliminée ou remplacée, indiquer la disposition et l’autorité responsable de la modification)
- Remarques
Requirements Traceability Matrix par DHWiki sous licence Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 licence aux États-Unis.
Structure de répartition du travail
Maintenant que les livrables et les exigences sont bien définis, le processus de division du travail du projet par l’entremise d’une structure de répartition du travail (SRT) peut commencer. La SRT définit la portée du projet et divise le travail en éléments qui peuvent être planifiés et évalués et faire facilement l’objet de mesures de suivi et de contrôle. L’idée qui sous-tend la SRT est simple : subdiviser une tâche complexe en tâches plus petites jusqu’à ce que l’on atteigne un degré qui ne peut plus être subdivisé. Tous ceux qui connaissent l’organisation des dossiers et des fichiers dans la mémoire d’un ordinateur ou qui ont fait des recherches sur l’arbre généalogique de leurs ancêtres sont bien au fait de ce concept. Vous arrêtez de diviser le travail lorsque vous atteignez un degré suffisamment bas pour évaluer la précision souhaitée. À ce stade, il est généralement plus facile d’évaluer la durée et le coût de la petite tâche que d’évaluer ces facteurs à des degrés plus élevés. Chaque degré descendant de la SRT représente un degré plus élevé de définition détaillée des travaux du projet.
La SRT décrit les produits ou les services à fournir dans le cadre du projet et la manière dont ils sont divisés et liés. Il s’agit de la division d’un projet en éléments plus petits, axée sur les résultats attendus. Elle définit et regroupe les éléments de travail distincts d’une manière qui aide à organiser et à définir la portée totale des travaux du projet.
La SRT fournit également le cadre de travail nécessaire pour contrôler les coûts et en faire une estimation détaillée, en plus de proposer des orientations pour élaborer et contrôler le calendrier.
Aperçu
La SRT est une décomposition hiérarchique du projet en phases, en livrables et en lots de travail. Il s’agit d’une structure arborescente qui montre une subdivision des efforts nécessaires pour atteindre un objectif (p. ex. un programme, un projet et un contrat). Dans le cadre d’un projet ou d’un contrat, la SRT subdivise d’abord l’objectif final en composantes gérables sur le plan de la taille, de la durée et de la responsabilité (p. ex. systèmes, sous-systèmes, composantes, tâches, sous-tâches et lots de travail), qui comprennent toutes les étapes nécessaires à l’atteinte de l’objectif.
Les étapes de création de la SRT :
- Énumération de tous les extrants du projet (livrables et autres résultats directs).
- Détermination de toutes les activités nécessaires à la livraison des extrants.
- Subdivision de ces activités en sous-activités et en tâches.
- Détermination du livrable et des étapes de chaque tâche.
- Détermination de la durée d’utilisation de toutes les ressources (personnel et matériel) nécessaires à l’achèvement de chaque tâche.
L’élaboration d’une SRT vise à :
- faciliter la gestion de chaque composante;
- estimer précisément les délais, les coûts et les ressources nécessaires;
- faciliter l’affectation des ressources humaines;
- faciliter l’attribution des responsabilités des activités.
Exemple de SRT
Pour nettoyer une pièce, je commencerais par ramasser les vêtements, les jouets et les autres objets qui se trouvent sur le plancher. Je pourrais utiliser un aspirateur pour nettoyer la moquette. Je pourrais enlever les rideaux et les apporter chez le nettoyeur, puis dépoussiérer les meubles. Toutes ces tâches sont des sous-tâches effectuées pour nettoyer la pièce. Pour ce qui est de passer l’aspirateur dans la pièce, je sortirais l’aspirateur du placard, brancherais le tuyau, viderais le sac et remettrais l’appareil dans le placard. Il s’agit de tâches plus petites à effectuer dans le cadre de la tâche secondaire appelée « passer l’aspirateur ». La figure 9.3 montre comment cela peut être représenté sous forme de SRT.
Source : Project Management Skills for All Careers
Il est très important de noter que l’ordre dans lequel le travail sera effectué et les interrelations entre les tâches ne doivent pas être pris en compte au moment d’élaborer une SRT. Cette question sera abordée lors de l’élaboration du calendrier. Par exemple, au point 3.0 « Passer l’aspirateur », il est évident que le point 3.3 « Passer l’aspirateur sur la moquette » doit être effectué après le point 3.4 « Raccorder le tuyau et la fiche »! Il se peut que vous commenciez tout de même à réfléchir de manière séquentielle, car il semble que ce soit dans la nature humaine de le faire. L’élaboration d’une SRT vise essentiellement à saisir toutes les tâches, quel que soit leur ordre. Par conséquent, si vous remarquez que vous-même et d’autres membres de votre équipe réfléchissez de manière séquentielle, ne vous en faites pas trop, mais n’essayez pas de schématiser la séquence, car vous ralentiriez le processus de détermination des tâches. Une SRT peut être structurée de la manière qui vous convient le mieux et qui convient le mieux à votre projet. Dans la pratique, la structure en tableau est très souvent utilisée, mais la SRT peut également prendre la forme d’une liste (figure 9.4).
Source : Project Management Skills for All Careers
Dans les deux figures, chaque élément à chaque niveau de la SRT s’accompagne d’un identifiant unique. Cet identifiant unique est généralement un nombre qui sert à effectuer le résumé et le suivi des coûts, des échéanciers et des ressources associés aux éléments de la SRT. Ces chiffres sont généralement associés au plan comptable de l’entreprise, qui permet de suivre les coûts par catégorie. Collectivement, ces identifiants numériques sont connus sous le nom de « code de comptes ».
Il existe également de nombreuses autres façons d’organiser une SRT. On peut, par exemple, l’organiser par livrables ou par phases. Les principaux produits livrables du projet constituent le premier niveau de la SRT. Par exemple, si vous réalisez un projet multimédia, les livrables peuvent comprendre la production d’un livre, d’un CD et d’un DVD (figure 9.5).
De nombreux projets sont structurés ou organisés par phase du projet (figure 9.6). Chaque phase représente le premier niveau de la SRT, et ses livrables constituent le niveau suivant, et ainsi de suite.
Le gestionnaire de projet est libre de déterminer le nombre de niveaux de la SRT en fonction de la complexité du projet. Vous devez inclure suffisamment de niveaux pour estimer avec précision la durée et les coûts du projet sans utiliser trop de niveaux pour qu’il soit difficile de faire la distinction entre les composantes. Quel que soit le nombre de niveaux d’une SRT, le niveau le plus bas est appelé « lot de travail ».
Les lots de travail sont les éléments qui peuvent être facilement attribués à une personne ou à une équipe de personnes, et qui définissent clairement la responsabilité pour achever la tâche. C’est au niveau du lot de travail que la durée, les coûts et les ressources sont estimés.
Règle des 100 %
La règle des 100 % est le critère le plus important dans l’élaboration et l’évaluation d’une SRT. La règle stipule que chaque niveau de subdivision (enfant) doit représenter 100 % du travail applicable à l’élément immédiatement supérieur (parent). Autrement dit, si chaque niveau de la SRT suit la règle des 100 % pour les activités, cela signifie que 100 % des activités auront été déterminées au moment d’élaborer le calendrier du projet. Au moment d’établir le budget du projet, 100 % des coûts ou des ressources nécessaires auront été déterminés.
Énoncé relatif à la portée
Les énoncés relatifs à la portée peuvent prendre de nombreuses formes en fonction du type de projet mis en œuvre et de la nature de l’organisation. L’énoncé relatif à la portée détaille les livrables du projet et décrit les principaux objectifs. Les objectifs doivent comprendre des critères de réussite mesurables pour le projet.
L’énoncé relatif à la portée décrit, en termes très généraux, le produit du projet, par exemple : « élaboration d’un système informatisé permettant de saisir et de suivre les commandes de logiciels ». Un énoncé relatif à la portée doit également comprendre la liste des utilisateurs du produit ainsi que les caractéristiques du produit résultant.
En règle générale, un énoncé relatif à la portée comprend les éléments suivants :
- Le nom du projet
- La charte de projet
- Le propriétaire du projet, les promoteurs et les intervenants
- L’énoncé du problème
- Les buts et les objectifs du projet
- Les exigences du projet
- Les livrables du projet
- Les aspirations du projet (ce qui est hors de la portée)
- Les principales étapes
- Les estimations des coûts
Dans les organisations davantage axées sur les projets, l’énoncé relatif à la portée peut également contenir les sections suivantes, entre autres :
- Plan de gestion de la portée du projet
- Demandes de modification approuvées
- Hypothèses et risques du projet
- Critères d’acceptation du projet
Attribution
Ce chapitre du livre Gestion de projet est une copie dérivée de Project Management par Merrie Barron et Andrew Barron, sous licence Creative Commons, Attribution 3.0, non transposé, Project Management/PMBOK/Scope Management et Development Cooperation Handbook/Designing and Executing Projects/Detailed Planning or design stage par Wikibooks, sous licence Creative Commons Attribution 3.0, partage dans les mêmes conditions, Structure de répartition du travail par Wikipédia L’encyclopédie libre, sous licence Creative Commons Attribution 3.0, partage dans les mêmes conditions, et 100 Percent Rule par Pabipedia, sous licence, Creative Commons Attribution 3.0, partage dans les mêmes conditions.
