La MOA pragmatique du SI (Business Analysis, Analyse d'Entreprise, Maitrise d'Ouvrage)

Aller au contenu | Aller au menu | Aller à la recherche

Tag - Entretien

Fil des billets - Fil des commentaires

mardi, novembre 30 2010

Comment acquérir la confiance et le respect des parties prenantes de vos projets ?

Par Olivier Durand le mardi, novembre 30 2010, 22:06 - Piloter

Acquérir la confiance et le respect des différentes parties prenantes de vos projets est primordial pour pouvoir jouer pleinement votre rôle de facilitateur et d'influenceur. Si les gens vous respectent, vous pourrez plus facilement désamorcer les conflits. Si les gens vous font confiance, vous obtiendrez plus facilement l'adhésion aux décisions prises. Mais comment en arriver là ? Comme aujourd'hui je suis d'humeur optimiste, commençons par la méthode Coué :

Si vous avez confiance en vous-mêmes, vous inspirerez confiance aux autres.
Johann Wolfgang von Goethe.

On respecte un homme qui se respecte lui-même.
Honoré de Balzac.

Communiquez, faites circuler l'information

Si vous faites circuler l'information, à bon escient évidemment, on vous reconnaitra comme quelqu'un de confiance. Celui qui fait de la rétention d'information n'est pas vu comme quelqu'un de confiance, mais plutôt comme un incompétent. En effet, si il était compétent, il n'aurait pas besoin de faire de la rétention d'information pour se valoriser.  

Ne réagissez pas aux objections infondées

Si on sur-réagit à des objections infondées (qu'elles soient émises par mail, en réunion ou par tout autre média), c'est qu'on est sur la défensive et donc que l'on a des choses à se reprocher. Dans ce cas là, mieux vaut ne pas réagir du tout. Laisser un blanc dans une réunion suite à une objection infondée fera clairement comprendre à son interlocuteur qu'il s'est lourdement trompé. Et cela vous assurera le respect.

Prenez vos responsabilités, assumez les erreurs

Nous commettons tous des erreurs. En tant que MOA, vous devez accepter vos propres erreurs (par exemple un oubli dans une spécification ou une erreur de conception fonctionnelle), mais vous devez également assumer les erreurs de toute l'équipe projet face à vos sponsors. Inutile de rechercher et identifier le coupable idéal, cela ne vous apportera rien. Face au sponsor, soyez efficace : quelle erreur a été commise, quels sont les impacts, quel plan d'action pour y remédier. Savoir gérer et assumer les problèmes vous aidera à gagner la confiance des parties prenantes de vos projets.

Finalement, acquérir confiance et respect dans le milieu professionnel est un travail sur le long terme. Éthique, déontologie, développement durable sont des concepts à la mode que l'on peut appliquer pour soi au quotidien. Pour une fois c'est mon côté Candide, ou l'optimisme qui parle.

Le travail éloigne de nous trois grands maux : l'ennui, le vice et le besoin.
Voltaire.

jeudi, mars 25 2010

Comment découvrir les besoins ?

Par Olivier Durand le jeudi, mars 25 2010, 17:20 - Etudier

Recueillir les exigences des différentes parties prenantes d'un projet, c'est comme construire les fondations de votre projet. C'est sur ces exigences que l'ensemble du projet va reposer. Dans le billet "Comment améliorer l'alignement IT/métier en utilisant un outil de gestion des exigences ?", j'ai essayé d'expliquer l'intérêt d'un outil pour gérer ces exigences. Mais avant de les formaliser un minimum, il faut déjà les découvrir.

Organisez des entretiens Top-Down

Je conseillerai plutôt de commencer par rencontrer les personnes ayant une vision plus globale du processus concerné pour finir par les utilisateurs clés des systèmes supportant le processus (par exemple dans une salle des marchés commencer par s'entretenir avec un directeur de l'exploitation ou un directeur d'une ligne métier, ensuite voir un responsable de table pour finir par un opérateur de marché et enfin un assistant). Cela permet de commencer par découvrir les exigences stratégiques pour finir par les exigences fonctionnelles et non fonctionnelles. Je pense également que le temps à passer doit être moins important avec le top management qu'avec les opérateurs au cœur du processus.

Préparez vos entretiens

Une réunion demande toujours d'être préparée, d'être conduite, puis il faut en rédiger un compte-rendu. Le compte-rendu d'un entretien de recueil de besoins est la matière première qui va permettre de construire le référentiel des exigences. Le point clé de la préparation de la réunion, afin d'avoir un compte-rendu copieux, c'est de prévoir les questions qui vont cadencer l'entretien. Ces questions doivent être adaptées à votre interlocuteur et suivre une évolution du plus global au plus précis. Vous trouverez des idées de questions génériques dans cet article de Mr. Monteleone lu sur modernalyst.com : Generic Questions for Interviewing Stakeholders.

Pensez processus métier et architecture orientée service (et non pas système)

On ne cherche pas encore à spécifier un système ou une solution même si les utilisateurs auront tendance à se rattacher à du concret. Posez vos questions afin qu'elles soient le plus possible absolue vis à vis des solutions (pour caricaturer, demandez quelles sont les informations nécessaires pour remplir un dossier plutôt que de demander quel écran de saisie est nécessaire). Gardez également toujours en tête comment cette partie s'inclut dans un processus métier complet. Voir par exemple cet article sur business analyst times qui décrit cette approche avec une jolie métaphore du temple grec : Breaking Down the Silos for Better Requirements Elicitation. Et comme je le disais déjà dans mon billet précédent La MOA doit elle comprendre SOA ?, penser "services" vous permettra de poser les bonnes questions pour identifier les réutilisations possibles. Certaines MOA vont jusqu'à prôner une approche où l'on va tenter de conformer les besoins aux services existants comme dans cet article de John Moe lu sur modernalyst.com : Service Oriented Analysis. J'ai un peu de mal avec cette approche car tordre ainsi le besoin c'est risquer d'aboutir sur une solution qui ne saura satisfaire votre sponsor.  Mais dans certains cas ça pourrait marcher, si le SI est déjà organisé en SOA d'un bon niveau, comme le dit l'auteur de cet article.

Une exigence n'est donc pas simplement une information qui est venue à nous sans aucun travail. Le recueil des besoins est une phase clé du projet. Se contenter d'un mail succinct (le fameux Post-it) envoyé par le sponsor pour se lancer dans une phase de spécification fonctionnelle n'est pas suffisant. Il est vrai que cette phase de projet n'est pas "technique" mais exploite plutôt les compétences d'analyse et le relationnel de la MOA, et on peut donc parfois la sous-estimer sur un planning. Mais attention alors au risque de retard, car entre la préparation, la planification des entretiens, et l'analyse des résultats, cette phase peut être très consommatrice de temps.