jeudi 27 juin 2013

Six Steps to Project Quality Management: Manage Quality

A lire sur:  Method123


Many people find quality management to be one of the more difficult project management processes to implement. This is because quality is hard to define, and formal quality management requires you to collect metrics to validate the state of quality. The following process will help create a framework for the quality management process.
1. Create a Quality Management Plan
Develop a Quality Management Plan to identify the major deliverables, completeness and correctness criteria, quality control activities and quality assurance activities. The Quality Management Plan also describes how you will ensure that the client’s quality requirements are achieved. It is the place to describe the processes and activities that will be put into place to ensure that quality deliverables are produced. 
2. Determine the customer requirements for quality
Work with your customer to determine their requirements for quality. The high-level characteristics of quality can be uncovered during the project definition process. The detailed quality requirements should be uncovered when you gather business requirements.
3. Define a set of metrics to validate quality requirements are met
Identify a set of metrics that will provide insight into the quality of the deliverables. The project manager should already be capturing overall financial and duration metrics. The quality-related metrics need to be more sophisticated. There are two areas where you are trying to manage quality - in your project work processes and in the actual deliverables you are building. You should try to capture metrics that will measure each.
4. Execute quality control activities
Quality control refers to activities that validate the quality of your deliverables. It is also referred to as "inspection". Ensure that the quality control activities for every deliverable are performed while the project is underway.
5. Execute quality assurance activities
Quality assurance refers to the processes used to build deliverables. It is also referred to as "prevention". Having good processes should results in good quality deliverables.
6. Monitor and resolve deliverable quality
You need to validate the quality of your deliverables on an ongoing basis. When quality problems are found, implement a process to determine the cause and to make improvements in the process.
Using this process will help you understand, plan for and manage the state of quality on your project.

Savoir cibler son plan stratégique SI

A lire sur:  http://www.it-expertise.com/savoir-cibler-son-plan-strategique-si/

DSI, adapter votre plan aux enjeux de votre organisation

Des tendances de fond…


La fonction SI, poussée par les exigences métiers accrues d’agilité, d’excellence opérationnelle, d’ouverture vers l’extérieur ainsi que par le changement de paradigme née de la révolution numérique, est rentrée dans un processus de mutation profonde et permanente.

Les évolutions les plus spectaculaires concernent notamment :



… qui nécessitent de revoir les modèles SI…


La prise en compte de ces grandes tendances par les DSI passe par la redéfinition et le renfort de fondamentaux sur :
- l’architecture et le cœur du SI pour aller vers davantage d’ouverture du SI et de nouveaux canaux d’accès (BYOD, mobile, tablettes…), mieux exploiter la richesse des données, passer d’une logique applicative à des logiques d’écosystèmes ou plateformes, intégrer les solutions innovantes du marché source de différentiation, apporter un soin accrue à l’ergonomie, au design de ses solutions…
- l’organisation de la fonction SI en co-construisant une vision dans les différents métiers, étant en capacité de fonctionner en mode programme avec des équipes mixtes intégrées plus innovantes et axés sur les enjeux business finaux, faire évoluer la culture pour que les équipes SI agissent en entrepreneur et non plus « ingénieur responsable », développant les pratiques collaboratives  et synergies transverses…
- Les politiques et règles SI pour faciliter l’intégration des SI, adapter les règles de sécurité par une réévaluation des risques, une coordination des autonomies…



Quel plan stratégique SI conduire pour homogénéiser, consolider un SI diversifié ?


Un plan stratégique SI est indéniablement utile pour réagir à un constat d’hétérogénéité, de complexité, d’absence de confiance ou de maitrise insuffisant sur l’une ou l’autre des dimensions SI : Processus, Données, Logiciels, Infrastructures…

Dans ce cas, la filière SI se doit de fixer un cadre, établir une cible cohérente et la décliner aux travers de politiques et règles SI pour que l’ensemble des acteurs de la filière soient en capacité d’agir en faveur de la cohérence d’ensemble.

Un plan stratégique SI visant à consolider ou harmoniser un SI est efficace s’il:

- fait émerger une cible cohérente du SI.
La définition d’une cible SI d’entreprise nécessite d’adopter une posture et des savoir-faire d’architecte ou d’urbanisme. Il ne s’agit pas de remettre en cause l’ensemble du patrimoine mais de rénover les différents quartiers du SI, de positionner des axes de circulations de l’information et de délimiter les frontières au sein du SI. Les approches type TOGAF offrent l’avantage d’être aujourd’hui assez largement diffusés dans les grands groupes internationaux. Elles ne donnent toutefois pas les clefs pour définir le bon niveau de maille de réflexion lors d’un plan stratégique SI. Autant les principes du processus TOGAF consistant à fixer les principes, analyser les existants, définir les orientations cibles et les décliner en roadmap sont importants, chacune des étapes étant utile pour aborder les différents points de vue, autant ce type d’approche très méthodologique peut conduire les praticiens à se perdre et rentrer dans des démarches longues et coûteuses. On continuera pour les réflexions de cible SI à privilégier certains livrables d’architecture comme le Plan d’Occupation des Sols, le mapping fonctionnel des composants SI ou la carte de trajectoire SI. Ces cartographies permettent de se focaliser rapidement sur les points durs d’architecture (référentiels, couches d’échanges, redondances fonctionnelles…) et offre le grand avantage d’être communiquant pour la plupart des parties prenantes du SI.

