Management de projet IT

8/19/2019 Management de projet IT

http://slidepdf.com/reader/full/management-de-projet-it 1/41

Gestion de projet ITRésumé

Frédéric Montet

Professors : Elena Mugellini & Jean Hennebert

January 23, 2016



Contents

1 Fondamentau x 41.1 Qu’est ce qu’un projet? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Qu’est-ce que la gestion de projet? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Quelles sont les contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Qu’est ce qui fait la diff érence d’un projet IT? . . . . . . . . . . . . . . . . . . . . . . 41.5 Structure d’un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5.1 Projet Pure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5.2 Projet fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5.3 Projet Matriciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6 Attributs d’un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6.1 Temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6.2 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6.3 Appartenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6.4 Ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6.5 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.6.6 Risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6.7 Interdépendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6.8 Changement organisationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.7 Les phases de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.7.1 Project Life Cycle - PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.7.2 IT System Developement Life Cycle - SDLC . . . . . . . . . . . . . . . . . . . 7

2 Phase 1 - Initialisation, conceptualisation du projet IT, business cas e 82.1 Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Séléction de l’équipe du Business Case . . . . . . . . . . . . . . . . . . . . . . 82.1.2 Dénition du MOV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Identication des alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.4 Dénition de la faisabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.5 TCO - Dénition du coût total d’appartenance . . . . . . . . . . . . . . . . . 92.1.6 TBO - Dénition du bénéce total d’appartenance . . . . . . . . . . . . . . . 92.1.7 Analyse des alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.8 Proprosition et recommandation de support . . . . . . . . . . . . . . . . . . . 10

2.2 Séléction du projet et approbation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Phase 2 - Développement de la charte et du plan de proje t 113.1 Charte de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Plan de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1 Périmètre (Scope) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.2 WBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1



Résumé January 23, 2016

6 Phase 4 - Gestion du changemen t 326.1 Changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.2 Gestion du changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.3 La nature du changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.4 Plan de gestion du changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.4.1 Impact sur les diff érents secteurs . . . . . . . . . . . . . . . . . . . . . . . . . 336.4.2 Réaction au changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.4.3 Le plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.4.4 Les stratégies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.4.5 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Phase 4 - Implémentation, Clôture 377.1 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.1.1 Normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.1.2 Challenged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.1.3 Raté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.1.4 Perpetuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.2 La réalité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.3 Acceptance du sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.4 Point de vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.5 Clôture administrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.5.1 Rapport nal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.5.2 Meeting nal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.5.3 Check-list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

8 Phase 5 -Evaluation 398.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8.2.1 Niveau projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398.2.2 Niveau individuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398.2.3 Niveau Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3



Chapter 1

Fondamentaux

1.1 Qu’est ce qu’un projet?

Un projet est une série d’activités reliées dans le but de fournir un/des résultats majeurs dans unepériode de temps données et en réspéctant des contraintes.

1.2 Qu’est-ce que la gestion de projet?

La gestion de projet consiste en la planication, la direction et le contrôle des activités et desressources pour rester dans les contraintes du projet.

1.3 Quelles sont les contraintes

1. Résultat2. Coût

3. Temps

1.4 Qu’est ce qui fait la di ff érence d’un projet IT?

Un projet IT vise la conception d’une service ou produit informatique. L’utilisation d’IT est unfacteur détérminant.

1.5 Structure d’un projetLa structure d’un projet déni la relation entre le projet et l’organisation hiérarchique ou fonctionnellede l’entreprise recevant le projet. Il y a 3 structures de projet principales: pure, fonctionnelle etmatricielle.

1.5.1 Projet Pure

Projet ou une équipe dénie travail à 100% sur le projet. Cette structure s’applique bien auxorganisations plate.

4




1.5.2 Projet fonctionnel

Le projet est reçu dans une division fonctionnelle d’une entreprise. e.g. Projet A,B,C,etc. dudépartement Ra&D.

1.5.3 Projet Matriciel

Les diff érents projets sont sur les axes horizontaux de la matrice alors que les départements (ressourcesfonctionnelles) sont sur les axes verticaux.

1.6 Attributs d’un projet

1.6.1 Temps

Les projets ont un début et une n.

1.6.2 But

Les objectifs d’un projet sont de produire quelque chose apportant de la valeur à une organisation.

1.6.3 Appartenance

