Pourquoi avoir une démarche SAM (Software Asset Management) ?

, , ,

Qu’est-ce que la SAM (Software Asset Management) ?

Sam, Software Asset Management ou en français, Gestion des Actifs Logiciels est la démarche correspondant à gérer le cycle de vie des logiciels déployés sur l’ensemble du Système d’Information.

Depuis 2012 la Gestion des Actifs Logiciels est encadrée par la norme Iso 19770-1 définissant des niveaux de maturité et proposant des phases d’implémentation.

Pourquoi mettre en place une démarche SAM ?

– Parce que ne pas en avoir, expose l’entreprise ou la collectivité aux risques suivants :

o Risque financier : En cas de non-conformité constatée, l’entité devra acheter les licences pour son usage actuel voire son usage passé.

o Risque Juridique : Les articles L331-1 du code civil et l335-4 du code pénal fixent les pénalités encourues en cas de condamnation pouvant aller jusqu’à 300000€ d’amende et 3 ans d’emprisonnement.

o Risque d’image : Une entreprise condamnée pour une mauvaise utilisation des licences s’expose à ces deux risques en termes d’image :

 Mise en cause de son intégrité par ses clients.

 Mise en cause de son honnêteté par ses fournisseurs.

o Risque Technique

Trois risques techniques majeurs peuvent être identifiés :

 Cessation de fonctionnement d’un logiciel soumis à clé d’activation par période .

 Impossibilité d’avoir l’assistance technique de l’éditeur en cas de dysfonctionnement.

 Impossibilité de déployer des correctifs de sécurité face à une faille de sécurité découverte et publiée.

 SAM Software Asset Management

– Parce qu’avoir une vraie démarche SAM permet :

o De gagner du temps de disponibilité des équipes internes lors des audits des éditeurs ou de la BSA (Business Software Alliance).

o De démontrer aux éditeurs que les licences sont vraiment gérées et donc de réduire la fréquence des audits.

o De connaître parfaitement son parc logiciel et d’être :

 En position de force pour négocier avec les éditeurs ou les revendeurs lors des achats ou renouvellement de licences.

 Sûr de ne pas acheter des licences dont on n’a pas besoin lors de nouveaux  projets ou du renouvellement de son parc matériel (serveurs ou postes de travail).

 Sûr de ne pas détenir des licences non utilisées et donc payer pour rien.

o De ne pas s’exposer aux risques cités précédemment.

En conclusion :

– Mettre en place une démarche SAM fait économiser de l’argent à l’entreprise ou à la collectivité sur un des postes budgétaires très importants du système d’information (20 à 40% du budget total de l’IT).

– Ne pas mettre en place une démarche SAM coûte cher à  une entreprise et peut potentiellement lui coûter encore plus cher.

 

Patrick
Consultant Ankaa Engineering®
Spécialiste sénior de la gestion des actifs des système d’information.
Processus ITIL, accompagnement SAM, gestion des configurations et des changements, administration des incidents ou problèmes.

 

Sources :
– Guides des licences logicielles, Raphaël COCHE et Teddy MONIN, éditions ENI.
– ITIL V3, Guide to Software Asset Management
– Software Asset Management, CIGREF octobre 2012
– Norme Iso 19770-1 : http://www.boutique.afnor.org/norme/nf-iso-cei-19770-1/technologies-de-l-information-gestion-des-actifs-logiciels-partie-1-procedes-et-evaluation-progressive-de-la-conformite/article/806119/fa169141
– Business Software Alliance: http://www.bsa.org/?sc_lang=fr-FR
/par

Lean Office pour gagner en efficacité

,

La DSI d’un Grand Groupe industriel devait se réapproprier ses objectifs, renouveler ses compétences, revaloriser son image, récupérer une crédibilité et la confiance des métiers (les Clients internes et Fournisseurs externes).
Dans le cadre de cette démarche, je suis intervenue auprès de son équipe pour définir et mettre place une méthodologie en pilotage de projet et conduite du changement, puis en fournir les outils métiers.

Il s’agissait d’outiller les Chefs de projets de façon professionnelle (« best practice ») et complète.

J’ai mené une première phase d’observation de l’équipe de Chefs de projets, de ses modes de fonctionnement, de sa charge de travail, des périmètres de ses projets, du type de sujets traités par ses projets.