- définit et renforce les règles et politiques SI.
L’homogénéisation d’un SI nécessite, outre une vision, de fixer et faire respecter des règles communes permettant de concrétiser les orientations métiers (règles SI dits stratégiques), les politiques SI (règles SI dits tactiques) dans les pratiques des différents acteurs SI : Instances de décisions, Chefs de projets métiers et applicatifs, responsables de patrimoine, architectes techniques, développeurs, responsables contractuels… Les règles SI s’appuient elle-même sur des référentiels de processus (ITIL, COBIT, CMMI…), d’applications et de composants techniques ou technologiques qu’une volonté d’homogénéisation nécessite d’établir ou renforcer. Les effets du dispositif sur la cohérence du SI tiennent, sur cette base, avant tout sur son animation. Le positionnement et le bon couplage des contrôles du cœur de la politique SI avec les cycles SI seront à définir dans le plan stratégique.


Quel plan stratégique SI conduire pour répondre à de nouveaux enjeux business ?


Une des premières motivations pour mener un plan stratégique SI tient à la nécessaire réaction à des bouleversements et évolutions métiers de l’entreprise.

Lors d’une fusion acquisition, du repositionnement d’une entreprise, d’une restructuration interne majeure, il est primordial pour une direction ou filière SI de démontrer son adaptabilité. La DSI est trop souvent centrée, dans ses phases de bascule ou de mouvement fort, sur les urgences et besoins immédiats. Elle se montre ainsi attentiste vis-à-vis de la stratégie métier encore en devenir. C’est pourtant lors de ses périodes que sa capacité de réactivité prime et que les capacités de se réinventer sont les plus importants. Dès les premiers signaux, la DSI doit pouvoir réévaluer son patrimoine et portefeuille de projet, contribuer à la structuration des programmes SI/business qui vont faire que la synergie, les nouvelles opportunités se concrétisent.

Un plan stratégique SI déclenché par un changement d’enjeu ou finalité business doit être centré sur:

- la mise à jour de la vision business, notamment dans l’étude des potentiels business et des nouveaux positionnements possibles. La filière SI est attendue en tant qu’experte et force d’innovation pour exploiter le nouveau contexte, challenger la crédibilité et la faisabilité des différentes  visions business exprimées. Il s’agira aussi de revisiter la vision SI, de lancer des réflexions sur l’adaptation de son modèle SI en support des réflexions stratégiques d’ensemble.

- le changement de cap des investissements SI. On voit trop souvent des projets et programmes d’investissement se poursuivent sans autre finalités et objectifs que ceux établis lors de leurs genèses. Il est pourtant rare que le contexte marché, financier, RH ou réglementaire n’implique pas une révision des objectifs voire une remise en cause de la raison d’être des projets ou programmes, surtout s’ils sont pluri-annuels. C’est un des principaux apports des démarches de Portfolio management qui obligent à une évaluation continue des investissements en regard des évolutions stratégiques. Un plan stratégique SI faisant suite à un bouleversement business majeur passe par la remise à plat du portefeuille d’investissement SI, en s’appuyant et consolidant si possible le dispositif de portfolio management.

- la définition du ou des programmes répondant aux nouveaux enjeux. Outre la remise à plat du portefeuille SI, voire du patrimoine SI, un changement de référentiel nécessite des adaptations. La filière SI se doit d’étudier les scénarii, d’analyser les transformations cœurs indispensables : plus qu’à un autre moment, on va solliciter son expertise pour distinguer l’essentiel de l’accessoire et trouver les trajectoires les plus directes pour atteindre la cible recherchée : nouvelle offre opérationnelle, réduction des effectifs et des moyens, etc.


Quel plan stratégique conduire pour rationaliser, cost-cutter, réduire l’OPEX ?


La fonction SI est historiquement une des fonctions les plus suivie et faisant l’objet d’un contrôle analytique rigoureux. La crise actuelle génère une pression particulière sur les budgets SI, notamment sur le récurrent et sur ce que l’on nomme les « commodités ».

En effet, des pans entiers des systèmes d’information se banalisent, et sont l’objet de marchés globalisés : évolutions technologiques et rendements d’échelle ont créé des offres performantes. Sont ainsi concernées les couches d’infrastructure technique (Cloud, réseaux, data center), les couches applicatives (postes de travail, fonctions supports…).
De plus en plus d’entreprises distinguent :
  • les activités et SI à forte valeur ajoutée, sources de différenciation (innovation vers de nouveaux produits et services…)
  • Les SI régaliens pouvant être standardisés et potentiellement gérés en cloud public,
  • les activités SI les plus récurrentes (« RUN » des applicatifs et infrastructures, helpdesk de premier niveau…) et les plus facilement filialisables et/ou externalisables.
Sur ces dernières, des réductions sont souvent attendues là où les gains de productivité sont les plus immédiats, par le recours à de grands contrats le plus souvent en Off shoring.



Les basculements en modèle « off shore » ont des impacts budgétaires finalement limités (~- 15% sur les budgets RUN*) en raison du renforcement de pilotage nécessaire. Ils peuvent aussi générer des pertes de contrôle sur le SI (difficultés linguistiques, incompréhensions, documentation SI…). Les gains sont surtout importants en terme d’agilité, pour des groupes ayant de fortes contraintes de réactivité (respiration d’actifs, programme réglementaires…), ou pour répondre à un besoin de présence internationale.


Un plan stratégique SI déclenché par un objectif de rationalisation doit être centré sur:

- la standardisation du SI. Il va s’agir, dans ce cadre, de distinguer les différents pans du SI afin d’adopter des stratégies différenciées en privilégiant l’établissement de gammes SI standardisés, de plateformes paramétrables, de requalification des périmètres ERP, d’externalisation ou de cloudisation de certains pans SI…
En fonction de l’objectif et de l’horizon de rationalisation fixé, une approche d’analyse de la valeur et d’analyse des risque doit permettre de positionner les frontières des commodités SI. Le plan stratégique peut alors positionner des stratégies ambitieuses de rationalisation.
- l’analyse du patrimoine SI. Outre le portefeuille de projet, une approche de rationalisation nécessite de mettre en place une approche d’Application Portfolio Management (APM) pour établir un screening du patrimoine et être en capacité de piloter la rationalisation.


Exemple d’analyse de patrimoine SI (Troux technologie)

- l’organisation de la filière SI. Une rationalisation ambitieuse du SI nécessite presque toujours de revoir les règles et processus de gouvernance. Le plus souvent, il va s’agir d’être beaucoup plus dirigiste donc de constituer une équipe technico-financière rattachée à un sponsorship de haut niveau (Direction financière ou Direction Général) pour participer aux arbitrages, recadrer les déviances.


Quel plan stratégique conduire pour faire face aux nouveaux enjeux de la globalisation ?


L’organisation des fonctions et filière SI sont très différentes selon les organisations et entreprises. Elles sont en grande partie dépendantes de l’historique capitalistique et de l’homogénéité des activités. La structuration de la filière, son niveau de décentralisation ou au contraire de centralisation sont souvent en décalage avec les nouveaux défis de la mondialisation et les évolutions des barycentres de décisions et de développement : BRIC, marchés émergeants…

On pourrait penser que le SI, par essence dématérialisé est moins sujet que d’autres activités à l’adhérence territoriale et aux frontières mais c’est sans tenir compte des business models territoriaux nécessitant des solutions low-cost ou adaptés aux marchés locaux, à l’importance accrue de la réglementation notamment locale dans les SI.

L’impulsion donnée en central est primordiale pour relever les défis de la mondialisation, coordonner les activités et s’avère essentielle pour diffuser les réussites et meilleures pratiques. A contrario, l’autonomie et la réactivité des branches métier ou zone pays passe par une subsidiarité dans les décisions et activités SI.
Il s’agit donc de trouver le bon équilibre et les bons modèles de rattachement hiérarchique et fonctionnel des acteurs de la filière SI en maximisant la contribution à la valeur business.

Un plan stratégique SI déclenché par un objectif d’adaptation à la globalisation doit être centré sur:
la transformation de l’usine, du modèle SI. S’adapter à la globalisation nécessite de définir pour les différents sujets : Processus core model, logiciels, infrastructures, le curseur central/local tant au niveau des processus de décision que des opérations SI. Il va s’agir entre autre de positionner les centres de service partagés SI et les niveaux d’externalisation, d’off shoring pertinent pour assurer le bon service au meilleur coût.
l’adaptation des visions cibles. Les réponses SI, dans un monde global, ne sont pas uniques et nécessitent de travailler sur des gammes SI resserrés et évolutives permettant d’accompagner les évolutions business zonales.
l’organisation de la filière SI. Par filière SI, il faut entendre l’ensemble des acteurs contributeurs à la délivrance des services SI. Un monde global nécessite d’adapter les services SI aux spécificités et ainsi positionner des acteurs et instances aptes à piloter et délivrer ses services localisés en tenant compte des langues, contraintes d’exploitations, risques pays…
la redéfinition des politiques SI. Un des clefs de globalisation consiste à préserver la cohérence globale à long terme sans pénaliser le développement local à plus court terme. Cela passe par la mise en cohérence fine des règles et politiques SI porteurs des principes de subsidiarité et de délégation.


Quel plan stratégique conduire pour se projeter vers l’Entreprise Numérique


C’est sans aucun doute le sujet le plus important tant la révolution numérique rabat les cartes et remet en cause les business model les plus robustes. La filière SI a un rôle clef pour faire prendre conscience de l’importance du changement et des potentialités amenées par le digital.

En effet, la maturité des entreprises sur le sujet digital est encore très différente selon les secteurs d’activité (les entreprises B2C ont plus naturellement, sous l’impulsion des Directions Marketing, opéré le virage stratégique vers le numérique) même si la plupart des grands Groupes ont maintenant initié des programmes ambitieux de transformation numérique.

Dans l’idéal, un plan stratégique SI déclenché par un objectif de projection vers l’Entreprise numérique ne devrait être envisagé que dans une logique d’ensemble transcendant la fonction SI et intégrant les acteurs de la stratégie, du marketing, de la RH, de la communication et des différentes directions métiers. En fonction de la maturité, la DSI doit néanmoins s’adapter et envisager les premières itérations de stratégie digitale en mode plus resserré, tout en abordant les sujets au bon niveau, c’est à dire:

en intégrant la stratégie digitale aux enjeux et à la vision business de l’entreprise. Un plan stratégique digital doit faire l’inventaire des initiatives existantes, objectiver les opportunités et menaces digitales pour l’entreprise, se projeter sur les nouveaux business models, évaluer l’impact sur les business model existants et l’expérience client
en adaptant les fondamentaux de l’usine SI: adaptation des modèles de collaboration et d’innovation, méthodes agiles, création de digital labs, développement des nouveaux métiers de community manager, data scientists, ouverture du SI…
en établissant les nouveaux modèles d’organisation et de gouvernance : logique d’investissement et de goodwill, partenariats stratégiques,  industrialisation des réussites digitales, culture d’entreprenariat, droits à l’erreur…
en définissant les programmes de transformation digital autour des nouveaux business models digitaux, du développement de l’expérience client (enrichissement des offres, nouveaux moyens de marketing, apport des outils digitaux de CRM, social media, m-commerce…), des environnements numériques et collaboratifs (RSE, Digital workplace, knowledge management…).


