Home » Posts tagged 'processus'

Tag Archives: processus

Abonnez-vous à ce blog par e-mail.

Saisissez votre adresse e-mail pour vous abonner à ce blog et recevoir une notification de chaque nouvel article par email.

PRINCE2 – Elaborer le projet

Elaborer un projet PRINCE2

Un projet démarre toujours par une idée qu’il va falloir ensuite concrétiser sous la forme d’un produit. Le processus Elaborer le projet évalue la viabilité et la justification d’un tel projet. Hélas, bien souvent, on a des idées irréalistes ou ne conduisant nulle part. Il est possible aussi que l’idée soit belle mais pas vraiment justifiée vis à vis de la stratégie de l’entreprise. Le premier processus de PRINCE2 va donc devoir s’assurer que les produits préalables à l’initialisation du projet sont bien en place et répondre à la question fondamentale : le projet est-il viable et justifié?

PRINCE2 - Processus Elaborer le Projet

Le projet est-il viable et justifié?

C’est la question à laquelle doit répondre le premier processus de PRINCE2 : Elaborer le projet. L’objectif de ce processus est de s’assurer qu’il existe une justification continue pour l’entreprise, que le périmètre du projet est confirmé et qu’une approche du projet a été approuvée. Il est conçu afin d’assurer les principales parties prenantes de l’Entreprise que le projet est raisonnable et créera bien la valeur attendue conformément à la stratégie de l’Entreprise.

L’élément déclencheur de cette étape est le mandat du projet. Il s’agit d’un document fourni par la direction (d’entreprise / de programme) pour décrire les objectifs et les raison du projet. Il pourra, de plus, fournir une estimation de haut niveau du coût et du temps. Le processus Elaborer le projet est exécuté une seule fois sur chaque projet. Il est focalisé sur l’obtention d’une approbation, obligatoire pour initialiser le projet. Cette autorisation déclenchera l’exécution du processus Diriger le projetqui sera donc le deuxième processus de PRINCE2.

L’objectif du processus Elaborer le projet

Rien ne doit être entrepris avant que les informations nécessaires à la prise de décisions rationnelles n’aient été définies. Il faut aussi avant d’aller plus loin doter les principaux rôles et responsabilités des ressources adéquates. Rien ne peut être démarré non plus sans que les bases nécessaires à une planification détaillée soient disponibles.

L’objectif du processus Elaborer le projet vise à éviter l’initialisation de projets mal conçus et n’approuver que des projets viables. C’est donc un processus « léger » qui effectue seulement les vérifications minimum nécessaires pour déterminer si l’initialisation du projet se justifie.

Le contexte

PRINCE2 utilise le Mandat de Projet pour déclencher le projet. Ce mandat est généré par par l’autorité responsable ayant commandité le projet. Il s’agit généralement de la Direction de l’Entreprise ou de la Direction de Programme. Par Mandat de projet, il faut entendre toutes les informations disponibles et utiles pour déclencher le projet. Il peut s’agir d’une étude de faisabilité ou encore d’une demande proposition client ou fournisseur par exemple. Le Mandat de projet doit établir les termes de référence du projet. Il doit également contenir suffisamment d’informations pour permettre d’identifier le candidat au rôle d’Exécutif du Comité de Pilotage du projet. Il sera ensuite affiné pendant l’exécution du processus Elaborer le projet pour aboutir à l’Exposé de Projet.

Le Comité de Pilotage devra disposer de suffisamment d’informations pour décider si, oui ou non, il peut autoriser l’initialisation du projet. C’est la raison d’être de l’Exposé de projet.

La préparation de l’ébauche du Cas d’affaire et de l’Exposé de projet exigent une interaction et des consultations régulières entre le Chef de Projet, les membres du Comité de pilotage et les autres parties concernées. Plus les exigences seront définies de façon précise et plus on économisera de temps lors de la réalisation du projet. Cela permettra également de réduire les incidences, exceptions et replanifications. Cette phase est donc absolument cruciale pour la réussite du projet.

PRINCE2 - Workshop Elaborer le Projet

Les activités du processus

Les activités du processus Elaborer le projet se répartissent entre la Direction de l’Entreprise, l’Exécutif et le Chef de projet.

Nommer l’Exécutif et le Chef de projet

Pour avancer le projet a besoin d’un décideur disposant le l’autorité appropriée. Pour ce faire, la première activité de projet est la nomination à la fois d’un Exécutif qui sera responsable de la justification continue sur le projet et de représenter les intérêts des partie prenantes de l’entreprise sur le Comité de pilotage du projet, et d’un Chef de projet à qui l’exécutif délèguera la gestion quotidienne du projet.

Recueillir les Retours d’expérience

Il est important de tirer enseignements, en termes de faiblesses et de points forts, d’autres projets menés par le passé. Ces Retours d’expérience peuvent influencer la composition de l’équipe de projet et la préparation de l’ébauche de cas d’affaire. Il sera ensuite nécessaire de tenir un registre des retours d’expérience tout au long du projet, afin de faciliter la réussite du projet et de pouvoir en tirer des leçons pour l’avenir.

