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

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

Piloter

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

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.

mercredi, février 17 2010

Le rôle de MOA est-il compatible avec les méthodes agiles ?

Par Olivier Durand le mercredi, février 17 2010, 07:17

Les méthodes agiles telles que Scrum et Extreme Programming ne sont pas adaptées à tous types de projets et demandent une organisation bien différente de la classique organisation verticale. De grands penseurs (Ward Cunningham inventeur du Wiki, Kent Beck fondateur de l'extreme programming...) se sont réunis en 2001 et ont publié le manifeste des méthodes agiles qui met en avant les quatre valeurs fondamentales des méthodes agiles :

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Le troisième point place le client au centre de ces méthodes. Terminée la relation client vs fournisseur, MOA vs MOE... Le client doit faire partie de l'équipe projet. Un des douze principes de ce manifeste est :

Business people and developers must work
together daily throughout the project.

On comprend donc que la MOA doit être très impliquée et collaborer très étroitement avec les autres intervenants du projet. Voici pour exemple un schéma expliquant le fonctionnement d'une des plus connues des méthodes agiles, SCRUM :

En plus de l'équipe qui va réaliser les développements, Scrum définit deux rôles que pourraient jouer une MOA "classique".

Le Product Owner. C'est celui qui va définir le Product Backlog composé des demandes des parties prenantes du projet, priorisées d'un point de vue business. Dans une organisation classique, sur une application qu'on fait évoluer en mode catalogue, la MOA fait déjà souvent ce travail via un outil comme JIRA par exemple. Là il s'agit de le faire avec une terminologie et une finalité différentes. A partir de ce Product Backlog le Product Owner va définir le contenu de la prochaine itération (le sprint) avec l'aide de l'ensemble de l'équipe : c'est le Sprint Backlog.

Le Scrum Master. C'est celui qui aura pour rôle de faciliter le travail de l'équipe. Ce n'est pas un chef, il n'y a pas de notion de hiérarchie dans ce process. Ce rôle consiste à faciliter la résolution d'éventuels conflits, rappeler les principes de Scrum lorsqu'un membre de l'équipe s'en écarte... Et en tant que MOA on joue déjà le rôle de facilitateur. Par contre je connais peu de MOA ayant des compétences sur ces méthodologies.

En plus de cette organisation, Scrum propose d'utiliser des outils tels que le daily scrum ou daily standup meeting, le burn down chart, les post-it et les grands tableaux blancs pour concevoir... Tous ces éléments font que l'organisation du travail est assez différente d'une organisation classique. Il n'y a pas de chefs, il faut s'auto-gérer, s'auto-motiver... C'est un mode de fonctionnement que tout le monde ne voudra/pourra pas accepter. Et cette terminologie et organisation assez spécifique peut créer un effet de communautarisme dès lors que cette organisation n'est pas celle de toutes les équipes de votre service.

Depuis quelques années on essaie d'utiliser des méthodes adaptées à l'industrie "lourde" comme Lean ou Six Sigma pour des projets SI. Or la maturité de l'industrie informatique est très loin de celle d'autres industries plus anciennes comme l'automobile. De plus, le travail d'un développeur informatique n'est en rien comparable aux tâches effectuées par des opérateurs d'une chaîne de production. C'est pourquoi les méthodes agiles me semblent plus pertinentes. Mais encore faut il trouver sa place en tant que MOA dans ces organisations parfois mises en place par des nerds. Il faut également savoir rester pragmatique pour ne pas adopter n'importe quelle méthode, n'importe comment. On doit s'approprier une méthode publique pour construire sa propre méthode qui sera acceptée par tous les intervenants.

Modernanalyst.com - How new are all those "new" methodologies really?

mardi, janvier 12 2010

Management transverse, comment vaincre les clivages ?

Par Olivier Durand le mardi, janvier 12 2010, 23:32

En tant que MOA, on est souvent amené à travailler en réseau, à utiliser le management transverse. Et quand l'organisation de notre entreprise est très hiérarchisée, ce travail en réseau n'est pas facilité. Autre contrainte au niveau SI, l'architecture orientée service a souvent été mise en place sans refonte de l'organisation. Voilà les pire cas que l'on peut rencontrer et quelques idées pour les gérer au mieux.

Gérer le clivage MOA/MOE

  • La caricature :

Il vaut mieux être au courant : La MOA pense que les MOE sont des "pisseurs de code", la MOE pense que la MOA sont des "pisseurs de slides".

  • Les solutions du point de vue de la MOA pour éviter d'en arriver là :

Utilisez le plus souvent possible un style de management participatif. Demandez "quel est le plan d'action à mettre en œuvre pour tenir la date de livraison ?" plutôt que d'imposer une échéance.

Utilisez également un style autocratique lorsqu'il le faut. La MOA a son expertise, les décisions en relevant doivent être clairement prises et actées de tous. Ceci n'empêche pas d'expliciter les tenants et les aboutissants bien sur.

De la même manière, ne remettez jamais en cause les décisions prises par la MOE qui relèvent de leur expertise. Par exemple, une MOA ne doit pas remettre en cause le chiffrage fourni par la MOE, même si elle est en droit de demander des détails ou des explications.

Gérer le clivage MOA/Sponsor

  • La caricature :

Le Sponsor n'a pas de temps à accorder à  la MOA. Pour lui, la MOA est un "informaticien" comme un autre. La MOA pense que son sponsor ne s'implique pas assez dans le projet.

  • Les solutions du point de vue de la MOA pour éviter d'en arriver là :

Usez de vos qualités relationnelles. Sachez apporter légèreté et humour quand les conditions sont réunies, soyez toujours d'humeur égale, traitez parfois de hors sujets...

Adaptez votre style à votre interlocuteur. Certains interlocuteurs peuvent faire attention aux détails : ponctualité, look, sachez vous adapter.

Optimisez votre temps. Organisez des réunions courtes (30 minutes sont souvent suffisantes) mais régulières. Préparez les en utilisant un support optimal (type "Flash report"), conduisez les réunions en évitant les écarts, rédigez et diffusez toujours le compte-rendu dans la foulée pour mettre noir sur blanc les résultats de ces réunions.

Gérer le clivage intergénérationnel

  • La caricature :

La différence essentielle entre un jeune con et un vieux con réside dans le temps qu'il leur reste à être cons. - Jean Dion.
En tant que MOA vous serez amener à travailler avec des gens qui ont des rôles bien différents, vous amenant à réaliser un grand écart générationnel.

  • Les solutions du point de vue de la MOA pour éviter d'en arriver là :

Soyez ouvert. Vous allez être tantôt le jeune, tantôt le vieux. Sachez rester ouvert aux points de vue de tous les intervenants. Un utilisateur qui a 30 ans d'expérience sur son poste ne vous fera pas les mêmes retours qu'un utilisateur qui sort de l'école. Mais tous sont bon à prendre.

Acceptez la critique. On vous prendra un jour pour un jeune prétentieux aux dents longues parce que vous souhaitez bouleverser un processus métier qui fonctionne très bien depuis 15 ans, et le lendemain pour un vieux de la génération X parce que vous ne pratiquez pas le twittering et que vous avez aimé connu le doux chant du modem 56K. Acceptez de recevoir toutes les critiques, vous n'avez rien à prouver.