Livre blanc - ITIL et Prince2 v2

COMMENT PRINCE2 ET ITIL COHABITENT-ILS ?
Par Romain Hennion de Thyses
Directeur Gouvernance et Organisation, Global Knowledge France
• ITIL V3 Expert, ITIL V2 Service Manager. ATP par l’Exin.
• Prince2 Practitioner, Formateur accrédité et certifié par l’APMG
• Professeur titulaire au Cnam et à l’Edhec Business School
Global Knowledge France • T é l é p h o n e : 0 1 7 8 1 5 3 4 0 0 • C o n t a c t @ g l o b a l k n o w l e d g e . f r
Est-il possible de gérer les changements d'ITIL sous forme de projets Prince2 ?
ITIL est un référentiel de gestion de service informatique, largement répandu. Ainsi, toutes les entreprises du CAC 40
l'ont d'ores et déjà adopté. Prince2 est une méthode de gestion de projet, très utilisée outre-Manche, et qui commence
à conquérir l'hexagone.
ITIL et Prince2 appartiennent à l'OGC, l'Office of Government of Commerce. Mais au-delà de ce point commun,
comment ITIL et Prince2 cohabitent-ils pour apporter davantage de valeur ?
Introduction
Les systèmes d'information s'appuient massivement sur les référentiels de gestion des services, comme ITIL, et de
gestion de projets, tel Prince2 (PRoject IN Controlled Environment). Certes, les méthodes de gestion de projets ne
datent pas d'aujourd'hui et n'ont pas été conçues spécifiquement pour les systèmes d'information. Les premières méthodes remontent aux années 50 et les diagrammes de Gantt datent du début du siècle précédent.
En revanche, notons que les méthodes de gestion des services sont beaucoup plus récentes. Ainsi, ITIL V2 ne date que
de 2001. La norme associée ISO 20000 a vu le jour en 2005 - celle-ci s'appuyant sur la BS 15000 -. Et ITIL V3 date de
2007 seulement, soit bien après l'émergence des premiers systèmes d'information.
ITIL et Prince 2 reposent chacun sur des processus spécifiques. Ceux-ci doivent pourtant cohabiter pour s'appliquer
de concert à des objectifs communs et à une infrastructure informatique unique. De nombreuses questions pratiques
se posent lorsqu'il s'agit s'appliquer conjointement les deux référentiels. La théorie y répond difficilement. Et il faut
avouer qu'ITIL et Prince2 font assez peu référence l'un à l'autre. Enfin, des aspects relatifs à l'organisation et aux outils mis en oeuvre impliquent une meilleure compréhension de la convergence entre les deux référentiels.
Le premier point sur lequel nous allons nous pencher est l'interaction forte entre la gestion des changements (processus d'ITIL) et la gestion de projets (Prince2). Appliquée au monde des systèmes d'information, la gestion de projets
favorise une évolution et une transformation maîtrisée de l'infrastructure et des applications. Ce qui correspond à la
définition d'une des caractéristiques d'un projet selon Prince2 : « un projet est le moyen par lequel nous introduisons
un changement » (p. 3). Quant à la gestion des services selon ITIL, elle favorise une fourniture efficace et efficiente des
services, tels que convenu avec le métier.
A priori, les objectifs d'ITIL et de Prince2 sont convergents. Mais en y regardant de plus près, nous pourrions penser
qu'ils se chevauchent inutilement. Or, les services informatiques ne sont pas statiques. Ils évoluent en permanence. Et
ITIL V3 assure que ces évolutions soient bien prises en compte, maîtrisées, et toujours alignées sur les besoins du métier. Les deux processus à même de gérer les évolutions du SI sont la gestion des changements et la gestion des mises
en production. Ceux deux processus conservent une interaction très forte avec la gestion de projets.
Dans certains cas, ITIL et Prince2 n'ont pas besoin de cohabiter, notamment pour des changements standards ou ceux
dont l'impact est limité.
En revanche, des changements tactiques (notamment au niveau des SLA, les contrats clients-fournisseurs), voire stratégiques (avec un impact significatif sur le métier), impliquent plusieurs mises en production et des évolutions successives de versions. Dans ce cas, il est fortement conseillé de concilier le processus de gestion des changements avec une
méthode de gestion de projets, comme Prince2.
Dès lors, une gestion fine du périmètre et de la planification s'imposent : quand un changement doit-il être géré
comme un projet ? Est-ce qu'une mise en production doit être gérée comme un projet ? Quand et comment un projet
doit-il se traduire en changements et mises en production ? Le cas échéant, quelles sont les responsabilités et les activités du projet et de la gestion du changement ?
Voilà autant de questions auxquelles nous apporterons des réponses, en nous appuyant sur des retours d'expérience.
Global Knowledge France • T é l é p h o n e : 0 1 7 8 1 5 3 4 0 0 • C o n t a c t @ g l o b a l k n o w l e d g e . f r
Qu’est-ce que Prince2 ?
Une méthode de gestion de projets
PRINCE2 est une méthodologie globale de management qui se focalise sur les aspects « management » des projets.
PRINCE2 a été lancé en 1996 par le CCTA. Depuis plusieurs versions ont été produites. La dernière a été publiée en
juin 2009.
Créé en 1975, et baptisé à l'origine PROMPT, le référentiel de gestion de projet fut d'abord adopté par le Central
Computer and Telecommunications Agency (CCTA), devenu par la suite l'Office of Government Commerce, qui est
également à l'origine d'ITIL. Prince2 fut rapidement érigé comme standard pour la gestion des projets liés aux systèmes d'information. Il a ensuite été régulièrement et enrichi et revu, jusqu'à sa récente version 2009.
Prince2 est une méthode que l'on peut appliquer et dupliquer. Il vient du terrain. Il s'applique à de nombreux contextes, aussi pour pour la création de nouveaux produits ou services, que pour l'implémentation d'un changement dans
un environnement donné. Prince2 est donc suffisamment souple pour s'adapter à tous les domaines autres que les
systèmes d'information.
Prince2 s'appuie sur un principe très simple : le product-based approach. Cela signifie que l'accent est mis sur la production de livrables tout au long du cycle de vie des projets, et non sur les activités nécessaires à la production des
produits ou services.
PRINCE2 est désormais une marque déposée du Ministère du Commerce (OGC) au Royaume-Uni et dans les autres
pays. L'APM Group (APMG) a été autorisé à organiser la certification des organisations, entreprises et personnes travaillant en relation avec des projets, programmes ou risques sur la base de méthodes développées par le gouvernement
britannique. Cette certification est supervisée par le siège social de la Compagnie au Royaume-Uni, tandis que les activités opérationnelles sont gérées par des bureaux auxiliaires de l’APMG.
Qu’est-ce qu’un projet ?
Un projet est un ensemble d'activités liées entre elles au sein d’une organisation provisoire, destiné à fournir, selon des
conditions définies, un ou plusieurs produits ou services prédéfinis.
Dans le contexte de la méthodologie PRINCE2, un projet est défini comme : une organisation temporaire, créée en vue
de livrer un ou plusieurs produits d'entreprise conformément à un Business Case.
Les projets sont généralement menés dans des circonstances où les conditions normales d’exécution des affaires quotidiennes sont inopérantes. Ceci survient en particulier lorsque le métier et les affaires évoluent et se transforment,
afin de répondre à de nouvelles exigences, survivre ou devenir plus compétitifs.
L'organisation temporaire des projets permet de réunir tous les participants afin de livrer les produits ou les services
attendus. La structuration et les processus proposés par une méthodologie de gestion de projets renforcent la cohésion
et les engagements quant aux produits et services à fournir. Pour cette raison, les projets constituent un moyen significatif d'accompagnement du changement, tant technique que humain et organisationnel.
Global Knowledge France • T é l é p h o n e : 0 1 7 8 1 5 3 4 0 0 • C o n t a c t @ g l o b a l k n o w l e d g e . f r
La structure de Prince2
• Sept Principes – les règles à observer et les bonnes pratiques permettent de déterminer si le projet est véritablement
conduit selon PRINCE2. Un projet n'est pas considéré comme un projet PRINCE2 tant que tous ces principes ne
sont pas appliqués.
• Sept Thèmes — ceux-ci décrivent les aspects de la gestion de projet qui doivent être abordés en permanence et en
parallèle durant tout le projet. Les thèmes expliquent le traitement spécifique exigé par PRINCE2 pour différentes
disciplines de gestion de projet et pourquoi ils sont nécessaires
• Sept Processus — ils décrivent la progression pas à pas tout au long du cycle de vie du projet. Chaque processus
fournit des listes de contrôle des activités, des produits ou des responsabilités associées
• Adaptation de PRINCE2 – ce chapitre traite de la nécessité d'adapter PRINCE2 au contexte particulier du projet à
traiter. Ce contexte dépend de facteurs spécifiques au projet aussi bien que de facteurs environnementaux.
La gestion des changements
et des mises en production d’ITIL v3
La gestion des changements
La gestion des changements garantit que les changements soient enregistrés, évalués, autorisés, priorisés, planifiés,
testés, mis en œuvre, documentés et revus de manière contrôlée.
Un changement est l’ajout, la modification ou la suppression d’un service, ou d’un composant d’un service, autorisé,
planifié, associé à une documentation pertinente.
Le périmètre de la gestion des services comprend les changements de la configuration de référence (baseline) des actifs de services et des CI, au sein d’un cycle de vie des services. Chaque organisation doit elle-même définir les changements couverts par son processus de gestion des changements et ceux qui ne le sont pas. Par exemple, le remplacement d’un disque dur d’un PC ne fait peut-être pas partie du processus de gestion des changements.
La gestion des changements est souvent prise en charge par des personnes ou des équipes dédiées, comme le gestionnaire des changements ou le CAB (Change Advisory Board), ainsi que les propriétaires de services. Des outils et des
solutions informatiques servent également de support.
Global Knowledge France • T é l é p h o n e : 0 1 7 8 1 5 3 4 0 0 • C o n t a c t @ g l o b a l k n o w l e d g e . f r
Dans ITIL V3, des liens entre la Gestion de projets et la Gestion des changements sont clairement établis. Ainsi, le
livre Service Design (Conception des services) indique clairement que l'introduction de nouveaux services ou la modification de services existants doit être gérée sous la forme de projets. Ainsi, la figure suivante (source OGC), extraite
d'ITIL V3 Service Design, indique comment gérer les différentes étapes du cycle de vie d'un nouveau service ou d'un
service existant modifié, au moyen de la gestion des changements. Cette figure met également l'accent sur le développement, le test, la mise en production et le déploiement.
Ainsi, concernant le processus de Gestion des changements, nous pourrions en déduire que :
• les projets affectant les services devraient se soumettre aux procédures de gestion des changements ;
• les projets pourraient s'appuyer sur des changements standards ou des requêtes de services pour des changements
opérationnels simples et pré autorisés ;
• les projets devraient être associés à des procédures spécifiques pour les changements qui n'impactent pas le service
ou la baseline de conception.
La gestion des changements selon ITILv3
La gestion des déploiements et des mises en production
La Gestion des déploiements et des mises en production vise à construire, tester et déployer les services spécifiés dans
la conception de services et à assurer que le client utilise le service de façon efficace. Ce processus met donc en oeuvre
concrètement les changements dans l'environnement de production. La figure suivante (source OGC) illustre les liens
entre les processus de Gestion des changements et de Gestion des déploiements et des mises en production. Ainsi,
une release peut contenir un ou plusieurs changements. Parallèlement, certaines activités de la Gestion des déploiements, comme la conception et l'installation des builds, sont déclenchées et gérées par des changements.
Global Knowledge France • T é l é p h o n e : 0 1 7 8 1 5 3 4 0 0 • C o n t a c t @ g l o b a l k n o w l e d g e . f r
Les liens entre la gestion de projets et ITIL
Comment la Gestion de projet et la Gestion des déploiements et des mises en production sont-elles liées ? Principalement dans le cadre des activités de planification de la Gestion des déploiements et des mises en production. Ainsi,
celles-ci devraient comprendre les activités de déploiements et les ressources nécessaires pour les mener à bien, notamment, dans le cadre des tests. Le modèle en V d'ITIL V3 (figure suivante, extrait d'ITIL V3, source OGC) devrait
influencer la définition de la planification des projets.
Lorsque la gestion des services couvre les activités opérationnelles, le lien avec la gestion de projet n'est pas évident, à
juste titre. La gestion des changements d’ITIL gère parfaitement le quotidien. Mais d'importantes modifications de
services, ou bien des créations de services, sont en jeu, les frontières ne sont plus nettement définies.
Ainsi, une grande question demeure : les changements significatifs et stratégiques doivent-ils être gérés comme des
projets ? L'expérience montre que, dans certains cas, lorsque des changements sont significatifs en termes de taille et
de ressources, il est en fait recommandé de les gérer comme des projets. À elle seule, la gestion des changements n'est
pas appropriée ni suffisante pour garantir la réalisation de tous les résultats escomptés, ainsi que la maîtrise des risques.
Mais quand un changement doit-il être géré comme un projet ? Y a-t-il une taille spécifique du changement, selon laquelle les processus de gestion de projet doivent être activés ? Prince2 apporte-t-il une approche cohérente dans ce
contexte ? Est-il trop complexe ?
La même question se pose à propos des mises en production. Si une mise en production n'est pas associée à un projet
existant, doit-elle être quand même gérée comme un projet ? Cette situation n'est pas décrite par la théorie. Mais dans
la vraie vie, certaines circonstances nous conduisent à nous poser cette question. Encore une fois, il n'est pas évident
de décrire la situation type dans laquelle la gestion de projets doit être activée, ni l'approche la mieux adaptée.
D'autres relations ont été identifiées, mais pas analysées en profondeur. Par exemple, la relation entre la mise en production et la gestion du changement. La gestion des mises en production implique l'installation d'une version spécifique dans différents environnements (test du système, de test d'acceptation, de production, etc.). Cette tâche doit-elle
être gérée par un changement, devrait-il s'agir d'un changement standard ? À nouveau, la théorie ne donne pas de réponse claire.
Une autre question se pose et dont l'impact n'a pas été suffisamment pris en compte. Elle concerne les périmètres et
les objectifs des processus. Alors que la gestion de projet se concentre sur la production de livrables dans des délais
stricts, la gestion des changements et des mises en production met l'accent sur le minimum de perturbations des services informatiques existants.
Les changements et les mises en production doivent-ils s'appuyer sur une structure permanente, ou bien qui dure
seulement le temps d'un projet ? Comment les processus de gestion (en particulier ceux responsables de la fourniture
de produits, par exemple, CS et MP), doivent-ils être associés aux processus de gestion des changements et des mises
en production ? Ces choix peuvent renforcer, ou au contraire, réduire la capacité d'atteindre les objectifs des changements, notamment en termes de qualité et de délais.
Enfin, parlons des outils. Nous disposons maintenant de suffisamment de recul sur les processus de gestion de projets,
des changements et des mises en production, pour leur associer des outils matures et efficaces. Mais généralement, ces
outils ne couvrent pas les deux disciplines à la fois. Certaines questions se posent : quelles sont les principales tâches à
accomplir par chaque outil ? Quelles sont les principales interfaces à mettre en oeuvre ?
Voici quelques-unes des questions auxquelles nous allons tenter de répondre.
Global Knowledge France • T é l é p h o n e : 0 1 7 8 1 5 3 4 0 0 • C o n t a c t @ g l o b a l k n o w l e d g e . f r
Les liens entre la gestion de projets, des changements et des mises en production
Une gestion par paliers
Certains changements peuvent être significatifs en terme de risques associés, de coûts et/ou de ressources
nécessaires. Dans ce contexte, le processus de gestion des changements peut se révéler insuffisant pour garantir les
résultats escomptés. Chaque changement étant associé à une transformation, un ajout ou une suppression, il est possible de s'appuyer sur les processus de la gestion de projets.
Une première solution consiste à établir des paliers : par exemple, vous estimez que les changements impliquant plus
de 40 jours/homme doivent être gérés comme des projets. Parallèlement, vous pouvez établir deux types de projets : un
projet light, et un projet standard. Par exemple, le projet light serait appliqué pour des projets impliquant de 40 à 200
jours/homme. Et les projets standards s'appliqueraient pour des projets dont les ressources dépassent 300 jours/
homme. À vous de voir et d'établir les paliers.
Certes, un projet de 40 jours/homme ne permet pas à Prince2 de révéler toute sa pertinence. Toutefois, Prince2 est suffisamment souple pour s'adapter à tous les types de projets. Il ne s'agit pas d'omettre certains aspects de Prince2, mas
d'adapter Prince2 au contexte. Nous vous conseillons alors de vous référer au chapitre 19 Tailoring, de Prince2, et plus
exactement à la section 19.5.1 Simple project (p. 221). Ainsi, pour de simples projets, vous pourrez alléger les procédures
pour établir un business case, qui sera probablement établi par le processus de gestion des changements. En outre,
vous pourrez dérouler le processus Starting up a process de manière informelle et vous pourrez le combiner avec le processus Initiating a process.
Global Knowledge France • T é l é p h o n e : 0 1 7 8 1 5 3 4 0 0 • C o n t a c t @ g l o b a l k n o w l e d g e . f r
Dès lors, une RFC est associée à un projet. À nouveau, rappelons qu'il s'agit souvent de changements associés à des
modifications de services existants ou de conception de nouveaux services. Lors qu'une RFC est associée à un projet,
des tâches peuvent être accomplies simultanément. Ainsi,l'analyse, l'évaluation, la planification, l'autorisation, la mise
en œuvre et la revue sont effectuées en commun. Si le projet reste indépendant de la gestion des changements, les
risques encourus sont élevés. En effet, la gestion de projet va s'assurer que les objectifs soient atteints, notamment en
termes de coûts et de délais. Alors que la gestion des changements s'attachera à la mise en oeuvre du changement en
perturbant au minimum les services en cours.
Un conflit pourrait naître entre la gestion de projets et des changements. Un projet pourrait pousser la mise en production d'un service, et la gestion des changements pourrait bloquer la démarche, faute de communication. Nous insistons donc sur la cohérence entre les deux approches. Cette situation sera détectée notamment lors des tests et de la
livraison des livrables, cette tâche étant sous le contrôle de la gestion des changements.
La gestion de projets devrait superviser l'ensemble de la démarche. Et la gestion des changements s'insère au sein de
la gestion de projets. Celle-ci détermine les changements qui seront mis en oeuvre par la gestion des changements. Par
exemple, le processus de Prince2 Managing a product delivery pourrait être rattaché à la gestion des mises en production d'ITIL. Et le processus Controlling a stage de Prince2 pourrait être associé aux activités d'évaluation et d'autorisation des changements, de la gestion des changements.
Une intégration complète
L'alternative consiste à gérer le changement comme un projet. La gestion des changements est d'un grand intérêt
pour sa spécialisation dans la gestion des services informatiques et son apport administratif (notamment dans des enregistrements et une traçabilité homogènes des changements).
Rappelons que Prince2 s'applique à tous les types de projets, pas uniquement dans le domaine des systèmes d'information. L'autorisation est donnée par la gestion de projet, la gestion des changements assurant l'aspect administratif.
L'implémentation du changement est supervisée par la gestion de projets et est assurée par la gestion des mises en
production. Ainsi, les différents work packages, selon Prince2, sont autorisés par le processus Directing a project de
Prince2, puis transmis à la gestion des changements d'ITIL pour leur implémentation, tout en supervisés par le processus Controlling a stage de Prince2.
D'un point de vue organisationnel, les responsabilités doivent être claires entre les fonctions et les rôles de la gestion
et ceux de gestion du changement. En outre, les canaux de communication devraient être bien établis. ITIL version 2
n'était pas clair sur l'organisation : seuls les rôles principaux des processus, tel que gestionnaire de changement, a été
identifié, mais aucune information n'a été donnée sur la façon d'organiser les fonctions. Or, dans ce cas, la gestion du
projet décrit relève du CIO.
Au niveau des outils, les activités de la gestion des changements font partie de la démarche de la gestion des services.
Ainsi, la gestion des coûts et des dépenses, ou encore la planification sont des techniques utilisées par la gestion de
projet. Une vue complète des activités et de la charge de travail, engendrée par la gestion de projet et des changements,
constitue autant d'informations clés pour prendre de bonnes décisions et assurer une planification efficace. Par conséquent, si une solution unique ne couvre pas toutes les fonctions, il sera important de mettre en oeuvre des interfaces
entre la gestion de projet et les outils de gestion du changement.
Conclusion
Dans cet article, nous avons identifié et exploré les relations entre la gestion de projets et des changements, en nous
appuyant sur ITIL et Prince2, comme cadres de référence pour déterminer la portée et les détails du processus. Les
relations entre les processus de gestion des changements et des mises en production sont décrites par ITIL V3. Toutefois, pour des changements significatifs, il est conseillé de recourir à une démarche projets.
Global Knowledge France • T é l é p h o n e : 0 1 7 8 1 5 3 4 0 0 • C o n t a c t @ g l o b a l k n o w l e d g e . f r
Ainsi, différents scénarios de mise en œuvre sont possibles, en fonction de la maturité et de l'influence des fonctions
correspondantes : la gestion de projet étant traditionnellement mieux établie pour le développement de nouveaux services et d'applications, tandis que la gestion des changements et des mises en production ont tendance à être plus
opérationnelles. La façon dont les processus sont interfacés reflétera l'équilibre entre la stabilité et la réactivité au sein
de l'organisation informatique.
Nous avons appris que les changements doivent être gérés comme des projets, dès que leur taille et les risques associés
deviennent significatifs. Les projets génèrent des changements à mettre en œuvre. Les exigences spécifiques du projet
sont ensuite intégrées par la gestion des changements, pour les appliquer lors des phases de tests et de déploiement.
Cette cohérence entre la gestion de projets et des changements optimise l'utilisation des ressources et la planification
globale des activités, tout en minimisant les risques d'effets néfastes. Mais ce n'est pas la seule possibilité. La gestion
de projet peut également intégrer et remplacer les activités typiques de la gestion des changements et des mises en
production.
Quelle que soit la solution adoptée, en fonction de la structure et de la maturité de votre organisation, le secret de la
réussite repose dans une bonne communication et une participation entre la gestion de projet et les processus de gestion des services. Un canal de communication efficace doit être établi le plus tôt possible entre la gestion de projet et
des changements.
Remerciements
Avec le soutien d’Annelise Savill et de Marion Bosch, éditrices chez Van Haren Publishing.
L’auteur de ce livre blanc est également Quality Assessor pour les ouvrages suivants :
Ce livre blanc vous est offert par Global Knowledge France
Tour Albert 1er
65, avenue de Colmar
92507 Rueil-Malmaison
01 78 15 34 00
[email protected]
Global Knowledge France • T é l é p h o n e : 0 1 7 8 1 5 3 4 0 0 • C o n t a c t @ g l o b a l k n o w l e d g e . f r