Formation management de projet

 

Objectifs et bénéfices de la formation

Formation : Management de projet
  • Apprendre à dérouler le cycle de vie d’un projet, de l’idée jusqu’à la clôture
  • Acquérir ou consolider les techniques de gestion spécifiques au projet et les placer dans une perspective managériale

Méthodes pédagogiques 

Pédagogie active centrée sur la pratique des techniques et la dynamique de groupe

Programme de la formation

Télécharger la fiche PDF et le bulletin d'inscriptionFormation : Management de projet

1.Cadrer le projet
- Exprimer le besoin et formaliser les enjeux
- Analyser les parties intéressées au projet et en tirer les conséquences
- Répartir les responsabilités et les risques
2.Vérifier la faisabilité du projet
- Aide aux choix structurants
- Viabilité économique et financière
3.Structurer & Planifier le projet – Etablir le budget de référence
- Découper le projet en lots de travaux
- Etablir le réseau d’activité (PERT) et le GANTT
- Estimer les ressources et les coûts
4.Constituer et gérer le portefeuille des risques - Prendre des dispositions pour faire face à l’incertitude
- Méthodes pour identifier les sources de risques et les zones d’incertitude
- Développer des stratégies de réponse
5.Former l’équipe projet et y associer les autres prestataires
- Profils de personnalité et de compétences
- Rôles & Responsabilités – Modalités d’animation et de contrôle
6.Préparer le lancement du projet
- Etablir le plan de communication et organiser le contrôle qualité
- Utiliser le système de gestion de l’entreprise
- Rédiger et faire accepter le plan de management du projet
7.Effectuer le suivi de l’avancement et piloter les activités de manière proactive
- Gérer la valeur acquise et la prévision à terminaison
- Gérer les perturbations et évolutions
8.Converger vers un résultat accepté par les utilisateurs / exploitants et clôturer le projet
- Valider les livrables et les transférer vers les opérations
- Capitaliser les enseignements tirés des expériences vécues

 

Informations pratiques de la formation

Télécharger la fiche PDF et le bulletin d'inscription Formation : Management de projet

DUREE :
2 jours / 14h

TARIF :
- 1190€HT, déjeuners non inclus
OPTIONS :
- Accompagnement post-formation MagiCoach® :
MagiCoach® "Performance" : 590€HT
MagiCoach® "Excellence" : 790€HT
MagiCoach® "Premium" : nous consulter
- Coaching téléphonique de 40mn - 230€HT
EvaluAction®- 190€HT

DATES ET LIEUX :

A Paris

20 et 21 février 2017

19 et 20 juin 2017

02 et 03 octobre 2017

PRE-REQUIS :
Aucun

PUBLIC CONCERNE :
Toute personne partie prenante d’un projet

NOMBRE DE PARTICIPANTS :
Jusqu'à 10 personnes

REFERENCES :
Accendo : P12-DH01
AGEFOS-PME : 2540



Nous contacter par téléphone : 01 75 43 88 00

 

Votre formateur

Frédéric formateur accendo
Frédéric
Après une formation universitaire en informatique et un 3ème cycle à HEC, Frédéric s’est rapidement investit dans le management de projets et dans la direction d’unités de conseil. Durant 25 ans, Frédéric est principalement intervenu auprès de grands comptes du secteur privés et d’organisations publiques, auprès desquels, il a dirigé des projets complexes, mobilisant ainsi plusieurs centaines de personnes. Allant des projets applicatifs aux projets de transformation, il maintient une forte implication opérationnelle au niveau de la conduite et du pilotage de projets. Spécialisé dans la sécurisation et du redressement de projets, il apporte son expertise méthodologique, organisationnelle et managériale. A la fois conseil, formateur, coach d’équipes et d’organisations (Major de promotion DESU Paris 8), Frédéric accompagne les équipes impliquées dans un processus de changement et réconcilie les aspects technologiques, fonctionnels, méthodologiques, opérationnels, stratégiques, organisationnels et humains inhérents à tout projet ou transformation.



Accendo Formation
59, rue Boissière - 75116 Paris
Téléphone : 01 75 43 88 00 - Fax : 01 75 43 20 19
E-mail : Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.- Site : www.accendo.fr


Article(s) dans la presse en rapport avec la gestion de projet

"La question du management transverse est centrale"
Par YGG le 31/05/2010 dans http://pensermanagement.blogsome.com


