Tag Archives: planning

Saviez-vous que 3 des termes de PRINCE2 sont agiles ?

23 Août

En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet.

http://www.alctraining.com.au/4-prince2-terms-you-may-not-know-are-agile/ par ALC Group

Dans le monde de l’informatique, beaucoup de praticiens agiles croient que PRINCE2 n’est pas assez flexible pour les demandes business contemporaines. Cependant, pour ceux qui ont passé la formation PRINCE2, la plupart seront conscients que ceci est faux.

3 termes Agile Prince2En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet. Pour renforcer cette remarque, voici trois termes qui sont plus agiles que beaucoup ne le pensent.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Premier terme Agile – Initiation

A few videos to get started on Agile, Scrum and Kanban

A few videos to get started on Agile, Scrum and Kanban

Quand des projets PRINCE2 sont implémentés, ils comptent sur le cas d’affaires pour garantir qu’ils sont justifiables. Il y a aussi les plans qui décrivent ce qui arrivera, les contraintes budgétaires et les stratégies de livraison. Tous ces éléments sont identifiés et décidés pendant l’étape d’initiation.

Le cas d’affaires est l’espace parfait pour articuler une perspective agile et structurer les besoins de projets et planifiant d’incorporer en mode Agile des jeux de fonctionnalités et sorties de produit. Prenez par exemple le management du projet et de l’approche de livraison, les chefs de projet PRINCE2 peuvent tout à fait utiliser des approches agiles comme Scrum et Kanban.

De plus, les plans pourraient aussi être en « time boxing » plutôt que cascade, tandis que le financement pourrait être basé sur les releases plutôt que les étapes techniques traditionnelles liées à l’effort de livraison.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Mindview est Partenaire de DantotsuPM

Mindview est Partenaire de DantotsuPM

En implémentant ces approches dans l’étape d’initiation, le projet peut se concentrer sur la livraison de valeur, diminuant les délais de time-to-market et permettant aux utilisateurs finaux d’utiliser des composants de valeur dès que possible.

Second terme Agile – Work package (Lot de travail)

Une des idées fondamentales des approches Agiles est l’auto-organisation des équipes. Pour que ceci devienne une réalité, les équipes doivent être conscientes de leurs responsabilités et organisées selon des  frontières comprises et communicables.

Le lot de travail PRINCE2 n’écarte pas ces principes de base Agile et peut faciliter cette forme d’organisation. Par exemple, les lots de travail peuvent permettre aux praticiens agiles de communiquer aux parties prenantes leurs rôles, responsabilités et autorité. Ceci permettra aux équipes d’être certaines de ce qu’elles doivent faire pour construire et livrer des produits de valeur.

Troisième terme Agile – Tolérance

prioriser2Avec PRINCE2, le contrôle de la tolérance est sous la responsabilité du chef de projet. La tolérance se réfère à n’importe quelle variation des estimations acceptées lors du cas d’affaires par rapport aux délais, coûts, risques, bénéfices et contenu (périmètre). Si ces tolérances semblent en passe d’être excédées, il est de la responsabilité du chef de projet de remonter ceci au Conseil de Projet pour maintenir un contrôle formel des changements et obtenir une rapide prise de décision.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Les méthodologies agiles ont les mêmes approches, bien que sous l’apparence de mécanismes de priorisation. Par exemple, beaucoup de praticiens utiliseront MoSCoW pour ajuster le contenu de leur projet et rester les délais et budget alloués.

Produit Viable Minimum (MVP)

Produit Viable Minimum (MVP)

La qualité suit une approche similaire. Prenez par exemple la fabrication d’une voiture. Une approche Agile se concentrerait sur le produit viable minimal – le moteur, le châssis et d’autres fonctions centrales, tandis que les fonctionnalités comme le système de climatisation et le toit ouvrant seront inclus seulement si le temps et les coûts le permettent. PRINCE2 peut faire de même. Il a déterminé les tâches requises et le budget alloué qui est accompagné du contenu. Ceci permet aux projets d’être changés en temps réel pour répondre à des éventualités du marché ou dans le périmètre du projet.

Pour beaucoup, PRINCE2 est toujours l’une des plus, sinon la plus, importante des méthodologies de management de projet disponibles.

Assister à un cours de formation PRINCE2 est une excellente façon de comprendre l’agilité inhérente à cette méthode. C’est aussi une bonne façon d’étendre vos perspectives de travail et d’améliorer votre capacité à livrer des projets rentables dans les temps, avec un focus client et des standards élevés.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

une mauvaise migration de système ressemble à une passe ratée dans la surface de réparation !

18 Août

Le système est-il prêt ?

Article original en Anglais « Planning System Cutovers » par Dave Nielsen

Office Workers Clapping at Office PartyL’équipe a bossé dur et construit un système qui satisfait à toutes les exigences business. Elle l’a testé et a vérifié qu’il répond à tout le jeu de normes de qualité applicables et les membres de l’équipe l’ont livré dans les temps. Maintenant vous pouvez vous asseoir et vous féliciter de l’excellent travail que vous avez fait en manageant ce projet.

Eh bien, pas tout à fait … …votre travail n’est pas terminé tant que le nouveau système n’est pas en production et la responsabilité du support transférée aux opérations. Pour y parvenir, vous devez planifier la migration parfaite.

Avant la planification de la migration il y a quelques interrogations auxquelles on doit répondre, comme:
  • “Comment le système se comportera-t-il dans l’environnement de production ?”
  • “Comment le système se comportera-t-il dans l’environnement de production ?”
  • “Le nouveau système peut-il supporter tous les utilisateurs qui doivent l’utiliser ?”

Telles sont les questions auxquelles l’on devrait répondre avant d’être prêts pour une transition en production.