Ensuite, je me suis attachée à collecter et étudier l’éventuel existant, au vu de quelques échos reçus par certains Chefs de projets.
En effet, un grand Cabinet de la place avait fourni une base de 130 documents ; documents et guide diffusés en masse sur l’intranet de l’entreprise.
Ce référentiel non personnalisé, pensé sur une base « standard », sans accompagnement, n’a donc pas obtenu d’adhésion.
Contenant et contenu donnaient lieu à une certaine répulsion des équipes dans leur exploitation opérationnelle.

un régime administratif du framework méthodologique serait judicieux

Framework méthodologique

 

En troisième lieu, je me suis appuyée sur mes propres livrables, éprouvés par les pilotages de projets antérieurs. Cela représente une approche de type knowledge management.

Après une analyse réalisée sur ces trois phases, j’ai fait le choix de sélectionner certains de mes livrables en propre, car ils trouvaient leur place ainsi. Puis, j’ai amélioré d’autres documents de mon référentiel ou ceux issus de la livraison initiale du Cabinet.
L’ensemble fut adapté aux observations et attentes notées en première étape, puis mis à disposition accompagné d’un bref guide d’utilisation (1 slide). Les modèles de livrables ont été marqués de signalétiques ludiques, pour permettre une appropriation rapide et simple.

Le bénéfice tiré… les métiers ont pu exprimer leur besoin en systèmes d’informations corporate ou dédiés métier, d’une façon assez professionnelle pour permettre à la DSI de traiter correctement les demandes des Clients internes.
Les Chefs de projets ont rapidement pris possession des modèles pour les exploiter.

Lean Office et rendu assez pragmatique, qui a réduit le référentiel projet de 130 à 30 modèles de livrables.

L’optimisation de la démarche est apparue sous la forme de :

  • une préconisation d’axes d’améliorations, transmis à la DSI centrale sur les documents qu’elle détenait en termes de pilotage d’un projet et d’une conduite du changement.
  • un coaching des Chefs de projets, au comportement à adopter en cas de difficultés et dérives. Cette sensibilisation a fait l’objet d’un support sous la formalisation d’un guide, reprenant une approche Lean Office adaptée, et une liste de livrables structurée selon les étapes et phases d’un projet, suivie d’un Glossaire des signalétiques utilisées.

A retenir…

Dans le monde technique des « système d’information », il est recommandé de respecter les « standards » pour des raisons principalement de coûts et de maintenabilité.
Lorsqu’on aborde les processus et les modes de fonctionnement, il est nécessaire de répondre de façon personnalisée et pragmatique avec une touche de créativité.
Ainsi,

  • l’adhésion est plus facilement obtenue ;
  • il est plus aisé d’emmener tout le monde vers l’objectif ;
  • les gains sont réels ;
  • l’existant est optimisé.

Pour ce faire, le diagnostic « terrain » (en rappel au « Gemba » – méthode TPS) et préalable couvre une étape importante.

Copier-coller l’intégralité d’un framework méthodologique n’est pas gage d’efficacité.
Ecoute, adaptation et personnalisation : les composants d’une mission de conseil réussie…

 

Sandrine
Consultante Ankaa Engineering®
Professionnelle de 20 ans en Management de la fonction Achat et en Conseil organisationnel et de transformation, Sandrine a travaillé au sein d’environnements multiculturels, aux côtés d’équipes pluridisciplinaires.
Elle a exercé aussi bien auprès de grands Groupes que de PME-PMI, lui permettant ainsi d’approcher des problématiques différentes, des modes de fonctionnement hétérogènes, des circuits de décisions variés, des priorités et enjeux originaux.
Le parcours à dominante industrielle de Sandrine, lui a donné la possibilité de développer certaines compétences dont quelques-unes la distinguent ; telles qu’une double compétence métier, une bonne capacité d’adaptation, un fort sens du résultat et du service, une grande pratique de méthodes et outils métiers.
Ses domaines de prédilection :

  • Strategies achats – Optimisation de processus – Organisation – Methode
  • Sourcing, negociation, contractualisation
  • Pilotage de projets et changements – Evaluation sous KPI
  • Perimetres internationaux, Gestion simultanee, Management transverse
/par

Projets en retard = mauvaises évaluations de charge ?

, ,

Et si les mauvaises évaluations de charge n’étaient pas la seule cause des projets en retard ???

Pour qui veut apprendre comment évaluer des charges d’un projet, les supports ne manquent pas : Méthodes des points de fonctions, COCOMO, RAD, DELPHI, STIMA, ARAMIS, ESI, PRT, etc…

On se retrouve dans certains cas rapidement confronté à des méthodes conçues par des mathématiciens en mal de reconnaissance…LOL

