Home » Posts tagged 'DEVOPS'

Tag Archives: DEVOPS

Abonnez-vous à ce blog par e-mail.

Saisissez votre adresse e-mail pour vous abonner à ce blog et recevoir une notification de chaque nouvel article par email.

Etes-vous plutôt agile ou classique?

AGILE ou traditionnelle, quelle approche choisir?

L’approche agile vous semble peut-être nouvelle ou au contraire, peut-être êtes vous un ou une adepte des méthodes agiles? Quoi qu’il en soit, il est important de partir sur de bonnes bases. Déjà quand nous parlons d’agile à quoi faisons-nous référence? Ce blog étant spécialisé dans la gouvernance, le management et la sécurité, vous comprenez bien sûr que nous faisons référence à l’agilité dans la gestion de projets. Avant de démarrer il faut comprendre que le terme « Méthode » est trop limitatif pour aborder ce mode de gestion de projet. Le terme approprié serait plutôt « Approche Agile » car il s’agit plus d’une philosophie que d’une méthodologie.

Approche agile

Cette approche, donc, est devenue au cours de ces dernières années, très populaire dans les entreprises. Elle est conçue de sorte à apporter de nombreux avantages mais requiert une discipline stricte pour produire la valeur promise. Chaque étape est importante et indispensable. Nous allons vous montrer, au travers de cet article, les avantages de cette approche déjà très populaire. Il vous appartient ensuite de décider si elle est pertinente pour vous.

Agile, de quoi s’agit-il?

Né aux Etats-Unis, le mouvement agile est apparu en 2001, lorsque 17 experts se sont alliés pour mettre au point une nouvelle façon de développer des logiciels, visant à réduire le taux d’échec important des projets informatiques. C’est d’ailleurs à cette occasion que le terme Agile est apparu pour  qualifier cette nouvelle approche. Ce rassemblement a donné naissance à un manifeste définissant quatre axes de valorisation pour les projets :

  • Les individus et leurs interactions avant les processus et les outils
  • Des fonctionnalités opérationnelles avant la documentation
  • Collaboration avec le client plutôt que contractualisation des relations
  • Acceptation du changement plutôt que conformité aux plans

L’approche agile est une approche de gestion de projet défiant les approches classiques. La notion même de « Gestion de projet » est remplacée au profit de « Gestion de produit » de façon à mieux se focaliser sur le produit plutôt que sur le projet. L’objectif de tout projet est de livrer un produit. Dans une approche dite « classique », on attend généralement du client une expression détaillée et validée du besoin. Cette expression de besoin validée en début de réalisation laisse peu place au changement. La réalisation prend le temps qu’il faut et rendez-vous est repris avec le client pour la recette. Cet effet tunnel peut être mauvais et très conflictuel.

On remarque fréquemment un déphasage entre le besoin initial et l’application réalisée. On se rapporte alors aux spécifications validées et au contrat. La majorité des projets se terminent très mal au risque d’affecter la relation avec le client. De plus, il peut arriver que certaines fonctionnalités demandées soient inutiles à l’usage. D’autres, découvertes en cours de route, auraient pu donner plus de valeur au produit.

En quoi consiste réellement l’approche agile?

En 1994, une enquête réalisée par le «  Standish Group » a démontré que 31% des projets informatiques sont stoppé en cours d’exécution, 52% n’aboutisse pas et ne respectent pas les délais et le budget imposés proposant souvent moins de fonctionnalités qui étaient prévus. Et pour finir, seuls 16% des projets sont synonyme de réussite. La même enquête de nouveau menée en 2008 indique un taux de réussite de 35%. Cela représente une nette progression mais reste insuffisant.

Parmi les principales causes d’échec relevées on peut citer :

  • Manque d’implication des utilisateurs finaux : 12,8 %.
  • Changements de spécifications en cours de projet : 11,8 %.

L’approche Agile propose de réduire complètement les conséquences de cet effet tunnel en donnant davantage de visibilité, en impliquant le client du début à la fin du projet et en adoptant un processus itératif et incrémental. Elle considère que le besoin ne peut être figé et propose au contraire de s’adapter aux changements de ce dernier. Mais cela ne peut pas se faire sans un minimum de règles.

Comment est-ce que cela fonctionne?

Le principe de base des méthodes « Classiques » est qu’il peut être contre-productif. C’est-à-dire qu’avant de développer un produit, il faut le planifier et en spécifier les moindres détails. En effet, prévoir tous les aspects de la production entraîne dans la plupart des cas des frustrations et pertes de temps car les imprévus surviennent très souvent pendant la réalisation. C’est cette approche prédictive et séquentielle de type waterfall ou cycle en V que les tenants des méthodes « Agile » veulent casser.

Ainsi, le mieux serait de procéder par étapes c’est-à-dire se fixer des objectifs à court terme et commencer le développement sans perdre de temps. Une fois l’objectif atteint, on passe à la phase suivante et ainsi de suite jusqu’à atteindre le but recherché. Concernant le niveau de développement de logiciel, il appartient au client de transmettre à l’équipe de développeurs sa vision du produit avec les fonctionnalités qui l’accompagnent. Cela permet ainsi d’avoir un échange direct avec l’équipe et et de définir ensemble le coût de chacune des fonctionnalités pour aboutir à un budget final approximatif. L’équipe devra choisir ensuite une partie des exigences du client à exécuter dans un court délai appelé « itération ».

Itération agile

Le principe des itérations

Dans chaque itération se trouvent les travaux de conception, les techniques de développement et les spécifications fonctionnelles. Au terme de chaque itération, le produit semi-fini mais utilisable, est montré au client. Il peut donc se rendre compte par lui-même du travail réalisé dans un temps très court. Quant à l’utilisateur final, il peut déjà se projeter dans l’usage du produit. Cela lui permet de transmettre des feedbacks importants pour les prochaines itérations. Cette transparence est un grand avantage pour solidifier la relation de confiance et de collaboration entre le client et le fournisseur. Cela permet ainsi d’économiser son budget et de récolter rapidement un premier retour sur investissement. Le client a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n’ont pas encore été développés (prochaines itérations).

Cette souplesse ainsi offerte est donc un véritable atout pour le client. Encore une fois, on pense plus « Produit » que « Projet » d’où le terme approprié ici est « gestion de produit » remplaçant celui de « gestion de projet ».

Les différentes méthodes agiles

Il existe plusieurs types de méthodes Agiles, se différenciant par leur capacité d’adaptabilité à certains projets. Parmi ces méthodes nous retrouvons la méthode RAD qui implique par exemple la présence d’une tierce personne pour résoudre les problèmes et les incompréhensions. La méthode SCRUM, la méthode FDD et la méthode DSDM sont quant à elles basée sur l’organisation de plusieurs mais courtes réunions permettant de d’approuver chaque étape, contrôler les avancées et développer une bonne relation de confiance entre les intervenants en la rendant plus interactive.

