Business Analysis

Introduction
Mise en situation

https://www.youtube.com/watch?v=BKorP55Aqvg

2
Plan du cours
1. Introduction
a. Qu’est-ce qu’un Business Analyst ?
b. Qu’est-ce qu’une Exigence ?
2. Pre-Study
3. Domain Understanding
4. Requirement Analysis

3
Qu’est-ce qu’un Business Analyst ?

4
Définition

5
Business Analyst - Définition
Les Business Analysts (ou analystes d’affaires, ou BA) sont chargés d'analyser
les besoins de leurs clients d'affaires.
● Fonction de liaison entre le côté affaires de l'entreprise et les prestataires de
services internes et externes.
● Chargé d’étudier et d’analyser le domaine d’affaire
● Proposer une solution ou des recommandations
○ Pas nécessairement technologique.
○ La solution proposée est souvent une optimisation du processus d'affaires existant afin
d'éliminer ou de réduire les activités sans valeur ajoutée, ce qui peut engendrer une
augmentation de la performance ou une réduction des coûts associés.

6
Rôle du Business Analyst
Le BA peut être impliqué dans différentes situations

● Lors de la création d’un nouveau produit.

● Lors de l’amélioration d’un produit actuel.
● Pour aider à résoudre un problème en comprenant la situation et en
proposant une solution.
● Pour aider les membres de l'équipe de projet à mieux comprendre les
besoins du client.

7
Rôle du Business Analyst
L'analyste intervient à différents moments dans la vie du projet.

● Au début d'un projet (compréhension)

○ Pour documenter les processus d'affaires du client.
○ Pour identifier les possibilités d'amélioration.
○ Pour préparer les mandats des projets.
○ Pour aider le management à déterminer quels sont les projets à mettre de l'avant.
○ Pour identifier et documenter les orientations stratégiques et le scope du projet.
○ Pour collecter les besoins des parties prenantes.
○ Pour estimer l'impact du projet sur l'organisation.

● Pendant le projet (aider)

○ Pour aider à atteindre les objectifs fixés.
○ Pour aider l’entreprise à gérer le changement.

8
Rôle du Business Analyst
Il peut également

● Intervenir dans / dirigé / effectuer l'analyse des besoins.

● Cerner les contraintes d'affaires.

Ces connaissances et cette compréhension sont ensuite transférées aux

différentes équipes de développement afin qu’ils comprennent les concepts du
domaine et les besoins des utilisateurs.

9
Rôle du Business Analyst
Ce rôle varie en fonction de différents facteurs :

1. Le type d'industrie.
2. La taille de l'organisation.
3. Le cycle de vie du projet.
4. La méthodologie (waterfall, agile, etc.).
5. La maturité de l'organisation en termes de pratiques de gestion de projet et
d'analyse commerciale.

10
Business Analyst - Limites
Souvent confondu avec le chef de projet et l'analyste fonctionnel
● Son travail s'arrête à la limite de l'analyste fonctionnel.
○ Qui doit lui proposer des solutions informatiques en vue du développement.

● Il arrive parfois qu'une même personne jouent les deux rôles.

● Très important de distinguer les besoins du client de la solution
○ La solution peut être changée par l'équipe technique.
○ Le besoin est de la responsabilité du client.

11
Analyses des besoins
Toutes analyses passent par 4 phases :

1. Identifier le problème
○ Identifier le problème qui doit être résolu ou l’amélioration qui doit être réaliser.

2. Évaluer l’état actuel

○ Comprendre quels sont les facteurs qui causent le problème.

3. Identifier l’état désiré

○ Identifier avec le client qu’elle est l’état désiré.

4. Comprendre le gap
○ Identifier les éléments manquants pour arriver à la solution.

12
Analyses des besoins

Comprendre et Définir l'écart entre les deux situations Définir la situation

définir la situation
Proposer des solutions ou des recommandations future espérée
actuelle

13
Le Problème
L'analyste intervient dans l’optimisation de problèmes structurés ou dans la
résolution de problèmes non-structurés
● Problème structuré
○ Le problème ainsi que ses causes sont clairement identifiés
○ Les routines pour résoudre le problème sont comprises
○ Des experts savent quelles routines appliquer