Composer et nommer l’équipe de projet

La réussite d’un projet passe par la nomination de personnes compétentes et justifiant de l’autorité, des responsabilités et des connaissances nécessaires pour pouvoir prendre les décisions opportunes. L’équipe de projet doit refléter les intérêts de toutes les parties concernées. Ceci inclut bien évidemment  l’Entreprise, les utilisateurs et les fournisseurs.

Afin d’assurer que chaque rôle de l’équipe de gestion de projet est rempli de manière appropriée et que chacun sait qui est responsable pour chaque rôle, il est important de définir des descriptions de rôles pour l’équipe de gestion de projet .Ceci est principalement de la responsabilité du Chef de projet. Par contre, la nomination des personnes sur chacun des rôles est de la responsabilité de l’Exécutif.

Préparer l’ébauche de Cas d’Affaire

Le Cas d’affaire est un élément crucial du projet vu qu’il détermine sa viabilité. L’exécutif est chargé de la création de l’ébauche du cas d’affaire qui explique pourquoi le projet est nécessaire ou utile. Pour sa création, on s’appuiera sur le mandat du projet et le journal des retours d’expériences. Après avoir développé l’ébauche du cas d’affaire, une Description du Produit du projet est écrite par le Chef de projet. Elle formalise les attentes des utilisateurs sur ce qui doit être livré par le projet. Dès que possible, les critères d’acceptation du projet sont documentés. Il s’agit là des caractéristiques mesurables du produit projet acceptables pour le client.

Définir l’approche du projet et préparer l’Exposé de projet

Il est de la responsabilité du Chef de projet de créer l’approche du projet et l’Exposé de projet, puis de les soumettre au Comité de pilotage en vue de leur approbation. L’approche du projet décrit la manière dont le projet sera abordé. La solution doit-elle être développée en interne ou externalisée? La solution sera-t-elle une modification d’un produit existant? Sera-t-elle développée à partir de zéro? La solution sera-t-elle basée sur un produit du commerce ou conçue sur mesure?

L’Exposé de projet doit contenir des informations détaillés dans le but de prendre connaissance des contraintes et des exigences pertinentes pour le projet, incluant le cas d’affaires (fourni par l’exécutif), la description du Produit du projet (créée par le chef de projet, avec la participation de l’utilisateur principal) et l’approche projet (avec la participation du fournisseur principal).

Planifier la Séquence d’Initialisation

Le processus d’initialisation du projet nécessite du temps et des ressources. Avant que le projet ne puisse être initialisé, le Chef de projet doit donc préparer un plan de la séquence d’Initialisation. Ce plan, accompagné de l’Exposé du Projet et de l’Ebauche de Cas d’Affaire sera soumis au Comité de Pilotage. Celui-ci devra alors l’approuver dans le cadre du processus Diriger le Projet. Ce n’est qu’à partir de ce moment que projet pourra réellement commencer.

Formation accréditée

Vous voulez en savoir plus?

Bien sûr cet article n’a pas vocation à être un cours exhaustif sur le processus Elaborer le Projet. Ce sujet, comme tout le contenu de la méthodologie PRINCE2 sont décrits dans le manuel « Réussir le Management de Projet avec PRINCE2 » (Ed. TSO).

Nous vous invitons également à lire nos articles précédents relatifs aux thèmes Cas d’affaire et Organisation en particulier. Pour mieux comprendre les processus de PRINCE2, vous pouvez également lire sur ce même blog 7 processus pour un projet PRINCE2.

Pour vous familiariser avec PRINCE2, nous vous invitons également à suivre une formation accréditée par AXELOS durant laquelle, sur 5 jours vous apprendrez le contenu de la méthode ainsi que l’utilisation pratique de PRINCE2 au travers d’études de cas. AB Consulting, ATO d’AXELOS, organise régulièrement des sessions de formation PRINCE2 Bootcamp de 5 jours vous permettant d’obtenir les qualifications PRINCE2 Foundation et PRINCE2 Practitioner et de faire reconnaître votre compétence en matière de Gestion de projet.

N’hésitez pas à nous laisser vos commentaires sur cet article et à nous apporter vos témoignages sur votre expérience de PRINCE2. Vous pouvez également interroger nos experts sur toute question pratique d’application de la méthodologie PRINCE2.

Nouveau: DevOps débarque en Afrique!

Une évolution nommée DevOps

Apparu depuis quelque temps, un nouveau mouvement professionnel et culturel visant à améliorer le flux entre les développeurs de logiciels et les équipes opérationnelles commence à faire ses preuves. Encore peu répandu sur le continent Africain où, pourtant, de nombreuses organisations réalisent leurs propres développements de logiciel en interne avant de les exploiter, DevOps répond clairement à un besoin croissant d’agilité des organisations dans un contexte de plus en plus mondialisé. Certains en ont peut-être déjà entendu parler sur des blogs ou via des offres d’emploi.