Le projet appartiendra à un individu ou a un groupe une fois celui-ci terminé. Les parties prenantes(Stakeholders) du projet sont les personnes ayant un intérêt envers les résultats du projet. Les clients(sponsors) sont ceux qui nancent et fournissent les ressources pour le projet.

1.6.4 Ressources

Les ressources fournissent les moyens pour atteindre l’objectif d’un projet, c’est aussi une contrainte.

5



Chapter 2

Phase 1 - Initialisation, conceptualisationdu projet IT, business case

2.1 Business Case

C’est une analyse documentée de la valeur organisationnelle, faisabilité, coûts, bénéces et risquesdu projet à un niveau stratégique.

2.1.1 Séléction de l’équipe du Business Case

Permet d’avoir de la crédibilité, dans le cas de projets inter-départementaux de dénir l’appartenance,les accords, etc.

2.1.2 Dénition du MOV

Le MOV est la valeur organisationnelle mesurable (Measurable Organisational Value). En fait, c’estle but du projet et une mesure de succès. Un MOV doit: être mesurable, apporter de la valeur, fairel’objet d’un accord, être vériable.

Identication de la zone d’impacte désirée

Stratégique, Client, Financier, Opérationnel, Social

Identication de la valeur désirée du projet IT

Better, Faster, Cheaper, Do More?

Développement d’une métrique

Argent, pourcentage, valeurs numériques

Temps

Quand est-ce que le MOV sera atteint?

Vérication et accord des parties prenantes du projet

Le chef de projet et son équipe peuvent seulement guider le processus.

8




Résumé du MOV

Le projet sera un succès si ...Exemple: The project will provide a 20% return on investment and 500 new customers within therst year of its operation.Our goal is to land a man on the moon and return him safely by the endof the decade.On peut aussi faire un résumé sous la forme d’un tableau.

2.1.3 Identication des alternatives

On doit penser out-of-the box pour atteindre le MOV de notre projet, il y a plein de solutions! Ilfaut envisager “ne rien faire” comme étant une alternative.

2.1.4 Dénition de la faisabilité

On doit dénir les risques et la faisabilité de chaque alternatives de l’étape précédente. La faisabilitéconcerne les aspects economiques, techniques, organisationnel, etc. Les risques sont les éléments qui

entravent la complétion du projet et ce qui doit aller comme prévu.

2.1.5 TCO - Dénition du coût total d’appartenance

le TCO (Total Cost of Ownership) est une première estimation des coûts du projet, elle va êtreaméliorée dans les phases suivantes et connue à la n du projet. Les coût peuvent être direct,courant, indirects, etc.

2.1.6 TBO - Dénition du bénéce total d’appartenance

Le Total Benets of Ownership dénis les bénéces tangibles et intagibles du projet. E.g. Améliorela précision et l’efficience, améliore la prise de décision, etc.

2.1.7 Analyse des alternatives

Pour l’analyse des alternatives on peut utiliser des modèle de scoring comme: ROI, Payback period,break even, etc. Dans cette analyse on doit voir quels sont les impacts externes et organisationnelset également ceux sur l’organisation du projet.

On peut utiliser une scorecard pour résumer l’analyse:

9




2.1.8 Proprosition et recommandation de support

Normalement fait par le client/sponsor, cette partie dénira si le projet sera exécuté ou non et selonquelle alternative.

2.2 Séléction du projet et approbation

Dans la plupart des entreprises, il y a un processus de séléction des projet IT. Les critère sont baséssur: la correspondance avec les buts de l’entreprise, le MOV, coûts tangibles et intangibles, plusieursniveaux hiérarchiques de l’entreprise.

10



Chapter 3

Phase 2 - Développement de la charte etdu plan de projet

3.1 Charte de projet

La charte de projet est un plan tactique documenté du projet. Il sert d’accord ou de contrat entreles clients/sponsors et l’équipe du projet. Il inclut une base de plan de projet.

Une charte de projet:

1. Documente le MOV

2. Dénis l’infrastructure du projet

3. Résume les détails du plan de projet

4. Dénis les rôles et responsabilités

5. Montre les promesses du projet

6. Dénis les mécanismes de contrôle du projet

Une charte de projet contient:

1. Project ID

2. Project Stakeholders

3. Project Description4. MOV

5. Project Scope

6. Project Schedule (summary)

