Organisation de projets

Organisation de projets

Données clés

Faculté	Faculté d'économie et de management
Département	Services généraux GSEM
Professeur(s)	Jolita Ralyte
Cours	Gestion de projet

Lectures

Deux rôles dans la réalisation d'un projet SI

Maître d'ouvrage (MOA) : l'entité porteuse du besoin, définissant l'objectif du projet, son calendrier et le budget consacré à ce projet.

Le résultat attendu du projet est la réalisation d'un produit, appelé ouvrage.

Maître d'oeuvre (MOE) : l'entité retenue par le maître d'ouvrage pour réaliser le projet, dans les conditions de délais, de qualité et de coûts fixées par ce dernier conformément à un contrat.

(Kueviakoe, 2004)

Maîtrise d'ouvrage VS Maîtrise d'oeuvre

Compétences métier VS compétences techniques

• Différence du langage -> difficultés de communication
• Différence de connaissances -> difficultés de compréhension

Situations de projet :

• MOA et MOE appartiennent à la même organisation
• MOA et MOE sont deux organisations différentes, proches ou distantes géographiquement
• Développement distribué : collaboration de plusieurs organisations.

Maître d'ouvrage (MOA) : client

Le maître d'ouvrage (MOA) est le client pour lequel l'ouvrage (le SI) est réalisé.

• Il exprime l'objectif et maîtrise l'idée de base du projet.
• Il est responsable de l'expression fonctionnelle des besoins mais n'a pas forcément les compétences techniques liées à la réalisation de l'ouvrage.

Les responsabilités du MOA

La responsabilité du client est totale du début du projet jusqu'à son déploiement. Il doit :

• définir et exprimer les besoins de SI en réalisant un cahier des charges
• valider l'adéquation des solutions détaillées, proposées par le maître d'oeuvre, aux besoins exprimés
• conduire le changement et mettre en oeuvre le produit sur les différents sites
• suivre le déroulement des travaux
• payer les travaux commandés et réalisés.

Qui peut réaliser le rôle du MOA ?

Une équipe interne à l'organisation

• les usagers du futur système
• les services informatique/SI de l'entreprise (s'il en existe un).

Un prestataire externe à l'entreprise

• maître d'ouvrage délégué, sollicité pour assurer l'interface entre l'utilisateur et le fournisseur
• une assistance à maîtrise d'ouvrage, sollicité pour conseiller le MOA interne à l'organisation.

Équipe client

Chef de projet côté client (chef MOA)

Les responsabilités du MOA :

• diriger l'équipe des usagers sélectionnés pour participer dans le projet
• gérer les ressources du projet : les finances, les ressources humaines, le matériel de l'équipe client
• être en contact permanent avec l'équipe fournisseur.

Le chef MOA peut être représenté par :

• un membre de la direction de l'entreprise
• un responsable du département informatique interne
• un responsable du SI
• un consultant externe.

Sponsor

Le promoteur est une personne haut placée dans l'entreprise (de préférence) qui :

• soutient le projet auprès de la direction de l'entreprise
• prend des décisions stratégiques, politiques et de définition des objectifs
• sélectionne les usagers les plus représentatifs de leur métier à participer dans le projet
• assure que la solution proposée corresponde bien aux besoins de l'entreprise tant au niveau technique que stratégique
• est crédible influent
• dirige officiellement le Comité de Pilotage
• est le recours ultime, quand les arbitrages sont nécessaires entre départements de l'entreprise

Le sponsor peut être représenté par :

• un membre de la direction de l'entreprise
• un responsable du département informatique interne
• un responsable du SI
• un consultant externe (dans le pire des cas).

Très souvent, le rôle de Sponsor interne n'existe pas dans les entreprises. Il faut le créer!

Comité de pilotage

Le comité de pilotage :

• est un donneur d'ordre du projet
• prend la décision finale sur la solution proposée par le Sponsor
• assure le suivi du projet
• valide la solution proposée au niveau budgétaire et stratégique.

Usagers représentatifs

Les usagers capables d'exprimer les exigences concernant leur métier :

• les employés les plus représentatifs de chaque département de l'entreprise concerné par le projet SI.

Objectifs et responsabilités des usagers :