Loin d’être une simple méthodologie, l’approche Agile définit un état d’esprit impactant l’ensemble des entreprises souhaitant s’y conformer. Cette démarche, à la fois longue et difficile à mettre en œuvre, en vaut largement la peine. Elle permet, en effet, d’obtenir des résultats très satisfaisants. Il est donc primordial d’en maitriser chaque partie afin de faire accepter ce changement tant au sein de l’entreprise qu’auprès du client.

Les évolutions récentes

La plupart des méthodes « agile » de gestion de projet sont ciblées sur les projets de développement de logiciel. Est-ce à dire qu’on ne peut utiliser Agile que pour l’informatique? A l’heure où la mondialisation exige des Entreprises qu’elles soient toujours plus agiles pour se repositionner sur le marché grâce à des innovations constantes, ne pourrait-on pas imaginer créer des produits non logiciels de façon agile?

La réponse est bien sûr positive. Les méthodes de gestion de projet traditionnelles se sont récemment enrichies d’une version agile. L’agilité n’entame en rien la nécessité d’utiliser une méthode éprouvée. Aussi, récemment les principaux éditeurs ont publié des versions « agile » de leur méthode traditionnelle :

  • AXELOS, éditeur de PRINCE2, vient de publier PRINCE2 Agile qui à donné naissance à la certification PRINCE2 Agile Practitioner,
  • PMI a créé récemment la certification PMP-ACP (PMP Agile Certified Practitioner).

Alors au final vous êtes plutôt Agile ou Classique?

Les méthodes Agiles pourront être utilisées pour de gros projets car elles proposent une adaptabilité, une meilleure visibilité et gestion des risques. Elles pourraient tout aussi bien être utilisées pour les projets où il n’y pas de documentation détaillée. Le client peut alors suivre la progression du projet et l’adapter au fur et à mesure selon ses besoins.

.Par contre, les méthodes Traditionnelles seront plus adaptées si vous avez une idée précise de votre projet avec un cahier des charges et planning très détaillé où vous avez anticipé tous les risques envisageables. Nous essaierons prochainement de vous orienter entre l’approche Traditionnelle ou l’approche Agile selon les types de projets. Notre prochain article proposera une étude comparative des approches et méthodes « agile » pour vous aider à faire un choix raisonné.

Bien sûr, nous vous invitons à réagir et à nous communiquer vos commentaires.

Nouveau: DevOps débarque en Afrique!

Une évolution nommée DevOps

Apparu depuis quelque temps, un nouveau mouvement professionnel et culturel visant à améliorer le flux entre les développeurs de logiciels et les équipes opérationnelles commence à faire ses preuves. Encore peu répandu sur le continent Africain où, pourtant, de nombreuses organisations réalisent leurs propres développements de logiciel en interne avant de les exploiter, DevOps répond clairement à un besoin croissant d’agilité des organisations dans un contexte de plus en plus mondialisé. Certains en ont peut-être déjà entendu parler sur des blogs ou via des offres d’emploi.

Dans un premier temps, DevOps peut être vu comme un outil d’amélioration des performances opérationnelles fonctionnant de manière intelligente. La stratégie DevOps aura un impact sur l’ensemble des réseaux de distribution. A la clé figurent des avantages non négligeables:

  • réduction du temps de commercialisation,
  • diminution des problèmes liés aux nouvelles publications,
  • réduction des délais de mise à disposition de correctifs
  • et accélération des temps de reprise après sinistre.

L’évolution constante des entreprises vers le numérique pousse désormais les développeurs à revoir sérieusement les modes de création d’applications.

DevOps-Evolution

Il n’est désormais plus tolérable d’attendre 6 mois, voire 1an avant de livrer les services demandés par les entités business. Les systèmes d’information doivent s’aligner sur la sortie des produits et services métiers. Le marketing ne peut plus attendre, surtout que les projets futurs deviennent de plus en plus complexes notamment en matière informatique. Le tout se retrouve dans un contexte économique pesant sur les budgets. Dans le cadre de ce développement, DevOps répond parfaitement à ce défi digital et les entreprises en ont maintenant pris conscience.

Qu’est-ce que DevOps?

DevOps est l’abréviation de « Développement » et « Opérations » dans le domaine informatique. Ce n’est pas un outil, un processus ou une méthodologie. DevOps a débuté comme étant, et continue d’être, une convergence d’idées en vue de combler le fossé qui sépare les équipes de développement et d’exploitation dans les Directions Informatiques. L’idée maitresse est de rationaliser le développement de logiciels et de faciliter leur exploitation et leur maintenance. Le terme DevOps identifie un mouvement déclenché par la frustration des professionnels de l’informatique, vers 2010, résultant des dysfonctionnements et de l’incapacité d’y remédier du fait d’outils et de processus inadaptés. Ces professionnels IT frustrés ont partagé leur vision du fait que le développement de logiciels et les opérations peuvent, et doivent être plus efficaces et moins douloureux.

Aujourd’hui, la définition originale de DevOps comme étant l’intégration du « développement » et des « opérations » est devenue trop limitée et inexacte. DevOps implique plus d’acteurs que les seuls développeurs et les techniciens d’exploitation. Le cycle de développement de logiciel  implique également de nombreux autres rôles qui constituent des contributeurs essentiels. Parmi ceux-ci, citons la gouvernance, l’assurance qualité (QA), les tests, la sécurité et la gestion des versions. DevOps est donc une combinaison de personnes, de culture, de processus, d’outils et de méthodes  réduisant les risques et les coûts, et permettant à la technologie d’évoluer à la vitesse de l’entreprise, et d’améliorer la qualité globale.

Pourquoi une nouvelle approche?

L’approche traditionnelle repose sur un ensemble de facteurs qui la fragilisent et l’alourdissent. DevOps représente une prise de conscience que l’approche traditionnelle n’est plus en mesure de satisfaire le besoin d’agilité nécessaire à l’Entreprise pour rester concurrentielle. Un exemple typique serait le cas du web qui gère des applications dans le Cloud. DevOps est une démarche innovante qui s’apparente à une philosophie destinée à des personnes à la recherche d’efficacité.