Dans un premier temps, DevOps peut être vu comme un outil d’amélioration des performances opérationnelles fonctionnant de manière intelligente. La stratégie DevOps aura un impact sur l’ensemble des réseaux de distribution. A la clé figurent des avantages non négligeables:

  • réduction du temps de commercialisation,
  • diminution des problèmes liés aux nouvelles publications,
  • réduction des délais de mise à disposition de correctifs
  • et accélération des temps de reprise après sinistre.

L’évolution constante des entreprises vers le numérique pousse désormais les développeurs à revoir sérieusement les modes de création d’applications.

DevOps-Evolution

Il n’est désormais plus tolérable d’attendre 6 mois, voire 1an avant de livrer les services demandés par les entités business. Les systèmes d’information doivent s’aligner sur la sortie des produits et services métiers. Le marketing ne peut plus attendre, surtout que les projets futurs deviennent de plus en plus complexes notamment en matière informatique. Le tout se retrouve dans un contexte économique pesant sur les budgets. Dans le cadre de ce développement, DevOps répond parfaitement à ce défi digital et les entreprises en ont maintenant pris conscience.

Qu’est-ce que DevOps?

DevOps est l’abréviation de « Développement » et « Opérations » dans le domaine informatique. Ce n’est pas un outil, un processus ou une méthodologie. DevOps a débuté comme étant, et continue d’être, une convergence d’idées en vue de combler le fossé qui sépare les équipes de développement et d’exploitation dans les Directions Informatiques. L’idée maitresse est de rationaliser le développement de logiciels et de faciliter leur exploitation et leur maintenance. Le terme DevOps identifie un mouvement déclenché par la frustration des professionnels de l’informatique, vers 2010, résultant des dysfonctionnements et de l’incapacité d’y remédier du fait d’outils et de processus inadaptés. Ces professionnels IT frustrés ont partagé leur vision du fait que le développement de logiciels et les opérations peuvent, et doivent être plus efficaces et moins douloureux.

Aujourd’hui, la définition originale de DevOps comme étant l’intégration du « développement » et des « opérations » est devenue trop limitée et inexacte. DevOps implique plus d’acteurs que les seuls développeurs et les techniciens d’exploitation. Le cycle de développement de logiciel  implique également de nombreux autres rôles qui constituent des contributeurs essentiels. Parmi ceux-ci, citons la gouvernance, l’assurance qualité (QA), les tests, la sécurité et la gestion des versions. DevOps est donc une combinaison de personnes, de culture, de processus, d’outils et de méthodes  réduisant les risques et les coûts, et permettant à la technologie d’évoluer à la vitesse de l’entreprise, et d’améliorer la qualité globale.

Pourquoi une nouvelle approche?

L’approche traditionnelle repose sur un ensemble de facteurs qui la fragilisent et l’alourdissent. DevOps représente une prise de conscience que l’approche traditionnelle n’est plus en mesure de satisfaire le besoin d’agilité nécessaire à l’Entreprise pour rester concurrentielle. Un exemple typique serait le cas du web qui gère des applications dans le Cloud. DevOps est une démarche innovante qui s’apparente à une philosophie destinée à des personnes à la recherche d’efficacité.

Pour la réalisation des grands projets informatiques, différentes équipes aux rôles bien définis sont impliquées. Il s’agit d’une part de l’équipe de développement et d’autre part de celle chargée de l’exploitation. Habituellement, les équipes de développement tentent de répondre à des spécifications fonctionnelles issues du métier ou du client. Elles travaillent généralement dans leur propre environnement, avec leurs outils destinés aux développements. Elles ne se soucient guère de l’impact que peut avoir leur code sur la phase d’exploitation qui exécutera l’application sur un environnement de production. Les équipes chargées de l’exploitation, quant à elles, tentent de répondre à des impératifs de performance ou de stabilité du système. Et c’est pourquoi, elles sont très attentives à minimiser les impacts des modifications afin de préserver ces performances. Hélas, cela risque de générer un goulot d’étranglement pour l’ajout de nouvelles fonctionnalités aux applications.

Quelle que soit l’équipe, il est toujours compliqué d’être au courant de comment une autre équipe gère ses tâches. Cela rend difficile l’optimisation des deux côtés. C’est à ce niveau qu’intervient DevOps dont le rôle est, en quelque sorte, de réaliser l’intégration des différentes équipes pour faciliter la communication et diffuser l’information. Les autres fonctions de DevOps incluent l’amélioration de la coordination durant les phases de livraison et de déploiement afin de limiter les erreurs.

Les résultats sont-ils probants?