7. Project Budget (summary)

8. Quality issues/standards/requirements

9. Resources

10. Assumptions et Risks

11




11. Project Administration

12. Acceptance et Approval

13. References

14. Terminology (acronyms et denitions)

3.2 Plan de projet

Le plan de projet est un plan d’action détaillé pas à pas qui à l’unique objectif de supporter le MOV.

Les étapes sont:

1. Dénition du périmètre (Scope)

2. Diviser le projet en phases

3. Dénir les tâches pour chaque phase

3.2.1 Périmètre (Scope)

Le périmètre du projet déni les délivrables ou travaux produits qui seront complétés pour atteindrele MOV. On va dénir des déclaration de périmètre, soit une forme écrite de la frontière entre ce qui

et inclus et non-inclus dans le projet.Il y a 2 types de périmètres: Orienté projet (PLC) et orienté produit (SDLC).

3.2.2 WBS

Le Work Breakdown Structure représente une décomposition logique du travail à eff éctuer. Il estorienté délivrable et supporte le MOV. C’est une représentation des tâches à éff ectuer. Le niveau dedétail doit supporter la planication et le contrôle.

3.2.3 Estimation

Guestimating

Basé sur un ressenti, pas bon pour les jeunes chefs de projet.

12




Technique Delphi

Implique des experts anonymes qui estiment et on compare. Si il y a des divergences on réitère jusqu’à convergence et on moyenne.

Time Boxing

Une “Box” de temps est allouée pour une tâche ou délivrable. Une “box” n’est pas extensible. Il fautfaire attention à la motivation de l’équipe.

Top-Down

Les Top et Middle manager dénissent la base et/ou les coût. Les managers de niveaux plus bas fontdes WBS en tenant compte de ces contraintes.

Bottom-Up

Forme la plus commune d’estimation, le programme et budget sont construit depuis le WBS fait parles exécutants.

Analogies

On se base sur des projets antérieurs similaire pour estimer le projet courant.

3.2.4 Estimation IT

Line of Code (LOC)

Souvent utilisé pour détérminer la taille d’un projet, mais le plus controversé.

Function Point Analysis (FPA)

Estimation indépendante de la technologie basée sur 5 points:

1. External Input - e.g. formulaire pour user input

2. External Output - e.g. Graphique

3. Demandes externes - e.g. Combinaison de input et output

4. Fichiers logiques internes - e.g. Customer table in DB

5. Interfaces externe - e.g. Same as chiers logiques internes mais maintenu de manière externe.

13




COCOMO - COnstructive COst MOdel

Cocomo sépart les projets en 3 types: Organic(2.4), Embedded(3.6) et Semi-detached(3.0).Un projetorganique est une routine. Un projet Embedded est un challenge. Un projet semi-detached estintermédiaire. Chacun de ces modèle (eff ort) à un facteur multiplicateur de difficulté respéctivement2.4, 3.6 et 3.0. Une unité, le KDSI est le millier d’instructions sources délivrée.

14




3.2.5 Sequence et organisation

Project Schedule

Le calendrier du projet se construit sur la base du WBS en identiant la séquence des activitésainsi que leurs dépendances. Les outils sont: Gantt, Project Network Diagrams (Activity On theNode(AON), Critical Path Analysis, Programm Evaluation and Review Technique (PERT), Prece-dence Diagramming Method (PDM)), Monte-Carlo simulations.

Critical Path

Le chemin critique est le plus long chemin. Il détérmine le temps le plus court permettant de terminerle projet.

PERT

Basé sur une distribution statistique.

15




16




Precedence Diagramming Method

Lead

C’est démarrer la tâche suivante alors que la première tâche n’est pas terminée. e.g. commencer àinstaller des OS alors que tous les PC ne sont pas montés.

Lag (ou Negative Lead)

C’est ajouter un “buff er” de temps avant que la prochaine tâche ne commence. e.g. une fois que lesmûrs sont peind, on attend qu’ils sèchent avant de mettre la tapisserie.

3.2.6 Développement du budget

La dénition du budget se fait en 5 étapes:

1. Dénition des ressources (What)

2. Dénition de la quantité de ressources (How much)

3. Dénition du cout par ressource

4. Calcul du cout de l’activité

5. S’assurer de l’équilibrage des ressource (Pas de sur-allocation, ni sous-allocation)

Types de couts