Pour la réalisation des grands projets informatiques, différentes équipes aux rôles bien définis sont impliquées. Il s’agit d’une part de l’équipe de développement et d’autre part de celle chargée de l’exploitation. Habituellement, les équipes de développement tentent de répondre à des spécifications fonctionnelles issues du métier ou du client. Elles travaillent généralement dans leur propre environnement, avec leurs outils destinés aux développements. Elles ne se soucient guère de l’impact que peut avoir leur code sur la phase d’exploitation qui exécutera l’application sur un environnement de production. Les équipes chargées de l’exploitation, quant à elles, tentent de répondre à des impératifs de performance ou de stabilité du système. Et c’est pourquoi, elles sont très attentives à minimiser les impacts des modifications afin de préserver ces performances. Hélas, cela risque de générer un goulot d’étranglement pour l’ajout de nouvelles fonctionnalités aux applications.

Quelle que soit l’équipe, il est toujours compliqué d’être au courant de comment une autre équipe gère ses tâches. Cela rend difficile l’optimisation des deux côtés. C’est à ce niveau qu’intervient DevOps dont le rôle est, en quelque sorte, de réaliser l’intégration des différentes équipes pour faciliter la communication et diffuser l’information. Les autres fonctions de DevOps incluent l’amélioration de la coordination durant les phases de livraison et de déploiement afin de limiter les erreurs.

Les résultats sont-ils probants?

Les résultats sont probants et donnent un bon aperçu des avantages de DevOps. Selon un sondage récent 66% des entreprises dans le monde utilisent déjà une stratégie DevOps ou envisagent d’en mettre une en œuvre. Plus de 90% d’entre elles ont observé ou s’attendent à un gain substantiel grâce à leurs initiatives DevOps. Les résultats de DevOps sont réels et quantifiables car cette approche génère des améliorations, augmentations ou réductions, à deux chiffres (de 17 à 23%).

Infographie DevOps

Les résultats concernant la France sont inférieurs aux chiffres résultants du sondage mondial mais sont néanmoins significatifs.

Quels sont les enjeux?

L’arrivé de DevOps met la pression aux développeurs car ils doivent produire davantage dans un temps réduit et réaliser des tests supplémentaires tout en respectant les contraintes budgétaires imposées. Parmi les enjeux majeurs apparaissent la réactivité commerciale et les délais de commercialisation qui bien souvent affectent l’expérience du client. Cela dit, DevOps impose un niveau de collaboration, d’agilité, de visibilité de développement et de rapidité de distribution qui relève le défi des projets à long terme dont la lenteur est à bannir compte-tenu des contraintes du monde de l’entreprise.

La stratégie DevOps est moins adaptée aux mainframes car il est généralement compliqué de faire évoluer des processus traditionnels bien ancrés et de développer la collaboration autour de technologies solidement établies. La majorité des schémas organisationnels sont en réalité inadaptés ou insuffisants pour permettre aux équipes de développement d’atteindre leurs objectifs et le niveau de productivité qu’exige leur entreprise.

DevOps, pour quels bénéfices

Le slogan pré-Devops était « Vite vite on met en production ! ». Mais attention, il ne faut pas confondre vitesse et précipitation. La production c’est du sérieux ! En effet, les développeurs produisent du code à partir d’un cahier des charges précis. Ils se préoccupent peu des impacts que peut avoir leur code sur la production. De la même façon, les équipes de production sont quant à elles obnubilées par la stabilité de l’infrastructure, garante de la création de valeur pour les métiers. Elles freinent donc les mises en production et blâment le code du développeur si le résultat voulu par l’utilisateur n’est pas satisfaisant. La vision DevOps tente de pallier à ce problème en favorisant une répartition des responsabilités et l’implication de l’ensemble des acteurs de la chaine. Le développeur devient ainsi testeur de son code.

Les intérêts d’adoption d’une démarche Devops sont multiples :

  • Réduire le cycle et le coût de mise en production,
  • Avoir une approche plus fragmentée (petites évolutions),
  • Faire que les mises à jour deviennent transparentes,
  • Mise en commun des responsabilités (tout le monde dans le même bateau!)
  • Une amélioration continue du produit,
  • Répondre plus rapidement aux besoins des clients.

NETFLIX, Amazon, Singapore Power ont été conquis par DevOps

Eh oui, même les plus grands ont adopté Devops ! Des entreprises telles que Netflix ou Amazon ont bâti une bonne partie de leur succès en s’appuyant DevOps.

Cycle de vie DevOpsChez Netflix, par exemple, le déploiement est totalement automatisé, depuis le packaging du nouveau code jusqu’à la mise en production. Cela passe par la mise en oeuvre de l’infrastructure virtuelle et les tests fonctionnels. Une nouvelle version d’application sera promue automatiquement dans une nouvelle infrastructure virtuelle. Elle est mise en service en lui redirigeant un sous-ensemble du trafic utilisateur. Après une phase pilote avec monitoring automatisé, si le comportement s’avère satisfaisant, la totalité du trafic est redirigé. L’ancienne instance de l’application et son infrastructure sont alors automatiquement décommissionées.

Vous souhaitez en savoir plus sur DevOps?

DevOps est désormais accessible en Afrique. Laissez vous tenter par cette révolution. Faites partie des premiers à satisfaire enfin le besoin d’agilité tant attendue par le Business. Grâce à DevOps vos équipes informatiques pourront concevoir et déployer des applications plus rapidement. Elles travailleront de manière efficace et efficiente, s’adapteront facilement au changement, développeront de meilleurs logiciels. Dernier avantage non négligeable, DevOps vous permettra d’optimiser les coûts. Une mise en œuvre parfaite de DevOps est essentielle et nécessite des professionnels expérimentés dans le domaine. C’est pourquoi AB Consulting, seul organisme officiellement accrédité en Afrique, vous aide à comprendre et à mettre en œuvre DevOps dans votre Organisation. Nous vous accompagnons également dans la conduite du changement culturel au sein de vos équipes. Pour plus d’informations sur nos prochaines formations DevOps Foundation, consultez notre site.

N’hésitez pas à nous adresser vos commentaires et vos questions qui seront les bienvenues pour que s’instaure un dialogue fructueux autour de la révolution DevOps.

ITIL Practitioner, une certification UTILE?

Au moment où la nouvelle certification ITIL Practitioner d’AXELOS arrive sur le marché, nous nous sommes posé la question de son utilité alors que le cursus ITIL est déjà bien fourni et que la grande majorité des informaticiens se contentent de la formation et de la certification ITIL Foundation. Alors était-ce vraiment utile de rajouter encore un niveau supplémentaire?

ITIL Practitioner

ITIL Practitioner, le chaînon manquant

La nouvelle certification introduite sur le marché par AXELOS début février 2016 vient compléter le cursus existant basé sur les niveaux Foundation, Intermediate, Expert et Master qui existent depuis la publication d’ITIL V3 en 2007, en y ajoutant un niveau se situant immédiatement au dessus de la certification ITIL Foundation. En gros ITIL Practitioner c’est en quelque sorte le chaînon manquant dans le parcours de certification d’AXELOS. Nous avons essayé, dans notre précédent article ITIL Foundation, Guide de survie, de clarifier quelque peu le schéma global hérité de celui défini par APMG il y a maintenant bientôt 10 ans. Le diagramme suivant illustre la structure du nouveau parcours de certification:

ITIL Practitioner dans le schema de certification

ITIL Practitioner, c’est quoi?

Il manquait donc, dans ce parcours de certification « historique », un niveau pratique destiné à certifier les aptitudes des praticiens et des consultants dont la tâche quotidienne est de travailler sur des projets d’implémentation ou d’amélioration des bonnes pratiques de gestion des services IT dans les Organisations. C’est bien là l’objectif de cette formation et de la certification ITIL Practitioner. A priori, c’est une excellente nouvelle pour tous les certifiés Foundation qui vont pouvoir maintenant apprendre comment mettre en oeuvre leurs connaissances dans la pratique. La mauvaise nouvelle c’est que le format de la formation préparant à cette qualification tel qu’il est été défini par AXELOS n’est pas vraiment adapté. En effet, cette session est prévue sur une durée de seulement deux jours (examen inclus), ce qui est nettement insuffisant pour couvrir la totalité d’un contenu extrêmement riche et dense. De plus cet examen de certification se déroule à livre ouvert et la formation associée va souvent, en fonction de votre organisme de formation et de la compétence de ses formateurs, se focaliser sur la façon d’utiliser le manuel dans un cas réel plutôt que sur un retour d’expérience sur les problématiques rencontrées par les consultants dans leur expérience concrète de conseil en Entreprise. C’est bien dommage. Bien sûr on m’objectera que les personnes concernées peuvent toujours demander une formation de durée plus longue pour appréhender l’ensemble des pratiques décrites mais, franchement, quelle Entreprise acceptera de financer une session plus longue que les deux jours préconisés par AXELOS?

Le parcours existant de certification était-il suffisant?

Nous avons clairement montré dans notre article sur le parcours « historique » de certification ITIL qu’il manquait de toute évidence un niveau de certification destiné à la fois aux consultants en charge de mener des projets d’implémentation et/ou d’amélioration des bonnes pratiques ITIL ainsi qu’aux personnels internes aux organisations concernés et impliqués dans les projets d’implémentation et/ou d’amélioration. Bien sûr, on m’objectera que c’était normalement la vocation des niveaux dits « Intermediates » et du niveau MALC conduisant à la certification ITIL Expert. Hélas, sur aucun de ces niveaux ne sont abordées les problématiques clés liées spécifiquement à un projet d’implémentation telles que la gestion du changement organisationnel, la facilitation du changement culturel, la communication à mettre en oeuvre pour viser à assurer la réussite d’un tel projet ou encore la conception d’un modèle de métriques et d’indicateurs nécessaires pour s’assurer que les bénéfices attendus en termes de création de valeur pour les parties prenantes de l’organisation sont bien réalisés conformément au cas d’affaire validé en début du projet. Ces aspects ne sont traités nulle part dans le parcours de certification ITIL « historique ». Cela signifie que même un « Expert ITIL » se trouve complètement démuni face à ces problématiques qui constituent cependant le quotidien des consultants et qu’il sera souvent incapable de mener avec succès un projet d’adoption et surtout d’adaptation des pratiques ITIL dans une Entreprise. Trop de lacunes existent!! Cela explique sûrement en partie les raisons de l’échec de tant de projets d’implémentation de bonnes pratiques ou de processus sur la base d’ITIL.

Les apports du cours et de la certification ITIL Practitioner

La publication par TSO de ITIL Practitioner Guidance vient combler quelque peu les lacunes existant dans les 5 publications centrales sur lesquelles sont basée les certifications historiques depuis ITIL Foundation jusqu’à ITIL Expert. Cette nouvelle publication sert de trame à la nouvelle certification ITIL Practitioner à laquelle elle donne son nom. On retrouve donc dans le syllabus de la formation et de la certification ITIL Practitioner les éléments clés de la publication qui est d’ailleurs autorisée pour le passage de l’examen.

Concrètement, elle s’articule autour 3 grands thèmes principaux correspondant aux trois compétences clés indispensables pour réussir un projet d’implémentation ou d’amélioration des pratiques de gestion des services en adaptant les processus ITIL au contexte de l’organisation :

  1. Communication
  2. Gestion des Changements Organisationnels (OCM)
  3. Mesures et métriques

Un consultant, certifié ITIL Expert, qui ne possèderait pas ces trois compétences clés se retrouverait un peu dans la situation du joueur de tennis avec un énorme potentiel qui possède parfaitement le jeu d’échange de fond de court mais qui est incapable de réussir un service ou de monter au filet face à son adversaire. Il ne pourrait que perdre la partie, étant dans l’impossibilité de s’adapter au contexte…

Elle est complétée par les 9 principes qui doivent guider toute initiative d’implémentation ou d’amélioration, hérités d’autres cadres tels que COBIT, DevOps, Agile, Lean etc.

La gestion de changement est un facteur-clé de réussite

Les neuf principes supportant une initiative d’implémentation

L’expérience a montré que la réussite de tout projet d’implémentation basé sur une approche d’amélioration continue résulte systématiquement de neuf principes directeurs suivis par le projet et permettant de délivrer les résultats attendus. Ces neuf principes, repris par de nombreux cadres de bonnes pratiques, s’appliquent bien évidemment aux projets ITSM.

1 – Focalisation sur la valeur

Tout projet d’implémentation ou d’amélioration des services IT doit créer de la valeur pour les parties prenantes de l’Entreprise et, seules ces mêmes parties prenantes sont à même d’évaluer les bénéfices résultant du projet.

2 – Focalisation sur l’expérience utilisateur

Les services et les processus IT doivent toujours être conçus pour satisfaire les besoins des clients et des utilisateurs afin de leur fournir une expérience positive de bout-en-bout.

3 – S’appuyer sur l’existant

Il ne faut jamais repartir de zéro. Un projet ne peut réussir que si l’existant, avec ses forces et ses faiblesses est bien compris pour permettre l’adaptation des bonnes pratiques, génériques par essence, au contexte spécifique de l’Entreprise, en capitalisant sur ses forces existantes.

4 – Utiliser une approche holistique

Aucun composant ou service n’existe en isolation. Les services sont des systèmes complexes qui doivent toujours être envisagés depuis la conception jusqu’à l’exploitation et l’amélioration comme un tout.

5 – Progresser de façon itérative

Il faut résister à la tentation, souvent forte, de vouloir tout faire en même temps. Toujours découper le travail en « tranches » faciles à gérer et délivrant chacune un bénéfice mesurable sur lequel on pourra capitaliser pour conserver l’élan afin d’entamer la tranche suivante. Ce sont les petits cours d’eau qui créent les grands fleuves…