Il existe bien sûr des quotas moyens qui ressortent à l’usage, et  pour certains référentiels, la répartition des charges entre les étapes d’un projet se présente selon :

Etude de faisabilité : 15%
Etude détaillée : 25%
Conception : 45%
Mise en production : 15%

Ces rapports peuvent varier selon les projets bien sûr.
Certains projets seront plus consommateurs de temps d’étude et moins en réalisation par exemple.
La matrice n’est donc pas aussi simple.

Charge, durée, délai ?

La notion de charge est la quantité de travail à produire et elle se traduit en nombre de jours/homme dans le contexte de projet d’ingénierie.
Le nombre de ressources affectées à produire le travail attendu influera (ou pas) sur le temps de réalisation et fournira la notion de durée.
Quant au délai, il correspond lui à la date de fin de réalisation (ou de livraison) et est directement dépendant des disponibilités des ressources pour accomplir le travail attendu.

75% des projets dépassent le délai de 30%.

Et très souvent, trop souvent, la cause annoncée de ce retard est une mauvaise estimation des charges.

Après 28 années de recul en gestion de projet de tout type et toute taille, le constat que j’ai opéré est que les projets en retard le sont bien souvent pour une autre raison qu’une mauvaise évaluation de charge.

En effet, un temps certain est passé sur l’évaluation des charges par les équipes, les chefs de projet, la maîtrise d’ouvrage.
Les charges sont même très souvent à l’origine de négociations et de discussions.
Bref les charges retiennent toute l’attention qu’elles méritent.

Mais quid de la capacité des ressources ???

Là, je ne sais pas pourquoi, même dans les projets avec des équipes non dédiées, le raccourci d’une affectation de ressources à temps plein est très très très souvent pris.
Or dans la vraie vie, les membres d’une équipe sont très rarement mobilisés 100% de leur temps sur le projet.
Plein de tâches parasites viennent grignoter leur capacité d’affectation (autres projets, autres projets en retard, maintenance, support, études, vacances, etc).
Leur capacité d’affectation est inférieure à du temps plein, voir largement inférieure.

Petit rappel de calcul simple :
1 jour de charge attribué à une ressource affectée à 100% de son temps demandera 1 jour de durée pour être réalisé.
1 jour de charge attribué à une ressource affectée à 50% demandera 2 jours de durée
1 jour de charge attribué à une ressource affectée à 25% demandera… 4 jours de durée

L’impact de la disponibilité des ressources n’est pas neutre puisque les coefficients sont significatifs.
Un projet réalisé avec des ressources d’une disponibilité réelle de 25% mettra 4 fois de temps à être réalisé que ce qui a été imaginé sur la base d’une affectation temps plein !

Alors une charge de travail parfaitement estimée à l’aide de toute les méthodes scientifiques du monde ne garantira pas la maîtrise du délai (et donc des coûts associés) si l’on ne met pas en face des capacités très clairement évaluées elles aussi.

C’est juste une histoire de contenant et de contenu.

Le problème est :
– qu’avec l’arrivée de l’informatique, les panneaux muraux et les fiches cartonnées des chefs d’équipe d’antan ont disparus.
– que les PMO (bureaux de planification des travaux) sont plutôt rarissimes dans les organisations.
– que compte tenu des deux points précédents, personne ne sait plus qui fait quoi quand et que de fait la surcharge règne (le règne des surbookés ?).

La solution :
– évaluer au cas par cas des projets les capacités des équipes/ressources impactées pour mesurer le coefficient de disponibilité et identifier de manière réaliste les délais jouables.
– réinstaurer les fonctions de PMO au sein des équipes.
– responsabiliser les équipes sur leur propre gestion de disponibilité et donc les autoriser à négocier/refuser des missions et travaux lorsque ceux-ci sont en conflit avec leur capacité…Oups !

Oups ! car dans ce cas, on met les pieds dans le plat d’un changement culturel d’entreprise ou le système hiérarchique historique risque d’être bousculé avec tous les problèmes d’ego que cela peut induire pour l’équipe d’encadrement de l’organisation .

Management transverse…A grands maux, grands remèdes ?

/par

10 rappels pour une conduite de changement efficace

, ,

Petit mémento pour chef de projet stressé ou 10 rappels pour une conduite de changement efficace.

Clarification et partage d’objectif

