Tout le monde en convient : la seule constante dans le monde, c’est le « Changement ». Vous pouvez concevoir des plans parfaits, mais ils ne représentent rien face à n’importe quel changement potentiel qui pourrait survenir. Plus la durée de votre projet est longue, plus vous aurez probablement affaire à des changements.

C’est la raison pour laquelle le processus TenStep conçoit très bien que les processus de définition initiale (processus 1) et de planification (processus 2) ne soient pas parfaits. Votre équipe et vous-même devez accomplir le meilleur travail que vous pouvez, étant donné l’état de vos connaissances au moment où vous l’effectuez. Et c’est déjà bien ainsi. Par la suite, vous devez gérer le contenu.

Diagramme de flux simplifié

Si vous examinez les raisons pour lesquelles les projets échouent, vous vous trouvez habituellement confronté à deux problèmes : soit que l’équipe n’a pas passé assez de temps à définir le travail, soit qu’il y avait un manque de management du contenu du projet. Même si le chef de projet a réalisé un bon travail au niveau de la définition du contenu, la partie difficile est de gérer le projet à l’intérieur de ce contenu, tel qu’il a été convenu au départ.« Contenu »  est le terme utilisé pour désigner la totalité du travail ainsi que les limites du projet. Le contenu est utilisé pour définir ce que le projet livrera et ce qu’il ne livrera pas. Pour les plus grands projets, la définition du contenu peut inclure les livrables importants qui sont créées, les organisations concernées, les transactions affectées, les types de données incluses, etc.

Le but du management du contenu du projet est de protéger la viabilité de la charte du projet approuvée et celle des exigences commerciales, elles aussi approuvées. En d’autres termes, la charte du projet définit le contenu global du projet, alors que les exigences commerciales définissent les livrables dans le détail. L’équipe du projet s’est engagée pour une date limite et un budget, sur la base de cette définition, à la fois générale et détaillée, du contenu du projet. Si un changement des livrables est effectué pendant le projet (et habituellement cela signifie que le client réclame des éléments supplémentaires), les estimations initiales du coût, de l’effort de travail, et de la durée peuvent ne plus être valides. Si le commanditaire accepte d’inclure le nouveau travail dans le contenu du projet, le chef de projet a le droit d’exiger que les coûts, l’effort de travail et/ou la durée soient modifiés (habituellement, ils s’accroissent) pour justifier ce travail supplémentaire. Ces nouvelles estimations de coût, d’effort de travail et de durée deviennent alors le nouvel objectif approuvé.Modifications du contenu (5.0. P2)

Parfois, le chef de projet pense que la gestion du contenu revient à dire « non » au client. Cela peut rendre le chef de projet nerveux et le mettre mal à l’aise.

Ce qu’il faut garder à l’esprit, c’est qu’une gestion efficace du contenu n’a d’autre intérêt que d’amener le commanditaire à prendre des décisions qui entraîneront des modifications du contenu.

Cela est très important. Peu de clients peuvent voir et exprimer chaque spécification à l’avance. Par conséquent, il y a habituellement des changements qui doivent être introduits dans le projet. Ces changements peuvent s’avérer tout à fait nécessaires pour la solution, et il peut y avoir des raisons commerciales valides pour lesquelles ils devront être pris en compte. Le chef de projet et l’équipe de projet doivent savoir quand ces changements deviennent incontournables. Ils doivent alors suivre un processus prédéfini de modification du contenu. Ce processus fournit, en fin de compte, les informations appropriées au commanditaire du projet et lui permet de décider si la modification doit être approuvée en se basant sur la valeur marchande ainsi que sur l’impact pour le projet, en termes de coûts et de délais.

 5.0.1 La nature du contenu

     5.1 Gérer le contenu / Processus

     5.2 Gérer le contenu / Techniques

     5.3 Gérer le contenu / Références rapides

   5.1.3.1 Créer le plan de management du contenu

   5.1.3.2 Créer un plan de management des exigences

   5.1.3.3 Réunir les exigences

  5.1.3.4 Vérifier le contenu