6 – Observer directement

Toujours baser ses décisions sur des informations vraies, pertinentes et incontestables. A chaque fois que c’est possible, toujours remonter à la source de l’activité et observer directement, en personne.

7 – Faire preuve de transparence

Toujours être clair et honnête sur ce qui se passe vraiment et pourquoi, dans le déroulement du projet de telle sorte que les rumeurs et bruits de couloir ne puissent pas miner la confiance des personnes concernées et que la vérité soit toujours clairement établie de telle sorte que chacun puisse toujours s’exprimer sereinement sur des bases claires et incontestables.

8 – Favoriser un approche collaborative

Toujours travailler ensemble de façon créative avec les personnes concernées par le projet dans la direction validée. Le partage des efforts et de l’engagement permettra ensuite de partager les résultats et les bénéfices.

9 – Garder les choses aussi simples que possible

Ne faire que ce qui est indispensable pour atteindre l’objectif fixé et toujours éliminer ce qui ne contribue pas directement à la création du bénéfice attendu et qui constitue, de fait, du gaspillage.

A qui s’adresse la certification ITIL Practitioner?

Cette certification, comme vous l’aurez certainement compris, s’adresse directement aux personnes impliquées dans un projet d’implémentation ou d’amélioration des services et processus IT en Entreprise, mais aussi, et de façon primordiale, aux consultants accompagnant ce type de projets chez leurs clients.

Cette certification se situe, dans le nouveau parcours de certification, au niveau immédiatement au dessus de la certification ITIL Foundation. Pourtant, il apparaît clairement que les professionnels qui en tireront le plus grand profit sont avant tout les certifiés ITIL Expert, car elle leur apportera le côté pratique qui leur manquait jusque là. Très sincèrement, après avoir passé (et réussi) cette certification, et malgré les nombreux projets de ce type que j’ai eu la chance de mener dans des Entreprises de toutes tailles et dans des régions du monde différentes, j’ai trouvé cet examen d’un niveau de difficulté tel que j’imagine que peu de candidats sans expérience et possédant seulement la certification ITIL Foundation seront capables de le réussir, surtout après une formation de deux jours.

Alors, ITIL Practitioner, UTILE ou pas?

Oui, bien sûr, ITIL Practitioner est une certification très utile pour tous les consultants, même s’ils risquent de « tomber de haut » à la lecture de leurs résultats à l’examen. Je la préconiserais plutôt à des consultants expérimentés qui y trouveront des réponses à des challenges qu’ils auront dû gérer de façon empirique dans le cadre de leurs missions. A mon sens, compte tenu du format de la formation qui tient sur deux journées, examen inclus, il est nécessaire que les participants aient déjà consacré un temps important à la lecture et à la compréhension du manuel ITIL Practitioner Guidance (Ed. TSO) qui doit impérativement faire partie du package pédagogique remis par votre organisme de formation accrédité (ATO), au minimum 3 semaines avant la session. La formation elle-même portera alors d’avantage sur les retours d’expériences délivrés par le formateur, sur un échange des bonnes pratiques et une bonne compréhension des compétences à mettre en oeuvre et, bien sûr, sur la préparation à l’examen.

Comment se former et se certifier ITIL Practitioner?

Aujourd’hui quelques ATOs proposent d’ores et déjà cette formation à leur catalogue, dont AB Consulting. Vous pouvez également vous auto-former en vous référant au manuel ITIL Practitioner Guidance (Ed. TSO). La meilleure approche consiste indéniablement à approfondir le manuel dans un premier temps avant de suivre la formation ITIL Practitioner auprès d’un ATO (Accredited Training Organization) d’AXELOS qui saura vous apporter les retours d’expérience indispensables à la réussite de cet examen assez difficile.

Pour en savoir plus

A l’occasion du lancement de la certification ITIL Practitioner, AXELOS organise le 25 Février 2016, une conférence internationale au travers de 6 webinaires gratuits accessibles en ligne, directement depuis votre poste de travail. AB Consulting, partenaire d’AXELOS sur cette initiative, vous invite à découvrir en exclusivité cette nouvelle certification avec la participation de l’équipe qui est à l’origine de cette initiative. Pour vous inscrire, cliquez simplement sur l’image ci-dessous:

ITIL Practitioner - Conférences gratuites

 

Si vous avez aimé ou détesté cet article et si vous souhaitez nous apporter vos commentaires, merci d’utiliser le formulaire de contact suivant :

Jugez-vous votre organisation IT efficace?

Votre organisation IT est-elle efficace? Comment pouvez-vous évaluer son efficacité? Vos clients Business ont-ils la même perception que vous?

organisation IT efficace

 

L’évaluation de l’efficacité, tout comme celle de la qualité, peut être très subjective. Dans de nombreux cas, l’efficacité est évaluée par rapport au denier service que vous avez mis en production ou au travers d’un projet que votre organisation livré. En outre, on accordera beaucoup plus de poids à des résultats décevants qu’à des résultats positifs. C’est naturel n’est-ce pas ? Dans un monde idéal, vos services informatiques devraient fonctionner de façon optimale. Nous avons donc besoin de définir des caractéristiques objectives de l’efficacité des organisations informatiques avant de pouvoir travailler à les améliorer.

Commençons par définir la mission de l’informatique « fournir la capacité de traitement de l’information requise par le business à un coût qui représente une valeur« . Beaucoup d’entre vous sont en train de lire cette définition en se disant qu’elle est très floue. En effet, les besoins de l’entreprise évoluent en permanence et il en va de même de la perception de la valeur. L’efficacité ne peut être évaluée que par rapport aux attentes attentes actuelles, aux objectifs de niveau de service définis et aux ressources disponibles. Pour cette raison, l’une des caractéristiques les plus importantes d’une organisation informatique efficace est sa capacité à répondre rapidement à l’évolution des besoins du business.

Pour être considérées comme efficaces, les organisations IT devront satisfaire les contraintes suivantes :

Flexibilité

L’IT fournit des services à la demande (résolution de problème et assistance) ainsi que des services planifiés (amélioration et projets). Les problèmes à priorité élevée, les demandes toujours urgentes, et l’évolution des besoins de l’entreprise vont perturber les dates cibles d’achèvement, le périmètre planifié et l’effort estimé. Les organisations efficaces doivent trouver un juste équilibre entre la variabilité des demandes, l’évolution permanente des priorités, et les changements dans les besoins. Afin d’obtenir cette flexibilité, les entreprises doivent gérer les demandes, les horaires, les priorités, le périmètre / les exigences, la mise à disposition et les compétences du personnel afin d’optimiser les résultats et de minimiser les impacts.

Adaptabilité