Une règle d’or à appliquer, y compris si l’on a défini de travailler avec agilité, est la clarification et le partage de l’objectif.
Pour que tous les acteurs du projet rament dans le même sens en direction du coeur de la cible définie, il est impératif d’avoir identifié le résultat recherché et de l’avoir présenté et partagé au sein de l’équipe projet.
Tout changement de cap devra déclencher une nouvelle coordination des acteurs sur la cible, le processus et le délai.

Identifier la roadmap

Il est impératif que le processus choisi pour aller du point A au point B soit clairement choisi et officialisé auprès des acteurs.
La roadmap du projet a posé les règles de pré-requis entre les tâches et a donc positionné dans l’espace temps des enchaînements de travaux.
Tout ne se fait pas en même temps, les réalisations nécessitent le respect d’une « recette de cuisine » où chaque action a sa justification pour la suite des opérations.

Acteurs directs et indirects

Qui fait quoi quand.
Pour chaque travail à réaliser il est nécessaire d’identifier quelle personne ou équipe dispose de la meilleure compétence pour garantir une réalisation conforme aux exigences de qualité, de maîtrise des délais et de coûts.
Cet inventaire permettra de définir la cartographie des acteurs directs du projet.
En management de projets transverses, l’affectation des acteurs directs amène à des négociations de disponibilité de ressources puisque ces dernières ne sont pas dédiées au projet.
Au delà des acteurs directs, chaque entité concernée ou impactée doit être identifiée (clients externes, autres services, etc).
Le plan de communication sera défini selon la cartographie obtenue des acteurs.
Pour mener cette réflexion de qui fait quoi, une matrice de RACI peut être utilisée.

Impliquer la maîtrise d’ouvrage dans le projet

Le donneur d’ordre (MOA) doit être impliqué à plusieurs niveaux dans la réalisation.
– En amont, dès la clarification d’objectif à atteindre, car la MOA est la seule à pouvoir définir et choisir le cœur de cible (fonctionnalités, design, etc).
– Pendant, afin de participer aux COPIL pour suivre l’avancement et valider des changements de roadmap.
– Pendant encore en déléguant les capacités d’acteurs directs sur les phases de tests, de formation, de recette, …
– En aval, pour ajuster et optimiser les processus métiers au changement

La MOA est bien souvent le sponsor financier du projet et doit être décideur dans les options fonctionnelles, techniques ou de gestion des risques.
Chaque investissement, chaque affectation de ressource, qu’elles soient externes ou internes augmente le coût d’acquisition et dégrade le ROI du projet.

Mettre en place les comités, le reporting et communiquer

Choisir et officialiser les membres du comité de pilotage (COPIL), définir la fréquence de réunion de cette instance de décision auprès de laquelle sera présenté de manière synthétique .
Clarifier auprès des membres la possibilité d’ajout de réunions extraordinaires et spontanées en cas de situation de crise.
Définir la fréquence et le contenu du reporting pour que les informations de la réalisation effective sur le « terrain » viennent se confronter à celles du prévisionnel.
Organiser la fréquence et les modalités des réunions de suivi de projet (COPROJ).
Mails, téléphone, conf-call skype ou Google Hangout mais aussi et surtout réunion en face à face pour évaluer à se juste mesure « la communication non verbale » des acteurs.

Communiquer, coordonner, synchroniser

Informer, communiquer doit être le travail essentiel du chef de projet.
Les acteurs directs doivent eux se concentrer sur la qualité des travaux à mener dans le respect des délais et du budget.
La coordination est l’affaire du chef de projet qui doit animer les COPROJ, assurer la synchronisation des acteurs entre eux, reporter au COPIL et communiquer vers les acteurs indirects selon le plan de communication identifié.

Adaptations, agilité et versioning

Un projet se doit d’être agile et ce pour deux raisons.
1- Le projet dans sa vraie vie ne se déroulera jamais comme prévu.
Les capacités de réadaptation sont donc essentielles pour ajuster l’organisation aux aléas rencontrés.
2- La MOA explicitera bien entendu en cours de projet des besoins impératifs, essentiels, importants, critiques, … d’ajouts non prévus.
L’art de gérer ce type de situation se résume à faire définir la version de rattachement des « add-on » demandés (version en cours ou report au sein de la version suivante).
Ne pas oublier que chaque travail supplémentaire ajouté au périmètre initial du projet a une influence sur la date de fin et le budget.
Accepter des « add-on » au sein de la version en cours sans réviser le périmètre initial du projet augmente le risque de ne pas respecter les engagements de qualité, maîtrise du budget et de respect du délai.

Communication positive