En synthèse, il y a différentes approches possibles pour traiter de la stratégie SI. En 2013, le management d’une DSI doit redonner du sens à sa fonction, retrouver une nouvelle légitimité pour lui-même et ses équipes. Construire, partager, mettre en oeuvre la feuille de route SI nécessite de maitriser le périmètre des sujets à aborder.



Nicolas CHEVALIER
Nicolas chevalier accompagne depuis 2000 les clients d’ORESYS dans la transformation et l’adaptation de leur modèle SI. Il est responsable de l’offre Entreprise Numérique.

Learn About Earned Value Management (EVM) (Part 1 of 2)

A lire sur:  Tenstep


Have you ever been asked how far along you were on a project? Of course you have. If you do not have a valid schedule, or if you are not keeping the schedule up-to-date, you know that your answer is pretty much a guess. If you have a good schedule and you are keeping it up-to-date, you should have a sense for how much work is remaining and what the projected end-date is. But are you 50% complete? Or 90% complete? It is not always easy to know.
Earned value metrics were established to remove the guess work from determining where you are at in relation to a baseline. Using it allows a project manager to know precisely how far along he is, how much work is remaining, what the expected cost will be, and all sorts of other interesting information.
Are you using earned value on your project today? Probably not. You are not using earned value because your organization has not adopted it. Implementing earned value on your project requires a tremendous level of discipline and a common set of processes. It is hard to apply earned value one project at a time, since no one else would understand what you are doing and why. It required an organization focus.
History
Earned value has not been around for hundreds of years. You can actually trace its beginning to the late 1800s and early 1900s, as managers attempted to make the factory floor and the production line as efficient as possible. The drive for efficiency requires a foundation in metrics and earned value was a way to measure things more precisely.
In the 1960s, the US Department of Defense began to mandate the use of earned value on defense related projects. As you might expect, if the government is contracting out projects worth hundreds of millions or billions of dollars, they want project progress updates to consist of more than "we seem to be on target." Earned value calculations can provide a better sense for exactly where the project is against the baseline and provide an early warning if the trends indicate that the project would be overbudget or over its deadline.
EVM is based on just three core values.
  • Actual cost (AC). The actual cost of work completed as of a point in time.
  • Planned Value (PV). The budgeted cost of work you planned to complete as of the same point in time.
  • Earned Value (EV). The budgeted cost of the work actually completed as of the same point in time.
Earned Value is calculated by adding up the budgeted cost of every activity that has been completed. (Remember, this is not the actual cost of the work activities. This is the budgeted cost.) Look at the following example:       
 Today's Date is March 31
Completed Activity
A
B
C
D
Remaining Work
Target Date
March 10
March 15
March 31
April 5
July 31
Budgeted Cost
20
10
15
5
500
Actual Cost
20
5
20
10
?
Let's say that as of March 31 you have actually completed activity A, B, C and D. Let's calculate AC, PV and EV.
  • AC is the actual cost of the work completed. This is 55 (20 + 5 + 20 + 10).
  • PV is the budgeted cost of the work planned to be completed. This is 45 (20 + 10 + 15). Note that Activity D is not counted since it was not planned to be completed as of March 31.
  • EV is the budgeted cost of the work completed. This is 50 (20 + 10 + 15 + 5).
These three numbers seem to be interesting, but by themselves they do not tell you too much. So, we need to combine and compare the values to determine our status against schedule and budget. Sorry, but this next bit of information must wait until next week's email.

Five reasons to discuss project failure

A lire sur:  http://www.techrepublic.com/blog/tech-manager/five-reasons-to-discuss-project-failure/1103

Takeaway: ZDNet blogger Michael Krigsman offers five reasons why he believes analyzing project failures can lead to greater insight than merely talking about project successes.
This is a guest post from Michael Krigsman of TechRepublic’s sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.
Readers frequently ask why this blog emphasizes failure rather than success. Although I try to presents facts in a balanced manner, the blog name (IT Project Failures) definitely tells a particular story.
There are five key reasons I believe analyzing failures leads to greater insight and higher value than merely talking about success:
  1. Failure is instructive. Most of us have an instinctive aversion to discussing weakness, based on concerns that criticism may hurt our pride, reputation, and so on. While I deeply respect these sensitivities, fear creates an environment where repeated cycles of failure can manifest. Breaking this cycle requires understanding the source of problems followed by developing solutions to address them.
  2. Success stories don’t work. Sugar-coated corporate meetings often ignore ugly truths, which contributes to denial and perpetuates failure. As a result, many organizations ignore small problems until they fester into large public spectacles. Success stories simply don’t achieve the same impact as discussions about failure.
  3. Failure is a massive problem. Statistics say that 30%-70% of IT projects fail in some important way: they are late, over-budget, or do not achieve planned results. These facts are inherently negative and quickly lead toward uncovering roots of failure rather than examining causes of success.
  4. Taboo busting. In many organizations, discussing failure is tantamount to committing career suicide. Given this, it’s no wonder failure rates remain high, despite massive industry investments to improve methodologies, project management processes, and so on. Success rates will rise when we lessen the taboo and stigma around discussing these issues.
  5. Failure is real. This blog regularly describes actual conflicts of interest, greed, arrogance, fear, and so on. Folks, I don’t make this stuff up.