Les organisations informatiques doivent répondre aux évolutions nécessaires dans les types de services fournis, elles doivent intégrer et soutenir les nouvelles technologies, et elles doivent adapter aux changements organisationnels de l’entreprise et de l’informatique. Afin de s’adapter, l’informatique doit redéfinir ses rôles, transformer ses processus de planification et de livraison, et investir fortement dans la formation (notamment les bonnes pratiques telles que ITIL, COBIT ou encore Lean IT).

Prévisibilité

Des résultats reproductibles ne peuvent être atteints que par l’exécution de processus normalisés et par un engagement vis à vis de la qualité qui évite l’héroïsme et les solutions sur mesure.

Efficience

Chacune de ces caractéristiques est en conflit avec les autres. Une approche équilibrée est donc nécessaire. L’efficacité est généralement sacrifiée pour améliorer la flexibilité. L’efficacité peut être améliorée grâce à la documentation des connaissances, à la formation croisée, à l’utilisation des processus standardisés, d’outils de gestion, et en limitant la variété des environnements techniques.

Fiabilité

La fiabilité fait référence aux applications, à l’infrastructure et aux personnes qui délivrent les services. Les moyens de traitement (infrastructures, réseaux, applications) doivent être fiables, mais le personnel doit aussi faire preuve de fiabilité dans la livraison de services IT. Cela impose donc de définir des critères d’acceptation, d’effectuer des revues de qualité, des tests, et de nombreuses autres activités qui assureront la cohérence de la fourniture de services et des moyens de traitement mis en oeuvre.

Innovation

Le business ne comprend pas les limites de la capacité et de la technologie disponibles. L’IT est dans la position idéale pour recommander des stratégies au business plutôt que d’attendre que ce soit l’entreprise qui définisse elle-même ses stratégies. Sur un plan plus tactique, l’IT devrait être à la recherche de solutions visant à réduire les problèmes et améliorer les processus de telle sorte qu’ils s’alignent avec les autres caractéristiques.

Pro-activité

L’informatique doit être capable d’anticiper les besoins ou les incidents et de prendre des mesures pour se préparer à des pointes d’activité ou pour éviter les problèmes. Grâce à la compréhension des besoins business et des capacités existantes, et en effectuant le suivi des changements, l’IT peut anticiper et manager de façon pro-active. Cela nécessitera des processus reproductibles, des métriques et des mesures, et aussi une communication renforcée avec le business.

Alors, quelle stratégie adopter pour une IT efficace?

équipe IT efficace

Ces contraintes peuvent parfois se contredire entre elles et entraîner du gaspillage. La rigueur nécessaire du processus qui nous rend prévisible peut aussi entraver notre efficacité. Afin d’équilibrer les contraintes, l’IT doit affiner son rôle et sa culture. En plus d’exploiter et de soutenir la capacité de traitement existante, l’IT doit reconnaître que les besoins de l’entreprise évoluent en permanence et qu’une organisation efficace doit être en mesure de répondre à ces changements. Afin d’offrir de la valeur, les organisations informatiques doivent assurer les caractéristiques d’efficacité qui ont été décrites plus haut. Cela nécessitera de gérer l’organisation informatique comme une entité business indépendante qui est responsable de ses coûts et de ses revenus, et elle devra faire la preuve de sa valeur à ses clients sur une base quotidienne.

Le succès ne se mesure pas sur le respect ou le dépassement des attentes. Les attentes peuvent être impossible à satisfaire (compte tenu notamment des ressources disponibles) ou déraisonnables. Le succès se mesure par la gestion des attentes, la prise d’engagements et l’atteinte ou le dépassement des engagements. L’IT doit faire montre de leadership et pas simplement attendre que le business décide du parti qu’il peut tirer de la technologie. Lorsque l’IT démontre sa valeur, elle peut de nouveau être considérée comme un investissement et non pas simplement comme un coût destiné à être réduit ou éliminé.

Pour plus d’informations ou pour vous abonner à notre newsletter, merci de remplir le formulaire de contact:

 

Fournisseur de services informatiques… un challenge

Aujourd’hui l’entreprise dépend étroitement du bon fonctionnement de ses services informatiques. Un problème d’ordinateur, de serveur, de logiciel ou de connexion Internet et l’entreprise se trouve bloquée ou ralentie dans ses activités.

utilisatrice des services informatiques

Qu’est ce qu’un service informatique ?

Selon ITIL®, le référentiel de bonnes pratiques publié par AXELOS®, le plus utilisé dans le monde, Un service informatique est un moyen de fournir de la valeur aux clients en facilitant les résultats qu’ils veulent obtenir, sans avoir à en gérer ni les coûts, ni les risques spécifiques.

Un Service informatique s’appuie sur quatre éléments: les technologies, les informations, les personnes et les processus.

Les services informatiques touchent l’ensemble des actions coordonnées de recherche, de traitement, de communication et protection des informations utiles d’une entreprise.

 La gestion des services informatiques

Lagestion des services informatiques gestion de services informatiques (ITSM) se réfère à l’ensemble des activités – définies par des politiques, organisées et structurées grâce à des processus et des procéures de soutien – qui sont effectuées par une organisation ou une partie d’une organisation consistant à planifier, à organiser, exploiter et contrôler
les services informatiques offerts aux clients internes ou externes. La gestion des services informatiques est donc préoccupée par la mise en œuvre de services informatiques de qualité qui répondent aux besoins des clients. Elle est réalisée par le fournisseur de services informatiques grâce à l’utilisation d’une combinaison appropriée de personnes, de processus et de technologie de l’information.

Si, la plupart du temps, l’activité d’une Entreprise débute avec quelques ordinateurs et des logiciels de bureautique, très vite le développement de l’activité amène à devoir faire évoluer son système informatique. Or une bonne gestion du système informatique, pensée à l’avance, permet de prévoir ces évolutions et d’éviter les freins au développement et le surcoût.

Pour assurer cette gestion les responsables des organisations informatiques sont chargés de transformer leurs organisations afin de passer de fournisseur technologique traditionnel à fournisseur de services. Ils doivent pour cela adopter une approche systématique orientée sur le cycle de vie de la gestion de services informatiques (ITSM), afin de s’aligner sur les objectifs métier et informatiques de l’entreprise.

La transformation nécessaire de l’organisation

Il s’agit là d’une transformation majeure tant au niveau de la culture de l’organisation informatique qui doit être focalisée sur les besoins de ses clients au lieu des aspects techniques,  que des structures organisationnelles et des processus à implémenter. Bien sûr, cette transformation nécessitera la mise en place d’outils adaptés pour gérer efficacement les services. Adieu donc aux gestions de parc informatique en open-source et autre logiciels spécifiques bon marché. Il faut désormais se concentrer sur le cycle de vie des services et miser sur des suites d’outils intégrés.