Couts directs, Couts indirects, sunk costs, Learning curve, prorated cost, reserves.

17



Chapter 4

Phase 3 - Choix d’une méthodologie

Le PLC (Project Life Cycle) est le cycle de vie générique d’un projet. Il a 5 phases: Initialisation,plannication, exécution, clôture, évaluation.

Le SDLC (System Developement Life Cycle) est un processus d’exécution en 4 phases pourconstruire un système d’information: plannication, analyse, design, implémentation

4.1 Les phases

4.1.1 Plannication

Souvent cette phase est dénie par la phase 2 du PLC. Soit c’est le client qui dit: Je veux ça pour 10$dans 1 semaine. Soit c’est le client qui nous demande: Je dois mettre quoi comme fonctionnalités.Ou bien c’est un mix.

Feature drivenProjet ou le set de fonctionnalités est determiné et la date de n du projet n’est pas encore connue.

Date driven

Projet ou la date de n est xée et le set de fonctionnalités n’est pas totalement connu.

Réalité

Souvent les projets sont Feature et Date driven.

4.1.2 AnalyseSouvent fait par un business analyst. On récolte de l’information, BPM, Model de haut-niveau.

4.1.3 Design

C’est la phase architecturale (Physical design, Architecural design, Interface design, Database andle design, Program design), Choix des technologies. Le délivrables est un document de spécication.

4.1.4 Implémentation

Ecriture du code, Intégration des diff érents résulats des développeurs, Tests (unitaires, intégration,

fonctionnel)

18




4.2 E ff ets indésirables

4.2.1 E ff et tunnel

4.2.2 Contract game/Squirrel Burger/Magical Toolbox

4.2.3 Cone de l’incertitude VS Cout du plan

4.2.4 Cout du changement

Le cout du chanagement en Waterfall grandi plus le projet avance. Avec l’agilité, ce n’est pas commecela, le projet peut changer. (Orienté personne plutôt que orienté process)

4.2.5 Loi de ParkinsonL’eff ort pour une tâche s’etend sur toute la durée de la tâche. Il faut allouer la juste quantité detemps.

4.2.6 Cow-Boy coding

Pas de méthodes dénies, tout le monde fait comme il veut. Ce n’est pas Agile.

4.2.7 Murphy’s law

Tout ce qui peut aller de travers, arrivera tôt ou tard!

19




4.3 Pas de solution “one-size-ts-all”

4.4 Classication des méthodologies

1. Structurée ou Waterfall

2. RAD -Rapid Application Developpement

3. Agile

20




4.4.1 Waterfall

Avantages et inconvénients

4.4.2 Parallel Waterfall

21




4.4.3 RAD - Rapid Application Developement

L’objectif est d’avoir des éléments logiciel dévelopés rapidement pour avoir des feedback client le plusvite possible.

Versioned development

22




Protoyping

Throw-away prototyping

4.4.4 Agile

4.5 Le choix

Le choix d’une méthodologie dépend du contexte du projet, sa taille, criticalité, l’organisation cliente,sa culture, la réactivité du marché

23




4.5.1 Etapes1. Dénition des critères qui vont éventuellement permettre à l’organisation de prendre la meilleure

solution possible

2. Apprendre les diff érences, avantages et inconvénients de chaques SDLC

3. Evaluer les besoins de l’organisation

4. Appliquer les critères liés à notre contexte

4.6 Les rôles

4.6.1 Fully invloved

Project manager

Doit gérer les équipes de spécialistes, orchestrer et gérer le plan de projet, assigner les ressources. Ilest le point d’entrée pour toutes communication.

développeurs

Leurs but est de créer de la valeur business par le biai de l’implémentation de fonctionnalité, ilsdoivent réspecter les délais et sont intriséquement résponsables de la qualité du développement.

24




4.6.2 Partly involved

Analyst team: business analyst, system analyst, infrastructure analyst, change management ana-lystLe rôle des analystes est de faire le lien entre le business et l’IS.Architect team: System designand specication

4.7 Conclusion

25



Chapter 5

Phase 3 - Méthodologies

5.1 Agile

5.1.1 Les 4 valeurs1. Individus et intéractions plutôt que processus et outils

2. Logiciel fonctionnel plutôt que documentation

3. Collaboration client plutôt que négociation contractuelle

4. Réponse au changement plutôt que suivi d’un plan