Penser à communiquer sur l’avancement du projet au sein de l’équipe.
Chaque acteur direct a bien souvent « la tête dans le guidon » et ne voit et ne vit QUE les problèmes du projet.
Insuffler une énergie positive en officialisant des passages de jalons importants comme des fin de phase ou d’étape permet à tous de prendre conscience que le projet avance malgré tout.

Accompagner au changement

La livraison d’une solution au client devra être accompagnée d’un plan d’accompagnement au changement.
Simple « flyer » ou dispositif pédagogique complexe et lourd, l’accompagnement au changement n’est pas une option dans un projet.
La réussite d’un projet ne s’appuie pas uniquement sur la maîtrise des processus de conception mais aussi et surtout sur la capacité d’adaptation et d’adhésion des clients par rapport au produit.

Clôturer le projet

Comment gérer efficacement le versioning des évolutions sans effectuer une clôture de projet ?
Cette étape d’évaluation et de mesure des écarts entre le prévu et le réalisé est trop souvent oubliée.
De fait, la version 1.0 du projet perdure dans le temps et le sentiment d’échec lamine peu à peu les équipes.
Tous les acteurs directs ont le sentiment que les clients n’ont pas été satisfaits puisque des demandes de nouvelles évolutions sont incessantes.
Se rappeler alors ce qui composait le périmètre initial de la version 1.0 en terme fonctionnel est primordial car cela va permettre de vérifier si ces besoins ont bien été couverts.
Que les clients demandent de nouvelles adaptations et fonctionnalités est plutôt un signe positif.
Cela sous-entend qu’ils ont assimilé et digéré le fonctionnement de la version 1.0 et en demandent plus.

Fil rouge

Ces 10 points ne sont pas exhaustifs bien sûr.
Ils ne sont que des jalons importants dans la mise en oeuvre d’une conduite du changement.
Mais paradoxalement, tout ou partie de ces éléments sont souvent oubliés par les directions de projet.
Alors, un petit rappel du fil rouge de temps à autre ne fait pas de mal…

 

 

 

/par

Agile manifesto, Boehm, EVO, Deming : l’œuf ou la poule ?

, ,

Agile manifesto, Boehm, EVO, Deming

Ils ont en commun de s’appuyer sur des concepts de gestion de projet itératif, incrémental et adaptative.
Mais quid de l’oeuf ou la poule ?

Apparu en 2001, Agile manifesto a démocratisé la terminologie « Agile » en regroupant au sein d’un même référentiel diverses méthodes itératives de développement de produit.
Historiquement les méthodes RAD, DSDM, XP Extreme programming et Scrum sont les principales représentation de ces méthode et poussent des principes de planification pilotée par les résultats des tests utilisateurs ou l’auto-organisation des équipes et l’apprentissage de groupe.

Avant cela ?

Barry Boehm en 1986 a formalisé une approche itérative des tâches selon un processus en spirale.

Agile manifesto, Boehm, EVO, Deming : La spirale de Boehm

4 étapes dans l’approche itératives

1. Définition de l’objectif à atteindre
2. Évaluation des risques
3. Conception et tests
4. Mesure des écarts entre le livrable et l’objectif

Retour à 1. pour l’objectif suivant…

Avant cela ?

En 1976, Evo (Evolutionary Project Management), aborde la mise en place d’un processus organisationnel dynamique pour permettre la prise en compte des changements et nouvelles idées aussi souvent qu’on le souhaite au sein d’un projet.
Cette approche étant stimulée pour générer le maximum de valeur ajoutée auprès des acteurs.

Avant cela ?

Le statisticien William Edwards Deming  à popularisé dans les années 1950 un outil développé par Walter A. Shewhart.

La symbolique est une roue qui tourne selon un cycle PDCA (Plan-Do-Check-Act).

Roue de Deming

 

 

 

Cet outil d’amélioration continue a été intégré au sein de la méthode de gestion de la Qualité Kaisen.

On est la aussi dans une logique d’itération.

Avant cela ?

Rien de clairement identifié…

Donc

Agile manifesto, Boehm, EVO, Deming, même principes fondamentaux…

Au final, Deming n’a-t-il pas initié un mouvement sans cesse renouvelé et amélioré ?
Et la roue n’a pas finie de tourner…

/par

Développer ses compétences en gestion de projet

,

La gestion de projet n’est pas innée, elle s’apprend.

Quel que soit notre métier et statut au sein de l’entreprise, nous faisons tous de la gestion de projet au quotidien, parfois sans le savoir.
Certes, face à des retours d’expérience terrain parfois difficiles où simplement parce que la fiche de poste stipule ce savoir-faire, certains bénéficierons de formations dédiées sur cette compétence.