Définir le contenu est peut-être la partie la plus importante de la définition et du procédé de planification initiaux. Si vous ne savez pas ce que vous devez livrer et où se situe le périmètre du projet, vous n’avez aucune chance de le mener à bien. Si vous n’avez pas fait un bon travail de définition du contenu, la gestion de celui-ci sera presque impossible.

Il y a deux niveaux de définition du contenu – haut niveau et bas niveau.

Les livrables. Même si vous n’êtes pas encore sûr de savoir ce que vous devez incorporer dans la définition de votre contenu, vous devez toujours inclure vos livrables. Le fait de comprendre les livrables que vous produisez concorde avec la compréhension du contenu du projet.L’objectif de la définition du contenu est de décrire clairement les frontières logiques de votre projet et d’obtenir un accord à leur sujet. L’énoncé du contenu sert à définir ce qui est situé ou non à l’intérieur du périmètre du projet. Plus vous pouvez identifier des aspects du contenu, plus votre projet aura de chances de bien se dérouler. Définir le contenu de votre projet comporte deux aspects importants : les livrables et les limites.

• Tous vos livrables finaux doivent évidemment être listés. Il s’agit des livrables que vous produisez pour votre client. En outre, vous pouvez lister les livrables internes axés sur le client, tel que le rapport sur les exigences commerciales ainsi que l’évaluation de la situation courante. Ces livrables doivent être approuvés par le client. Il sera ainsi raisonnable de les mentionner. D’autre part, vous n’aurez pas besoin de faire référence à d’autres documents internes au projet, tels que l’échéancier du projet, les spécifications de la conception technique ou les protocoles de tests. Le commanditaire ne comprend pas ces livrables. De toute façon, il n’y prêtera pas attention.

• Limites du projet. Les énoncés relatifs aux limites sont utilisés
  pour décrire les aspects de l’environnement inclus dans le contenu versus ceux qui ne le sont pas. Vous n’aurez pas besoin de mentionner qu’un certain aspect du projet était dans le contenu à moins que vous puissiez aussi indiquer, en contrepartie, qu’un certain autre aspect n’est pas inclus dans le contenu. La nature d’un véritable énoncé de limite est qu’il y a une contrepartie dans le contenu et une autre contrepartie pertinente qui ne l’est pas. Par exemple :

  • Les principaux processus du cycle de vie qui sont dans le contenu ou hors de celui-ci.Votre projet peut inclure seulement la phase d’analyse, et pas celles de conception, de construction, d’essais, etc.

  • Les types de données qui sont dans le contenu et hors du contenu. L’expression « types de données » se rapporte à des livrables tels que des «données financières », des « données concernant les ventes » ou des « données concernant les employés ». Il se peut que votre projet utilise certains types de données et pas d’autres.

  • Les sources de données (ou bases de données) qui sont dans le contenu et hors de celui-ci. Il y a des similitudes avec les types de données, excepté le fait que vous fassiez référence à des agrégats de données, tels que la base de données des clients, le grand livre, le système de facturation, etc. (ces sources de données peuvent comporter plus d’un type de données).

  • Les organisations qui sont dans le contenu et hors de celui-ci : Dans certains cas, les organisations concernées par le projet peuvent aider à délimiter le périmètre du projet. Par exemple, le produit de votre projet peut être applicable aux directions « ressources humaines » ou « comptabilité », alors que la division « fabrication » serait en dehors du contenu.

  • Les fonctionnalités principales qui sont dans le contenu et celles qui sont hors du contenu. Par exemple, la fonctionnalité qui aide à la décision et à la gestion des rapports d’avancement. Les fonctionnalités peuvent être incluses dans le contenu, alors que la fonctionnalité concernant le traitement des données, effectué la nuit, serait en dehors du contenu.

Quand le projet a été initialement proposé en vue de son financement, il doit y avoir un ensemble d’objectifs généraux et des livrables initiaux définis. Il pouvait aussi y avoir un énoncé général du contenu. Toutes les informations qui ont été rassemblées précédemment devraient être utilisées comme point de départ pour une formulation plus détaillée du contenu, en vue de l’élaboration de la charte du projet. Si vous constatez que vous n’avez pas assez d’information pour aboutir à un énoncé clair et compréhensible du contenu, vous devez travailler avec le commanditaire pour recueillir des renseignements complémentaires. C’est l’un des principaux objectifs des processus de définition et de planification.