Différents chantiers récents remettent au centre des nos réflexions la question du management transverse dans les organisations; la question est, au départ, double : le management veut des gens capables de manager des processus tranverses et des projets; les intéressés font plutôt –disent-ils massivement– l’expérience de l’impuissance dans ce rôle : "on dépend des autres mais on n’a rien à leur donner" "on ne peut pas leur donner des ordres" "on ne peut pas passer son temps à escalader"...

On sait que le collectif n’existe qu’à la condition de respecter des conditions précises (et bien connues depuis belle lurette) : avoir une perception commune des buts et des finalités (vision), créer un système de relations sûres et confiantes, travailler ensemble avec des méthodes partagées, et partager une information fiable sur les indicateurs de progression et la mesure des écarts à l’objectif.

Ces quatre composantes (vision, régulation, convergence et synchronisation) donnent les ingrédients de base d’une stratégie de démarrage, puis de pilotage de l’activité. En particulier, en face d’une situation problématique, on peut diagnostiquer la source du problème et en déduire le domaine des actions correctives à envisager.

La question est bien –face à l’expression des difficultés– celle du management : "optimiser l’utilisation des moyens en fonction des buts à atteindre"; dans le cas d’une activité transverse (donc par nature multidimensionnelle, et à cheval sur plusieurs univers de référence, plusieurs domaines d’activité et d’appartenance), la question est bien celle des buts (transverses) et celle des moyens (transverses).

Dans les organisations actuelles, on observe de façon récurrente :

  • la montée des professionalités qui oblige à une "subsidiarité" de fait, au niveau des spécialistes proches des lieux où les décisions sont nécessaires, pour avoir de meilleures décisions; on a des expertises d’exécution proprement "inencadrables" pour cause… d’expertise! (cf les niveaux de coordination de Mintzberg);
  • le rôle du top management est dans la détermination des buts (vision + stratégie); c’est sa zone d’expertise;
  • la traduction des buts globaux en objectifs par entités devient l’enjeu de luttes parfois féroces; et le lieu de constitution d’expertises intersticielles encore (semble-t-il) mal décrites et mal évaluées (à suivre) (confer par exemple les expertises de packaging et de pricing dans les activités de service...).


On observe donc, dans un système englobant de plus en plus uniforme (globalisation, terrain de jeu et de concurrence worldwide + entreprise étendue : relations de plus en plus intriquées et intimes avec les fournisseurs/ sous-traitants…), des enchaînements eux-même de plus en plus communs à toutes les organisations (celles qui sont appelées à continuer, en tout cas), et les quatre comportements-clés suivants :

  • exigence lean : alignement des coûts sur les concurrents aux prix les plus bas; donc recherche systématique d’économies à tous les niveaux du processus,
  • pour cela, amélioration continue des performances (le fameux kaizen de Toyota –attention, pas jeter le bébé avec l’eau du bain!), c’est à dire recherche continue de progrès sur toutes les dimensions possiblement utiles, exercice tous azimuts de l’ingéniosité de chacun,
  • ce qui exige une fort degré d’autonomie de décision des acteurs (auto-activation et subsidiarité) pour qu’ils puissent exercer leur expertise au bon endroit du processus,
  • et un management stratégique du temps : parallélisation, time to market et right to market, ingénierie simultanée, anticipation des coûts en temps des décisions en amont...
  • tout ceci organisé autour du centrage sur l’aval, c’est à dire de l’alignement du processus (et des quatre comportements-clés précédents) sur les contraintes des clients et successeurs dans le processus...

On voit que l’ensemble de ces facteurs exige et soutient la démarche de management transversal; on voit aussi qu’une application partielle, incomplète va générer une dose vite insupportable d’effets pervers qui risquent de bloquer le système –au profit des acteurs qui ont intérêt à démontrer que "le transversal ça ne marche pas...".

Notons enfin que dans un certain nombre de cas, une application incomplète du système sera palliée par les efforts des acteurs intéressés –mais avec une efficacité bien moindre, et à un coût humain souvent disproportionné.