● Problème non-structuré
○ Le problème n’est pas bien assimilé: le business constate des effets négatifs, mais comprend
mal la chaîne causale qui mène à cet état
○ Les routines pour résoudre le problème sont inexistantes
○ Des experts doivent intervenir pour comprendre le problème, et créer de nouvelles solutions!

14
Combinaison avec d’autres rôles
Les analystes d'entreprise peuvent se chevaucher dans des rôles tels que chef de
projet ou consultant.

Un BA ne fonctionne pas toujours dans des projets liés à l’IT, puisque les
compétences de BA sont souvent nécessaires dans des rôles de marketing et
financiers.

15
Pré-requis du Business Analyst
Il n'y a pas de manière unique et définie pour devenir analyste.

1. Souvent, le BA a une formation technique.

○ Expérience en tant que programmeur ou ingénieur.
○ Diplôme en informatique.
○ Formation en gestion de l’information.

2. Possibilité d’atteindre un rôle de BA à partir d'un rôle d'entreprise.

○ Statut d’expert en la matière + compétences analytiques = Bon BA.

3. Formations spécifiques au métier d'analyste d’affaire.

16
Chaos Report 2015

17
Quelles sont les chances de réussites d’un projet ?
Quelles sont les chances et les facteurs de réussites d’un projet ? Pour
comprendre le taux de réussite des projets on va se baser sur le Chaos Report
de 2015.

https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf

18
Taux de succès

19
Respect des contraintes

20
La taille du projet

21
Par industrie

22
Par région du monde

23
Par complexité

24
Par méthodologie

25
LES MÉTHODOLOGIES

26
Méthode de développement
Qu'est ce qu'une méthode de développement ?

Cadre établi afin de

1. structurer
2. planifier
3. contrôler

le processus de développement d'un système d'information.

27
Les disciplines du développement de software
1. Analyse des exigences
○ Comprendre les besoins du client
2. Conception (Design)
○ Définir la solution technique
3. Développement
○ Implémenter la solution
4. Validation (Testing)
○ S’assurer que la solution répond adéquatement aux besoins
5. Déploiement
○ Intégration globale et mise en production
6. Maintenance

28
Différentes méthodologies
Les différences entre différentes méthodologies de développement résident
essentiellement dans :

1. L'importance donnée à chaque activité.

2. La séquence permise entre chaque activité.

Large variété de méthodologie: en cascade, en spirale, incrémentale, agile...

29
Méthode en cascade (“waterfall”)
Le cycle en “cascade” se caractérise par des phases séquentielles, qui se
succèdent après la validation des livrables produits lors de la phase précédente.

30
Méthode en cascade (“waterfall”)
1. Les besoins sont exprimés et recueillis dans une analyse détaillée.
2. La conception du système qui répondra aux besoins exprimés dans l’analyse.
○ Textuelle ou sous forme de diagrammes.
○ Doit être validée avant le démarrage des développements.
3. Le développement.
○ Doit être achevés pour permettre à l’équipe de testeurs de lancer les tests fonctionnels et
techniques.
4. Les tests.
5. Mise en production après que les anomalies aient été corrigées.

31
Méthode en cascade (“waterfall”)
Dans ce contexte, et sur la base du périmètre défini, on demande au chef de
projet de s’engager sur un planning détaillé de réalisation, prévoyant les jalons de
début et fin de phases, et les activités à mener.

32
Réflexion
1. Quels sont les avantages et les inconvénients d'une telle méthode?
2. Quels sont les critères favorable / défavorable pour cette méthode?

33
Avantages
1. Le temps alloué dans les premières phases des projets permet d'atteindre
des économies d'échelle.
2. La documentation est aussi importante que le code. Cela permet de
pérenniser la connaissance au sein du projet.
3. Approche simple, disciplinée et facile à comprendre.

34
Inconvénients
1. La rigidité de l’approche prédictive.
○ La préoccupation majeure du chef de projet devient alors de coller au plus près au plan.

○ Tout retard ou imprévu est perçu comme échec, incompétence.

2. L’effet tunnel ou "black box".

○ La marge de manœuvre laissée au client pour préciser ou faire évoluer ses attentes est quasi
inexistante.

3. Une mauvaise communication.