Abordons ces questions dans l’ordre.

“Comment le système se comportera-t-il dans l’environnement de production ?”

SMP Test maturiteLa réponse à la première question devrait être “il s’exécutera aussi bien qu’il le faisait dans l’environnement de test”. Vous pouvez répondre avec assurance à la question parce qu’un jeu complet de tests a été exécuté dans un environnement de test qui est en tout un double de l’environnement de production hormis la présence des utilisateurs. Cet environnement est parfois appelé l’environnement de pré-production.

Le serveur qui supporte le système devrait être un clone du serveur de production. Si le système s’exécute dans un environnement distribué, tant l’hôte que le client doivent être dupliqués sur un réseau qui est un double du réseau de production.

Mindmap est Partenaire de DantotsuPM

Mindview est Partenaire de DantotsuPM

Fréquemment nos systèmes nouveaux ou mis à jour doivent fonctionner dans un environnement qui comporte un système d’exploitation standard et du logiciel “sur étagère” supplémentaire (Off The Shelf). Les systèmes d’exploitation et le logiciel “sur étagère” dans l’environnement de pré-production devraient être le duplicata exact de ce qu’ils seront dans l’environnement de production et toutes les versions logicielles devraient être les mêmes.

Assurez-vous que toutes les corrections qui seront appliquées au système de production sont aussi appliquées à l’environnement de pré-production.

Si votre nouveau système exige une mis à jour du système d’exploitation et/ou d’un logiciel auxiliaire assurez-vous que vous installerez les mêmes sur l’environnement de production que sur l’environnement de pré-production. Tester votre système nouveau ou mis à jour sur le même matériel et le logiciel que ceux sur lesquels il fonctionnera dans l’environnement de production est une partie critique des tests. Fréquemment le logiciel se comportera différemment selon la combinaison de matériel/OS sur laquelle il fonctionne. Le système peut fonctionner sur la nouvelle combinaison, mais se comporter différemment selon l’environnement; donc une série complète de tests devrait être utilisée pour tester dans l’environnement de pré-production.

“Comment le système se comportera-t-il dans l’environnement de production ?”

data hard diskLa plupart des systèmes exigent de nos jours que des informations soient stockées et récupérées. Cela peut être minimal, comme un jeu d’identifiants utilisateurs et de mots de passe pour la connexion d’utilisateurs, ou cela peut être l’exigence plus importante d’une grosse base de données relationnelle. Les données qui doivent être propagées depuis l’environnement de production précédent doivent être clairement identifiées et un plan de travail défini pour les capturer et les installer dans le nouveau système pendant la migration.

En attendant, les tests dans l’environnement de pré-production devraient être réalisés avec un jeu de données qui simule l’environnement de production aussi étroitement que possible. Les données devraient imiter la production dans les secteurs de la volumétrie et de la distribution. C’est d’habitude accompli dans les systèmes ayant une grosse base de données relationnelle en prenant une copie instantanée des données de production, la convertissant au nouveau format de données et la chargeant dans l’environnement de pré-production. Ce processus de conversion est critique à la migration.

Pendant la migration, le processus utiliser pour convertir et charger les données dans l’environnement de pré-productions sera répété pour transférer les données vers le nouvel environnement de production. Non seulement le processus doit être répétable, il doit être optimisé pour que le téléchargement, la conversion et le chargement se déroulent rapidement.

“Le nouveau système peut-il supporter tous les utilisateurs qui doivent l’utiliser ?”

fastVotre projet peut ou pas avoir délivré des améliorations de performance. S’il l’a fait, ces améliorations doivent être vérifiées dans l’environnement de pré-production. Si aucune amélioration de performance n’a été exigée, il devrait s’exécuter au moins aussi bien que la précédente version. Le test devrait inclure la mesure de la performance de fonctions fréquemment utilisées en temps de charge. Par exemple, si le nombre maximal d’utilisateurs que le système doit supporter est 1000, à quelle rapidité le 1000ème utilisateur est-il connecté ?

Des points de référence devraient être spécifiés dans les secteurs de la performance, de la charge et le test de stress devrait être exécuté dans l’environnement de pré-production et vérifier par rapport à ces points de référence.

C’est seulement quand tous les points de référence ont été atteints ou dépassés que vous êtes prêts pour la migration.

Les Utilisateurs sont-ils Prêts ?

Le système peut être prêt pour les utilisateurs mais est-ce que les utilisateurs sont prêts pour le système ? De nouveaux systèmes apportent les communications dans l'équipegénéralement de nouvelles fonctionnalités que la communauté métier doit utiliser pour satisfaire aux nouvelles demandes du marché, pour répondre à un besoin de réduire l’effort, pour améliorer les performances, etc.

Les utilisateurs doivent être préparés pour qu’ils puissent bénéficier du nouveau système aussitôt qu’il est activé. Toute nouvelle fonctionnalité demande généralement de former la communauté des utilisateurs, mais au-delà de cela, ils doivent savoir quand le nouveau système sera mis en œuvre. Passer au nouveau système sans notifier la communauté d’utilisateurs, même une communauté d’utilisateurs formés, aboutira à un déluge d’appels de support.

La migration exige souvent une fenêtre de temps pendant laquelle ni les nouveaux systèmes ni les vieux ne seront disponibles.

C’est particulièrement vrai des systèmes qui utilisent d’importants volumes de données. Les données doivent être gelées pour être récupérées du vieux système, converties et copiées vers le serveur du nouveau système. Les utilisateurs n’auront pas d’accès aux données pendant ce laps de temps et donc devraient être notifiés pour qu’ils puissent planifier en amont cette période d’inactivité. Migrer vers le nouveau système pendant les heures de travail normales sans notifier la communauté d’utilisateur déclenchera immanquablement un déluge d’appels de support et peut causer plus de dégâts si les délais ne sont pas respectés. Votre migration comprendra un bulletin avant la fermeture du vieux système mais votre communauté d’utilisateurs doit être informée bien en avance de ce bulletin dans votre processus de migration.

