Tag Archives: CMMI

February 18 – Webinar (PMI) – All about CMMI and PMBoK !

10 fév

A PMI Project Management Quality Community of Practice Webinar with Arun SEETHARAMAN

18 February 2014 10:30 – 11:30 AM EST 16:30 CET/Franve

CMMI LogoArun Seetharaman will share his knowledge on « All about CMMI & PMBoK » by providing a glimpse of CMMI, the road map of CMMI, maturity levels of CMMI, how CMMI is structured, comparison of CMMI & PMBoK and sample mapping of one CMMI process area with PMBoK.

9 & 10 April – Webinar (PMI) – CMMI® and OPM3® as Maturity Appraisal and Improvement Models? (English and Arabic)

4 avr

CMMI® and OPM3® as Maturity Appraisal and Improvement Models?  by Ms. Rania Al-Maghraby

ENGLISH:        9th April 2013 12:00pm EST (UTC-4) and     ARABIC:        10th April 2013 12:00pm EST (UTC-4)

OPM3 par PMIThe purpose of this webinar is to survey the SEI’s CMMI model and the PMI’s OPM3 model as being used in appraising organizations based on maturity. Organizations seeking appraisal of their current maturity, either for internal strategic goals, or for external commercial and trade requirements, will consider basing their maturity assessment and improvement efforts on a global framework which was developed for satisfying these organizational improvement needs.

caractériqtiques des modèles de maturitéIn this webinar we will explore these two models from maturity assessment and improvement point of view. We will highlight differences, and show the applicability of each model, while opposing components and characteristics of each model to clarify how it is intended to be applied in actual use.

Ms. Rania Al-Maghraby is an independent management consultant from Egypt. She is PMP® certified, ITIL® Foundation certified, and MSc Computer Science. Rania is a PMI certified OPM3® Professional, the first in Egypt. She is a speaker at several professional events including PMI Global Congress. She has published a number of papers and articles in wide spread international magazines, journals, conference proceedings, and authored books.

1 Octobre – Webinar – Agile Project Management : un cadre global pour le management de projet Agile

29 août

Agile Project Management : un cadre global pour le management de projet Agile le 1er Octobre 2012

présenté par l’APMG avec Ian Stokes expert sur le sujet.

Inscription :https://www4.gotomeeting.com/register/202102831

QRP International France

Partenaire de DantotsuPM

Ce Webinar a pour objectif de présenter l’intégration des approches agiles dans une gestion de projet organisationnelle à l’aide du référentiel Agile Project Management.

L’approche Agile PM fonctionne en synergie avec des approches plus classiques tel que PRINCE2, ISO9001, PMI et CMMI afin d’intégrer la production Agile avec les enjeux, les contraintes de l’organisation, les facteurs clés de réussite des projets et les objectifs définis dans un portefeuille de projets.

Les projets Agile permettent de concevoir et de développer des solutions qui tout en définissant dès le début d’un projet les critères de réussite ne précisent pas toutes les fonctionnalités.

Le référentiel Agile PM avec DSDM/Atern s’articule avec des approches agiles comme Scrum et XP. Il offre un cadre et des conseils pratiques pour la planification globale, la priorisation des versions, la gestion du contenu, la gestion du prototypage, le pilotage des tests, le management de la qualité et la maîtrise des risques propre à un projet agile.

Ce cadre comporte un ensemble de principes, un état d’esprit, des livrables à produire, des rôles à mettre en œuvre, ainsi qu’une logique et une dynamique de gouvernance à respecter.

Partenaire de DantotsuPM

Nous prenons la route vers la certification CMMI en mode projet

18 avr

Voici un premier retour sur l’expérience de l’organisation de notre « voyage » vers la certification CMMI en mode Projet. Soyez indulgents car je ne prétends en aucun cas être un expert CMMI.

Comme beaucoup d’équipes informatiques, nous avons lancé des programmes d’Amélioration Continue. Ceux visent à accroître la qualité et la fiabilité des services que nous fournissons à nos clients internes. Sur le plan du développement de logiciel, il y a plusieurs initiatives que nous ciblons. Le défi le plus important que nous sommes donnés, en tant qu’équipe de management de notre informatique interne, est d’atteindre la certification CMMI.

