Gestion de projets

de système d’information

Saïd GOURRAM gourram@yahoo.fr

1
 Votre professeur…
Titre: Consultant, expert international en TIC,
Professeur worldwide - DG - POLYSOURCING
Distinctions & expérience:
Ancien enseignant et membre du comité pédagogique à l’Université
de Lille.
En délocalisé: Sunderland – UK, Laval – Canada, Supinfo, Skema
Lille, INSA Lyon, Université de Rennes, Toulouse, Clermont-
Ferrand, Bordeaux, Orléans, Grenoble, Bourgogne, Caen.
12 ans(Directeur Hors Classe- DSI / Banque Commerciale
Internationale)
Correspondant de CNEJITA – Fr au Maroc
Membre silver d’ISACA - US
Saïd GOURRAM
Conférencier: SIIE / IEEE best paper #5 - MICAD – Université
Numérique Régionale - 3ème congrès international de lutte contre la
cybercriminalité – Forum SI RH
Formateur certifié / qualifié & certifié ITIL
Formation: Docteur en Informatique – Université de Lille
E- mail: gourram@yahoo.fr

2
 Cadre de travail : DSCG5

Partie 1 - Gouvernance des systèmes d'information :

• Relation entre informatique et système d'information
• Structure du système d'information
• Structuration du système d'information
• Architecture technique
• L'audit des systèmes d'information
Partie 2 - Gestion des projets en système d'information :
• Conduite et gestion d'un projet,
• Implantation du système d'information
• Gestion d'un SI d'une organisation
Partie 3 - Outils et méthodes informatiques :
• Progiciels de gestion intégrés,
• Gestion de la performance informatique,
• Sécurité des SI
• l'auditeur en environnement informatique

3
 Objectifs
➢ Ce cours présente et analyse les différentes étapes liées au
management de projets des systèmes d'information en traitant
également des enjeux et des risques d'un projet, il vise :

✓ Gestion des engagements des acteurs et relation Maîtrise

d'ouvrage-maîtrise d'œuvre
✓ Choix de l'organisation adaptée aux projets SI (méthodes)
✓ Evaluation des charges, des délais et des coûts de réalisation.
✓ Elaboration du planning.
✓ Maîtrise des risques.

4
 Activités pédagogiques et évaluation
➢ Présentations magistrales
➢ Lectures
➢ Travaux en groupe, avec exposés
➢ QCM - Examen
➢ Rendu

# Évaluation % remarques
1 Participation en classe 10
2 Travaux : Projet Rendus 30 1 jour retard=-1

3 QCM - Examen 60

5
 Bibliographie & support
➢ SUPPORT
✓ Cours et exemples d’illustration
✓ Des mini-cas

➢ ORIENTATIONS BIBLIOGRAPHIQUES
✓ A. Burlaud, Ph. Germak, JP Marca (2010), DSCG 5 : Management des systèmes
d'information - Manuel et applications, Sup'Foucher Collection : LMD collection
✓ M. et P. Gillet (2008), Management des systèmes d'information - DSCG 5 - Manuel et
applications, Dunod.
✓ Morley, C.(2006), Management d’un projet système d’information : principes, techniques,
mise en œuvre et outils, 5ème édition des éditions Dunod, Paris, 430 pages
✓ Reix, R.(2002), Systèmes d’information et management des organisations, 4ème édition
des éditions Vuibert, Paris, 439 pages
✓ O’Brien, J.A. (2001), Introduction aux systèmes d’information: un outil essentiel pour
l’entreprise branchée, Éditions de Chenelière /McGraw – Hill, Montréal, 561 pages.
✓ Kalika, M., Lehu, M., Isaac, H., Beyou, C. et Josserand, E.(2002), Le e – management:
quelles transformations pour l’entreprise? L’impact des TIC sur la performance, la
stratégie et les compétences. Les Éditions Liaisons, Paris, 191 pages.
✓ Laudon, K. et Laudon, J. (2006), Management Information Systems, 9th édition, Pearson
Education.
✓ Lequeux, J-L.Manager avec les ERP, Editions d’organisations, 2ème édition.

6
 Introduction
(compléments en Freemind)

Freemind à installer à partir de :

http://freemind.sourceforge.net/wiki/index.php/Download

7
Le management de projet SI Comptable

a été élaboré en séance et envoyé

8
 Projet et Opération
➢ Pour atteindre un objectif:
▪ projet
▪ opérations
▪ ou les deux
➢ Caractéristiques communes des opérations et des projets:
▪ Ils sont réalisés par des personnes.
▪ Ils subissent les contraintes de ressources limitées.
▪ Ils sont planifiés, exécutés et maîtrisés.
➢ Les différences :
▪ les opérations sont continues et répétitives,
▪ alors que les projets sont temporaires et uniques.