Le Plan de Migration

PM PlanLe travail qui peut être fait sans perturber l’environnement de production devrait être fait en avance de la migration. Des tâches comme des installations de matériel, des installations de base de données, des installations d’OS, des installations logicielles devraient toutes être faites en avance de la migration réelle. Le plan de migration doit identifier et prévoir toutes les activités qui doivent se produire au moment de la migration. Mettre en place de nouveaux systèmes qui remplacent des systèmes existants exigera typiquement que la migration se déroule pendant des heures creuses. Le temps nécessaire devrait être identifié dans votre plan. L’heure H marque le début de vos activités de migration. Le plan devrait inclure chaque activité à exécuter, son responsable principal et le temps alloué à cette tâche. L’identification d’un remplaçant au responsable principal vous donnera un niveau de sécurité supplémentaire .

La première tâche sera le bulletin notifiant la communauté d’utilisateurs que l’arrêt se produira à l’heure H. Vous pouvez vouloir publier plusieurs bulletins pour vous assurer que tous les utilisateurs reçoivent la notification (y compris les utilisateurs qui se connectent 30 minutes avant l’arrêt). La tâche suivante est la récupération de toutes les données de l’environnement de production. Le téléchargement, la conversion et le chargement de données devraient suivre la procédure définie pendant le test.

Il y a plusieurs façons d’approcher la migration.

Vous fournissez un nouvel environnement de production et mettez le vieux à la retraite, vous utilisez l’environnement de production existant et échangez l’environnement de production par celui de la pré-production.

L’approche que vous prenez déterminera vos étapes suivantes et sera influencée par combien d’argent l’organisation doit/peut dépenser sur le système et à quel point le système supporte une mission cruciale pour l’entreprise.

  • Fournir un nouvel environnement de production et mettre le vieux à la retraite ou échanger la pré-production et les environnements de production vous permettra d’exécuter des activités comme l’installation de matériel, les installations de base de données, les mises à jour logicielles, etc avant la migration.
  • La réutilisation de l’environnement de production existant exigera probablement que vous exécutiez ces activités pendant la migration.

Chaque activité devrait être vérifiée sur l’environnement de pré-production et mesurée pour qu’une durée raisonnable puisse être intégrée dans votre plan de migration. Puisque le but ici est de  limiter la durée d’indisponibilité, essayez de prévoir autant d’activités en parallèle que possible sans risquer l’échec. Une fois que l’environnement de production a été mis à jour vous pouvez charger les données converties.

L’étape suivante devrait être un test “de fumée” (smoke test) du nouveau système de production.

Le test devrait être assez minutieux pour assurer qu’aucune étape de migration n’a été manquée, mais rationalisé pour qu’il puisse être exécuté dans une durée relativement brève. Les connexions d’utilisateur sont toujours un bon candidat aux tests de fumée. N’importe quel travail qui est exécuté fréquemment par les utilisateurs en est un autre.

La dernière étape devra exécuter toute mise à jour de l’OS nécessaire pour rediriger les utilisateurs sur le nouveau système et notifier que le système est prêt.

Ce bulletin est aussi une occasion d’informer les utilisateurs de tous les changements du système, comme des numéros de version, de nouvelles fonctionnalités, etc. Rendez le nouveau numéro de version évident à trouver et dirigez des utilisateurs sur les documentations décrivant la mise à jour dans votre bulletin d’annonce. Arrangez-vous pour faire surveiller le nouveau système dès la migration. Puisque la plupart des migrations arrivent pendant les périodes d’utilisation non-maximale, la  surveillance devrait durer au moins jusqu’à ce que le système rencontre une situation d’utilisation maximale, par exemple le lundi matin.

NQI est Partenaire de DantotsuPM

NQI est Partenaire de DantotsuPM

Votre plan devrait toujours être testé sur l’environnement de pré-production pour vous assurer de sa complétude (c’est-à-dire toutes les activités nécessaires sont identifiées) et que les durées sont adéquates. Si l’équipe a des problèmes à réaliser une tâche à 10h00 un mardi où personne ne souffle sur leurs nuques, ils échoueront quand ils essaieront à minuit un samedi avec le le Vice Président des Opérations qui les observe.

Stratégie de Retour Arrière

L

Vous souvenez-vous j’ai mentionné qu’un test de fumée et un contrôle sont les parties essentielles du plan ? Que se passe-t-il si le test de fumée échoue ou le contrôle révèle un degré inacceptable de dégradation de système pendant l’utilisation nominale ? La réponse est: un retour arrière.

Le retour arrière rétablit le système et les données précédents sur l’environnement de production et ressemble fortement à une autre migration.

La stratégie de retour arrière dépendra de l’approche de migration utilisée. L’environnement de production doit-il être changé pour revenir en arrière ? ou est-ce que ce sera simplement une question d’installation de l’ancienne base de données dans l’environnement de pré-production et de rediriger les utilisateurs sur celui-ci ?

La stratégie de retour arrière devrait être testée avec le plan de migration pour s’assurer qu’elle fonctionne.

Cela peut sembler beaucoup de travail, d’autant plus que vous devrez probablement ramener l’environnement de pré-production à son état d’avant la migration, mais cela mérite l’effort particulièrement sur des systèmes de mission cruciale.

Et pour finir

Le plan de migration, y compris la stratégie de retour arrière, devrait être passé en revue avec des experts des migrations précédentes et le groupe de support.