Bien sûr, cela soulève de nombreuses questions :

  • De quel niveau de certification CMMI avons-nous besoin et lequel est le plus approprié pour nos activités au vu de notre situation actuelle ?
  • Lequel pouvons-nous nous permettre financièrement ?
  • Dans quelle période pouvons-nous l’atteindre ?
  • Pourquoi et avec quelles ressources ?
  • Qui prend le leadership ?
  • Qui décide ?

Pour atteindre un consensus et établir une direction claire, nous avons lancé cette initiative d’amélioration de notre performance comme un projet avec une responsable de projet et des sponsors seniors dans la communauté informatique. Après un certain nombre de sessions de travail entre les sponsors et la responsable de projet et son équipe, nous avons un plan d’attaque :

1. Dresser la carte de nos processus par rapport à CMMI et à ITIL pour nous assurer que nous avons une compréhension non ambiguë de quel standard utiliser pour chaque processus.

Par exemple, la plupart des processus de management de projet sont couverts par le Niveau 2 CMMI à l’exception du management des risques qui est de Niveau 3. Les étapes de définition initiales de notre cycle de vie des projets de développement de logiciel sont dans le périmètre du Niveau 2; alors que la conception, le développement et les tests relèvent du niveau 3 de CMMI. Des étapes postérieures comme le déploiement en production, le support et l’amélioration continue sont plutôt dans le périmètre ITIL…

2. Clarifier ce que les Niveaux 2 et 3 CMMI signifient pour nous

Bien sûr, nous avons des processus en place dans la plupart de ces secteurs. Cependant, nous sommes une organisation globale résultant de multiples fusions et d’évolutions successives au fil des ans. Aussi, il est important d’être clair sur la portée de chaque niveau pour décider comment se lancer au mieux et quel objectif devrait être le nôtre.

CMMI Niveau 2
Sept secteurs de Processus doivent être couverts pour une liste définie de projets qui devraient être représentatifs des activités de l’organisation : Gestion des Exigences, Planification de Projet, Suivi et contrôle de Projet, Gestion des approvisionnements et fournisseurs, Mesures et Analyse, Processus d’Assurance qualité de Produit et Gestion de Configuration
le Niveau 2 de CMMI est clairement centré sur le management de projet et des processus de support pour assurer qu’un jeu représentatif de projets de notre activité est :

  • Managé avec des plans documentés et en conformité avec les règles établies
  • Pourvu en personnel convenablement qualifié
  • Contrôlé et suivi pour vérifier le progrès et assurer la participation des parties prenantes
  • Contrôlé au niveau des livrables produits
  • Fourni une bonne visibilité au management aux jalons définis

CMMI Niveau 3
Dix-huit secteurs de Processus à maîtriser (11 de plus que le Niveau 2) : Développement des exigences, Solution Technique, Intégration de Produit, Vérification, Validation, Processus de gouvernance, Formation sur l’Organisation, Gestion de projet Intégrée, Management des risques et Analyse de Décision et Résolution.
La portée à ce niveau est l’organisation toute entière et non plus un sous-ensemble de projets.
Tous les Objectifs du Niveau 2 doivent être atteints. Les processus standards d’organisation (des procédures, des outils, des méthodes etc.) doivent être définis, mis en œuvre et institutionnalisé à travers l’organisation entière.

CMMI Niveau 4 et 5: A voir plus en détail lorsque nous aurons atteint le niveau 2.

3. Évaluer les scénarios alternatifs dans notre situation pour être bien tous d’accord avec le niveau que nous visons et comment au mieux l’atteindre.

Pour nous, nous pourrions décider de partir pour :
1. Le niveau 2 de Maturité suivi par le Niveau 3 avec notre organisation entière
2. Allez directement au Niveau 3 de Maturité avec notre organisation entière
3. Le niveau 2 de Maturité suivi par le Niveau 3 mais avec une portée limitée (par exemple un sous-ensemble des domaines des applications logicielles)
4. Allez directement au Niveau 3 de Maturité, mais avec une portée limitée
Nous sommes arrivés à la conclusion que, dans notre situation spécifique, «le Niveau 2 de Maturité suivi du Niveau 3 avec notre organisation entière dans le périmètre» est la décision la plus appropriée. Les raisons sont que cela nous permet d’adopter une approche pas à pas; nous atteindrons des jalons intermédiaires qui valideront les efforts et progrès et augmenteront la motivation; cela facilite la gestion du changement car nous formons progressivement de plus en plus de managers et chefs de projets; cela assure la disponibilité nécessaire de l’infrastructure de processus quand nous nous lancerons dans l’objectif Niveau 3.