4. La levée tardive des facteurs à risques.
5. Une documentation pléthorique.
35
Exigences pour la méthode en cascade
1. L'environnement et les exigences sont stables.
2. La technologie est bien connue et mature.
3. Il n'y a rien de nouveau ou d'inconnu dans le projet (prévisibilité).
4. (De nombreux projets semblables ont déjà été exécutés avant).

36
Qui utilise ce genre de méthode?
● Institutionnel
● Banque/Assurance
● Aéronautique
● ….

37
Réflexion

Comment pourrait-on modifier le processus waterfall afin de l’améliorer ?

38
Empirisme
Agile est fondé sur l’Empirisme.
● La connaissance provient exclusivement de l'expérience.
● On prend des décisions en fonction de ce que l'on sait pas sur ce que l’on
croit savoir.
● Agile propose une approche itérative et incrémentale pour optimiser la
prévisibilité et contrôler les risques.

39
Incrémentation et itération
Incrémentation

Le développement va être découpé en plusieurs parties. Chacun des

développements vient enrichir l’existant. Un incrément est donc une avancée dans
le processus de développement.

Itération

A chaque itération, les parties prenantes ont l'occasion de faire des commentaires
sur l’augmentation la plus récente, ainsi que sur le produit dans son ensemble. Ce
retour sera incorporé dans la version suivante.

40
Avantages du développement itératif
1. La communication est de meilleure qualité.
○ L’utilisateur a la possibilité de clarifier ses exigences au fur et à mesure.
○ Malentendus, incompréhensions, incohérences sont mis en évidence très tôt dans le projet. Il
est donc encore possible de les corriger.
2. La visibilité est meilleure.
○ Le client reçoit des « preuves » tangibles de l’avancement du projet.
3. La qualité est évaluée en continu.
○ Les tests sont effectués à chaque itération, les anomalies détectées sont corrigées au fur et à
mesure.
4. Les risques sont détectés très tôt.
5. L’équipe prend confiance.

41
Avantages du développement itératif
6. Les coûts sont contrôlés.
○ Les coûts sont limités au périmètre de l’itération.
○ On ne perd que les efforts de cette itération et non la totalité du projet.
○ On peut arrêter à n’importe quelle moment, puisqu’on a une version finie à la fin de chaque
itération.
7. Possibilité d'exploiter méthodiquement les leçons tirées d'une itération.

42
Le Manifeste Agile
En février 2001, un groupe de 17 développeurs s'est réuni à Snowbird (Utah) pour
discuter de la possibilité de créer une meilleure méthode de développement.

Cette réunion a débouché sur un document intitulé The Agile Manifesto (Le
Manifeste Agile), qui décrit 4 valeurs fondamentales et 12 principes pour améliorer
la manière dont on construit des softwares.

43
4 Valeurs Fondamentales
1. Priorité aux personnes et aux interactions par rapport aux procédures et aux
outils
○ Travail en groupe, communication avec les clients plutôt que de travailler uniquement à partir
d'un outil de gestion de projet.

2. Priorité aux applications opérationnelles par rapport à une documentation

pléthorique
○ L’objectif est d’avoir un software qui fonctionne, pas une documentation.

○ Documentations succinctes à jour, documentation permanente du code.

44
4 Valeurs Fondamentales
3. Priorité à la collaboration avec le client par rapport à la négociation de contrat
○ Etablir une relation de confiance avec le client

○ Feedback régulier du client, solution répondant réellement aux attentes

4. Priorité de l’acceptation du changement par rapport à la planification

○ S’adapter au fur et à mesure de l’avancement du développement

○ Planning flexible, modifications possibles après 1ère version du système

45
Observations
1. Agile n'est pas normatif
○ Décrit un résultat spécifique, mais pas comment l'équipe doit parvenir à ce résultat.

○ Pourquoi ? Chaque situation est différente

2. Agile ne prétend pas être la seule solution

○ Priorité à… par rapport à…

○ Agile n’est pas la seulement manière de faire, mais souvent la meilleur.

46
12 Principes
1. Prioriser la satisfaction du client
○ La plus grande priorité est de satisfaire le client en lui livrant très tôt et régulièrement des
versions fonctionnelles de l’application source de valeur

○ Le client peut décider de la mise en production de l’application

2. Accepter les changements

○ Accueillir les demandes de changement à bras ouverts, même tard dans le processus de
développement. Les méthodologies agiles exploitent les changements pour apporter au client
un avantage concurrentiel