Les résultats sont probants et donnent un bon aperçu des avantages de DevOps. Selon un sondage récent 66% des entreprises dans le monde utilisent déjà une stratégie DevOps ou envisagent d’en mettre une en œuvre. Plus de 90% d’entre elles ont observé ou s’attendent à un gain substantiel grâce à leurs initiatives DevOps. Les résultats de DevOps sont réels et quantifiables car cette approche génère des améliorations, augmentations ou réductions, à deux chiffres (de 17 à 23%).

Infographie DevOps

Les résultats concernant la France sont inférieurs aux chiffres résultants du sondage mondial mais sont néanmoins significatifs.

Quels sont les enjeux?

L’arrivé de DevOps met la pression aux développeurs car ils doivent produire davantage dans un temps réduit et réaliser des tests supplémentaires tout en respectant les contraintes budgétaires imposées. Parmi les enjeux majeurs apparaissent la réactivité commerciale et les délais de commercialisation qui bien souvent affectent l’expérience du client. Cela dit, DevOps impose un niveau de collaboration, d’agilité, de visibilité de développement et de rapidité de distribution qui relève le défi des projets à long terme dont la lenteur est à bannir compte-tenu des contraintes du monde de l’entreprise.

La stratégie DevOps est moins adaptée aux mainframes car il est généralement compliqué de faire évoluer des processus traditionnels bien ancrés et de développer la collaboration autour de technologies solidement établies. La majorité des schémas organisationnels sont en réalité inadaptés ou insuffisants pour permettre aux équipes de développement d’atteindre leurs objectifs et le niveau de productivité qu’exige leur entreprise.

DevOps, pour quels bénéfices

Le slogan pré-Devops était « Vite vite on met en production ! ». Mais attention, il ne faut pas confondre vitesse et précipitation. La production c’est du sérieux ! En effet, les développeurs produisent du code à partir d’un cahier des charges précis. Ils se préoccupent peu des impacts que peut avoir leur code sur la production. De la même façon, les équipes de production sont quant à elles obnubilées par la stabilité de l’infrastructure, garante de la création de valeur pour les métiers. Elles freinent donc les mises en production et blâment le code du développeur si le résultat voulu par l’utilisateur n’est pas satisfaisant. La vision DevOps tente de pallier à ce problème en favorisant une répartition des responsabilités et l’implication de l’ensemble des acteurs de la chaine. Le développeur devient ainsi testeur de son code.

Les intérêts d’adoption d’une démarche Devops sont multiples :

  • Réduire le cycle et le coût de mise en production,
  • Avoir une approche plus fragmentée (petites évolutions),
  • Faire que les mises à jour deviennent transparentes,
  • Mise en commun des responsabilités (tout le monde dans le même bateau!)
  • Une amélioration continue du produit,
  • Répondre plus rapidement aux besoins des clients.

NETFLIX, Amazon, Singapore Power ont été conquis par DevOps

Eh oui, même les plus grands ont adopté Devops ! Des entreprises telles que Netflix ou Amazon ont bâti une bonne partie de leur succès en s’appuyant DevOps.

Cycle de vie DevOpsChez Netflix, par exemple, le déploiement est totalement automatisé, depuis le packaging du nouveau code jusqu’à la mise en production. Cela passe par la mise en oeuvre de l’infrastructure virtuelle et les tests fonctionnels. Une nouvelle version d’application sera promue automatiquement dans une nouvelle infrastructure virtuelle. Elle est mise en service en lui redirigeant un sous-ensemble du trafic utilisateur. Après une phase pilote avec monitoring automatisé, si le comportement s’avère satisfaisant, la totalité du trafic est redirigé. L’ancienne instance de l’application et son infrastructure sont alors automatiquement décommissionées.

Vous souhaitez en savoir plus sur DevOps?

DevOps est désormais accessible en Afrique. Laissez vous tenter par cette révolution. Faites partie des premiers à satisfaire enfin le besoin d’agilité tant attendue par le Business. Grâce à DevOps vos équipes informatiques pourront concevoir et déployer des applications plus rapidement. Elles travailleront de manière efficace et efficiente, s’adapteront facilement au changement, développeront de meilleurs logiciels. Dernier avantage non négligeable, DevOps vous permettra d’optimiser les coûts. Une mise en œuvre parfaite de DevOps est essentielle et nécessite des professionnels expérimentés dans le domaine. C’est pourquoi AB Consulting, seul organisme officiellement accrédité en Afrique, vous aide à comprendre et à mettre en œuvre DevOps dans votre Organisation. Nous vous accompagnons également dans la conduite du changement culturel au sein de vos équipes. Pour plus d’informations sur nos prochaines formations DevOps Foundation, consultez notre site.

N’hésitez pas à nous adresser vos commentaires et vos questions qui seront les bienvenues pour que s’instaure un dialogue fructueux autour de la révolution DevOps.

Implémentation d’ITIL: bien commencer