Mais dans tous les cas, il reste des fondamentaux à ne pas oublier :

– L’élément le plus important dans le projet est… le client, le donneur d’ordre, le maître d’ouvrage.
C’est LA personne à satisfaire alors même qu’il ne sait pas toujours ce qu’il veut.

– Tentez autant que faire se peut de clarifier l’objectif avant le lancement du projet.
Plus la cible est visible, plus il sera facile d’atteindre le cœur.
Le recours à de l’agilité dans projets ne doit pas faire oublier l’objectif final recherché.
L’agilité doit prendre sa place dans l’organisation des travaux de conception et non dans la définition d’objectif.

– Aider le client à clarifier son besoin en échangeant avec lui grâce à un vocabulaire simple et compréhensif.
L’usage d’un vocabulaire élaboré, spécifique ou trop technique ne fournit pas de garantie à votre client que vous que vous compreniez vous même vos propos…La culture, c’est comme la confiture…

– Soyez persuasif car le client n’a pas toujours raison.
Les choix doivent être portés par le ROI et les résultats attendus.
Vouloir en faire trop nuit à l’objectif principal.
L’important dans le projet est l’atteinte de l’objectif et non la complexité de ce dernier.
Le mieux est parfois l’ennemi du bien…

– Modélisez l’enchaînement des travaux pour partager le « fil rouge » avec l’équipe.
Par quoi on commence, par quoi on finit, et comment on s’organise entre les deux.
Élaborez un modèle de plan projet détaillé pour anticiper les problématiques organisationnelles des travaux à mener et assurer une gestion de risque cohérente.
– Estimez les charges des travaux mais pensez surtout à évaluez les capacités réelles des ressources sur le projet.
Diffusez l’organisation du « qui fait quoi quand », les ressources s’auto-organisent rarement correctement…

Définissez une date de livraison cohérente au regard des capacités réelles des ressources.
Un projet débuté en retard restera en retard (rappel : l’étude fait partie intégrante d’un projet…).
Et lui positionner une date de livraison utopiste ne réglera pas le problème initial.

Impliquez le client dans l’atteinte de l’objectif.
Le client est un acteur important et il mérite d’être impliqué dans l’organisation des travaux et l’atteinte de l’objectif.
Il est incontournable en phase de tests, de recette.
L’impliquer lui rappelle combien il est parfois difficile de faire plusieurs choses en même temps (notamment pour les hommes! LOL).

Ne négligez pas l’accompagnement au changement, élément fondamental de la gestion de risque.
50% de réussite dans les projets sont liés à l’organisation de la réalisation du produit.
50% sont dépendants de l’accueil du produit par le consommateur.
Communication, formation ne sont pas des tâches optionnelles et doivent avoir leur place au même titre que celles de l’ingénierie de conception au sein du projet.

– Mettez en place une organisation de reporting efficace.
Sans reporting un projet va dans le mur.
Plutôt qu’imaginer le reporting sous forme de compte rendus circonstancier, focalisez vous sur la donnée fondamentale qui est « le reste à faire ».
C’est la seule donnée sur laquelle peut être appliqué de l’influence et des modifications pour corriger les écarts constatés.
Le passé est le passé. On ne peut (malheureusement) pas revenir en arrière.

Mais l’élément fondamental de la gestion de projet reste la capacité de réadaptation de l’organisation « au fil de l’eau ».
Car aucun projet ne se déroule tel qu’il a été prévu et organisé.
D’ailleurs, la roue de Deming expliquait le processus bien avant que les méthodes agiles apparaissent.
Pour pouvoir réadapter un processus pour maintenir l’atteinte de l’objectif initial sans dégradation des ambitions et contraintes, il faut disposer de capacité de pouvoir le faire.
Un plan projet initial trop « optimisé » ne fournira pas de solutions, et selon la loi de Brook, la solution n’est pas d’ajouter des ressources…
La solution passe par la présence de « jokers » dans le plan projet qui sont les garants de l’atteinte qualitative du produit, la maîtrise budgétaire projet et le délai de livraison.

La vrai valeur du chef de projet se mesure à sa capacité de gestion de crise.
Élaborer un « joli » prévisionnel s’apparente à définir les plans de la construction.
On est dans le domaine du conceptuel et cela reste « sur le papier ».
Et pas toujours facile pour autant…
Mais faire en sorte que la construction ressemble aux plans…c’est le vrai défi du chef de projet !

/par