supportLes experts de migrations précédentes sont une source d’informations de valeur sur ce qui marche bien ou pas dans votre organisation. Les leçons apprises sont une autre source d’informations mais les auteurs de ces leçons sont d’encore plus de valeur.

Le groupe de support portera le contrecoup principal de n’importe quelles bévues dans la planification ou l’exécution de la migration. Il devrait se sentir confortable que le plan n’a pas loupé d’étapes et que son exécution leur livrera un système supportable quand il le recevra après la migration.

Le plan de migration sera un livrable clef à la réunion de revue de jalon, ou la réunion de pré-jalon, tenue pour déterminer que vous êtes prêts pour la migration.

Le plan de migration ne semblera pas être un livrable important dans le rush pour compléter le projet dans les temps mais l’attention aux détails de ce plan en avance de la migration vaudra bien tous vos efforts.

Ne pas prêter l’attention nécessaire à ce livrable critique gâchera tout le dur labeur de l’équipe pour atteindre ce point culminant.

Peu importe comment l’équipe a bien réussi pendant le reste du projet, on se souviendra seulement du désastre au moment de la migration bien longtemps après que tout ce bon travail soit oublié. Une mauvaise migration ressemble à  une passe ratée dans la surface de réparation. L’attaquant peut avoir gagné 150m en courant, mais on se souviendra seulement qu’il a coûté la victoire à son équipe en ratant la dernière passe décisive.

Enregistrer

Enregistrer

Enregistrer

connaissez-vous la règle des 18 mois et pourquoi des projets sont annulés pour de mauvaises raisons ?

30 Mai

Why Projects Are Cancelled For The Wrong Reasons

http://www.fatcat.com.au/news/home/Ask+an+Advisor/418_0.html

Un nombre élevé et disproportionné de projets sont annulés par le management à 18 mois.

Comme dans tout projet, il y a un flux et un reflux naturel. Un rythme naturel. Ce que je trouve intéressant est que le rythme semble s’installer dans ce que j’appelle la Règle des 18 Mois.

La règle des 18 Mois déclare que :

Loi_de_Moore

Loi de Moore

Un nombre disproportionné de projets est annulé par le management à 18 mois.

N’oublions pas que beaucoup de secteurs ont un rythme naturel, par exemple technologique. Le rythme technologique le plus célèbre est la Loi de Moore qui prévoit que la croissance dans le nombre de transistors par puce doublera tous les vingt-quatre mois. D’autres lois technologiques qui ont un rythme naturel incluent la Loi de Kryder pour le stockage sur disque (~12 mois) et la Loi d’Haitz pour la production de LED’s (~18 mois).

Pourquoi y-aurait-il une Règle de 18 Mois pour les projets ?

Y aurait-il une certaine loi naturelle dans le travail ? La réponse est simple : oui. La nature humaine.

En regardant en arrière tous les projets que j’ai managés dans ma carrière, le cycle de 18 mois d’annulation des projets revient à travers industries, contextes, technologies, tailles d’organisations et nationalités. La règle semble universelle. Pourquoi ?

Dix-huit est le nombre maximal de mois pendant lesquels le management peut souffrir. Cette douleur est la répétition des efforts de re-justification d’un projet dont on attend encore de voir les bénéfices.

Pourquoi 18 mois et pas 12 ou 24 ?

monthsPensez à un projet donné. La plupart débutent en milieu d’année avec un financement et des ressources alloués à grand-peine par le management en se basant sur le mérite et les impacts et bénéfices potentiels. Quand le cycle budgétaire suivant arrive, le projet est bien lancé et le financement est presque assuré car le projet a démarré depuis moins d’une année et que personne ne s’attend à ce qu’il ait déjà un impact. Donc, les ressources sont maintenues en place et le projet continue de progresser.

Le deuxième cycle est une question totalement différente.

Quand le cycle budgétaire suivant survient, des questions s’ élèvent sur le projet :
  • Est-ce que ce projet est toujours aussi important ?
  • Y-aurait-il des projets plus importants que nous devrions financer au lieu de celui-là ?
  • Atteignons-nous les progrès escomptés ?
des budget limités, voire compressés...

il faut se battre pour chaque nouvelle année de financement !

Pourquoi ces questions ?

Parce que chacun dans la chaîne de management doit re-justifier le projet pour encore une autre année de financement. C’est ce deuxième tour qui cause toute l’angoisse. Le résultat est que le management arbitrera s’il faut se battre pour une autre année de financement ou laisser le projet mourir et éviter cette peine. Comme nous pouvons tous l’apprécier, éviter la douleur est une réaction humaine naturelle.

Si le management pouvait voir la valeur (quelque chose qui justifie la peine), approuver que le projet continue ne serait pas un problème. Là où la plupart des équipes de projet s’attirent des ennuis est qu’elles ne saisissent pas cette réaction d’évitement de douleur du management. Dans leurs esprits, le management devrait seulement obtenir les financements et avoir confiance en équipe.

Le résultat est qu’un grand pourcentage de projets sont tués à 18 mois parce que l’on n’a pas démontré leur valeur.

Attendez ! Dites-vous. Nous avions un accord que ce serait un projet sur plusieurs années et que les bénéfices ne viendraient qu’à la fin. Ceci ne prouve-t-il pas que la Règle des 18 Mois ne s’applique pas ? NON. Si vous croyez vraiment que vous pouvez éviter le problème en obtenant un accord au départ, alors vous ne comprenez pas la nature humaine. Au cas où votre projet passerait le jalon des 18 mois, la peine grandira avec chaque cycle ultérieur. Ce qui signifie que vous devrez démontrer une valeur et un impact toujours croissants pour pouvoir continuer. La douleur ne part pas avec le temps. En réalité, elle augmente.