Implémentation d'ITIL - Raisons d'échecL’implémentation d’ITIL dans votre organisation n’est pas une partie de plaisir. Lorsque vous envisagez de mettre ITIL en œuvre, les premières questions qui vont inéluctablement se poser seront où commencer? Comment dois-je commencer? Qu’est-ce que je cherche à atteindre? Quelles informations me sont nécessaires pour y arriver, quelles personnes dois-je impliquer, et que doit produire ce projet?

Si vous ne disposez pas des réponses complètes à vos questions, votre implémentation d’ITIL va inéluctablement échouer. Nous allons dans cette série d’articles essayer d’identifier les causes d’échecs et vous donner quelques conseils pour pouvoir les éviter.

Implémentation d’ITIL, ça veut dire quoi?

Tout d’abord il est important de souligner qu’on n’implémente pas ITIL®. ITIL® est un référentiel de bonnes pratiques de gestion des services informatiques, publié par AXELOS®, basé, dans sa version 2011, sur les 5 étapes du cycle de vie des services, et couvrant 25 processus et 4 fonctions. Il est totalement impensable, même pour une très grande Entreprise, de tenter d’implémenter la totalité des bonnes pratiques décrites dans les cinq publications de base d’AXELOS®. De plus cela ne ferait absolument aucun sens. L’objectif est de décider, en accord avec les orientations portées par le Conseil d’Administration de l’Organisation et traduites en stratégies par le Comité de Direction, qu’est-ce qui pourrait, parmi les 25 processus et les 4 fonctions décrits dans ITIL®, améliorer le soutien de l’informatique au Business et lui permettre d’atteindre plus facilement les objectifs fixés par les stratégies de l’Entreprise. L’informatique a un rôle de « facilitateur » mais elle ne crée pas de valeur directe pour les parties-prenantes. Ca c’est le rôle des métiers de l’Entreprise.

Prenons le cas, par exemple, d’une banque. Tous les services bancaires s’appuient sur l’informatique qui est un élément clé du fonctionnement quotidien de la banque. Lorsque l’informatique s’arrête, la banque est dans l’impossibilité totale de délivrer ses services à ses clients. Cependant l’informatique ne crée aucune valeur directe pour la banque. L’informatique PERMET aux directions métiers de la banque d’élaborer des services financiers qui seront ensuite vendus aux clients de la banque et créeront de la valeur pour les parties-prenantes. Les véritables créateurs de valeurs sont les directions métiers qui vont « embarquer » des services informatiques dans les services qu’elles vendent et délivrent à leurs clients. Il est donc important que le département informatique soit en permanence aligné avec les besoins des directions métiers et en même temps suffisamment flexible pour leur permettre, dans un environnement extrêmement concurrentiel de créer de nouveaux services financiers afin de rester leaders sur leur marché en fonction des attentes nouvelles des clients.

Donc on implémente seulement des processus et des fonctions les plus indispensables pour permettre à l’Entreprise de créer de la valeur, c’est à dire ce qui est strictement nécessaire dans le cadre des stratégies de l’Entreprise. La décision relève donc des mêmes personnes en charge de valider les stratégies de l’Entreprise et « comptables » (Accountable) des ressources notamment humaines et financières de l’Organisation devant les parties-prenantes. C’est à dire que la décision se prend au niveau du Conseil d’Administration. Ce ne doit jamais être une décision prise par le DSI, ce qui conduirait inévitablement le projet à l’échec après avoir dépensé en pure perte beaucoup de temps, d’argent et gaspillé les ressources humaines disponibles au détriment d’autres projets plus importants. C’est la raison pour laquelle il est important de mettre en place une Gouvernance du SI et d’établir une stratégie informatique claire et validée.

Pour les processus et les fonctions, dans la mesure où il existe des bonnes pratiques reconnues de façon universelle pour la fourniture des services informatiques, on pourra bien sûr s’appuyer utilement sur ITIL®. Seul bémol, les processus et les fonctions ne suffiront pas. Il va également falloir travailler sur les ressources humaines et notamment leurs compétences techniques, bien sûr, mais, plus important encore, leur aptitude à adopter un comportement adéquat basé sur l’éthique de l’Organisation et la création d’une véritable culture du service. Et cela ne fait pas partie directement du périmètre d’ITIL® version 2011 même si les changements culturels et organisationnels sont effleurés dans la publication sur la transition des services.

Où commencer?

La première étape consiste à commencer par faire le constat d’un besoin de mise en oeuvre ou d’amélioration de la fourniture des services informatiques aux métiers de l’Entreprise et à obtenir le consentement à une telle initiative. Il faut cerner les points sensibles et les déclencheurs actuels, et créer un véritable désir de changement au sein de la haute direction.