○ Produire des systèmes flexibles

47
12 Principes
3. Livrer en permanence des versions opérationnelles de l’application
○ Livrer le plus souvent possible des versions opérationnelles de l’application, avec une
fréquence comprise entre deux semaines et deux mois, avec une préférence pour l'échelle de
temps la plus courte.

○ Objectif : livrer une application qui satisfasse aux besoins du client.

4. Coopérer quotidiennement
○ Clients et développeurs doivent coopérer quotidiennement tout au long du projet

5. Construire des projets autour d’individus motivés

○ Leur donner l’environnement et le support dont ils ont besoin et leur faire confiance pour
remplir leur mission

48
12 Principes
6. Favoriser le dialogue direct
○ La méthode la plus efficace pour communiquer des informations à une équipe et à l’intérieur
de celle-ci reste la conversation en face à face

7. Mesurer l’avancement du projet en fonction de l’opérationnalité du produit

○ Le fonctionnement de l’application est le premier indicateur d’avancement du projet

8. Adopter un rythme constant et soutenable

○ Adapter le rythme pour préserver la qualité du travail sur la durée du projet

○ Développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment

49
12 Principes
9. Contrôler continuellement l’excellence technique et à la conception
○ Maintenir le code source propre, clair et robuste

10. Privilégier la simplicité en évitant le travail inutile

○ La simplicité, art de maximiser la quantité de travail à ne pas faire, est essentielle

○ Répondre le + simplement aux besoins actuels pour que celui ci soit adaptable

11. Auto-organiser et responsabiliser les équipes

○ Partage des responsabilités par volontariat

50
12 Principes
12. Améliorer régulièrement l’efficacité de l’équipe en ajustant son comportement
○ A intervalles de temps réguliers, l’ensemble de l’équipe s’interroge sur la manière de devenir
encore plus efficace, puis ajuste son comportement en conséquence

○ Environnement en perpétuelle évolution

51
Comparaison
Cycle de vie Waterfall Agile

Planification Prédictive Adaptative

Documentation Produite en quantité Réduite au strict nécessaire

Équipe Ressources spécialisées Responsabilisation, initiative

et communication

Qualité Contrôle à la fin du cycle Contrôle qualité précoce et

permanent

Changement Opposition au changement Intégré dans le processus

52
Comparaison
Cycle de vie Waterfall Agile

Suivi de l’avancement Mesure de la conformité aux Travail restant à faire

plans initiaux

Gestion des risques Processus distinct Intégré dans le processus

Mesure du succès Respect des engagements Satisfaction client

initiaux

53
La problématique de la planification
Planification au fil de l'eau

● Acceptation de l'incertitude
● La fiabilité des estimations augmente avec les enseignements des itérations
précédentes

PRÉVISIBILITÉ INCERTITUDE IMPRÉVISIBILITÉ

54
Avantages de releases fréquentes

55
Version du produit « potentiellement livrable »
Chaque Sprint doit déboucher sur une version du produit qui est potentiellement
livrable
● Sera livrer ou non, selon l’estimation de l’équipe.
○ Estimation business et non technique.

● Toutes les fonctionnalités sur lesquels on a travaillé ne doivent pas forcément

être fini et livré à la fin du sprint.

56
Avantages de releases fréquentes

57
Avantages du « potentiellement livrable »
1. Meilleure valeur commerciale
○ Produit des revenus dès le début.
○ Récupérer les coûts plus tôt.
○ Diminuer l'investissement global.

2. Risque réduit
○ Créer un produit prêt à être expédié à tout moment.

3. Plus de transparence
○ Permet de montrer l’avancement du projet au fur et mesure.

58
Mythes vs réalité
1. Mythe: Les équipes Agile travaillent plus vite.
○ Réalité: Agile aide les équipes à livrer plus rapidement
i. Agile aide les équipes à livrer plus rapidement sur le marché en travaillant par
incrémentation.
ii. Termine le projet plus tôt car les équipes peuvent apprendre durant chaque itération que
toutes les fonctionnalités prévues ne sont pas réellement nécessaires.

2. Mythe: Agile et Scrum c’est la même chose.

○ Réalité: Scrum est un framework spécifique qui implémente les idées du Manifeste Agile.