Site de travail collaboratif mis à disposition gratuitement par Ankaa Engineering

,

Comment favoriser la communication et le partage entre les membres d’une équipe projet notamment lorsque celle-ci est en partie interne, en partie externe ?

Ankaa Engineering® a résolu cette problématique de partage et de synchronisation d’équipe en mettant gracieusement à disposition de ses clients un environnement de site de travail collaboratif.

Chaque projet dispose ainsi d’un environnement dédié au sein duquel chaque contributeur au projet qu’il soit interne ou externe peut collaborer et partager ses informations avec le reste du monde (le monde du projet intra-muros bien sûr !).

Sites Projet Ankaa Engineering

L’espace de publication de document donne lieu à une traçabilité du versioning.

Spécifications fonctionnelles, techniques, procédures, documentation utilisateur et fiches de tests et de recette peuvent ainsi être stockées, partagées.
La gestion de version permet à l’espace de devenir le référentiel des documents du projet.

L’espace de discussion permet de statuer sur les cas et situations ou le traitement de cas.
Les équipes peuvent aborder des points d’analyse, des choix d’architecture mineurs, des points de validation ou de contrôles.
Cet espace ne remplace pas les réunions projet, les entretiens téléphoniques, les mails.
Il permet de partager les informations, les décisions mineures, les choix opérationnels.

Une todo-list permet d’affecter des travaux ou vérifier que certains jalons sont respectés.
Cette liste permet au chef de projet de mémoriser des actions stratégiques, de matérialiser un PAQ en affectant des travaux ponctuels à une ou plusieurs ressources.

Bien entendu, l’accès aux données est géré par profils.
Les documents publiés sont en fin de projet extraits et restitués au client.

Cet environnement ne se substitue pas aux réunions d’équipe, ne remplace pas les mails, le chat ou les appels téléphoniques.

Il se limite à être le référentiel des documents du projet, autorise l’interactivité entre les participants, le support « pense-bête ».

Mais très souvent, le site de travail collaboratif Ankaa Engineering® est adopté et devient rapidement indispensable pour les équipes réparties (interne – externe) ou en mobilité.

/par

L’amélioration continue : Kaizen

, ,

Kaizen, terme japonais qui veut dire « bon changement » ou « amélioration continue ».
A partir de l’analyse des incidents et erreurs constatés, le principe du Kaizen est la recherche de solutions légères, simples à mettre en oeuvre et peu onéreuses.
C’est une méthode d’amélioration Qualité impliquant l’ensemble des acteurs d’un processus dans la recherche d’optimisation des ressources utilisées et disponibles.

Kaizen

La mise en oeuvre du Kaizen consiste à créer des groupes de travail (de progrès) et de les animer dans une démarche d’amélioration continue en se focalisant sur l’optimisation des moyens en place et disponibles avant d’envisager le recours à des acquisitions complémentaires de moyens.
Nous sommes dans un modèle de management participatif ou les acteurs opérationnels sont à l’initiative de recherche d’optimisation de leurs processus de travail et de leur activité.
Préalablement à la mise en oeuvre de la démarche Kaizen, les animateurs des séances de travail devront peut être acquérir les techniques de conduite et d’animation de réunion.

Chaque groupe de travail aura recours à des outils et méthodes d’analyse et de recherche de solutions comme la roue de Deming ou PDCA, méthode des 5S, QQOQCCP, Poka-Yoke, Ishikawa, SMED, etc.

Kaisen est une démarche d’amélioration de la Qualité et peut s’intégrer à une initiative de Lean Management.

Les résultats d’une démarche Kaizen sont la suppression des actions sans valeur ajoutée, l’optimisation des espaces de travail, la simplification des procédures, la réduction des durées des processus, la réduction du taux de rebuts et/ou d’anomalies, l’amélioration de la qualité d’un produit fini mais aussi l’augmentation de la sécurité et l’accroissement de la motivation des acteurs par une meilleure implication dans leurs conditions de travail.

Ce type de démarche impacte les services Qualité et Méthodes qui doivent alors compter de nombreux nouveaux contributeurs.
Pour être pleinement opérationnelle cette organisation devra, bien entendu, être soutenue par la direction générale.

/par

Roue de Deming PDCA et méthode agile

, ,

Réfléchir avant de faire, faire et corriger les écarts en réfléchissant à comment les mettre en application avant de les mettre en oeuvre, étudier les nouveaux écarts constatés et mettre en application les correctifs non sans avoir analysé avant la meilleure manière de les implémenter, etc…