4. Définir et mettre en œuvre l’approche qui nous convient

Pendant la première étape, CMMI le Niveau 2, nous choisissons des projets au sein de notre organisation par rapport à leur criticité métier, complexité technique et budget annuel alloué. Pour la deuxième étape, préparer le Niveau 3, nous généraliserons les meilleures pratiques CMMI Niveau 2 à travers l’organisation. Ainsi, à la troisième étape, le Niveau 3, nous pourrons embarquer tous les projets dans le périmètre de la certification.

5. Tout au long du chemin parcouru, nous avons identifié nos Facteurs Critiques de Succès

  • Engagement à 100 % des Leaders de l’informatique : nous avons passé du temps à expliquer l’approche, notre analyse et nos conclusions pour nous assurer que tous étaient à l’aise avec le projet avant d’engager l’étape 1.
  • Gouvernance de projet : Nous avons voulu une gouvernance très simple et directe pour ce projet critique. Ainsi, la responsable de projet continue à travailler avec les mêmes sponsors qui étaient impliqués dans la préparation de la proposition initiale. Elle a accès à l’équipe de direction informatique sur une base régulière pour donner des nouvelles, éliminer les obstacles, prendre des décisions et maintenir la mobilisation générale.
  • Les ressources sont clairement identifiées et nommées : l’effort requis pour entreprendre ce projet dans chaque équipe de développement ne doit pas être pas sous évalué. Il dépend en grande partie de votre point de départ, donc nos évaluations ne sont pas d’une grande utilité pour vous mais il est important que vous construisiez les vôtres avec réalisme et de manière conjointe avec les équipes de développement. Il est important d’être très clair dès le départ, par exemple : «chaque chef de projet dont le projet est dans le périmètre de la certification de Niveau 2 devra consacrer 4 jours par mois pendant la phase de démarrage (2-3 mois) et ensuite 2 jours par mois jusqu’à l’évaluation (6-9 mois)».

Conclusion (pour le moment)

Comme vous pouvez l’apprécier, le voyage CMMI n’est pas une ballade facile. Il exige de l’engagement, la clarté de but, le leadership et un management de projet rigoureux pour réussir.

Je vous garderai informés de notre progression.

Si vous vous êtes embarqués sur un voyage similaire, je vous invite à  partager vos astuces de voyages vers la certification CMMI avec les lecteurs de ce blog

getting started on our CMMI certification journey as a project

15 avr

This is a first return on experience about organizing our CMMI certification journey as a Project. Please bear with me as I am by no means pretending to be a CMMI expert.

As an internal Information Technology team, we have launched a number of Continuous Improvement programmes. These aim at enhancing the quality and reliability of the services we provide to our internal customers. On the development side, there are several initiatives that we are pursuing. The most important challenge that we set for ourselves, as an IT management team, is to reach a CMMI certification. Of course, this raises many questions:

  • Which CMMI level do we need and is the most appropriate one for our activities?
  • Which can we afford?
  • In what timeframe can we reach it?
  • Why and with what resources?
  • Who leads?
  • Who decides?

In order to reach consensus and establish clear direction, we launched it as a project with a clear project owner and senior sponsors in the IT community. After a number of working sessions between the sponsors and the project owner and her team, we had a plan of attack:

1. Map our IT processes to CMMI levels and to ITIL to ensure that we have a clear understanding about which standard is to be used for which process.

For example, most of the project management processes are covered by CMMI Level 2 with the exception of Risk Management that is Level 3. The initial definition steps of our Software Project life cycle are within Level 2 scope; while design, development and test are in CMMI level 3. Later steps such as deployment to production, support and continuous optimization fall into the ITIL best practices perimeter…

2. Clarify what CMMI Level 2 & 3 means for us

Of course, we have processes in place in most of these areas. However, we’re a global organization resulting from multiple mergers and evolutions over the years. So, it is important to be clear on the scope of each level to decide how to best get started and what objective should be ours.