▪ l'objectif d'un projet est d'atteindre son objectif et par là même de se

terminer.
▪ l'objectif d'une opération continue est de soutenir l'activité de
l'entreprise.
9
 Qu'est-ce que le management de projet ?
➢ Application de connaissances, de compétences, d'outils et de
techniques aux activités du projet afin d'en respecter les exigences.
➢ Intégration des processus de management de projet groupés en :
démarrage, planification, exécution, surveillance et maîtrise, et clôture.

Le chef de projet est la personne responsable de l’atteinte des objectifs du projet.

➢ Le management de projet comprend les points suivants :

▪ déterminer les exigences,
▪ définir des objectifs clairs et réalisables,
▪ équilibrer les exigences concurrentes de qualité, de contenu, de
délai et de coût,
▪ adapter les spécifications, les plans et l'approche aux différentes
préoccupations et attentes des diverses parties prenantes.
La qualité du projet dépend du bon équilibre entre : contenu du projet, délai et coût
➢ Gestion du projet : approche structurelle
10
 Infrastructure
Les activités d’un PMO Change
PMO
Design Build Test Roll-out

12. 2. Gère le
Communication périmètre

11. Coordination
du changement
Rapporte Suivi du 3. Gère les
l’état périmètre risques
d’avancement

10. Coordination Identifie les

avec Architecture risques

1. Programme 4. Gestion
Follow-up sur financière et
base de critères tracking &
Fournit les business case
de qualité reporting
données pour les
budgets et calcul
9. Quality
des coûts
management
Suivi de
Planning définit le l’allocation des
contenu des ressources 5. Gestion des
releases ressources
8. Gestion des
contrats

7. Coordination 6. Gestion des

avec les achats releases

11
 Infrastructure

Les processus gérés par le PMO Change

PMO
Design Build Test Roll-out

Processus de Besoins
Program management
Gestion du budget Monitoring du taux d’activité sur base du planning et du plan de staffing

Change control Contrôle strict sur les augmentations, réductions de périmètre, avec évaluation par rapport au
business case, au planning et aux coûts.
Ces points doivent être escalés au Comité de Pilotage
Délivrables/milestones/ Un mécanisme de tracking doit être suivi par tous les project managers
Dependency management
Problèmes Une des priorités des project managers est de résoudre les problèmes

Réunions de projets Les réunions sont focalisées sur l’état d’avancement (par rapport au budget, au planning, aux
délivrables), les problèmes et le change control
Qualité Des revues de qualité sont organisées afin de vérifier que le projet est géré selon de bonnes
règles de gestion de projet
Gestion des ressources Besoin d’anticiper les besoins en ressources et allocation au bon moment aux différents sous
projets
Risques Les risques doivent être bien documentés et escalés systématiquement au comité de pilotage

Suivi du temps passé Tout membre du projet doit rapporter son temps avec un niveau de détail suffisant que pour
assurer un bon contôle financier du projet

Gestion du planning Utilisation d’un outil de planning commun pour tous les sous projets. Les planning sont gérés
par chaque sous projet.
Tous les plannings alimentent un programme commun utilisé pour le suivi budgétaire

12
Processus de gestion de projet selon PMBOK

Initialisation :
– définir le domaine du projet
– les objectifs à atteindre Initialisation Planification
– l’engagement des parties
prenantes

Planification :
– découper le travail
– définir le plan de projet Exécution
Contrôle
Exécution :
– coordonner les ressources
– suivre le plan du projet
– Reporting
Clôture
Contrôle :
– surveiller / monitorer Clôture :
– mesurer – révision formelle
– définir les actions – décision formelle
correctives – documentation
13
PMBOK – Vue globale

14
Processus de management d’un projet

15
Interaction des groupes de processus dans un projet:

16
 Cycle de vie de logiciel en cascade
Proposé par Royce au début des années 70.
✓ Dans ce modèle, chaque phase se termine à une
date précise par la production de certains documents
ou logiciels.
✓ on ne passe à la phase suivante que si les résultats
de l’étape précédente sont jugés satisfaisants
✓ D'autres activités interviennent, par exemple le
contrôle technique et la gestion de la configuration
Spécification sont présents tout au long du processus.
Analye des besoins

Conception préliminaire
Risques élevés et non contrôlés:
• Identification tardive des problèmes
Conception détaillée
• Preuve tardive de bon fonctionnement
Codage

Intégration

maintenance