59
75% des équipes Agiles ont adopté l'approche Scrum ou
un hybride basé sur Scrum 60
ROI du BA

61
ROI du Business Analysis
Comment un BA réduit les coûts de mise en œuvre?
1. Réduction du rework (méthode)
○ Il aide l'équipe à se concentrer sur les bonnes exigences.
○ Il réduit la quantité de changement inutile.
2. Réduction du churn (efficacité)
○ Le temps des parties prenantes est précieux.
○ Les parties prenantes peuvent s’enliser dans des discussions improductives.
○ Le BA aide à conduire un processus de prise de décisions logique et efficace.
○ Le BA réduit le temps passé à ressasser les discussions précédentes.
3. Découverte des solutions plus rentables (recul)
○ L'analyste d'affaires trouve des solutions à un problème.
○ Les solutions peuvent ne pas impliquer les technologies de l'information.
○ Le BA aide à réduire les coûts en trouvant des solutions plus rentables.

62
ROI du Business Analysis
Comment un BA augmente les revenus?
1. Nouvelles exigences (créativité)
○ Le BA ne se contente pas « ramasser » ou « recueillir » les exigences.
○ Le BA doit activement rechercher les exigences.
○ Le BA permet à l'entreprise d’avoir une meilleure compréhension des besoins.
2. Hiérarchisation (priorisation)
○ Les intervenants sont réticents à établir des priorités.
○ Le BA utilise différentes techniques de priorisation.
○ Le BA aide à mieux comprendre l’importance des exigences partagées.
3. Mise en œuvre plus efficace de solutions (organisation)
○ Le BA peut aider son client à se préparer à des changements.
○ Le BA se concentre sur les principes de clarté et de l'alignement business-IT.

63
Origines des défauts logiciels

64
% de fonctionnalités réellement utilisées

65
Qu’est-ce qu’une exigence ?

66
Exigences selon IEEE
1. Une condition ou capacité nécessaire à un utilisateur afin de résoudre un
problème ou atteindre un objectif.
2. Une condition ou capacité qui doit être remplie ou possédée par un
composant du système ou d'un système pour satisfaire un contrat standard,
une spécification, ou d'autres documents formellement imposés.
3. Une représentation documentée d'une condition ou capacité comme dans (1)
ou (2).

*IEEE : Institute of Electrical and Electronics Engineers

67
Différents types d’Exigence
1. Exigence fonctionnelle
○ Une action qu’un logiciel (ou produit) doit effectuer pour être utile à l'utilisateur.
■ Le logiciel doit permettre de suivre les paiements individuels.
■ Le logiciel doit permettre d'ajouter un nouveau client.

2. Exigence non-fonctionnelle
○ Une propriété ou qualité qu'un logiciel (ou d'un produit) doit avoir.
■ Le logiciel doit être rapide et sécurisé.
■ Le logiciel doit être beau et facile à utiliser.

3. Exigences globales
○ Contraintes sur l'ensemble du projet.
■ Le projet doit être terminé pour le 1er mai.
■ Tous les clients devront utiliser le futur produit.

68
Ingénierie des exigences
Les procédés utilisés pour découvrir, analyser et valider les exigences d’un
système

● Tout, sauf évident…

69
Ingénierie des exigences

70
Ingénierie des exigences
● Les procédés utilisés en ingénierie varient largement en fonction du domaine
d'application, des personnes impliquées et de l'organisation de
développement les exigences.
● Cependant, il y a un certain nombre d'activités génériques communes à tous
les processus d’ingénierie des exigences :
a. Étude de faisabilité / Cas d’affaire (Pré)
b. Elicitation des exigences
c. Analyse des besoins & Triage
d. Validation des exigences
e. Gestion des exigences (Post)

71
Phases de l’ingénierie des exigences
1. Elicitation
○ Apprendre, découvrir, extraire, surfacer ou découvrir les besoins des clients, des utilisateurs et
d'autres intervenants potentiels.

2. Analyse
○ L'analyse des informations obtenues à partir de parties prenantes afin de générer une liste
des exigences des candidats, souvent par la création et l'analyse de modèles d'exigences,
avec pour objectif de mieux comprendre les exigences, d’améliorer l'exhaustivité et de réduire
l'incohérence.