CMMI Level 2

Seven Process areas need to be covered for a defined set of projects that should be representative of the organization’s activities: Requirements Management, Project Planning, Project Monitoring and Control, Supplier Agreement Management, Measurement and Analysis, Process and Product Quality Assurance and Configuration Management

CMMI Level 2 is clearly focused on project management and support processes to ensure that a set of projects representative of our activity are:

  • managed using documented plans & in accordance with policy
  • adequately staffed with suitably skilled resources
  • monitored & tracked to check progress and ensure stakeholders involvement
  • produce controlled outputs
  • visible to management at defined points (milestones)

CMMI Level 3

Eighteen Process areas to master (11 more than Level 2): Requirements Development, Technical Solution, Product Integration, Verification, Validation, Organization Process Focus, Organization Process Definition, Organization Training, Integrated Project Management, Risk Management and Decision Analysis and Resolution.

The scope at this level is the entire organization rather than a subset of projects.

All Level 2 Objectives must be met. The organization’s set of standard processes (procedures, tools, methods etc) are to be defined, consistently implemented & institutionalized across the entire organization.

3. Assess the alternative scenarios in our own situation to agree to the level we’re aiming at and how to best get there.

For us we could go for:

  1. Maturity Level 2 followed by Level 3 with our entire organization in scope
  2. Go direct to Maturity Level 3 with our entire organization in scope
  3. Maturity Level 2 followed by Level 3 but with limited scope (for example a subset of the applications’ domains)
  4. Go direct to Maturity Level 3 but with limited scope

We came to the conclusion that, in our specific situation, « Maturity Level 2 followed by Level 3 with our entire organization in scope » was the appropriate decision. The reasons are that it allows us to adopt a step by step approach; we will achieve intermediate milestones that validate the efforts and progress and boost motivation; it facilitates change management as we progressively get more managers and PMs educated; It ensures availability of necessary process infrastructure when we embark upon the Level 3 objective.

4. Define and implementation approach that suits us

During the first step, CMMI Level 2, we are selecting projects across our organization based on their business criticality, technical complexity and annual budget. For the second step, prepare for Level 3, we will generalize CMMI best practices across the organization. So, that, at the third step, Level 3 certification, we can embark all projects an activities in scope.

5. Along the way we identified our Critical Success Factors

  • 100% commitment of the IT Leaders: we spent time explaining the approach, our analysis and conclusions to ensure that all IT Leaders were comfortable with the project before engaging in step 1.
  • Project governance: We wanted very simple and straightforward governance for this critical project. So, the project owner continues to work with the same sponsors who were involved in preparing the proposal. She has access to the IT leadership team on a regular basis to provide update, remove roadblocks, make decisions and keep the momentum going.
  • Resources needs clearly identified and committed: The effort required to undertake such in each of the development shall not be under estimated. It will depend largely on your starting point, so our estimates are not relevant to you but it is important that you build yours with a very realistic mindset and jointly with the development teams. It is important to be very clear upfront, for example: « each project manager whose project(s) is/are in scope for Level 2 certification will have to spend 4 days a month in the startup phase (2-3 months) and then 2 days per month until the assessment (6-9 months) ».

Conclusion (for now)

As you can appreciate, the CMMI Journey is not an easy ride. It requires commitment, clarity of purpose, leadership and rigorous project management to succeed.

I’ll keep you posted on how well we progress.

If you have embarked on a similar journey, please share your CMMI certification tips with the readers of this blog

CMMI et le PMBOK

12 avr

Dans le portefeuille de programme d’amélioration des performances et capacités de mon entreprise actuelle, nous avons un projet de certification CMMI en cours pour notre informatique interne. Je reviendrai sur ce sujet dans un prochain article afin de parler plus en détail de la méthode utilisée pour ce projet. Car, en effet, se lancer dans une telle entreprise doit être conduit comme un projet avec ses objectifs, sponsors, parties prenantes, livrables, planning, ressources, plan de communication… Étant certifié PMP et, comme vous le savez, ayant occupé de nombreuses fonctions bénévoles au sein de PMI, le sujet proposé par Dave Nielsen m’a-t-il intéressé : CMM et le PMBOK. En voici une traduction personnelle.