5.1.2 Manifesto - Les 12 principes

1. Satisfaire le client en lui montrant des releases fréquemment

2. Accueillir les changements de requirements, même tard dans le développement.

3. Délivrer un logiciel fonctionnel souvent.

4. Collaborer entre Développeur et Business people

5. Construire des projets avec des gens motivés en leur donnant un environnement et conance.

6. La méthode de communication la plus efficace est face à face.

7. Une logiciel fonctionnel est la première métrique de succès.

8. Agile promeut un développement durable entre client, développeur et utilisateurs.9. Une attention continue à l’excellence technique et le bon design mène à l’agilité.

10. Simplicité

11. La meilleure architecture, requirements, design, emergent d’équipe s’auto-organisant

12. A interval réguilier, l’équipe discute de comment devenir plus éfficace et s’ajuste.

5.1.3 Pratiques fondamentales

Product Backlog

Catalogue des requirements avec iteration set et iterations

26




Iterations

set de fonctionnalités “DONE”, 2-4 semaines, time-boxed

Iteration Set

Set de fonctionnalités corrélées, 2-6 mois.

PSPI

Potentially Shippable Product Increment. A chaque n d’itération, le product owner recoit unélément logiciel fonctionnel qu’il peut évaluer.

Equipe

L’équipe est hétérogène et ne contient pas de spécialiste. Elle travaille en tant qu’entité. de 2 à 7personnes. Un scrum master qui coach, protège et s’assure que les principes agiles sont respectés. UnProduct owner qui fait le lien client, dév, maximise la ROI et représente les intérêts des utilisateurs.

Auto-organisation

L’équipe est auto-organisée. Ceci fonctionne grâce au paradigme control-inspect.

User stories

Brève description des fonctionnalités vues par un utilisateur ou client. As a <type of user>, Iwant <capability> so that <business value>La taille des user stories est dénie par l’équipe dedéveloppement. Souvent on utilise le poker planning.

DONE

Daily meeting

Une équipe agile se voit et discute quotidiennement des itérations, adaptation du product backlogen fonction des feedback etc.

27




5.1.4 Méthodes les plus utilisées

Scrum et Extreme programming

5.1.5 Logiciel fonctionnel

5.2 RUP - Rationnal Unied Process

Processus itératif pour la conception de logiciel. RUP est basé sur UML.

5.2.1 Motivation

La motivation de RUP est de résoudre les problèmes selon l’approche: Reconnaitre les symptômes,identier la cause, traiter la cause.

5.2.2 Best practices

Un set de principes, méthodes et processus, documentés et organisés pour faire accroite la qualité etla productivité d’un développement logiciel.

28




5.2.3 Process

Une approche systèmique pour la création d’un produit ou pour l’accomplissement d’une tâche. Ilfournit une guideline, réduit les risques et accroit la prédictabilité. Promeut une vision commune et

une culture. Capture et fait l’institution des best practices.Un process dénit Qui fait Quoi, Quand et Comment pour atteidre un objectif.

5.2.4 Les phases de RUP

Inception Dénition du scope

Elaboration Pland de projet, dénition des features, architecture

Construction Développement de la solution

Transition Transition du produit vers la communauté d’utilisateurs

29




5.2.5 Délivrables

Un élément de travail tangible et vériable. Chaque phase doit fournir au moins un délivrable.

5.2.6 Milestone

Une milestone est un événement important ou un résultat qui fournit l’évidence qu’un délivrable aété completé et que la phase (ou sous-phase) est complète.

5.2.7 Concepts clés

WorkerRole pouvant être joué par un individu ou une équipe de développement. e.g. designer, Use-CaseSpecier, etc. Les workers font des activité et produises des artifacts.

Activity

Une unité de travail qui peut être assignée à un worker. Dure de quelques heures à quelques jours.Les activités sont décomposées en étapes et peuvent être répétées dans chaque itérations si nécéssaire.e.g. Find Actors, Find Use Case, Develop a survey of the use-case model, etc.

30




Artifact

Une information qui peut être produite, modiée ou utilisée par un process. Elle appartient a unworker. e.g. Model, source code, executable, etc. Un artifact peut contenir d’autres artifacts

5.2.8 Résumé

31



Chapter 6

Phase 4 - Gestion du changement

6.1 Changement

C’est la transformation d’une organisation pour qu’elle s’aligne avec l’exéution d’une stratégie métierchoisie.