Ce n’est pas la faute de la direction. C’est la faute de l’équipe de projet qui échoue à comprendre le désir du management d’éviter la douleur.

Comment une équipe évite-t-elle cette règle ?

règle des 18 moisSuivez les quelques étapes simples suivantes :

1) Comprendre le cycle de votre organisation (ou votre client) pour vous assurer que vous comprenez le timing. Quand les budgets et/ou les stratégies sont-ils bouclés chaque année ?

2) Définir votre portée de projet et de livrables pour être certains que ce que vous livrez a un impact/une valeur avant que la règle ne soit appliquée.

3) Pour les projets qui s’étendent au-delà de 18 mois, découpez-les et faites de chaque partie un projet distinct. Pourquoi ? Pour esquiver le problème d’évitement d’une peine qui s’intensifie avec le temps car chaque projet remet les compteurs à zéro.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Dans mon expérience, j’ai vu la règle des 18 mois appliquée à des projets qui auraient du être tués dès le départ et à d’autres qui n’auraient jamais dus être arrêtés.

Cette apparente prise de décision aléatoire du management peut être perturbante et démoralisante dans une organisation. Si vous êtes dans le management, regardez-vous dans le miroir et comprenez que la nature humaine joue un rôle dans votre prise de décision de tuer des projets. Aidez vos équipes à le comprendre.

Si vous menez un projet, utilisez ces stratégies de management de projet simples afin d’éviter ce que dans le passé vous aviez attribué à des caprices du management.

CSP est partenaire de DantotsuPM

CSP est partenaire de DantotsuPM

En comprenant la Règle des 18 Mois, vous pouvez vous assurer que vos projets auront l’impact que vous désirez.

Bonne chance !

estimations de temps optimistes (par rapport à honnêtes)

19 Avr

Optimistic time (vs. honest time)

http://sethgodin.typepad.com/seths_blog/2015/01/optimistic-time-vs-honest-time.html par Seth Godin

Les estimation de temps optimistes semblent être une bonne idée. « Nous expédierons en janvier. » « La conférence commencera midi. » « Je serai là dans dix minutes. »

L’espoir est que l’attente même de l’événement élèvera nos attentes et augmentera les chances que quelque chose se produise réellement.

courir après la montre - dernières minutesEn fait, il y a cependant des coûts énormes au temps optimiste. Quand vous annoncez des choses basées sur l’optimisme, le reste des personnes avec lesquelles vous vous engagez construit des plans autour de vous et de votre annonce. Et le coût de la personne qui n’a pas votre logiciel au moment promis ou qui reste assise dans une salle de réunion à vous attendre pendant des heures est élevé.

L’alternative est le temps honnête. Temps sans recours ni négociation. Le train part à 5h52 pas 5h55, peu importe combien vous voulez qu’il attende.

Le logiciel est délivré ou la conférence démarre précisément quand nous avons dit que nous allions le faire. Donc, tout le monde planifie pour cela et en dépend et l’efficacité augmente.

executive timeOn n’expédie pas parce que c’est prêt. On expédie parce que c’est promis.

(Étonnamment, cette règle fait que les choses soient prêtes à temps, bien plus souvent).

C’est une position et un contrat avec vous-même. J’expédie quand j’ai dit que le ferai.

March 30 – Webinar (PMI) – PMI Scheduling Conference 2016

9 Mar

Registration Now Open — Only Available to PMI Members*

Details and registration (PMI Members only)

Details and registration (PMI Members only)

Manage large project schedules? Or, just love keeping your teams on track?

Don’t miss PMI’s premier scheduling event!

Free for PMI members, this all-day virtual event is the only place you’ll learn the latest tips, tools and techniques in project scheduling.

It includes valuable case studies and lessons learned in project scheduling from real projects and programs — not available anywhere outside of PMI.

Plus, if you are PMI certified, you can earn up to 6 professional development units (PDUs) for viewing presentations live and on demand.

February 25 – Webinar (PMI) – Achieving Higher Project Productivity And Predictability

12 Fév

Advanced Work Packaging can effectively align these different perspectives for greater project productivity and predictability.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

In construction projects:

  • The engineering side thinks “systems”…
  • The procurement side thinks “commodities”…
  • The construction field side thinks “all” and geographically…

Don’t miss the opportunity to discover through this webinar Advanced Work Packaging, an innovative disciplined execution approach that improves project outcomes by proactively aligning planning and execution activities throughout the project life cycle, from project set-up to start-up and turnover.

Register for this webinar

On demand – Webinar – Tips and Tricks for More Accurate Scheduling in Microsoft Project

8 Fév

Microsoft Project is a scheduling tool, and if you feed the software with the right information, Microsoft Project will produce an accurate schedule for the project.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Dale Howard

Dale Howard

However, many project managers fail at the basics of scheduling, which results in an inaccurate and untrustworthy schedule of their projects. A project manager, needs to have an accurate schedule.

In this powerful presentation, Dale Howard, a Microsoft Project MVP, will demonstrate a series of useful tips and tricks that will result in a more accurate and trustworthy schedule in Microsoft Project.

Agenda Highlights:

  • Using calendars effectively
  • Completing task planning as « deliverables » planning
  • Assigning resources properly
  • Understanding the proper use of constraints and deadline dates

Register for this free on demand webinar.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

comment approcher un projet à date fixe ?

3 Nov

How To Approach A Fixed Date Project

http://www.pmsouth.com/2013/05/04/how-to-approach-a-fixed-date-project/ par Harry Hall

Beaucoup de chef de projets haïssent les projets aux dates de fin fixées à l’avance. Les managers décident d’une date et disent « respectez-la ». Souvent, le manager a peu ou aucune compréhension du niveau d’effort requis.