William Edwards Deming,  professeur et consultant américain en amélioration des processus a formalisé cette routine sous la forme de la « roue de Deming » qui représente un cycle de 4 phases répétitives qui ont pour objectif l’amélioration qualité du produit fini.

Roue de Deming PDCA

  • Plan

    Planifier et préparer ce que l’on doit réaliser. Clarifier l’objectif, ordonnancer les tâches, planifier.

  • Do

    Exécuter les travaux prévus.

  • Check

    Contrôler et vérifier les résultats. Evaluer et comparer avec le prévisionnel.

  • Act

    Corriger, agir, réagir et réajuster les processus si nécessaire.

On entre alors dans un cycle répétitif d’amélioration permanente d’un produit ou d’un service.

Dans une logique d’évolution permanente, une cale symbolise la capacité à gérer les non-régressions.

Cette démarche d’ajuster et d’améliorer en avançant ressemble beaucoup à la logique des méthodes agiles.

Méthodes agiles

Les méthodes agiles s’appliquent au développement applicatif et reposent sur un principe de cycle de développement itératif, incrémental, adaptatif.

Parmi les plus répandues, nous trouvons les méthodes EVO, RAD, DSDM, ASD, FDD, Kanban, Scrum et XP Extremeprogramming.

Toutes s’appuient sur une approche d’amélioration continue :

– Affinage itératif du besoin en cours de réalisation :

– Fonctionnel, selon les résultats de la validation permanente des utilisateurs (RAD, XP)

– Technique, par révision du code (refactoring)

– Découpage incrémental du projet en fonctionnalités de quelques jours
– Techniques de contrôle du livrable dans un périmètre variable et adaptatif.

– Implication du client qui permet d’adapter et modifier « au fil de l’eau » le détail des fonctionnalités attendues.

méthode-agile

Les méthodes agiles se rapprochent de la logique de la roue de Deming dans la mesure ou les deux principes s’appuient sur une analyse empirique basée sur l’expérience terrain.

Concevoir avec pragmatisme et clarifier le besoin fonctionnel en avançant contribue à se concentrer sur l’utile et l’important au final.

Ce type d’approche contribue à une meilleure génération de valeur pour le compte de l’entreprise puisque les choix opérés portent sur des unités fonctionnelles plus petites, facilement compréhensibles et dont la valeur ajoutée est mieux ressentie et plus facilement évaluable.

/par

Comment réguler sa fonction « chef de projet » au quotidien

,

Dans les organisations de taille intermédiaire, nous constatons très souvent que le titre de chef de projet s’apparente plus à un titre honorifique qu’une responsabilité véritable affublée de moyens pour l’assumer.

Dans ces structures, qui plus est, le chef de projet se voit affecté au pilotage et suivi de multiples projets parallélisés.
Il doit en outre et en complément assurer sa fonction initiale, ou alterner entre rôle de chef de projet et celui de ressource.

Dans ce type de scénario, l’une des principales difficultés pour l’individu est d’équilibrer sa charge de travail entre ses multiples casquettes.
La question récurrente est : « Quel temps dois-je passer au suivi de mes projets ? »

Selon différents abaques méthodologiques, on peut considérer que le temps que le chef de projet doit affecter correspond entre 10 et 20% du nombre de jours total du projet. Bien entendu, cette charge n’est pas constante entre les projets, ni selon les phases du projet.

Le curseur du pilotage par le chef de projet sera le plus souvent ajusté selon le niveau de risque encouru.

Graphes affichés sur l'écran du chef de projet

Un projet novateur demandera probablement plus d’engagement de la part du chef de projet qu’une évolution fonctionnelle d’un système existant.

De même, au sein d’un projet, la présence du chef de projet sera variable selon la criticité des phases ou de l’impact des incidents rencontrés.

Mais comment savoir si le dosage « chef de projet » est le bon ?

Un indicateur très simple permet de déterminer si le temps consacré est le bon.

Si, à la question posée par la MOA « Comment se passe le projet ? », le chef de projet ne peut répondre que d’une formule laconique du type « Globalement ca se passe pas mal ! », le temps alloué à la fonction chef de projet est largement insuffisant.

Un chef de projet qui suit ses affaires correctement formulera une réponse claire et quantifiée du type « On est en retard de 10 jours sur l’objectif du à des problèmes rencontrés sur l’intégration de la fonction  de sécurité ».

En résumé, tant que le chef de projet n’a pas une vision claire et précise de la situation du projet, il doit se mettre à la tâche.

/par