CMM ou CMMI sont peut être les normes de qualité les plus en vue pour le logiciel. CMM/CMMI va au-delà de la portée de standards comme l’ISO (l’organisation internationale de normalisation) pour définir les critères de bons processus logiciels. Ceci rend ce standard très attractif dans toutes les organisations informatiques. CMM/CMMI est destiné à diriger les processus de l’organisation informatique dans son ensemble et le cycle de vie complet des applications doit inclure les processus utilisés pour diriger le développement du logiciel. L’influence de CMM/CMMI sur les processus qui gouvernent le développement logiciel signifie qu’il influence aussi la manière dont les projets de développement logiciels sont gérés. PMBOK de PMI’S (le Corpus de connaissances en management de projet) est reconnu dans le monde entier comme la Bible des meilleures pratiques en management de projet. Celles-ci s’appliquent à la gestion de projets dans n’importe quelle industrie y compris l’industrie informatique donc les meilleures pratiques du PMBOK seront sous l’influence de CMM/CMMI dans toute organisation qui souhaite appliquer les deux standards.

Pour autant que je le sache, personne n’a essayé de créer un standard CMM ou CMMI qui soit adapté au PMBOK et personne n’a personnalisé le PMBOK pour accommoder CMM ou CMMI. Cet article est ma tentative d’offrir des conseils au chef de projet qui est chargé de manager un projet logiciel dans une organisation qui est certifiée à un niveau CMM/CMMI de 2 ou plus. Heureusement, ces deux standards ne sont en aucun cas mutuellement exclusifs; cependant ils s’influencent vraiment. Aussi, un peu de soin devrait être pris avec les processus utilisés pour le projet. La meilleure façon d’adresser les rapports est par Secteur de Processus Clef (KPA) qui arrive à s’aligner assez étroitement sur les Domaines de Connaissance décrits dans le PMBOK. Ceci n’est pas un manuel pour réaliser CMM ou atteindre la certification CMMI, ni un manuel d’exécution des meilleures pratiques du PMBOK, j’indique simplement des façons de d’aligner les deux standards. Puisque l’audience prédestinée de cet article est principalement des chefs de projet, je commencerai en fournissant un certain contexte sur CMM/CMMI.

Contexte

CMM signifie Capability Maturity Model. CMMI standards pour CMM + Intégration est développé à partir de CMM. CMM a été développé pour le gouvernement de fédéral des États Unis par l’Institut de Génie logiciel (SEI), qui est associé à l’Université de Melon Carnegie (CMU) dans le but de mesurer la qualité des processus d’une entreprise travaillant pour le département de la défense. CMM s’est développé pour devenir un plan pour l’amélioration continue du logiciel en 5 étapes : Initial, Répétable, Défini, Managé et en Optimisation, puis encore raffiné pour aborder des problèmes de l’intégration CMM traité à travers l’organisation toute entière. La manière dont le SEI a tenté de faire cela est d’identifier des secteurs de processus différents, de définir les processus critiques à chaque secteur de processus et de définir des critères que les processus doivent atteindre. Les processus dans chacun des Secteurs de Processus Clefs (KPA) se développent au long de chacun des niveaux de maturité jusqu’à ce qu’ils atteignent le niveau 5. Cela ne signifie pas que les processus de chaque praticien doit atteindre le niveau 5. Le niveau 5 est destiné à des organisations comme la NASA qui ont besoin de ce niveau de maturité de processus.

Le niveau 1 est l’étape de départ pour le modèle et en fait n’importe quelle organisation qui crée du logiciel sera définie au niveau 1. Le niveau 2 exige que les processus de management de projet soient établis pour suivre à la trace le coût, le planning et le contenu. C’est l’étape à laquelle sera n’importe quel projet qui met en œuvre les meilleures pratiques du PMBOK et qui n’exige aucune rationalisation entre le PMBOK et CMM. Le niveau 3 exige que des processus logiciels tant pour le management que la réalisation soient documentés, standardisés et mis en œuvre à travers l’organisation sur tous les projets. C’est le niveau qui exige un degré de coordination entre le management de projet et CMM.