17
 Cycle en V dans le développement d’un SI

Branche conception Branche réalisation

Etude Plan de tests en service Mise en
d’opportunité charge
Spécifications
de domaine

Plan de tests de recette Validation

Spécification Dossiers de
Spécifications validation
Conceptuelles
Plan de tests
Conception d ’intégration Intégration
générale
Spécifications Plan de
Logiques tests
Conception unitaires Tests Difficultés :
détaillée unitaires • hypothèses difficiles à
Spécications respecter
Techniques • difficulté à prendre en
de Réalisation compte des évolutions du
Codage cahier des charges
des • visibilité tardive des résultats
• peu ou pas de maquettage
modules
et/ou de prototypage
18
 Logiciel et Génie logiciel
Evaluer les alternatives;
Déterminer Identifier et résoudre les
Les objectifs, Analye risques
Les alternatives Des risques
et les contraintes
Analye
Des risques
Analye
Des risques
Analye Prototype
des risques Prot Protopérationnel
Revue 2
prototype1 3
Planification
Simulation, modèles et
Des besoins etConcept Tests de performance
Du cycle de vieDe l’opération
Conception
Plan de détaillée
Validation
développementDes besoins code
Plan de test et Test
D’intégration Test unitaire
Test D’intégration
Mise en Développer
D’acceptation
Planification de la service
Et vérifier le produit
Prochaine phase De prochain niveau

19
 • Fixation et suivi de la stratégie et des plans à long
terme

Mois Comité IT • Décisions clés sur les gros programmes et les

projets transversaux

• Sponsorship & propriété des projets/programmes

Sponsor • Suivi de l’état d’avancement du projet et prise de
décision en matière de délivrables, périmètres,
Comité de problèmes, ressources, etc…
Mois
pilotage (*)
• Responsable pour la livraison du programme

Hebdo & Program • Rapporte l’état d’avancement au comité de

journalier pilotage
Manager
• Gère les interdépendances entre projets
Coordination
architecture PMO
Architecture
• Définit les processus et outils nécessaires pour la
Support gestion du programme et des projets
Journalier
fonctionnel et Hebdomadaire
• Aide/accompagne le program manager et les
technique project managers
• Assure la coordination et communication
transversale
• Responsable pour le planning et la livraison des
Project Manager Project Manager Project Manager projets
Journalier
• Rapporte le statut des délivrables, le planning, les
risques et problèmes au program manager

20
 Comité de Pilotage
➢ Donneur d’ordre du projet, décision finale sur la solution proposée par la
direction du projet
➢ Éclaire le chef de projet sur l’impact des décisions associées au projet.
➢ Valide les jalons
➢ Spécifie les priorités
➢ Soutient les décisions du chef de projet
➢ Valide les recettes
➢ Valide la solution proposée au niveau budgétaire et stratégique

21
Le rôle des membres du comité de pilotage
➢ Rôle
✓ Gardien de la vision et des objectifs du projet
✓ Gère la communication sur le projet vis-à-vis de tiers
✓ Suit le planning et les délivrables, pas les processus
➢ Responsabilités
✓ Règle les problèmes organisationnels et de ressources
✓ Gère l’allocation des ressources et les dépendances entre projets
✓ Est responsable de la communication au sein et en-dehors du projet
✓ Valide les délivrables
✓ Gère le périmètre et mitige les risques
➢ Fréquence de réunion : 1x/mois

22
 Le rôle du program manager
➢ Rôle
✓ Gardien du planning du projet
✓ Assure la gestion du projet au jour le jour
✓ Gère le statut du projet
✓ Escale à temps et de manière appropriée les problèmes au comité
de pilotage
➢ Responsabilités
✓ Coordonne les parties et s’assure de la réalisation du projet à temps
✓ Gère, planifie les ressources
✓ Gère les aspects financiers du projet
✓ Adhère aux best practices, méthodologies et outils de
développement
✓ Gère le périmètre et les risques

23
 Besoins
Un besoin est toute expression sur le comportement du système dans
l’environnement organisationnel de son fonctionnement, tels que:
- Une exigence usager
- Une contrainte fonctionnelle
- Une contrainte non fonctionnelle
- Un but organisationnel

Typologie des besoins

- Besoins fonctionnels : ce que le système doit faire
- Besoins non fonctionnels : sous quel contrainte le système doit le faire
Exprimer Quoi?
➢ Les objectifs, stratégie d’évolution à atteindre en utilisant le nouveau
système
➢ Les problèmes métier issus d’utilisation du système actuel (démarche,
performance, outils de supports, …)
➢ Les attentes de la part du nouveau système et les besoins en terme de
solutions