My core mission is helping organizations achieve success through understanding the roots of failure. If you think this blog is overly negative and should explore success more thoroughly, please let me know!

N°177: Le management de projet par rapport à la gestion de produit

A lire sur:  Tenstep

Les projets par rapport aux produits
Les « projets » sont la voie suivant laquelle un nouveau travail est livré. Toutes les institutions ont des projets qui peuvent être gérés à l’aide d’un ensemble commun de processus de management de projet. « Le Management de projet » se rapporte aux processus utilisés pour créer ou développer un produit.
Les « produits », d’autre part, sont des objets tangibles produits par les projets. (Si vous avez acheté le produit auprès d’un vendeur, c’est que ce dernier a produit cet objet en se référant à un projet). Si le produit est temporaire ou a une courte durée de vie, il n’est normalement pas considéré comme un « produit ». Généralement, le terme « produit » désigne quelque chose que nous construisons et dont nous assurons l’entretien pour une longue période.
Le « management de produits » est une approche permettant la coordination centrale des activités qui concernent la conception, le contexte commercial, le développement, la maintenance et l’amélioration d’un produit. Vous pouvez considérer que le management de produit englobe la totalité du cycle de vie d’un produit. La personne qui assume ces responsabilités est appelée chef de produit.
Le rôle du chef de produit varie en fonction du positionnement du produit dans le cycle de vie du produit. Les points qui suivent décrivent certaines des responsabilités spécifiques dévolues au chef de produit par rapport à un produit qui a été développé, qu’il soit destiné à un usage interne ou au commerce.
Le commencement
·         S’emparer de l’idée afin qu’elle puisse être explorée à fond
·         Identifier les opportunités d’utilisation du produit
Analyse de rentabilité
·         Lancer l’idée à travers le processus de planification commerciale de la société pour savoir si l’idée peut être financée. Si l’idée ne trouve jamais de réalisation, c’est que le cycle de vie du management du produit est très court.
Le projet
Un projet est lancé pour fabriquer le produit. À ce stade, le management de projet et le management de produit coïncident. Le chef de produit peut aussi bien assumer le rôle de chef de projet, mais il est plus courant qu’on fasse appel à un spécialiste de management de projet afin de gérer le projet jusqu’à son terme.
·         Coordonner les tests des nouveaux produits et leur mise en vente, y compris des expérimentations avec des utilisateurs potentiels du produit
·         Déterminer quand un produit est « prêt à produire » sur la base des projets de tests et d'expérimentations
·         Coordonner la diffusion du produit ou de nouvelles mises en vente
Maintenance et support
Nous abordons ici le management de produit à long terme. Le financement du travail a demandé quelques mois et la réalisation du produit demandera aussi quelques mois. Cependant, le produit a besoin d’être soutenu et amélioré plusieurs années de suite. Le chef de projet peut s’occuper du soutien et du perfectionnement, mais il est fort probable qu’une société spécialisée en matière de soutien soit impliquée.
·         Agir comme contact direct dans la coordination et la communication avec le vendeur du produit (produits vendeurs)
·         Surveiller l'orientation du produit avec le vendeur (produits vendeurs)
·         Chercher où le produit a été distribué
·         Recueillir continuellement les demandes du personnel au sujet de produits particuliers
·         Incorporer et ajouter de nouveaux produits et de nouvelles mises en vente (produits vendeurs)
Gestion financière
·         Coordonner les négociations de contrats de produits, obtenir les agréments et les accords de maintenance (produits vendeurs)
·         S’assurer que le budget pour les achats et la maintenance est disponible
·         Déterminer à quel moment il faut examiner la possibilité d’annuler ou de réduire les frais de maintenance, sur la base de l’orientation du produit (produits vendeurs)
Management des lancements de produit
·         Coordonner la certification de nouvelles mises en marché (produits internes et produits vendeurs)
·         Planifier et gérer la mise en œuvre de nouvelles mises en marché (produits internes et produits vendeurs)
 Retrait du produit
·         Déterminer le moment où un produit doit être retiré
·         Planifier et gérer le produit
·         Retirer (désinstaller) le produit du milieu environnant
Tous ces domaines constituent le cycle de vie typique d’un produit.
Terminologie de management de projet
Planifier les réponses aux risques. Processus qui consiste à élaborer des options et des actions permettant d'améliorer les opportunités et de réduire les menaces envers les objectifs du projet.
Procéder aux approvisionnements. Processus qui consiste à obtenir les réponses des vendeurs, à sélectionner un vendeur et attribuer un contrat.
Abréviations courantes
EVT (anglais) : : Earned Value Technique
       (français) : Technique de la valeur acquise

Plus de flexibilité pour un meilleur équilibre vie privée / vie professionnelle

A lire sur:  http://www.finyear.com/Plus-de-flexibilite-pour-un-meilleur-equilibre-vie-privee-vie-professionnelle_a26301.html

Nul ne peut contester l’importance de l'équilibre travail/vie privée. Sans lui, la santé et les relations sont mis à rude épreuve, les niveaux de stress augmentent, tandis que la productivité chute.



Frédéric Bleuse
Frédéric Bleuse
La problématique de l'équilibre travail/vie privée reste toutefois complexe. Si de nombreuses personnes avouent avoir refusé un poste à cause de son éventuel impact négatif sur l'équilibre vie privée / vie professionnelle, toutes ont cependant leur propre définition de cet équilibre. Pour les uns c'est un « travail exigeant mais passionnant » alors que pour les autres il s'agit plutôt d'« une routine ».