Pourquoi les chefs de projets n’aiment pas les dates fixes

  • dateManipulation. Les chefs de projets estiment qu’ils sont manipulés. LE management donne une date empirique. Plus tard, ils changent la date quand elle ne peut pas être respectée. Ce syndrome amène de la méfiance entre PMs et direction.
  • Manque de contrôle. Le chef de projets veut avoir le contrôle sur leur univers de projet. Quand quelqu’un dicte une date fixe, ils perdent un peu du contrôle désiré.
  • La réputation du chef de projets. Le chef de projets sait que sa réputation est basée sur sa capacité à livrer les projets dans les temps. Naturellement, nous n’aimons pas être mis dans une position où nous n’allons probablement pas rencontrer le succès.
  • Stress. Le chef de projets se sent coincé. Le sponsor pousse le chef de projet à faire pression sur l’équipe projet. L’équipe projet pousse le chef de projets à résister aux demandes du sponsor.
Partenaire de DantotsuPM

Partenaire de DantotsuPM

Manager un Projet à Date Fixe

Quand vous êtes mis au challenge de manager un projet à date fixe, voyez-y une opportunité. Vous pouvez livrer le projet dans les temps avec la bonne approche.

Voici certaines choses à considérer:
  • go signEngagez-vous. Faites savoir à votre sponsor que vous mettrez tout en œuvre pour livrer le projet à la date demandée. Établissez un rapport de travail positif avec votre sponsor. Exprimez le besoin de collaboration entre le sponsor et l’équipe.
  • Négociez les ressources compétentes. Formez une équipe avec la bonne alchimie. Les personnes, plus que quoi que ce soit d’autre, sauront faire la différence.
  • Choisissez votre cycle de vie de projet. Utiliserez-vous une approche traditionnelle en cascade ou quelque chose comme un cycle de vie adaptatif (avec les méthodes agiles) ? La réponse à cette question a des implications significatives dans l’aide ou l’entrave à la réussite de projets plus courts.
  • Définissez la charte de projet.
  • Rassemblez et priorisez les besoins.
  • Définissez le périmètre/le contenu.
  • wbs

    Un manuel de référence

    Créez la structure de répartition de travail (WBS).

  • Développez votre échéancier. Si votre chemin critique s’étend au-delà de la date fixée, travaillez avec votre sponsor et votre équipe pour réduire le contenu ou reporter certaines fonctionnalités sur de futures étapes ou itérations.
  • Complétez l’identification et l’évaluation initiales des risques.
  • Construisez des fonds de contingence. Cette réserve n’est pas un amortisseur artificiel. Le fond de contingence est basé sur les risques résiduels connus.

(Gardez à l’esprit qu’une bonne gestion des risques raccourcit souvent le projet. Les risques sont éliminés ou diminués. Cependant, il y a toujours les risques résiduels qui devraient être reconnus dans vos fonds de prévoyance. Par exemple, vous pouvez spécifier que le projet exige que des six semaines supplémentaires pour manager les risques identifiés sur le projet.)

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Astuces pour la compression de planningcar-pound-compression-destroy-leeroy

  • Ajoutez des ressources (c’est-à-dire, compression des délais ou « crashing ») et considérez d’utiliser des heures supplémentaires. Soyez prudent. L’ajout de ressources ou mise en des ressources existantes peut causer plus de mal que de bien. Réduire les délais résulte aussi souvent en un accroissement des coûts.
  • Accélérez l’exécution par chevauchement des tâches (« fast tracking ») : Cherchez des façons d’exécuter des tâches qui sont sur le chemin critique en parallèle ou en chevauchement. Cela peut provoquer des choses à refaire et des risques plus importants.

success 2Votre approche envers un projet à date fixe déterminera votre succès.

Le Chef de projets doit avoir la bonne attitude, s’assurer que les engagements envers le sponsor et l’équipe sont appropriés et choisir les bons processus, outils et techniques.

Question : quelles autres astuces proposeriez-vous pour permettre aux PMs de manager des projets à date fixe ?

La gestion agile de votre projet d’innovation avec Claude Emond

10 Oct

Nouvel atelier de Claude Emond en Gestion de Projet Agile des projets d’innovation et de développement de produits, en collaboration avec L’IDP.

Une approche comme toujours originale de notre ami Claude Emond: Sur 3 journées (4, 9 et 16 nov 2015) incluant, pour chaque participant, 3 heures de coaching personnel sur un projet de leur choix, pendant, entre et après chaque jour de formation.

Inscriptions et Détails

Inscriptions et Détails

Objectif de cette formation-action

Outiller les gestionnaires de projets en développement de produits sur les techniques de gestion agile. Cette formation leur permettra d’accélérer leur projet, de mieux mobiliser leur équipe de développement et ainsi maximiser les bénéfices et le retour sur investissement.

Bénéfices pour les entreprises participantes

  • Claude Emond FormateurPréciser le rôle du chef de projets, en mode agile
  • Augmenter le taux de succès de vos projets de développement de produits
  • Maîtriser le savoir-faire qui permettra d’accroître votre efficacité en gestion de projets
  • Développer vos compétences pour mobiliser et guider les équipes de projets agiles vers le succès
  • Intégrer de nouvelles connaissances par la formation-action dans le cadre d’un projet en cours dans votre entreprise
  • Profiter de l’encadrement des formateurs entre les rencontres pour maîtriser les nouveaux outils et mener à bien votre projet ;
  • Développer les habiletés de leadership de vos chefs de projets implanter des outils de suivi pour livrer vos projets en respectant les coûts  et les délais.