Le niveau 2 CMM exige des processus dans les secteurs suivants :

  • Gestion des exigences
  • Planification du projet logiciel
  • Suivi de projet logiciel et surveillance
  • Management de sous-traitance de logiciel
  • Assurance qualité logiciel
  • Gestion de configuration logicielle

Tous ces secteurs, à l’exception de la gestion de configuration logicielle, sont décrits en détail par le PMBOK. La gestion de configuration logicielle n’est pas couverte et considère normalement que le projet héritera ces processus de l’organisation exécutant le projet. Le management de sous-traitance de logiciel ne s’applique pas à chaque projet, si votre projet n’exige l’obtention d’aucun produit ou service extérieur, ce secteur peut être ignoré.

CMM se concentre sur la compréhension des besoins du client du projet logiciel, la traduction de ces besoins dans des exigences et la documentation de ces exigences. La capacité recherchée dans ce secteur est une compréhension commune de ce que sont ces exigences et leur documentation appropriée pour qu’elles puissent être utilisées à l’exécution et le suivi des activités du projet. La planification de projet se concentre sur le développement d’évaluations réalistes pour le travail qui doit être exécuté et l’obtention des engagements de faire le travail. La planification inclut aussi l’identification des objectifs, l’évaluation d’effort, l’évaluation des besoins en ressources, la planification du travail et l’identification des risques du plan. Le suivi et le contrôle de projet exigent que le chef de projet établisse une visibilité suffisante de la performance de projet pour que les déviations du plan puissent être détectées et corrigées. Les corrections peuvent inclure la re-planification du travail ou la prise d’actions qui permettront à l’équipe d’exécuter le plan existant. La gestion de contrat de sous-traitance gouverne comment les sous-traitants qualifiés sont choisis et managés. Le but e l qualité est de fournir la visibilité dans les processus utilisés et produits construits en passant en revue ces produits et processus pour s’assurer de la conformité par rapport aux standards établis. La gestion de configuration logicielle établit et maintient l’intégrité des produits et des composants se construisant partout et dans tout le cycle de vie du logiciel. Cette intégrité est établie en contrôlant les changements de configuration de produit à l’aide d’une bibliothèque de référence. Les changements au référentiel sont contrôlé par des processus de management du changement.

Le niveau 3 se concentre sur le projet et les problèmes organisationnels qui formalisent un génie logiciel et des processus de management efficaces à travers tous les projets. Le but est l’amélioration des processus de l’organisation. Le chef de projet ne peut pas être responsable des standards organisationnels, mais peut assurer que le projet qu’il gère supporte des processus de niveau 3. Les secteurs qui comprennent le niveau 3 sont :

Les processus d’organisation (le focus est appliqué à ce niveau en général)

  • Définition de processus d’organisation
  • Programme de formation
  • Gestion logicielle Intégrée
  • Ingénierie de produit logiciel
  • Coordination entre groupes
  • Revue de pairs

La définition des processus développe et maintient le jeu de processus qui délivrent les améliorations de performance. Elle définit aussi les données requises par la management de processus quantitatifs. Un exemple de ces données serait les résultats de test. Le processus n’adresse pas de tests spécifiques, mais plutôt comment les résultats de test seront utilisés pour améliorer le développement logiciel. La formation est concentrée sur le développement des compétences et de la connaissance pour exécuter les processus CMM mis en œuvre et les tâches demandées par le plan de projet. Les processus et le focus dans ce secteur sont à peu près inchangés par rapport au PMBOK. L’intégration adapte les processus du projet dans les standards, la politique et les actifs de l’organisation en répondant aux besoins techniques du projet. Les PMOs ou PMCs en sont probablement l’exemple le plus commun. Les processus d’ingénierie sont simplement les processus et les outils utilisés pour produire le logiciel. Un exemple d’ingénierie de produit logiciel est RAD (le Développement Rapide d’Application). Les compilateurs de code et des plateformes de développement Web sont d’autres exemples. La coordination entre groupes intègre les processus et outils utilisés par les groupes au sein du projet. Un exemple de cette intégration serait la participation du groupe d’Analyste Métier/Business dans l’examen des spécifications produites par le groupe de développement logiciel. Les revues de pairs se réfèrent aux revues de conception et de code.

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 1 129 autres abonnés

%d blogueurs aiment cette page :