6.2 Gestion du changement

C’est la gestion de l’humain dans un projet de changement.

6.3 La nature du changement

La perception du chanagement est diff érente pour chaque individu, elle peut être bonne ou mauvaise.

Le changement est un processus, est emotionnel, a un impact.

32




6.4 Plan de gestion du changement

6.4.1 Impact sur les di ff érents secteurs

Il y aura des impacts sur les gens, technologies, structure, tâches.

6.4.2 Réaction au changement

peut représenter une n, un abandon, être stressant, être plus facile pour ceux qui initie le change-ment, fourni une base de résistances et de conit, change les “rules for success”.

6.4.3 Le plan

Evaluation (Assess)

Tout le monde doit vouloir le changement, y être préparé, avoir l’habilité de l’eff éctuer.

33




Développement d’une stratégie

Il y a 4 stratégies, il faut en choisir une.

Implémentation

Etudier la progression du changement et écouter les communications. Rumeurs, media, non-dits,cercle vertueux de la communication

Evaluation

Documenter dans le but de créer de nouvelles best practices.

6.4.4 Les stratégies

Rationnelle - Empirique

Basé sur l’individu

Normative - Rééducation

Basé sur le groupe

Pouvoir - Coercitif

Basé sur le leader

34




Environnemental - Adaptative

Basé sur la structure

6.4.5 ImplémentationL’implémentation du projet se concentre sur l’installation et la livraision des délivrables majeurs -Le SI qui a été construit ou acheté.

Direct Cutover

35




Parallel

Phased

36



Chapter 7

Phase 4 - Implémentation, Clôture

7.1 Terminologie

7.1.1 NormalSi tout s’est passé comme prévu

7.1.2 Challenged

Prématurée

La date de n est plus tôt que prévu, même si le projet est incomplet

Retardé

La date de n est plus tard que prévue (avec ou sans extension du budget)7.1.3 Raté

Pas satisfaisant

Impossibilité technologique, cout de complétion dépassé, deadline dépassée.

Changement de priorité

Contraintes liées aux ressources, valeur mal évaluée, changement des besoins, starvation

7.1.4 Perpetuelfuite, jamais de n.

7.2 La réalité

Les équipes sont occupées avec des travaux futurs, Les délivrables ont encore des bugs, la documen-tation devient importante. La gestion de perojet à promis une date de livraison qui n’est pas aurendez-vous, il n’y a plus de ressources, de nouveaux projets viennent.

37




7.3 Acceptance du sponsor

Dépend si le sponsor est averti ou à une vision à court terme. En général les clôture se passent mieuxsi les critères d’acceptances sont clairement dénis dans les stages initiaux du projet (MOV, Scope),

la completion des tous les délivrables et milestones sont documentés, pas facile à accomplir en IT,Agile est la pour ça.

7.4 Point de vue

du point de vue administratif, la clotûre vient nouer les parties non nouées. Du point de vuepsychologique, cela fournit aux parties prenantes un ressenti comme quoi le projet a été sous contrôledu début à la n.

7.5 Clôture administrative

7.5.1 Rapport nal

Contient un résumé, une comparaison des ressources planniée et utilisée, les problèmes, lise de ladocumentation

7.5.2 Meeting nal

Communique que le projet est terminé, transfert le SI du team à l’organisation, reconnaissances,signatures formelles

7.5.3 Check-list

38



Chapter 8

Phase 5 -Evaluation

8.1 Motivation

Le but de l’évaluation est de acquérir des connaissances pour faire mieux dans les prochains projetset de donner des récompenses aux équipes et/ou aux individus.

8.2 Evaluation

8.2.1 Niveau projet

Revue interne

Entre le project manager et le team du projet. L’objectif est de passer en revue les performancesglobales du team, revoir chaque délivrable. Avoir un feedback de comment a fonctionné le team

(post-mortem review)Revue Externe

Faite par un auditeur externe

8.2.2 Niveau individuel

Auto-évaluation de chacun, évaluation individuelles

8.2.3 Niveau Résultat

Est-ce que le MOV est atteint? Client satisfait? Travail responsable? Qu’est-ce qui était bien pouratteidre le MOV, que faire de mieux la prochaine fois?

Vevey, January 23, 2016

39




Frédéric Montet

Management de projet IT

Documents

Transcript of Management de projet IT