Claude Emond formationQui devrait participer à ce programme de formation ?

Ce programme de formation spécialisé (voir la brochure détaillée) s’adresse aux personnes jouant le rôle de chefs de projets, ou membre d’équipe de projet, dans le cadre de projets de développement de produits et/ou de services.

Il est destiné à tous ceux qui désirent approfondir par l’action leurs connaissances en gestion de projets de développement de produits.

Une méthodologie ancrée dans l’action !

Ce programme unique de formation combine la présentation de notions théoriques et d’outils pratiques. Des exercices permettent d’appliquer les enseignements et d’utiliser les nouveaux outils dans le cadre d’un projet actuellement en cours dans votre entreprise. Entre les rencontres, vous devrez accomplir différentes tâches avec les membres de votre équipe de projet tout en bénéficiant d’une aide personnalisée de la part  du formateur.

De précédents billets de Claude sur l’Agilité:

nouvelle référence du management des ressources dans les organisations matricielles

4 Oct

Microsoft Project 2016 : nouvelle référence du management des ressources dans les organisations matricielles par Campana & Schott

La sortie de Microsoft Project Server 2013 il y a un peu plus de deux ans permettait pour la première fois un accès optimisé aux données projet depuis des appareils mobiles, facilitant ainsi la communication et la collaboration au sein des équipes.

La possibilité d’utiliser l’étendue des fonctionnalités de Microsoft Project Server en tant que service en ligne depuis le cloud avait elle aussi suscité un grand intérêt car elle permettait de simplifier le déploiement de l’outil dans toute l’entreprise, allégeant ainsi la charge du département IT. Bien que la nouvelle version Microsoft Project 2016 semble moins innovante, les apparences sont trompeuses, comme a pu le constater Campana & Schott au cours de ses nombreux tests. Les fonctionnalités étendues de management des ressources ont notamment fait très bonne impression car elles permettent de coordonner une organisation matricielle nettement plus efficacement qu’auparavant. En fonction de la spécialité de chaque entreprise, la mise à niveau avec la nouvelle version promet non seulement un gain de productivité significatif, mais aussi une gestion multi-projets plus souple, ce qui s’accompagne évidemment d’une plus grande réactivité face à la concurrence.

Les versions actuelles de Microsoft Project Server et Project Online offrent d’ores et déjà un aperçu global de l’évolution des projets en cours, depuis différentes perspectives. Les responsables de ressources et supérieurs hiérarchiques peuvent ainsi voir à tout moment sur quels projets leurs ressources sont affectées. Cependant, dans la pratique, ces affectations sont sujettes à de nombreuses modifications : certains employés peuvent subitement ne plus être disponibles pour raison de maladie ou parce qu’ils sont appelés ailleurs pour une urgence. Par conséquent, les chefs de projet sont amenés à replanifier leurs projets et il devient alors difficile pour les supérieures hiérarchiques d’évaluer rapidement et précisément les répercussions possibles de ces modifications sur les autres projets. L’engagement pris lors de l’affectation initiale est alors rompu. De ce fait, les supérieurs hiérarchiques manquent d’une base de décision valide pour accepter ou refuser les nouvelles demandes de projet affectant les membres de leurs équipes. Cette difficulté est principalement due au fait que la précédente version de Microsoft Project Server ne prévoyait aucun process officiel de validation d’affectation de ressources par les responsables hiérarchiques.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Les défis dans la pratique

Dans la pratique, on trouve des exemples typiques de ce genre de problématiques aussi bien dans les entreprises de services que dans le génie logiciel et l’ingénierie, secteurs dont la croissance est souvent soudaine et qui implique le déploiement rapide de nombreux sites. Il n’y a, dans les premières années, que peu de projets multi-sites : il est alors facile de garder une vue d’ensemble précise de la répartition des tâches parmi les employés. Mais à mesure du développement de l’entreprise et de l’augmentation du nombre de projets, cet aperçu devient de plus en plus compliqué : le personnel d’un site en particulier sera-t-il sur ou sous-occupé le mois suivant ? Où se trouvent les spécialistes les plus compétents pour le prochain projet ? Dès lors, les demandes urgentes de gros clients ne peuvent plus être traitées dans un délai suffisamment court, un inconvénient de taille dans la relation client. Il est en effet impossible de déterminer directement si la commande concernée pourra être prise en charge dans le délai imparti. Dans de tels cas, il devient finalement indispensable de procéder à une optimisation des outils pour le management des ressources. Cet exemple est typique dans la mesure où, souvent, une infrastructure de gestion de projet qui fonctionne bien à la base ne parvient néanmoins pas à tenir le rythme de croissance de l’entreprise sur le long terme.

Solutions complémentaires face à l’improvisation Excel

Par le passé, les utilisateurs de MS Project Server se servaient souvent de solutions complémentaires spécialisées réconciliant les besoins des projets et les engagements des équipes métiers au sein des organisations matricielles. D’autres ont essayé de modéliser la planification des ressources inter-projets au sein de fichiers Excel complexes. Malheureusement, ces solutions sont rarement pérennes et la double saisie engendrée entraîne d’inévitables incohérences. Résultat : davantage de coûts au lieu de davantage de transparence.

Une planification plus souple pour une productivité accrue

La version Microsoft Project Server 2016 offre de nouvelles perspectives dans la gestion des capacités et des ressources. Les nouvelles fonctionnalités « demande de ressources » et « engagement de ressources » remédient en effet au problème décrit plus haut : l’outil historise l’intégralité des accords et refus délivrés par les responsables hiérarchiques vis-à-vis des demandes d’affectations émanant des chefs de projet. Cela crée ainsi un socle solide sur lequel peut se baser la communication entre toutes les parties prenantes – y compris les responsables hiérarchiques.