S’il existe des objectifs ayant été définis pour le projet, consultez-les pour en tirer profit dans l’élaboration de l’énoncé du contenu. Par définition, il faut créer un ou plusieurs livrables pour réaliser chaque objectif. Définir les livrables du projet est l’un des aspects fondamentaux de la définition du contenu du projet. Après avoir déterminé les principaux livrables que le projet produira, commencez à poser d’autres questions pour déterminer de nouveaux aspects du contenu. Les livrables décrivent ce que le projet doit livrer. Vous pouvez également identifier quelles organisations seront concernées, quels types de données et quels dispositifs et fonctionnalités fondamentaux seront nécessaires, etc.

Pour plus de clarté et de précision, vous pouvez également identifier ce qui n’est pas compris dans le projet en décrivant des livrables possibles mais qui ne seront quand même pas créés, quelles organisations ne seront pas impliquées, quels dispositifs et fonctions ne seront pas inclus, etc. Naturellement, il existe un nombre infini d’éléments en dehors du contenu. Dans le cadre de la définition du contenu, vous inclurez seulement ceux qui aident à définir le périmètre du projet et qui abordent des domaines connexes pour lesquels le lecteur pourrait se poser des questions. Par exemple, si vous installez un progiciel financier, vous pouvez déclarer que le progiciel de comptabilité de paiement se trouve « dans le contenu », mais que le système connexe des achats est « hors du contenu ». Cependant, vous ne devez pas énumérer tous les autres systèmes comme étant hors du contenu, mais seulement ceux à propos desquels le lecteur pourrait se poser des questions.

Une bonne pratique de gestion de projet consiste à lister les organisations comprises dans le contenu et celles qui ne le sont pas. Les parties prenantes peuvent alors savoir plus facilement si elles sont impliquées et si l’on attend qu’elles apportent leur concours au projet. Par ailleurs, une autre raison très importante pour identifier les organisations qui sont dans le contenu, réside dans la possibilité d’avoir besoin de personnel ou d’autres compétences provenant de ces organisations, soit en tant que membres de l’équipe, soit pour participer au comité de pilotage, pour ne citer que ces deux exemples.

Quand vous avez terminé l’élaboration de vos énoncés d’objectifs et de contenu, revenez en arrière pour vous assurer qu’ils soient cohérents. Tous les objectifs doivent aboutir à un livrable qui matérialise leur réalisation. Si vous ne faites rien pour atteindre un objectif, vous ne pourrez jamais le réaliser.

De même, tous les livrables listés dans l’énoncé du contenu doivent être nécessaires pour satisfaire les objectifs énoncés. Vous ne voulez pas produire des éléments non essentiels à l’atteinte des objectifs du projet. Puisque les objectifs décrivent le but du projet et qu’ils sont utilisés pour valider le succès de ce dernier, pourquoi voudriez-vous concevoir des livrables qui ne vous permettent pas de réaliser vos objectifs?

Si les livrables listés dans l’énoncé du contenu ne sont pas concordants avec les objectifs du projet, vous devez les « aligner ». Voici comment procéder:

• S’il manque un livrable pour réaliser un objectif, vous devez vérifier si l’objectif est réellement important. S’il l’est, vous devez alors ajouter un livrable pour l’atteindre.

• Si vous trouvez un livrable qui semble ne répondre à aucun objectif, vous devez vous demander s’il est vraiment important. S’il ne l’est pas, écartez-le du projet. Si le livrable semble vraiment important, vous devez travailler avec le commanditaire pour vérifier l’énoncé des objectifs du projet où la définition d’un objectif important semble manquer. Peut-être cet objectif est-il valable mais qu’il n’a pas encore été énoncé explicitement.

Les exigences relatives aux produits définissent le contenu à un bas niveau. Pensez aux exigences. Les exigences décrivent simplement les livrables de façon plus détaillée. Les exigences décrivent les caractéristiques fonctionnelles et non fonctionnelles des livrables. Etant donné que les livrables font partie du contenu de haut niveau, il est logique que la description détaillée du livrable (les exigences) soit considérée comme le bas niveau du contenu.

Une fois le projet commencé, la plupart des changements de contenu affecte les exigences du projet.