72
Phases de l’ingénierie des exigences
3. Triage
○ Déterminer quel sous-ensemble des exigences déterminées par l’élicitation et l'analyse est
approprié pour être abordé dans des éditions spécifiques d'un système.

4. Spécification
○ Documenter le comportement externe souhaité d'un système.

5. Vérification
○ Déterminer le caractère raisonnable, la cohérence, l'exhaustivité, la pertinence et l'absence de
défauts dans un ensemble d'exigences.

73
Phases de l’ingénierie des exigences

Hickey and Davis, 2004, A unified model of requirements elicitation

74
 Requirements
Management

Requirements
Validation

Domain
Prioritization
Understanding

Requirements Conflict
Collection Resolution

Classification

Phases de l’ingénierie des exigences

75
Pré-Study

76
 Requirements
Management

Requirements
Validation

Domain
Prioritization
Understanding

Requirements Conflict
Collection Resolution

Classification

Pre-Study
77
Stakeholders Analysis

78
Stakeholders
Les personnes ou organisations qui ...
● … ont un intérêt valable dans le système.
● … sont touchés par le système.

79
Stakeholders
“Individual, group or organization that may affect, be affected by or perceive itself
to be affected by a decision, activity or outcome of a program or project.”

Project Management Body of Knowledge (PMBOK Guide)

80
Stakeholders – Quelques Exemples
● Toute personne qui exploite le système.
● Tous ceux qui bénéficient du système.
● Toute personne impliquée dans l'achat ou l’acquisition du système.
● Organisations qui régissent les aspects du système et autres organismes de
réglementation.
● Les organisations responsables des systèmes qui interfacent avec le système
en cours de conception.
● Des personnes ou des organisations opposées au système.

81
Identifier les Stakeholders
Il est important de savoir identifier toutes les personnes qui vont être affectées par
une solution ou qui vont avoir une influence sur le projet pour 2 raisons.

1. Comprendre leurs besoins.

2. Adapter une communication adéquate personnalisé pour chacun d’entre eux.

Attention ! L’intérêt (et donc notre communication) des Stakeholders peuvent évoluer durant un projet.

82
Communication
Pour chacun des groupes de Stakeholders il faudra adapter sa communication en
fonction de 3 critères :

1. Format
○ Support pour envoyer le message.
○ Email ? Meeting ? Call ?

2. Contenu
○ Quel type d’information sera partagé ? Quel niveau de détail ?

3. Timing
○ A quel moment doit-on communiquer ?
○ A quel féquence doit-on communiquer ?

83
Stakeholders’ Map
Représentation des différents Stakeholders sur un graphe.

● Différents modèles possibles, mais pas de réels standards de modélisation

1. Interest Map
2. Hub and Spoke

● Utile car elle permet

1. Offre une représentation visuelle des différents acteurs à prendre en compte
2. Offre une vision sur les interactions entre stakeholders (et le système)
3. Mettre les ressources là où elles sont nécessaires

84
Stakeholders’ Map – Interest Map
● Dimension Interest
○ A quel point un stakeholder souhaite-t-il voir le projet aboutir et souhaite contribuer à ce
dernier ?

● Dimension Power / Influence

○ A quel point un stakeholder peut-il influencer sur le projet et la solution ?

85
Stakeholders’ Map – Interest Map - Exemple
Influence / Power

Gouvernement (lois) Gouvernement (lois) Manager

Administration (budget) Administration (budget) Investisseurs

Autres départements Utilisateurs Utilisateurs

Clients Clients

Autres départements Autres départements Utilisateurs

Clients

Intérêt
86
Stakeholders’ Map – Interest Map
Influence / Power

impliquer / engager impliquer / engager partenaire

informer consulter consulter

informer informer consulter

Intérêt
87
Stakeholders’ Map – Hub and Spoke
● Représentation des stakeholders comme des cercles
○ La taille représente la puissance relative
○ La couleur représente l’attitude du stakeholder vis-à-vis du projet

● Le type de ligne représente l’impact d’un stakeholder sur le système

○ Et donc sur ses exigences

88
 Vert = Supportif
Jaune= Prudent
Rouge= Hostile
Gris= Impact inconnu, ou indifférent

Lignes pleines = Impact important

Lignes en trait = Impact modéré
Lignes pointillées = Impact mineur
Pas de ligne = Pas d’impact direct

Stakeholders’ Map – Hub and Spoke