Pour ce qui est des processus, il existe de référentiels de bonnes pratiques tels que ITIL® qui pourront être un support extrêmement important dans votre transformation. Toutefois il ne faut pas chercher à mettre en oeuvre l’ensemble des 25 processus et des 4 fonctions décrits par ITIL®. Concentrez-vous sur les attentes de vos clients et sur ce qui leur créera le plus de valeur. L’objectif n’est en aucun cas de réduire les coûts de fourniture des services informatiques mais bien de livrer des services à haute valeur ajoutée à vos clients, leur permettant d’atteindre leurs objectifs business en ligne avec les attentes définies par les actionnaires et autres parties prenantes portées par le conseil d’administration de l’entreprise.  Peut-être que seulement un ou deux processus feront sens dans le contexte de votre organisation. La priorisation est donc clé. Un référentiel de gouvernance et de management du SI tel que COBIT® 5 peut vous aider à définir vos priorités grâce à sa cascade d’objectifs permettant, à partir des attentes des parties prenantes de définir les objectifs de l’organisation informatique, d’en déduire quels processus seront vitaux pour leur atteinte et, pour chacun de ces processus, sur quels objectifs vous concentrer. Il va également falloir former les personnels de façon adéquate tant au niveau des compétences (formations ITIL® et/ou COBIT® en l’occurrence) qu’au niveau de la culture de services en vue de les amener à adopter le comportement idéal. Ne négligez pas cet aspect qui est primordial pour la réussite de votre projet.

Pour réussir votre projet de transformation vous aurez également besoin d’un expert du domaine, souvent un consultant externe, maîtrisant parfaitement la mise en oeuvre de ce type de projet de transformation. Comment le trouver? C’est très simple. Il doit avoir la connaissance des processus concernés et une bonne expérience de plusieurs implémentations réussies. La connaissance sera reconnue grâce à des certifications appropriées. Surtout ne confiez pas votre organisation à quelqu’un n’ayant qu’une certification Foundation. Recherchez un expert possédant la certification ITIL® Expert dans le cas de processus ITIL®. Bien sûr cela vous coûtera plus cher mais quel est votre objectif? Dépenser le moins possible et perdre votre investissement voire, plus grave encore, pénaliser votre entreprise à cause de services informatiques mal définis et non alignés sur les besoins business ou maximiser la valeur créée par le business à l’aide des services informatiques performants permettant de prendre de l’avance sur les concurrents?

Un de mes clients, ex-DSI d’une Entreprise, m’expliquait il y a quelque temps qu’il avait parfaitement réussi l’implémentation de processus ITIL® dans son organisation et, finalement avait fini par se faire licencier. Lorsque je lui demandais comment il s’y était pris pour « implémenter ITIL® » il m’indiqua qu’il avait défini et implémenté le processus de gestion des incidents. Quand je lui demandais comment le choix du processus de gestion des incidents avait été effectué, il me dit qu’un consultant externe, certifié ITIL® Foundation, les avait orientés dans ce sens car « c’est le point de départ logique et habituel de toute implémentation ITIL® ». Alors que je luis demandais quels étaient les challenges de son Entreprise, il me répondit que la stratégie fixée par le conseil d’administration consistait en un développement rapide de l’Entreprise grâce à l’ouverture de magasins au rythme d’une nouvelle implantation chaque semaine, ce qui était très problématique en terme de rythme pour le département informatique qui devait donc déployer des postes de travail et gérer l’évolution de ses services informatiques à une cadence effréné. Il m’indiqua que finalement le département informatique n’avait pas pu suivre et que le rythme des implantations avait dû être ralenti de ce fait. Je lui demandais alors si les utilisateurs et les clients se plaignaient de l’indisponibilité des services informatiques pour cause d’incidents. Il me répondit qu’au contraire ils étaient extrêmement contents de la stabilité de leur système d’information, ce dont il était apparemment très fier. Il devenait dès lors très clair que le choix d’implémenter la gestion des incidents était une erreur majeure et que des processus tels que la gestion des changements et la gestion de mises en production et des déploiements eussent été mieux ciblés. Il avait ainsi utilisé les ressources de l’organisation pour réaliser un projet coûteux, sans aucune valeur ajoutée et se retrouvait, de ce fait, dans l’impossibilité de soutenir les objectifs de son Entreprise, laquelle avait eu bien raison de le licencier…

N’oubliez pas que la transformation de votre organisation informatique en fournisseur de services à valeur ajoutée pour vos clients et un projet ou même un programme qui doit être justifié par un business case. Ce projet pourra être géré en utilisant une méthodologie de gestion de projet de type PRINCE2® par exemple. Gardez en mémoire que l’implémentation de processus et/ou de fonctions basés sur ITIL® nécessite une adaptation au contexte de votre Entreprise. Une simple copie des processus décrits dans le manuel sera sans aucun doute néfaste pour votre organisation. Cette adaptation pertinente à votre contexte n’est réalisable que grâce à l’implication forte de vos clients business dans le projet notamment grâce à l’organisation de groupes de travail, ce qui va nécessiter du temps, des ressources et un budget conséquent. C’est votre business case qui apportera les éléments de justification et de viabilité de ce projet. Le business case sera réactualisé tout au long du projet. Dès que le projet ne sera plus viable ni justifiable en termes de bénéfices attendus pour l’Entreprise, il faudra l’arrêter car il ne sert à rien de continuer à mobiliser des ressources et à dépenser des budgets qui n’ont plus d’utilité.

La gouvernance au coeur des projets

Qu’entend-on par « Gouvernance »?

gouvernance projetsLe terme gouvernance renvoie aux actions de gouverner, de donner la direction ou encore de contrôler.

Définir une gouvernance implique de décrire le mode de management et le cadre organisationnel à appliquer. L’objectif est d’identifier clairement les rôles et les responsabilités des acteurs de manière à assurer le bon déroulement, la continuité et la pérennité des activités.

Au niveau des projets lancés au sein de la structure, la gouvernance englobe principalement les sujets inhérents aux activités de pilotage des projets

Autrement dit, on cherche à résoudre à travers la notion de gouvernance l’éternelle problématique de la circulation efficace de l’information et de la prise de décisions au sein d’un projet. Une gouvernance efficace doit donc permettre à l’Organisation que seuls les projets viables et rentables sont réalisés, aux chefs de projet une remontée rapide des alertes et des besoins d’arbitrage et aux décideurs une prise de décision aisée sur la base d’informations claires, fiables, exhaustives et régulières.

La gouvernance doit également s’assurer que les risques inhérents aux projets sont sous contrôle, que la conformité réglementaire et légale est assurée pour les projets de l’entreprise et que la transparence requise est bien fournie à toutes les parties prenantes.