• Transférer à l'équipe de maîtrise d'ouvrage la connaissance sur leur domaine d'activité :
  • organisation
  • activités métier
  • système et règles de gestion
  • concepts
  • problèmes liés à l'utilisation des anciens systèmes
  • exigences pour le nouveau
• Valider la bonne perception de la situation existante et des problèmes qu'elle engendre
• Exprimer les besoins
• Valider le réalisme des solutions globales proposées
• Faire évoluer le produit

Consultants

Les consultant externes aident à :

• choisir le maître d'oeuvre ou le fournisseur ERP
• réaliser la spécification des besoins
• valider les solutions proposées par le maître d'oeuvre
• gérer le projet
• etc.

Expression des exigences

L'expression des besoins est du ressort du client.

Étapes d'expression des exigences :

• Identification : établissement et choix d'un objectif global
• Découverte : recueil des besoins auprès des utilisateurs et des dirigeants
• Exploration : affinement et stabilisation des besoins
• Formalisation : mise en forme des exigences, afin qu'elles soient suffisamment précises et compréhensibles par le maître d'oeuvre.

Les exigences sont spécifiées dans un cahier des charges.

Cahier des charges

C'est un document qui fixe les obligations réciproques du client et du fournisseur, un recueil de caractéristiques que doit présenter un produit en cours d'étude ou de réalisation. À partir de ce cahier des charges, un fournisseur doit pouvoir s'engager sur un budget et sur un délai. Les besoins sont définis, mais la manière de les satisfaire n'est pas abordée.

Problèmes d'expression des besoins

Les problèmes liés à l'expression des besoins peuvent être des sources de litiges entre le client et le fournisseur.

Questions à se poser :

• Les besoins formalisés par le client sont-ils exhaustifs ?
• Les besoins exprimés par le client sont-ils compréhensibles par le fournisseur ?
• Le client a-t-il les moyens nécessaires pour valider la solution ?

Solutions :

• Utilisation des méthodes d'analyse et de spécification des besoins
• Adaptation du cycle de développement du projet aux caractéristiques du domaine
• Adoption d'un langage commun fondé sur des modèles
• Participation accrue des deux parties.

Rédaction du cahier des charges

Structure du document :

1. Introduction - description générale du projet/futur SI
   1. les objectifs du futur SI
   2. le périmètre du projet : les frontières du domaine d'étude avec d'autres domaines
   3. la collaboration avec d'autres domaines et systèmes existants
   4. la décomposition en sous-domaines (si nécessaire)
   5. les décideurs du projet
   6. les principes de configuration du SI
   7. la terminologie : définitions, acronymes, abréviations
2. Description détaillée du futur SI
   1. Perspective produit
      1. les composants du SI et les liens entre eux
      2. les interfaces nécessaires avec d'autres systèmes existants
      3. le modèle conceptuel du domaine définissant les principales entités (les concepts du domaine) : entités de gestion, entités de référence produit/service, entités de reporting, etc.
      4. les cycles de vie des entités de gestion (ex. diagramme d'états).
   2. Perspective processus
      1. les processus d'entreprise concernés par le futur SI
      2. leur qualification : métier, support, management, etc.
      3. leur description détaillée (ex. BPMN, cas d'utilisations, scénarios, diagrammes de séquence, diagrammes d'activité)
   3. Perspective utilisateurs
      1. la liste et les définitions des rôles/utilisateurs type du SI
      2. les profils des utilisateurs (ex. expérience, niveau d'éducation, formation)
   4. Contraintes et qualités
      1. les contraintes techniques (réseaux, matériel, plateformes et systèmes existants ou imposés)
      2. les exigences qualité (performance)
   5. Hypothèses et dépendances
      1. les facteurs ayant un impact sur les exigences (ex. hypothèse qu'un système opérationnel spécifique va être disponible)
3. Description détaillée des exigences spécifiques
   1. Interfaces
   2. Exigences fonctionnelles
   3. Exigences non fonctionnelles
      1. performance
      2. base de données
      3. contraintes de design (standards et normes)
      4. propriétés du système logiciel (disponibilité, fiabilité, sécurité, maintenance, portabilité).
   4. Autres exigences
4. Annexes