Il est important de ne pas se focaliser uniquement sur comment on va s’y prendre mais de bien définir ce qui doit être fait pour soutenir les stratégies de l’Entreprise. Ce qui doit être fait doit entrer dans un cadre d’amélioration continue de l’Organisation en vue de créer davantage de valeur en alignement avec les stratégies de l’Entreprise et s’appuyer sur des points sensibles (« là où ça fait mal ») pour le business ou bien des déclencheurs tels que le remplacement de membres du Comité de Direction ou bien le résultat d’un audit externe ou bien encore un changement important sur notre marché ou une nouvelle exigence légale ou réglementaire à laquelle on ne pourra pas échapper. Les points sensibles sont des points de douleur ressentis par l’Entreprise vis à vis de son département informatique tels que par exemple l’incapacité de l’informatique à répondre favorablement à des demandes de nouveaux services IT correspondant à un besoin marché ou bien la perception par le business que la qualité des services IT qui lui sont livrés ne sont pas en adéquation avec ses besoins et sont finalement beaucoup trop chers comparativement à la valeur qu’ils permettent de créer.

Dans tous les cas il va falloir sensibiliser le top-management sur ces aspects pour arriver à transformer le besoin d’agir, dont tout le monde est bien conscient au niveau de l’Entreprise, en désir de changement en vue d’obtenir un sponsoring par au moins un des membres du Comité de Direction pour pouvoir lancer un pré-projet. Nous appellerons cette phase incontournable la « facilitation du changement ». C’est seulement lorsque vous aurez un sponsor pour ce projet que vous pourrez le démarrer, et cela commencera toujours par l’élaboration d’une ébauche de business case. Il s’agit d’un projet comme n’importe quel autre et il devra être géré comme tel, en s’appuyant sur une méthodologie de projet, comme par exemple PRINCE2®.

L’étape suivante se concentre sur la définition de la portée de l’initiative de mise en oeuvre ou d’amélioration et la mise en correspondance des objectifs de l’entreprise, des objectifs liés à l’informatique et des processus IT connexes, et en tenant compte des scénarios de risque qui pourraient également mettre en évidence des processus clés à cibler. Pour réaliser cela, on pourra utiliser par exemple la cascade d’objectifs décrite par COBIT® 5 et expliquée dans notre article sur la stratégie informatique.

Des diagnostics de haut niveau seront également utiles pour cerner la portée du projet et comprendre les domaines à prioriser. Une évaluation de l’état actuel doit ensuite être effectuée, de même qu’une évaluation de l’aptitude des processus existant pour cerner les problèmes ou lacunes. Les initiatives à grande échelle doivent être structurées sous forme d’itérations multiples du cycle de vie ne dépassant pas chacune une durée de six mois maximum. En effet, pour toute initiative de mise en oeuvre s’échelonnant sur plus de six mois, il existe un risque d’essoufflement, de perte de concentration et de démotivation des parties prenantes qui risque fort de conduire votre projet à l’échec.

Notre prochain article traitera des points suivants :

  1. Comment s’y prendre?
  2. De quoi ai-je besoin pour réussir une telle initiative?

Pour plus d’informations ou pour vous inscrire à notre newsletter, merci de compléter le formulaire de contact :

COBIT® is a trademark of ISACA® registered in the United States and other countries.
ITIL® is a registered trade mark of AXELOS Limited.
PRINCE2® is a registered trade mark of AXELOS Limited.

7 processus pour un projet PRINCE2

PRINCE2 est une méthodologie de management de projet qui fournit un cadre de gestion de la performance des projets d’une façon contrôlée. Elle est basée sur sept principes, sept thèmes et  sept processus qui seront exécutés à chaque niveau de management par l’équipe projet. PRINCE2® indique également à quel moment dans le cycle de vie d’un projet les activités de chaque processus doivent être exécutées.

processus projet PRINCE2

Dans cet article, qui fait suite à celui publié récemment sur ce blog et intitulé 7 thèmes pour un projet PRINCE2, nous allons nous intéresser aux sept processus de la méthodologie PRINCE2®.

Un processus est constitué d’une suite structurée d’activités décrivant ce que chaque rôle de l’équipe de projet doit exécuter pour que le processus délivre un résultat précis. PRINCE2 compte sept processus qui couvrent l’ensemble des activités requises pour diriger, manager et livrer un projet avec succès.

Le parcours PRINCE2 en 7 processus

Le Comité de Pilotage de Projet définit l’orientation et prend les décisions clés tout au long du cycle de vie du projet. Les activités du comité de pilotage sont couvertes par le processus Diriger le Projet qui se déroule de la phase de pré-projet jusqu’à la séquence finale inclue.

Les processus PRINCE2

1. Elaborer le projet

Exécuté principalement par le Chef de Projet dans la phase de pré-projet, il repose sur le mandat de projet qui permet de démarrer l’étude préalable au projet en vue de recueillir suffisamment d’informations pour décider si le projet est viable et justifié dans le cadre de l’Entreprise. La première étape consiste à déterminer qui occupera le rôle d’Exécutif qui siègera au sein du comité de pilotage du projet. C’est la Direction de l’Entreprise qui va le nommer. Le mandat de projet sera ensuite utilisé pour développer l’exposé de projet et l’ébauche de cas d’affaire, qui, à leur tour laisseront la place à la documentation d’initialisation de projet pendant la phase d’initialisation du projet. L’objectif principal de ce processus est de s’assurer que l’idée initiale est effectivement bonne et créera de la valeur pour l’Organisation. Si ce n’est pas le cas, alors pourquoi commencer un projet?