Les longues heures de travail sont-elles toujours préjudiciables ?
De prime abord, on pourrait penser qu'un bon équilibre implique une diminution des heures de travail. Toutefois, les statistiques semblent plutôt confuses à ce sujet, comme l'indique le dernier Indice Regus sur l'équilibre travail/vie privée. Dans cet indice, les trois économies présentant le meilleur équilibre travail/vie privée sont le Mexique, l'Inde et le Brésil. Or, selon les chiffres de l'Organisation de coopération et de développement économiques, les employés qui travaillent au Brésil et au Mexique sont plus susceptibles de travailler de très longues heures que la moyenne de l'OCDE (l'Inde ne faisant pas partie de l'étude de l'OCDE). En effet, c'est au Mexique que l'on trouve les moyennes d'heures de travail les plus élevées parmi les pays de l'OCDE. L'équilibre travail/vie privée ne dépend donc pas seulement de la durée de présence au bureau.

La flexibilité est un facteur clé en matière de bien-être
La liberté qu'a l'employé de choisir et contrôler lui-même la durée de sa journée de travail explique en partie cette situation. L'Indice Regus sur l'équilibre travail/vie privée montre que les chefs d'entreprise semblent bénéficier d'un meilleur équilibre travail/vie privée que leurs employés : 74 % d'entre eux apprécient davantage leur travail que l'année dernière, contre 66 % des employés. La seule différence étant que les chefs d'entreprise décident eux-mêmes où, quand et combien de temps ils travaillent.

Il serait donc logique que les employeurs permettent à leurs salariés d'en faire autant, afin qu'ils puissent adapter leurs horaires de travail à leurs modes de vie, avec une meilleure flexibilité du lieu de travail, et donc moins de temps passé dans les transports. Tout en améliorant l'équilibre travail/vie privée, le travail flexible permet en outre de réduire l'empreinte carbone des collaborateurs.

La flexibilité du lieu de travail est aussi importante que la souplesse des horaires
Le choix du lieu de travail est particulièrement important dans les zones métropolitaines. Avec l'urbanisation intensive et l'augmentation du trafic, le temps passé dans les transports est de plus en plus long. Permettre aux employés de travailler plus près de chez eux libère du temps, qui peut être aussi bien utilisé pour le travail que pour des activités non professionnelles.

Les entreprises ont encore du chemin à faire. Un peu moins de la moitié (49 %) des participants à l'Indice Regus sur l'équilibre travail/vie privée affirment que leurs entreprises font des efforts pour réduire le temps que les collaborateurs passent dans les transports. C'est un pourcentage non négligeable, supérieur à l'année précédente. Néanmoins, plus de la moitié des personnes interrogées pensent que les entreprises ne cherchent pas de solution.

Un outil de fidélisation des talents ... et de productivité
Dans la mesure où la réussite d'une entreprise dépend de ses employés clés, il peut être fondamental de permettre au personnel de travailler à sa façon et où il le souhaite.

Sans travail flexible, les employés clés risquent de démissionner, en particulier ceux des générations Y, moins fidèles à l'égard de leur entreprise. De plus, 72 % des entreprises à travers le monde considèrent que le travail flexible améliore la productivité des collaborateurs…un atout non négligeable en cette période où la compétitivité des entreprises apparait comme un atout majeur.


Frédéric Bleuse, Directeur Général France de Regus
www.regus.fr

Wednesday, June 26th 2013

mardi 25 juin 2013

5 Tips for Scheduling Resources

A lire sur:  ProjectManager.com

Try these 5 tips to make scheduling resources easier...
5 Tips for Scheduling Resources
Projects are normally done by a group of people. As a Project Manager, you will need to allocate tasks to the people on your project team. If you try to do it all yourself, or you don't allocate the right tasks to the right team members, you will seriously slow down your project. You can avoid this by scheduling resources effectively.
Tip 1: Assign resources to tasks
The first thing to do is to assign people to work on your project tasks. Create resource profiles for each of your team members and then you can allocate the right tasks to the right person. If you don't know who should be taking the lead on a task, ask! Talk to the individual or their manager. And if you do get it wrong, they will no doubt tell you and you can quickly assign someone else.
Tip 2: Check who has time available
Using the resource planning features in ProjectManager.com makes it easy to see who has time available to take on more tasks. These team members are under-allocated, so they have some slack in their day to do additional work. That can either be on your project, or on another project.
Tip 3: Check who has too much work
Some people on your project team may have too many tasks allocated to them. Again, you can use the resource planning reports and views to check who on the team is overstretched. Having too much to do can put additional stresses on your team members and reduce morale in the team, so it is good to know that with a few clicks you can see who might be struggling with a large workload.
Tip 4: Monitor progress regularly
Things change on projects all the time, and someone who had too much to do last week may have made lots of progress and is now managing their tasks effectively within the available time. Equally, someone who was under-utilized may find that suddenly they have a lot to do as a task has turned out to be bigger than anyone expected.
Check your resource scheduling reports regularly to ensure that the team is making progress and that everyone has a good balance of work. You'll also be able to identify when someone becomes available to pick up new tasks.
Tip 5: Reallocate tasks as necessary
If someone has too many tasks, you can reallocate some of their work to another person who has the experience to do the job. Talk to both people before you make the change online in your project management software, so they know what to expect when they next check their task allocations.
Reallocating tasks is a way of spreading the workload across all the members of the team and any other experts, so it is a good way to keep morale high and make the best use of everyone's skills.
The resource scheduling features of ProjectManager.com enable you to easily allocate tasks to the right people. You will have confidence that they are all working on the right tasks at the right time.

lundi 24 juin 2013

10 important lessons I've learned as a remote engineer

A lire sur:  http://www.techrepublic.com/blog/10things/10-important-lessons-ive-learned-as-a-remote-engineer/3758

Takeaway: It takes a special kind of person to handle the remote support role. But for the right tech, the work can be enormously satisfying.

I’ve been doing remote support for quite a while now, and the journey has certainly been an enlightening one. At any given point, it has been an exercise in frustration, satisfaction, and humor. The biggest challenge to the remote engineer is that you have one added element between you and success — the end user. For many IT pros, that’s just not acceptable. Fortunately, those support personnel aren’t doing remote support. It has been quite the learning experience — one every young hotshot coming out of a comp sci program should have to endure. Why? Because, in the end, they’ll better grasp the fundamentals of the desktop PC as well as those who use them.
What are the more important lessons to be taken away from being a remote engineer? Here are 10 you can read and live vicariously though my experience.

1: The lack of computer literacy is astonishing

It never fails to amaze me that there are so many out there who depend upon the PC to do their job — while at the same time have zero knowledge of the tool. That is not to say they are completely bereft of skills or intelligence. But if you work at a PC all day, you should at least know how to enter a URL into a browser. I can’t tell you how many times I’ve instructed the end user to enter a particular web address into a browser only to be asked, “What’s a web browser?” Sometimes I want to respond, “It’s the application you probably use day in and day out to do your job!” Either that or… “Think Facebook.”

2: People want to get their jobs done

That’s right, the one thing in the way of end users doing their job is the remote engineer. No matter how frustrating your job is, it is crucial to remember that the person you’re trying to help can’t do their job until you do yours. That means the longer it takes you, the less patient they will be. The less patient the end user, the harder your job will be. I go into every remote session with the understanding that the end user just wants to be able to work. If they can’t work, they wind up staying late. And no one wants to do that.

3: Patience is the only answer

If you do not have patience, you should seriously reconsider doing remote support. I have spent hour-long appointments where the first 50 minutes were trying to walk the end user through just getting me into his or her machine and the last five or 10 minutes solving the problem. It takes a special hand to deal with that level of end user, and without patience, you are doomed to fail.

4: Occam’s razor almost always applies

It’s taken me a while to develop this approach — but no matter the issue, I always start with the simplest possible solution, even if it’s a reboot of the desktop. Often, the simplest answer will work, saving you time and saving the client money. That is a win-win. The client will love you for solving the issue so quickly, and you can move on to other end-user problems. Granted, Occam’s razor doesn’t always apply; but when it does, it’s a real blessing.

5: There are times when you have to step away

It happens: You dive into waters deeper than you can handle or a problem continues to evade you. In those situations, it’s always best to step away. That might mean putting the client on hold and catching your breath or telling the client the machine has to come into the office. A fresh pair of eyes or a fresh perspective could be all you need to get a win on this one. But it’s important to know when it’s time to put the mouse down and call it. And it’s usually best to call it sooner rather than later. If you continue to struggle with an issue, you’re going to wind up with an unhappy customer charged for your failure. Give yourself a time limit on certain issues. When you reach that limit, let the customer know that either you’re going to have to come out and resolve the issue or the machine will have to come to your office.

6: Smartphone issues require special attention

I have a number of smartphones at my desk. When a client has an issue with a smartphone, I try to match up the smartphone I have that best suits what the client is using. With that, I can more easily walk through the troubleshooting process. And having the phone on hand allows you to better describe to end users what they should see. If you don’t have a similar smartphone, you will need to rely on end users to describe, in detail, what they are seeing.

7: The more details you get, the better your chances

Even before you dive into the problem solving, you need to gather as much information as possible — the more detailed, the better. Find out what end users were doing when the problem started, what they have done since, what the expected behavior should be, what platform they’re using, any passwords they might have, whether they’re connecting to a server, etc. There will be information you won’t be able to get from the end user, such as IP addresses of servers, admin passwords, and router information. Remember, you have to set yourself up for a win even before you pick up the phone to call. Don’t set yourself up to put them on hold just to gather information.

8: It’s important to take notes (because the problem will return)

Remember that really obscure fix you used to solve problem X a few months ago? No? Well, it’s returned to another client, and now you have to retrace your steps to solve the problem again. That is wasted time. Instead of finding yourself in this position, make notes of what you do to solve issues (unless it’s a common issue). Doing this will not only make your job easier, it’ll make it faster. In the world of remote support, efficiency is king. Go into every job with as much information as possible and your chances of success are much improved.

9: Not all remote tools are created equal

RDP is great for servers. But when you’re dealing with desktop machines, you’re looking at tools like TeamViewer or LogMeIn. Both of these tools do a great job of getting you into a client’s desktop and even working with the Windows 7 UAC and multiple monitor setups and handling file transfers. If you’re using anything that falls short in those areas, you are doing yourself a serious disservice. You might wind up having to purchase a full-blown support license for such a product. But it’s worth it. Yes, some are costly, but they are a necessary cost of doing remote support.

10: You have to know when to call in the cavalry

There are certain instances when the only route to success is calling in vendor support. This is especially true when you’re dealing with niche software that has zero documentation and is not a friend of Google. In that case, your best first move is to get the third-party support on the phone, remote them in, and let them handle the task. In fact, when a client calls in about their niche software, the first thing I ask is whether they have a support contract with the vendor. If they do, I’ll tell them to call them first and if they can’t resolve the issue to call me back. This helps save them money and makes you look like the good guy in the end.

Fulfillment

Remote support is a special beast that requires a special kind of engineer. It’s not just about patience or a soothing voice. You must have a specific approach to the very work you do. After numerous years of remote support, I’ve learned that the position takes a certain kind of person for any level of success to be achieved. It’s not the easiest path, but it has its own flavor of rewards that most in the IT industry would find fulfilling.

jeudi 20 juin 2013

Basics of Procurement

A lire sur:  Method123


Procurement refers to obtaining goods and services from outside companies. This specifically refers to vendors and suppliers. It does not refer to other internal organizations within your own company. (For the purposes of this discussion, "purchasing" and "procurement" are equivalent terms.) This is an area that project managers definitely need to understand at some level, and it is an area into which the project manager will give input. However, in many, and perhaps most companies, procurement is an area that the project manager does not own. The project manager normally does not have the authority to enter into contracts on behalf of the company, and he normally is not asked to administer the contracts once they are in place. (In some organizations the project managers have this authority, but my perception is that in most organizations they don't.) 
If you are purchasing goods or services on your project, you should determine whether you will simply follow the procurement contracts and plans that are already established by your company or your organization.
Examples
  • You may purchase hardware from companies using a pre-existing company contract.
  • You may acquire contactors using a pre-selected preferred vendor list.
In some cases, the vendor identification and selection processes occur at an organization level.
For instance, your company may purchase a Customer Relationship Management (CRM) system based on high-level management requirements. This CRM system would then be used on all subsequent projects - regardless of the specific needs of each individual project.
If your project team is actually conducting the vendor identification and selection process, you have some flexibility on when it is done. Many project teams perform the vendor identification and selection processes during the project Analysis Phase. This would be the case if you need to better understand your business requirements before you determine the vendor that can best meet the requirements.
Once the vendor is chosen, there are many procurement processes that are part of project management monitoring and control. This includes monitoring the vendor progress, answering questions, validating invoices, paying invoices, managing contractual issues, etc. Ultimately the procurement process concludes when the project is completed and all project contracts are closed.
In general the processes and techniques for procurement are not so hard, but it is an area where many project managers don't have a lot of experience. In fact, many project managers only acquire procurement knowledge as a way to pass the PMP Exam.  

mercredi 19 juin 2013

How to prioritize your organization's projects

A lire sur:  http://www.techrepublic.com/blog/cio-for-hire/how-to-prioritize-your-organizations-projects/125

Here are some tips for how to successfully prioritize your organization’s projects with management. I also include a sample PowerPoint presentation you can use to communicate your concepts.
——————————————————————————————————————-
You have all your projects in a central repository and have estimated the cost, the benefit, the resource requirements, the time frame for delivery, etc.
Now comes the fun part: Sitting down with management to prioritize projects. This is an active process. New projects and opportunities occur regularly and priorities need to be revisited regularly. What is very important today could be less important than a new opportunity tomorrow. Project funds get shifted around, projects get killed, resources get reallocated, etc.
The approach that made the most sense logically for me (but has not worked great in practice…yet) is to have company directors and vice presidents collaborate on the priority lists. These are typically the main stake holders for the projects and it is helpful for this group to understand what projects are being proposed and where their project(s) fit in. They scour the business cases for feasibility and ask all the right questions. This way, the bulk of the work is done for the next group, the executive team.
The idea is to have all the business cases and first stab prioritization basically squared away so the executive team can just make the decisions and IT can ramp up the project engine quickly. The problem I ran into was lack of participation of the initial management review. Because of this, the executive meetings took forever to get approvals for projects. All the questions that were supposed to be asked and answered in the previous step didn’t happen. The accountability for the entire scrubbing process fell to the PMO team and that is NOT a situation you want. There are a couple of root causes that I have uncovered, however. One could be that the executive team did not have faith in the VP and Director level to ask the right questions. The second, which is more likely, is the executive team did not see that accountability for project prioritization to be at the VP or director level.
Regardless, the goal of the PMO meetings is to get to yes or no decisions quickly so the company can start realizing the business benefits of the project. The decisions at the executive steering committee level would be:
  1. This project makes sense, we have the budget, and we have the resources. This project will allow us to further the goals of the company strategy. APPROVED.
  2. This project has possibilities. Strategic alignment is there. The business benefit is not as high as others, but we have the budget. APPROVED.
  3. This project has possibilities. Strategic alignment is there. The business benefit is not as high as others. We do NOT have budget or resources. DENIED.
  4. This project can have a pretty large impact on our business. Strategic alignment is there. We have the budget, but we do NOT have the resources to execute the project. APPROVED for outsourcing project execution or DENIED
  5. This project is very important. It will further our strategy further and faster than any project we have going on, but we don’t have the budget or the resources. What do we have to kill, delay or defer to make this project happen? APPROVED
(Here’s a sample PowerPoint presentation that may help you communicate these concepts and clarify roles and responsibilities.) That’s it. The VP/director tier will make sure that nothing but aligned projects find their way to the executive steering committee. If not, then the process needs to be refined. The project spreadsheet will aid you in figuring out what projects in the portfolio can be moved around to accommodate changes. Flexibility, speed of decision making, strategic alignment objectives achieved.
Once the decisions are made, executive sponsors are assigned to a project. For currently running projects, it is the executive sponsor that provides the status update. I do have to say that in all my years of doing this, I have not been able to get the executive sponsor to provide the status update. It is usually done by the PMO director or you, the IT leader. But it sure would be nice to have an executive demonstrate their accountability to a project like that wouldn’t it?