24
 Expression et cahier des charges
➢ Expression des besoins
✓ Elle est du ressort du MOA, elle suit les étapes suivantes:
▪ Recueil des besoins auprès des utilisateurs
▪ Établissement et choix d’un objectif global
▪ Mise en forme des besoins, afin qu’ils soient suffisamment précis
et compréhensibles par le maître d’œuvre.
✓ Les besoins sont exprimés dans un cahier des charges.

➢ Cahier des charges

✓ Fixe les obligations réciproques du MOA et du MOE, il est un
recueil de caractéristiques que présentent un produit en cours
d’étude ou de réalisation. À partir d’un cahier de charges, un
MOA doit pouvoir s’engager sur un budget, un délai et un
contenu.
✓ Le cahier des charges est établi à la fin de l’étude préalable.
25
 Rédaction du cahier des charges
➢ Description générale du futur SI
✓ Objectif du futur SI
✓ Frontières du domaine d’étude avec d’autres domaines
✓ Collaboration avec d’autres domaines
✓ Décomposition en sous-domaines
✓ Les décideurs du SI
✓ Les principes de reconfiguration du SI
➢ Description détaillée du futur SI, pour chaque sous-systèmes identifié:
✓ Les fonctionnalités, service du système (ex. utilisation use case)
✓ Qualification de chaque fonctionnalité (métier, support, pilotage)
✓ Description de chaque fonctionnalité (use case, scénarios, diagrammes de séquence,
diagramme d’activité)
✓ La structure statique sous forme d’un diagramme de classe, description de chaque attribut.
✓ Le cycle de vie (stats charts) de chaque entité de gestion
➢ Description des interfaces homme-machine
✓ Maquettes papier
✓ Formulaire, menus
✓ Graphisme
✓ Liens de navigation
✓ Prototype réalisé à l’aide d’un outil

27
 ERP, Pourquoi et comment?
➢ Pourquoi ?
➢ Economie par rapport à une solution spécifique
➢ Limiter la redondance des informations et leur gestion
➢ Généraliser les mises à jour en temps réel
➢ Attente d’une couverture fonctionnelle importante et cohérente.
➢ Comment
➢ Big bang : rejet des anciens Si et mise en place d’un nouvel ERP
avec implantation de tous les modules en une fois (un seul « go
live »)
➢ Franchising strategy : modulaire, plusieurs « go live », concerne
des grandes entreprises ayant des unité économique
indépendantes
➢ Slam Dunk (manga japonais): pour les petites entreprises,
implantation des modules « vanille » i.e. peu de personnalisation et
souvent utilisations des modules pré-paramétrisés

29
 Phases du Projet
ASAP: Accelered SAP

Préparation Préparation
du projet Modèle métier Réalisation finale Opérationnel

1 2 3 4 5
Autorisations
à définir Processus Métier Évaluation de
Liste Principale La Performance
Reports
Du Système
à écrire
Conversions x
Livrables

x
Plan à faire x x
x
Project Interfaces x x Processus Reports Plan test
x
Scope identifiées x procédures écrits
x Matériel test
métier
Processus métier Interfaces
Baseline Cas de test Plan
identifiés établies
Scope opérationnel
Structure org. Matériel de
Conversion
définie Formation
faite
Des
Système utilisateurs
de travail

30
 Les 3 instances décisionnelles

Structure de décision Fréquence Participants

► Équipe de Direction MOA

Comité de pilotage Tous les mois ► Direction de projet MOA
► Direction de projet MOE

► Direction de projet MOA

Hebdomadaire
Comité de projet ► Responsable de mission MOE
(jeudi matin)
► Responsables de domaine

Groupe de En fonction des Utilisateurs clés/

Groupe de Groupe de ►
Travail besoins Responsables de
Travail Travail
Achats domaine MOA
Finance Technique
Vente
► Consultants MOE

Valide Informe

31
 Infrastructure
La conduite du changement Change
PMO
➢ Les facteurs d’échec : Design Build Test Roll-out

✓ Un manque de communication ou une communication inappropriée

✓ Un manque d’implication du client dans le projet. Le projet est réalisé par l’IT ou par
une partie externe
✓ Manque de support du management pour l’utilisation du système
✓ Mismatch au niveau des attentes utilisateurs
✓ L’organisation n’est pas prête/revue pour la mise en production de l’application
✓ Les rôles, les compétences des utilisateurs ne sont pas adaptés à la nouvelle
manière de fonctionner
✓ Manque de prise de conscience des avantages du nouveau système
✓ Trop peu de formations ou des formations inappropriées