Pourquoi une gouvernance pour les projets?

La réalisation d’un projet implique la gestion de nombreux éléments :

  • les prises de décisions
  • le choix des partenaires et celui des stratégies à mettre en place
  • la mise en œuvre et la réalisation d’activités quotidiennes
  • la collecte de données
  • la création de contenu
  • la coordination des ressources humaines, les choix technologiques
  • l’achat de matériel et de logiciels
  • le financement
  • l’évaluation des résultats, etc.

La complexité et l’envergure de cette gestion peuvent parfois provoquer des conflits et être source de malentendus. Afin d’assurer une gestion harmonieuse, il est préférable de prévoir à l’avance des mécanismes de gouvernance qui orientent, guident et définissent la coordination du projet.

Comment implémenter une gouvernance efficace?

Une des premières questions à se poser consiste à savoir si le projet identifié contribue efficacement à la vision et à la mission de l’Organisation telle que définie par son conseil d’administration. Ensuite  il convient de définir comment on veut gouverner ce projet. Déterminer au plus tôt la gouvernance d’un projet est structurant pour son bon déroulement. Car, la réussite d’un projet ne se limite pas à la fourniture d’une solution répondant au besoin mais inclut également le respect du cadre initialement délimité en termes de délais, de coûts et de qualité ce qui nécessite un suivi sérieux et régulier.

La question qui se pose est la suivante : existe-il une approche standard ? Un modèle de gouvernance unique applicable dans tous les cas? La réponse est non. Etant donné que chaque projet est différent et correspond à un concept unique, le type de gouvernance ne peut être le même.

Le rôle des conducteurs de travaux et des chefs de projets est justement de trouver la solution sur-mesure. Par ailleurs, la gouvernance retenue pour le projet peut être amenée à évoluer. Elle doit être revisitée lorsque cela s’avère nécessaire. Définir une gouvernance s’inscrit donc dans un cycle d’amélioration continue.

Sept piliers pour la gouvernance des projets

1. Comment clarifier et communiquer les objectifs du projet?

Le cas d’affaire constitue la base de la définition des objectifs de tout projet. C’est sur la base de ce document essentiel que l’Organisation se basera pour déterminer si les projet correspond bien à la stratégie globale et contribuera de façon efficace et efficiente à satisfaire les besoins des parties prenantes. Le cas d’affaire restera, durant toute la durée du projet, jusqu’à sa clôture, le document de référence permettant d’évaluer si le projet reste viable et nécessaire et le cas échéant permettra à la Direction de l’Entreprise d’clôturer le projet de façon anticipée si celui-ci n’a plus rien à apporter à la stratégie globale.

2. Quelle méthodologie de gestion de projet utiliser?

Il est important, si aucune méthodologie de gestion de projet n’est retenue pour tous les projets d’Entreprise, d’en choisir une qui réponde aux besoins de l’Organisation. Les question auxquelles il convient de répondre sont les suivantes :

  • Quel est le niveau de familiarisation de l’équipe et particulièrement du chef de projet avec les méthodologies du marché?
  • Quelle est l’expérience du chef de projet en matière de gestion de projets?
  • Quel est le contexte de l’entreprise en terme de management (réactif vs proactif, aptitude à planifier, management par exception ou micro-management, aptitude à déléguer, etc.)?
  • Quelle est le contexte Business de l’Organisation (changements rapides et besoin de réactivité important ou changements plus planifiés dans le temps)?

Sur le marché, il existe deux grands référentiels de management de projets: PMP® et PRINCE2®. Sur ces deux méthodologies majeures, viennent se greffer des méthodes « Agiles » (PRINCE2® Agile, …).

3. Quelles structures de contrôle et de décision?

Le projet doit se doter d’instances de pilotage. Ces instances doivent en particulier servir pour arbitrer quand nécessaire, obtenir des ressources complémentaires etc…

Si les propositions de gouvernance peuvent venir du chef de projet, leur mise en place ne peut se faire sans le sponsor du projet, seul autorisé à inviter des dirigeants en comité de pilotage.

4. Quelles qualités attendre des membres de l’équipe?

Les qualités de savoir-être des membres de l’équipe sont très importantes pour la réussite d’un projet et notamment celles du chef de projet dont les aptitudes suivantes sont clés :

  • Sens de l’écoute
  • Habilité à la négociation et diplomatie
  • Gestion d’équipe
  • Autonomie et organisation
  • Résistance au stress
  • Disponibilité
  • Capacité à communiquer
  • Capacité à déléguer

5. Quel type de reporting mettre en place?

Le reporting doit permettre aux instances dirigeantes de l’organisation de comprendre le statut actuel du projet en quelques lignes.  S’il est trop long vous aurez du mal à cerner l’essentiel du contenu.

Ce dont vous avez besoin c’est celui que vous avez le temps de lire, celui qui prend 1h par semaine à votre chef de projet, celui de 10 slides en compil mensuelle et de 10 lignes sur un mail hebdomadaire.

6. Quels outils utiliser pour gérer les projets?

La gestion d’un projet nécessite au quotidien, pour le chef de projet, d’avoir à sa disposition l’ensemble des informations à jour sur l’avancement du projet pour pouvoir prendre les décisions qui s’imposent et, éventuellement, en cas d’anomalie importante, d’escalader une requête au Comité de Pilotage en charge de diriger le projet. Pour ce faire il convient de choisir les outils adaptés à la taille du projet et de s’assurer que l’ensemble des membres de l’équipe projet seront autonomes dans leur utilisation.

7. Quelles sont les compétences requises pour réaliser le projet?

Le choix du chef de projet, en particulier est un choix difficile et lourd car il sera presque impossible de le remplacer ensuite.

Les erreurs de choix sont en effet très lourdes pour les acteurs et le projet :

Le choix du chef de projet est essentiel car il compte dans tous les facteurs de succès des projets. Il va faire clarifier les objectifs, va obtenir le soutien des responsables, va organiser les ateliers utilisateurs, va définir les dates clés intermédiaires. Il doit par ailleurs disposer d’une expérience au sein de l’entreprise lui permettant d’anticiper toutes les problématiques de disponibilités des ressources internes ou des problématiques politiques internes, d’une expériences projets du même type avec des enjeux similaires d’un sponsor projet fort et concerné d’une légitimité lui permettant de faire entendre son avis notamment lors de la phase amont

Enfin, il doit maitriser les principes méthodologiques de gestion de projet, quitte à participer à une formation adaptée en amont du projet.

 

 

Catégories

Archives

Calendrier

juin 2018
L M M J V S D
« Avr    
 123
45678910
11121314151617
18192021222324
252627282930  
%d blogueurs aiment cette page :