89
Alternatives
Il existe plusieurs alternative au Stakeholders’ Maps

1. Onion Model
2. Radar Model

90
Onion Model
● Le modèle “Onion” est un moyen de visualiser la relation des parties
prenantes par rapport à l’objectif du projet.
● Le modèle se base sur une représentation par couche de stakeholders.
○ D’où son nom.

91
Onion Model
● Le modèle est généralement composé de 4 ou 5 couches. A partir du centre,
ces couches sont
1. Le produit ou la solution qui doit être délivré
2. Le Système d'affaires
■ 1 + gens avec un lien direct.
3. Les affaires
■ 2 + gens avec un lien indirect.
4. L'environnement
■ 3 + gens qui gravitent autour du business.
5. Autres
■ La couche externe peut être utilisée pour les parties prenantes qui ne rentrent pas dans
les autres couches.

92
Onion Model
93
Radar Model
Le radar est un moyen simple de montrer visuellement de l'information sur les
parties prenantes selon différentes variables d’intérêt.

● Il peut aider à identifier les stakeholders qui sont importants selon les
différents aspects du projet.
● Nécessite de classer les stakeholders, sur une échelle cohérente, le long des
axes de pouvoir, de légitimité, d'impact, d'intérêt et de soutien.
● Une échelle commune de classement est une échelle de Likert variant de 1 à
5.
○ Une échelle de Likert est un outil psychométrique permettant de mesurer une attitude chez
des individus. Elle consiste en une ou plusieurs affirmations (énoncés ou items) pour
lesquelles la personne interrogée exprime son degré d'accord ou de désaccord.

94
Radar Model

95
Etude de faisabilité
(Business Case)

96
Etude de faisabilité (Business Case)
Une étude de faisabilité ou Business Case décide si oui ou non le système
proposé vaut la peine d’être développé.
● Etude réalisé par les demandeurs de la solution.
● Inclut l'évaluation des besoins et autres données fourni par les différents
Stakeholders.
● Il prend la forme de petites études courtes et ciblées qui visent à vérifier si :
a. Le système contribue aux objectifs organisationnels.
b. Le système peut être conçu en utilisant la technologie actuelle et dans le budget.
c. Le système peut être intégré avec d'autres systèmes qui sont utilisés.

97
Etude de faisabilité - Contenu
1. Objectif du projet
○ Des petites phrases facilement mesurables qui décrivent ce qui doit être atteint par l’entreprise
(exigences initiales).
2. Analyse de la situation actuelle
3. Facteurs de succès du projet
4. Demandeur
○ Qui est responsable du projet ?
5. Bénéficiaire
○ A qui est destiné le projet ?
6. Stakeholders principaux
○ Quelles personnes sont impactées ?

98
Etude de faisabilité - Contenu
7. Contraintes
○ Techniques, ressources ou légales.
8. Jargon
○ Définition des premiers termes importants.
9. Faits et hypothèses importants
10. High-level milestones
11. Scop
○ Définir une première délimitation du projet.
12. Estimation des coûts
13. Estimation des risques
14. Estimation d’éventuelles alternatives

99
Etude de faisabilité – Procédure
Questions pour les personnes dans l'organisation

● Que faire si le système n'a pas été mis en œuvre ?

● Quels sont les problèmes dans les processus actuels ?
● Comment le système proposé aidera-t-il à gérer ces problèmes ?
● Quels seront les problèmes liés à l'intégration ?
● Est-ce qu’une nouvelle technologie est forcément nécessaire ? Quelles
compétences sont nécessaires à la réalisation du projet ?
● Quelles installations actuelles doivent être prises en charge par le système
proposé ?

100
Et puis ?
Une fois l’étude de faisabilité terminée :

● Le management dispose d’informations suffisantes.

● La décision go / no-go peut-être prise.
● Les budgets peuvent être débloqués.
● Les responsables peuvent être nommés.

101
Et puis ?
Comment favoriser un Go ?

● Définir un objectif clair et concis.

● Propose une cible mesurable.
● Veiller à concilier les objectifs et le contexte de l’entreprise.
● Être réaliste sur les risques.
● Ne pas sous-estimer les coûts.
● Proposer des raisons suffisantes pour justifier cette alternative.
● Garantir le support des stakeholders.

102