32
 La conduite du changement – d’une attitude négative

Infrastructure
Change
PMO
Design Build Test Roll-out

Efforts pour
Acceptation du
regagner le Bargaining
Actif

changement, réalisme
contrôle de la Minimise l’impact
situation du changement

Rejet réaction
défensive face à
Test, essaye de
Immobilisation une situation
nouvelles choses
crainte, inacceptable
confusion
Dépression frustration, sentiment d’échec
Temps
Source: Kuebler-Ross, 1969: Conner, 1992

Changement négatif Changement positif

33
 Infrastructure
Change
PMO
Design Build Test Roll-out

La conduite du changement – à une attitude

positive
Niveau d’acceptation du changement

“ Comment puis-je convaincre

Propriété/Buy in
d’autres de changer ? ”

Acceptation “Comment cela impacte-t-il mon

travail journalier ?”
Frontière de l’engagement
Test “Semble bien sur papier, mais nous
changeons tout le temps. Quand puis-je
l’essayer ?”
Compréhension
“Qu’est-ce que cette nouvelle organisation
Prise de conscience
signifie pour moi ?? ”
Contact
“Pourquoi remplace-t-on un bon système ?”
“De quoi s’agit-il ?”
Temps
Résistance Acceptation/Propriété
34
En résumé, la conduite de changement c’est:

Démontrer

Faire
Expliquer
exécuter

Projet SI

Participation Formation

Communication

35
 Les méthodes Agiles
➢ Cycle itératif et incrémental.
➢ L’Agilité prône la collaboration entre les personnes et l’intégration
des équipes.
➢ Les méthodes Agiles mettent l’accent sur l’importance de
développer le bon produit.
➢ 4 principes fondamentaux :
✓ priorité aux personnes et aux interactions,
✓ priorité au développement des fonctions,
✓ priorité à la collaboration avec le client,
✓ accueil et adaptation au changement.

36
 Manifeste Agile : 12 principes
1. Notre plus haute priorité est de satisfaire le client en livrant rapidement
et régulièrement des fonctionnalités à grande valeur ajoutée.
2. Accueillez positivement les changements de besoins, même tard dans le
projet. Les processus agiles exploitent le changement pour donner un
avantage compétitif au client.
3. Livrez fréquemment un logiciel opérationnel avec des cycles de
quelques semaines à quelques mois et une préférence pour les plus
courts.
4. Les utilisateurs ou leurs représentants et les développeurs doivent
travailler ensemble quotidiennement tout au long du projet.
5. Réalisez les projets avec des personnes motivées. Fournissez-leur
l’environnement et le soutien dont elles ont besoin et faites-leur
confiance pour atteindre les objectifs fixés.
6. La méthode la plus simple et la plus efficace pour transmettre de
l’information à l'équipe de développement et à l’intérieur de celle-ci est le
dialogue en face à face.

37
 Manifeste Agile : 12 principes

7. Un logiciel opérationnel est la principale mesure d’avancement.

8. Les processus agiles encouragent un rythme de
développement soutenable. Ensemble, les commanditaires, les
développeurs et les utilisateurs devraient être capables de
maintenir indéfiniment un rythme constant.
9. Une attention continue conduit à l'excellence technique et à
une bonne conception renforce l’agilité.
10.La simplicité – c’est-à-dire l’art de minimiser la quantité de
travail inutile – est essentielle.
11.Les meilleures architectures, spécifications et conceptions
émergent d'équipes auto-organisées.
12.À intervalles réguliers, l'équipe réfléchit aux moyens de devenir
plus efficace, puis règle et modifie son comportement en
conséquence.

38
User Stories

10 mn

39
 Scrum framework

Roles
•Product owner
•ScrumMaster
•Team Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts
40
SCRUM framework

Grooming : Entretien du backlog

41
 3 rôles
1. Le Directeur de produit,
2. Le ScrumMaster,
3. L'Équipe.

42
 Scrum utilise une planification à trois niveaux :
release/projet, sprint, et quotidien.

Pré-jeu
▪ Planning
✓ Définition du backlog, des jalons, de
l'équipe
✓ Identification des facteurs de risques
✓ Choix des outils & infrastructure +
logistique
✓ Budget, chiffrage & estimation du coût
▪ Architecture générale, conception générale
Jeu
▪ Sprints
✓ Développement (analyse, conception,
codage) > livraison > révision > adaptation
(~ Plan/Do/Check/Act)
Post-jeu
▪ Packaging global de la version
▪ Intégration & jeux de tests
▪ Documentation & manuels utilisateur
globaux, accompagnement au changement
43
44
45