c&s1_Resource_Engagement_PWA_Proposed_Request_Generic_Role_Timephased_DataIl s’agit là d’une fonctionnalité à forte valeur ajoutée pour le métier, attendue depuis longtemps par de nombreux clients de Campana & Schott. La capacité de décision ainsi acquise au niveau du responsable des ressources peut à elle seule générer un gain de productivité d’environ 10 % dans les entreprises de services. Autre avantage : ces fonctionnalités étendues de Microsoft Project Server 2016 en management de ressources sont directement disponibles, aucune configuration additionnelle n’est nécessaire.

Capacité immédiate de décision

Par ailleurs, la nouvelle version Microsoft Project Server 2016 favorise la prise rapide de décisions par le biais des dites « heat maps » – une fonctionnalité qui impliquait par le passé le recours à un partenaire d’implémentation : des graphiques de couleur permettent maintenant d’identifier d’éventuelles ressources en sur-utilisation ou à contrario en sous-utilisation entre différents projets, et ce même avec un important volume de données et des interdépendances extrêmement complexes.

c&s2_Resource_Engagement_PWA_Engagement_HeatmapLes cartes utilisent les couleurs des feux tricolores, avec des seuils à définir librement. Cela permet aux supérieurs hiérarchiques d’agir avec un maximum de flexibilité lors de la planification des interventions et de prévenir ainsi des situations d’impasse au niveau d’un projet ou d’une ressource critique.

D’autres nouveautés côté client riche

La fonctionnalité « Timeline » (frise chronologique) permettait déjà dans Project 2013 de visualiser le déroulement du projet le long d’un axe de temps. La version Microsoft Project 2016 propose à présent dans le client riche l’option de gérer plusieurs axes de temps pour un projet et de les afficher sous forme de barres superposées. Par exemple, la barre supérieure peut représenter le projet dans son ensemble, tandis que celle du dessous décrit plus précisément un lot spécifique du projet. Il est ainsi possible de différencier précisément les phases du projet, sans que les détails ne brouillent la vue d’ensemble du projet.

c&s3_MultipleTimelineEn outre, l’intégration d’une nouvelle fenêtre de recherche directement dans l’interface du client riche réduit considérablement le temps nécessaire pour trouver des fonctions rarement utilisées.

c&s4_Tell_me_what_you_want_to_do

Version Cloud : des innovations plus rapides à utiliser

Avec Project 2016, Microsoft poursuit sa route vers le cloud. Bien que Project Online ne soit disponible que depuis le début de la sortie de Project 2013, la plupart des nouveaux clients britanniques par exemple misent sur la version Online, le plus souvent en association avec Office 365. La France en revanche se montre encore hésitante vis-à-vis des solutions cloud et continue de privilégier la version on premise. Toutefois, l’interaction de Project Online avec d’autres offres de Microsoft dans le cloud devient de plus en plus importante en termes de productivité et d’efficacité – par exemple avec SharePoint Online, Power BI, Skype Entreprise Online, Dynamics CRM Online, ou encore avec la plateforme sociale dédiée aux entreprises Yammer, qui fait partie de Microsoft depuis 2012.

Microsoft est Partenaire de DantotsuPM

Microsoft est Partenaire de DantotsuPM

D’un point de vue utilisateur, le grand avantage d’une solution cloud comme Project Online est sans doute sa disponibilité immédiate évitant de longs et fastidieux accords avec le département IT. Comme les versions en ligne sont conçues et mises à disposition des utilisateurs de manière incrémentielle, les cycles d’innovation se raccourcissent. Inutile à présent d’attendre la version suivante : les nouvelles fonctionnalités sont immédiatement disponibles et utilisables. Cela réduit considérablement la charge de travail du département IT puisque le portefeuille d’applications gérées en interne n’augmente pas et les contraintes liées à un changement de version n’ont plus lieu d’être. Pour les PME notamment, qui n’utilisaient jusqu’à présent que le client riche en local, Project Online devient une possibilité simple de passer à Project Server, sans nécessiter d’investissements en nouveau matériel. De même, pour les entreprises utilisant à présent Project Server 2003, 2007 ou 2010 qui envisagent une migration, l’option Online mérite d’être étudiée. Microsoft a d’ores et déjà mis un terme au support global pour les versions 2003 et 2007 et le support devrait s’arrêter d’ici la fin de l’année pour Project Server 2010.

Conclusion

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Dans les entreprises dotées d’une organisation matricielle, les avancées significatives en termes de management des ressources de Microsoft Project Server 2016 apportent davantage de transparence entre la planification de projet et la planification hiérarchique. L’historisation des validations concernant les demandes d’affectation de ressources permet une meilleure visibilité et communication entre les différentes parties prenantes. Les outils complémentaires pour la planification des ressources tels que les tableurs Excel deviennent ainsi superflus. Par ailleurs, des rapports standards et des « heat maps » intégrés facilitent l’analyse d’éventuelles sur-affectations ou sous-affectations des ressources entre les différents projets de l’entreprise. Dans l’ensemble, la solution avancée de gestion des ressources proposée par Microsoft Project Server 2016 agit comme un important levier pour l’amélioration de la répartition des activités parmi les acteurs projet et donc pour l’augmentation de la productivité de l’entreprise. En effet, plus la part de chiffre d’affaires générée par ressource est élevée, plus l’impact d’une planification optimisée influe sur le résultat commercial. Néanmoins, il ne faut pas oublier qu’un outil de management, aussi performant soit-il, ne portera aucun fruit s’il n’est pas accompagné de procédures, règles et rôles appropriés afin de l’ancrer dans l’organisation.

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 1 570 autres abonnés

%d blogueurs aiment cette page :