2. Diriger le projet

Ce processus est déclenché à la fin du processus « Elaborer le projet » et doit permettre au Comité de Pilotage de pouvoir décider si le projet doit être lancé. Par la suite, le Comité de Pilotage aura la responsabilité d’assumer la réussite du projet en prenant les décisions essentielles tout en délégant au Chef de projet le management au quotidien. Le rôle du Comité de Pilotage est d’exercer un contrôle général du projet, d’être en mesure de s’assurer de sa viabilité, de sa justification pour l’Entreprise, et de fournir des conseils et recommandations au Chef de Projet. Le processus Diriger le Projet est exécuté par le Comité de Pilotage pendant toute la durée du projet pour en assurer la direction et le contrôle jusqu’à la clôture définitive..

3. Initialiser le projet

Exécuté par le Chef de Projet au cours de la première séquence de management pour planifier le projet en détail, ce processus s’assure que toutes les parties concernées du projet comprennent les missions qui leur ont été confiées ainsi que les objectifs à atteindre par le projet. Ceci permet au Comité de Pilotage de savoir si les directives du projet répondent aux objectifs de l’Entreprise avant d’engager des dépenses importantes. Le résultat principal de ce processus est la Documentation d’initialisation du projet qui contiendra entre autres les différentes stratégies (communication, risques, configuration et qualité) ainsi que le cas d’affaires détaillé et les différents contrôles du projet. C’est sur la base de cette documentation d’initialisation que le Comité de Pilotage, dans le cadre du processus « diriger le projet » décidera d’autoriser -ou non- la livraison du projet.

4. Gérer une limite de séquence

Dans PRINCE2, la gestion du projet est réalisée séquence par séquence. La fin de chaque séquence est un point où le Comité de Pilotage devra prendre la décision de continuer en autorisant la séquence suivante ou d’arrêter le projet. Pour ce faire, il faut lui fournir certaines informations lui permettant de prendre sa décision de façon « éclairée » notamment en lui fournissant un rapport de fin de séquence et un plan de la séquence suivante. Ces documents sont préparés par le Chef de Projet de telle sorte que le Comité de Pilotage soit en mesure d’évaluer la réussite de la séquence en cours et d’approuver le plan de la séquence suivante. Ce processus couvre la préparation de ces informations par le Chef de Projet. Le processus de Gestion d’une Limite de Séquence est exécuté une première fois à l’approche de la fin de la séquence d’initialisation puis vers la fin de chaque séquence de management, à l’exception de la dernière séquence de management à la fin de laquelle c’est le processus « Clore le projet» qui sera exécuté par le Chef de Projet.

5. Contrôler une séquence

C’est le processus que le Chef de Projet exécute pour gérer le projet au quotidien après que le Comité de Pilotage ait donné son autorisation de livrer le projet. Il couvre le management de la séquence autorisée par l’autorisation des différents Lots de Travaux attribués aux Chefs d’Equipes Techniques, le suivi du progrès de la séquence, le rapports de la progression au Comité de Pilotage et le traitement des incidences et des risques au fur et à mesure qu’ils surviennent. Ce processus a pour but d’affecter les tâches aux personnes concernées et d’informer le Comité de Pilotage de la progression de la séquence en cours.

6. Gérer la livraison du produit

C’est le processus qui contrôle le lien entre le Chef de Projet et le ou les Chefs d’Equipe en établissant des exigences formelles pour l’acceptation, l’exécution et la livraison des travaux du projet. Les Chefs d’Equipe exécutent ce processus pour livrer les produits spécialistes (techniques) du projet et rendre compte des progrès au Chef de Projet. Ils sont responsables de livrer les produits de la séquence au Chef de Projet. Les Chefs d’Equipe peuvent être internes ou externes à l’Entreprise.

7. Clore le projet

Les projets doivent avoir un début, un milieu et une fin contrôlés. Ils ne doivent pas partir à la dérive ou se diluer petit à petit. Ce processus est exécuté par le Chef de Projet a pour objectif de fournir un point fixe correspondant à la confirmation que le produit du projet est accepté, que les objectifs spécifiés dans la documentation d’initialisation de projet d’origine ont bien été atteints ou encore que le projet n’a plus rien à apporter à l’Entreprise, en vue d’assurer une fin de projet contrôlée. Il garantit que tout le travail qui était prévu a bien été achevé et il nous donne l’occasion d’évaluer le projet et de documenter les retours d’expérience qui pourraient être utilisés pour des projets futurs.

Ainsi les processus vous indiquent quelles activités vous devez effectuer et le moment dans le cycle du projet auquel il faut les faire. En exécutant ces activités vous soutenez les sept Principes qui font que le projet est un projet PRINCE2®.