Dans ce type de situation (que nous rencontrons fréquemment depuis quelques temps chez certains de nos clients) l’approche en quatre quadrants que nous évoquions en commençant nous a fréquemment permis d’impliquer le/ les groupes concernés dans une démarche de diagnostic puis de résolution de problèmes pragmatique et positive:

  • quel est le quadrant problématique essentiel? Vision? Régulation? Convergence? Synchronisation?
  • en fonction de ce diagnostic: quelle(s) action(s) seraient à même de corriger le dysfonctionnement? De qui ces actions dépendent-elles? Dans quel quadrant situez-vous le domaine des actions à entreprendre?
  • programme d’actions conçu avec l’équipe transverse dans le quadrant considéré et reprise du processus...



"Conception de produit : que faire quand tout ne se passe pas comme prévu?"


Par Olivier Ezratty pour LEntreprise.com, le 07/02/2012 dans http://lentreprise.lexpress.fr

Des développements qui prennent plus de temps, un logiciel qu'il faut réécrire, un sous-traitant défaillant... Comment prévenir ces difficultés de parcours et faire face à des imprévus pour respecter votre planning et être opérationnel dans les délais? Extrait #5 du Guide des startups high-tech en France d'Olivier Ezratty.

  Prévention Guérison
Développements qui prennent du retard Chiffrer les coûts et délais de développement en amont.
. Savoir que c'est une situation presque systématique, prévoir 30 à 40% de plus en termes de temps et de coûts
. Prévoir le BFR en consé-quence.
. Gérer un rétroplaning (Gantt) sur 18 mois avec les détails et le mettre à jour régulièrement.
. Mettre en place une comptabilité analytique des développements si possible dès le début pour avoir des indicateurs d'alerte. Elle sert aussi à valider son CIR.
Identifier et corriger la source du retard : compétences de l'équipe de développement, spécifications incorrectes ou incomplètes, mauvaise architecture à revoir, qualité de la sous-traitance
Défaillance de sous-traitants clés Ne pas dépendre que d'un seul sous-traitant pour des missions clés.
. Faire leur due diligence avant leur sélection.
. Blinder l'aspect contractuel avec eux.
. Commencer graduellement avec un premier "petit" contrat pour apprendre à se connaitre
. Ne pas hésiter à en changer si ce n'est pas satisfaisant.
Se désengager des sous-traitants qui ne vont pas.
. Réinternaliser rapidement certains développements clés (modulo les moyens financiers disponibles)
Difficulté d'industrialisation du produit (surtout matériel) . Bien architecturer le produit dès le départ.
. Modulariser le logiciel.
. Créer des interfaces claires entre composants.
. Prévoir la " scalabilité " du produit dans l'architecture (pour services Internet).
. Supervision par un expert externe (cher à l'heure) mais pour peu d'heures.
. Développements en mode Scrum
Audit d'architecture et mesures correctives.
Voir les points précédents.
Logiciel spaghetti qu'il faut réécrire entièrement pour le faire évoluer Il n'y a pas de commentaire dans le code. Pas de schéma d'architecture. Bien architecturer le produit dès le départ.
. Développer une approche modulaire, par composants, ...
. Embaucher au moins un Sénior qui aura notamment la charge de l'architecture (vous ne confieriez pas votre maison à un architecte qui fait son premier plan !). Même si un des fondateurs et le CTO et croit savoir faire.
. Imposer et vérifier que les commentaires et le nommage des variables correspondent à des règles écrites et tout doit être en anglais.
Envisager une réécriture... après une revue d'architecture.
Mauvaise fiabilité du produit Mettre en place procédures de tests rigoureuses.
. Plan de bêta test avec utilisateurs réellement impliqués.
Mise en place processus de tests et de correction
. Mettre en veilleuse roadmap produit pour améliorer la qualité du produit.
Le code contient des morceaux non libres de droits. Ajouter une clause au contrat de travail de tout développeur lui interdisant et le responsabilisant en cas d'usage/copie de code de tiers. Tout usage doit être connu et règlementé (logiciel type Black Duck si besoin).
. Dédier une personne interne à cette responsabilité.
. Déposer les codes à l'APP (+ Usage enveloppe Soleau de l'INPI)
 
Changements de règle de la plate-forme sous-jacente (Facebook, AppStore, etc) Eviter de trop dépendre d'une plateforme et d'un acteur qui peut changer les règles du jeu du jour au lendemain (Apple, Facebook)
. Préférer les plateformes ouvertes et sans " péage "
Devenir multi-plateforme
J'accepte les conditions d'utilisation

Conditions d'utilisation: en transmettant ce formulaire, vous acceptez de nous communiquer les données qu'il contient, protégées par notre charte de confidentialité et la loi sur la protection des données.