Ce que les processus ne nous disent pas c’est comment vous devez exécuter ces activités. C’est là que les sept thèmes entrent en jeu. Ils vous donnent des éléments d’approche PRINCE2® vis à vis de certains aspects de management du projet qui doivent être traités tels que l’organisation, les risques, les changements, etc.

Pour apprendre les fondamentaux de la méthodologie, vous pouvez suivre une formation PRINCE2® Foundation. Pour devenir un praticien reconnu et enregistré auprès d’AXELOS®, vous devrez suivre une formation PRINCE2® Practitioner et réussir l’examen de certification correspondant.

Pour en savoir plus sur le cursus de formation et de certification PRINCE2, nous vous invitons à consulter notre page décrivant le cursus PRINCE2.

Pour plus d’informations ou pour vous abonner à notre newsletter, merci de remplir le formulaire de contact :

COBIT for Assurance : Nouvelle publication de l’ISACA à destination des auditeurs

Alain Bonneaud - CGEIT®, COBIT, ITIL Expert
Le 30 mai 2013, l’ISACA a publié un nouveau guide de la famille COBIT® 5. A destination des auditeurs internes et externes, COBIT® for Assurance a pour objectif d’aider les Entreprises à mettre en oeuvre efficacement les activités d’évaluation, leur permettant ainsi d’obtenir l’assurance que leurs processus sont bien suivis et que les risques sont contrôlés et maîtrisés. Ce guide est disponible en téléchargement sur le site officiel de l’ISACA.

Une approche de l’audit partagée par toutes les parties-prenantes

Établir la confiance dans les processus et contrôles informatiques est important, même si les activités d’audit sont souvent une source d’irritation pour les partenaires commerciaux qui ont bien souvent le sentiment que ces activités consomment beaucoup de ressources, ralentissent les activités commerciales et peuvent entraîner un surcroît de travail, tout cela pour atteindre des objectifs dont ils ne comprennent pas l’intérêt. Le nouveau guide COBIT 5 for Assurance de l’ISACA tente de combler ce fossé en traduisant les activités d’audit et de contrôle dans un langage commun pertinent pour les Entreprises et leurs partenaires technologiques, et fait le lien direct entre les objectifs d’évaluation  et les objectifs commerciaux. Dernière publication en date du cadre de référence COBIT 5 mondialement reconnu, COBIT 5 for Assurance propose des directives pratiques pour fédérer les professionnels d’entreprises, de l’informatique et de l’audit autour d’une approche partagée lors de la planification et de la réalisation des évaluations.

COBIT 5 for Assurance aide les entreprises à rendre possibles des activités de contrôle et d’audit de l’IT efficaces afin d’obtenir un degré de confiance raisonnable dans les processus qu’elles appliquent et dans la façon dont elles gèrent les risques. Ce guide fournit une feuille de route claire, fondée sur des approches acceptées internationalement en matière d’audit.

« Les entreprises peuvent utiliser COBIT 5 for Assurance pour profiter de l’homogénéité, de la structure, du contexte et du vocabulaire du cadre de référence COBIT 5 », a indiqué Tony Noble, CISA, directeur de l’équipe de développement de la publication et vice-président de l’audit informatique chez Viacom. « Lorsque les professionnels de l’assurance baseront leurs évaluations sur le même cadre de référence qu’utilisent les entreprises et les directeurs de l’informatique pour maximiser la valeur de l’information et de la technologie, toutes les personnes concernées utiliseront un langage commun et auront un objectif commun. »

La seconde publication COBIT® destinée aux professionnels

COBIT 5 for Assurance est destiné aux auditeurs internes et externes, aux comités d’audit et aux organismes de réglementation, ainsi qu’aux conseils d’administration et directions d’entreprises. Il propose des exemples de programmes d’audit et de contrôle liés à la gestion des changements, à la gestion du risque et au BYOD. Ce tout dernier guide fait partie de la famille de publications COBIT 5 dédiées aux professionnels, et fait suite à COBIT 5 for Information Security.

« La gouvernance et la gestion de l’information et de la technologie sont un sujet vaste et complexe. COBIT contribue à contrer cette complexité grâce à des directives pertinentes, efficaces et simples à utiliser sur des domaines particuliers au sein des systèmes d’information. COBIT 5 for Assurance offre la perspective spécifique au domaine de l’assurance de cet important cadre de référence pour entreprises. Il a été conçu en réponse à l’importante demande en ce qui concerne des directives en matière d’audit et d’assurance en utilisant l’approche structurée éprouvée de COBIT 5 », a confié Greg Grocholski, CISA, président international de l’ISACA et directeur financier international de la division Ventures and Business Development au sein de la société Dow Chemical.

Catégories

Archives

Calendrier

janvier 2018
L M M J V S D
« Déc    
1234567
891011121314
15161718192021
22232425262728
293031  
%d blogueurs aiment cette page :