Migrer un parc informatique sur une nouvelle version de système d’exploitation

Changer de version de système dans une entreprise

L’informatique fait partie de ses technologies qui évoluent rapidement.

A peine une version de système d’exploitation est-elle installée dans les serveurs qu’il faut préparer la prochaine migration.

Les performances de l’entreprise sont liées aux performances de son système d’information et donc de toute son infrastructure informatique.

Les coûts induits par un changement imposé par les fabricants d’ordinateur et autres matériels représentent une part importante des dépenses d’une entreprise, surtout lorsqu’il s’agit d’une entreprise de services, comme une banque ou une assurance.

Comment gérer un tel grand projet, sur des lieux multiples, pour que tout se passe bien ?

Première étape : un inventaire

il convient tout d’abord d’avoir un inventaire complet de toutes les machines concernées : matériels et logiciels.
Comme elles ne vont pas être changées ou évoluées en même temps, il va falloir travailler par lieux et par lots, ce qui est la bonne démarche.

L’objectif premier est la continuité du service.
Une fois la procédure rodée, de préférence sur un petit nombre de machines dans un lieu le moins critique possible, elle pourra être étendue et améliorée au fur et à mesure des changements.

L’équipe de projet étendue

L’équipe de projet sera composée de personnels locaux et d’une équipe mobile (ou plusieurs selon le nombre de lieux).

L’équipe locale sera en charge de l’installation de la nouvelle version.
A elle de préparer le personnel utilisateur des éventuelles perturbations et de préparer un plan de secours en cas d’incident en cours de migration.

L’équipe mobile devra être capable de conseiller l’équipe locale dans la procédure et en cas d’incident pour trouver le plus vite possible une solution aux problèmes éventuels.

Changer ou garder le matériel

Deux cas se présentent :

• • Remplacement des ordinateurs incapables de supporter le nouveau système
  • Conserver les ordinateurs, quitte à les faire évoluer, par exemple en ajoutant de la mémoire

Les vérifications de bon fonctionnement

La migration en tant que telle est techniquement de la routine.

Par contre, il y a des tests de bon fonctionnement à faire après réinstallation de tous les logiciels utilisés.
Plus ils sont nombreux et plus le contrôle du bon fonctionnement des logiciels sera long.

De plus, les logiciels doivent être compatibles avec la nouvelle version.
Généralement, c’est le cas, mais parfois le fournisseur du logiciel ou vos développeurs devront mettre en place une nouvelle version du logiciel, compatible.

Mieux vaut avoir prévu suffisamment de temps, de disponibilité des compétences et un budget pour cette partie du grand projet.

Documentation et communication

Il est impératif de rédiger une documentation pour les techniciens, par l’équipe mobile pour pallier à toute erreur dans la migration.

Par ailleurs, il faut une communication à destination des responsables et des utilisateurs avec dates précises des interventions.
Lire la suite dans ce second article

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Système d’exploitation
UNIX
Salle informatique : Quelle surface faut-il prévoir ?

DSI RSI Mieux communiquer en interne en cinq conseils
Windows propre ou le nettoyage physique se confond avec le virtuel
Loi de Heare des grands programmes

Autres  Informatique et Management :

Récapitulatif 19 Informatique
Récapitulatif 19 Management

Sécurité informatique : L’audit des vulnérabilités

L’audit des vulnérabilités

L’épée de Damoclès

Dans le cadre de la sécurité informatique et des mesures à prendre pour pallier aux défauts, pannes, malveillance, etc., il convient de faire le point sur les mesures déjà existantes avant d’envisager d’étendre la protection du système d’information.

La vulnérabilité

La vulnérabilité est le caractère, qui, par ses insuffisances, ses imperfections, peut donner prise à des attaques (Petit Larousse).

C’est au travers d’un audit des vulnérabilités d’un système d’information, que l’on va évaluer son degré de maturité en termes de protection.

Moins il y a de vulnérabilités et mieux le SI sera protégé

Comme l’informatique et les systèmes d’information évoluent en permanence et à une vitesse toujours de plus en plus croissante, l’audit des vulnérabilités est donc à reconduire régulièrement.
Dans l’idéal, ce sera à chaque changement d’un des composants physiques ou logiciels.

Cependant, dans la réalité et pour tenir compte de l’établissement des budgets dans une organisation, c’est une fois par an que cet audit devrait avoir lieu.

Les domaines de l’audit

Le systématisme est nécessaire pour éviter d’oublier l’un ou l’autre des domaines d’un système d’information dans l’audit des vulnérabilités.

Voici les domaines de cette analyse :

1. Organisation de la sécurité
2. Sécurité des sites et des bâtiments
3. Sécurité des locaux
    
4. Réseau étendu (intersites)
5. Réseau local (LAN)
6. Exploitation des réseaux
    
7. Sécurité des systèmes et de leur architecture
8. Production informatique
9. Sécurité applicative
    
10. Sécurité des projets et développements applicatifs
11. Protection de l’environnement de travail
12. Juridique et réglementaire

Les questions à se poser

Pour analyser ces 12 domaines, il convient de se poser les questions appropriées à chacun d’eux :

1. Qui s’occupe de la sécurité ? Avec quels moyens et quel mode de fonctionnement ?
2. Comment les sites et les bâtiments sont-ils surveillés et protégés : gardien de nuit, caméras, etc. ?
3. Quels systèmes sont en place : alarme, détecteur de présence, anti-incendie, identification des visiteurs, etc. ?
    
4. Quels moyens ont été déployés pour protéger l’accès à distance des informations : identification, chiffrement, etc. ?
5. Comment et par quoi le réseau local est-il protégé : parafoudre, pare-feu, armoires de brassage fermées, etc. ?
6. Quels sont les moyens de pallier aux défauts de l’exploitation du réseau : maintenance des serveurs, enregistrements des mouvements des personnels (arrivants et partants), etc. ?
    
7. Comment les systèmes et architectures sont-ils protégés : sauvegardes, virtualisation, etc. ?
8. Par quels moyens la production informatique, c’est-à-dire les données sortantes du système d’information sous forme de papier ou à l’écran, est-elle protégée ?
9. Comment les applications, progiciels ou logiciels sont-elles sécurisées : autorisations d’accès, archivage des versions, etc. ?
    
10. De quelles manières sont protégés les projets informatiques, de l’idée à leur réalisation : fuite d’information, erreurs de programmation, paramétrages, etc. ?
11. Quelles sont les protections de l’environnement de travail en place : démultiplication des prises, fermeture des écrans inutilisés pendant quelques minutes, etc.
12. Quelles mesures de bons comportements sont-elles en place : déclarations CNIL, charte informatique et d’Internet, etc. ?

Cette liste de questions et les quelques exemples associés montrent l’étendu, non exhaustif, des questionnaires à mettre en place pour déterminer le degré de maturité des mesures de protection contre les vulnérabilités détectées.

Vigilance

Il faut être particulièrement vigilant en matière de sécurité informatique.

Par exemple, pour le point 1, il faut que le responsable de la sécurité informatique soit une personne indépendante de la hiérarchie des informaticiens. Son indépendance vis-à-vis de cette hiérarchie va permettre de surveiller et d’agir contre tout informaticien indélicat, responsable du service inclus.

Pour cela,

• soit un service séparé doit être défini et rattaché, par exemple, directement au responsable de l’établissement, pour une entreprise importante,
• soit à un collaborateur d’un autre service qui en sache suffisamment en matière informatique, pour des organisations plus petites.

Philippe Garin, plus de 20 ans de management en entreprise

Pour mieux protéger votre système d’informations, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Lexique informatique
Menace – Vulnérabilité – Risque
Parefeu : Utilité et risques

Liste des risques de sécurité informatique
Plan d’un rapport d’audit en entreprise
RCO, LCC et MTBF expliqués pour les nuls

Autres Informatique, Management, Organisation et Sécurité :

Récapitulatif 15 Informatique
Récapitulatif 15 Management
Récapitulatif 15 Organisation
Récapitulatif 15 Sécurité

Management de projet : 5 causes de l’échec

Une étude menée par Standish Group aux États-Unis indique que seulement 16% des projets se terminent dans les budgets et délais initiaux, et seulement 9% dans les grandes entreprises.

Fort de ce constat, il faut reconnaître que les dépassements, de budget ou de délais, sont tellement courants que les prévisions et les estimations de coûts sont systématiquement faussées malgré les 10 à 20% de « réserve pour dépassement » que le responsable interne ou l’entreprise extérieure ajoute, « à toutes fins utiles ».

L’échec d’un projet se traduit par les dépassements et aussi par un arrêt du projet, ce qui représente une perte sèche pour l’entreprise et pire un retour en arrière, lorsque c’est encore possible.

Les causes de l’échec

Les causes de l’échec sont multiples. Elles sont présentes tout au long du projet, à commencer par la définition du projet, de la description de la situation en cours à la situation prévue, en passant par toutes les étapes d’un projet. Le choix des participants au projet est du ressort du management. Plus le projet est important pour l’entreprise et plus haut remontent la responsabilité.

Des exemples :

• La mise en place d’un nouveau serveur informatique est du ressort du responsable technique du service informatique, voire du responsable informatique.
• La mise en place d’un système de surveillance d’un bâtiment est du ressort du responsable de l’établissement.
• L’achat d’une entreprise qui va devenir filiale est du ressort du comité directeur, voire du patron lui-même.

Parmi toutes les causes possibles, en voici 5 qui nous paraissent intéressantes à analyser ;

1. La peur du changement

C’est LE classique. Le motif le plus courant est la peur du changement. C’est une illustration de la peur de l’inconnu, du futur, de devoir changer ses habitudes, de ne pas être à la hauteur. C’est la crainte de la perte de son pouvoir, de son image ou que l’on découvre son incompétence bien cachée jusque là.

2. La rivalité

Dès qu’un nouveau projet est évoqué, la rivalité entre personnes devient plus apparente. Les conflits augmentent avec les enjeux du projet, politiques, personnels, financiers.

La rivalité commence à l’intérieur de l’organisation, et se poursuit entre les acteurs internes et externes à la société, et même entre fournisseurs concurrents.

Toutes ces questions de personnes, entre compétences et égos, conduisent à des pertes de temps, d’argent, de ressources matérielles et humaines, donc à l’échec du projet.

3. Le résultat

La difficulté pour le décideur consiste à s’imaginer le résultat auquel il veut parvenir, puis à choisir la personne qui mènera le projet jusqu’à son terme et dans le budget prévu, – cette personne peut être elle-même -enfin, la description du chemin par lequel il faut passer pour parvenir au résultat attendu. Le projet est composé de plusieurs tâches : Les unes se succèdent alors que d’autres peuvent être exécutées par des acteurs différents, en parallèle, c’est-à-dire en même temps.

Selon l’ampleur du projet, des jalons avec dates précises et résultats intermédiaires précis, sont fixés ou sont complètement absents. Le manque de jalons ou points de situation intermédiaires, le manque de contrôle et de rapports du chef du projet au décideur conduisent immanquablement à l’échec.

4. Les mesures

Pour anticiper et réagir aux aléas d’un projet, plusieurs indicateurs sont nécessaires. Quel que soit le degré d’importance du projet, il faut être capable de mesurer son avancement et sa réussite, tout au long du projet et pas seulement en constatant le résultat final ou intermédiaire obtenu. Cependant, que les mesures soient définies, dans les tableaux de bord, en jours/homme, en rapport dépenses/économies ou gain, ces chiffres sont souvent inutilisables ou/et incompréhensibles pour le décideur. Même un chef de projet professionnel est amené à « sentir » l’avancement de son projet, malgré toute la rigueur et l’organisation mises en place. Il reste que nombre d’actions nécessaires pour mener une tâche à bien sont improvisés. Donc, dérapage et échec à la clé.

5. Les outils de pilotage

Plus une entreprise est grande ou plus le nombre de projet est important pour l’organisation et plus la présence d’outils de pilotage de projets est nécessaire et même indispensable.

Le nombre de tâches et les enchaînements entre elles devient croissant au point de devoir se procurer des outils qui vont indiquer à chaque collaborateur impliqué dans les projets, la liste des tâches à accomplir à chaque journée planifiée, avec quels moyens techniques ou en coordination avec d’autres personnes, en interne ou externes à l’entreprise.

Plus le pilotage est informatisé et plus le chef de projet se base sur ses outils et moins sur les relations humaines, pourtant indispensables. L’encouragement ou la réprimande font partie des éléments de motivation du responsable du projet vis-à-vis de ses collaborateurs. Passer à côté de cela et c’est l’échec assuré.

Des règles de bon sens

• Sortir la tête du guidon est un bon moyen de faire le point « vu d’en haut » (certains disent « vu d’avion »)
• Se faire accompagner par une personne extérieure au projet, comme un organisateur ou un responsable qualité ou encore un coach, permet de poser le crayon et de se demander si et comment les méthodes employées vont conduire au succès du projet.
• Définir des jalons est bien ; définir les « délivrables » est mieux. Il s’agit de résultats intermédiaires documentés. La documentation doit être terminée, sans remise en question par des jalons précédents. Si ce n’est pas le cas ou si la qualité est insuffisante, alors il faut corriger, refaire ou abandonner, avant d’aller plus loin vers l’échec.
• Savoir de quoi on parle et choisir les indicateurs de pilotage compréhensibles par tout et utiles pour prendre des décisions. Là encore, le bon sens doit permettre de s’y retrouver suffisamment facilement pour comprendre, juger et décider de la suite à donner, attribuer des félicitations, des encouragements ou des reproches.
• Former le personnel aux outils, notamment le responsable au pilotage de son ou ses projets, permet de gagner du temps et de monter d’un ou plusieurs degrés la qualité du management et les chances de succès du projet.
• Penser que l’échec d’un projet est une exception et non la règle malgré tous les risques que le projet contient par sa nature.

C’est avec des principes de bon sens que la rivalité entre personnes sera amoindrie et les conflits entre personnes réduits.

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en avoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Un cahier des charges pour éviter des conflits entre client et fournisseur
Que se passerait-il si le projet n’avait pas lieu ?
Le TCO ne suffit pas pour changer de logiciel en entreprise

Évolution du besoin en cours de projet
Analyse de dysfonctionnements et réduction de coûts cachés en 10 étapes
A savoir sur la gestion des ressources pour un chef de projet

Autres Management :

Récapitulatif 14 Management

Projet : Que se passerait-il si le projet n’avait pas lieu ?

Gestion de Projet : Que se passerait-il si le projet n’avait pas lieu ? Ou s’il était retardé ?

Voilà une question que le donneur d’ordre, le maître d’ouvrage, doit se poser lorsqu’il souhaite lancer un nouveau projet, informatique ou autre.

Plusieurs facteurs rendent le démarrage d’un projet indispensable

• Les contraintes législatives : Le passage à l’Euro a été imposé à tous, les changements de taux de TVA, etc.
• Les changements de réglementations dans son domaine d’activité : Accords de branche et conventions collectives, traçabilité des produits dans la Distribution, etc.
• La concurrence : Nécessité de mener des actions marketing ou commerciales pour contrer les attaques de la concurrence
• La position de leader, l’image de la société : Lancement de projets de « prestige », construction de beaux bâtiments, dont les aménagements doivent rassurer le client ou le banquier
• Etc.

Dans tous les cas, c’est la volonté du dirigeant de l’entreprise qui donne l’impulsion et dénoue les cordons de la bourse, mobilise le personnel pour œuvrer dans le projet

Un chef d’entreprise qui, mis au courant des risques pris pour l’entreprise, du démarrage, du retard ou de l’abandon d’un projet, dois prendre la décision qui convient.

La question se pose d’abord avant de lancer le projet.

Elle se pose aussi et différemment quand le projet a déjà démarré, car des frais ont été engagés, des autorisations ont été parfois demandées

• Choisira-t-il de maintenir sa décision initiale, malgré les risques ?
• Changera-t-il d’avis ?
• Quel sera l’impact de cette nouvelle décision sur son image en tant que manager auprès de ses employés, de ses concurrents, de ses fournisseurs, de ses clients ?
• Combien cela lui coûtera-t-il de maintenir sa décision ou d’en changer ?

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Projet : Go / no Go ou Faut-il y aller ;?
Règles et axiomes d’un chef de projet en trois langues
Bien définir son besoin

Questions à poser à un client de référence
Modèle de cahier des charges
Questions préliminaires liées au Management de projet

Autres Informatique et Management :

Récapitulatif 1 Informatique
Récapitulatif 2 Informatique
Récapitulatif 7 Informatique
Récapitulatif 5 Management
Récapitulatif 7 Management

Tous les articles de ces catégories sont listés dans les pages Informatique et Management

Management de projet : Neuf erreurs les plus courantes du Chef de projet

Les 9 erreurs les plus courantes du Chef de projet

Sous la pression de son donneur d’ordre, un chef de projet informatique, ou autre, a peu de moyens pour réaliser son projet dans le temps imparti.

Parfois, la date de fin est imposée, parfois c’est lui qui doit la donner.

Dans les 2 cas, le dépassement est plus ou moins long. Très rares sont les projets qui finissent à la date prévue.

Voici une liste des 9 erreurs les plus courantes qui conduisent à un retard :

1. Prendre en compte des besoins mal définis
2. Se précipiter au début du projet
3. Sous estimer la charge, les moyens et les coûts
4. Accepter des évolutions fonctionnelles demandées en cours de projet, sans révision du projet
5. Nommer une équipe sans diversité des talents et compétences techniques (débutant, expérimentés)
6. Rester inflexible sur une méthodologie trop lourde et trop contraignante
7. Choisir des outils aux contraintes techniques trop rigides
8. Choisir des technologies trop récentes et potentiellement non pérennes
9. Ne pas suffisamment penser aux évolutions dans le temps du système d’information, objet du cahier des charges

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Règles et axiomes d’un chef de projet
Les 11 phases du déroulement d’un projet informatique
Le rôle des ressources internes dans un projet

Rôle des acteurs majeurs dans un projet
Ajouter des ressources en cours de projet ou le principe chinois
Composition d’une équipe de projet : juniors et seniors

Autres Informatique :

Récapitulatif 6 ;informatique

Tous les articles de cette catégorie sont listés dans la Page Informatique

Le rôle des ressources internes dans un projet

Un des rôles du Chef de Projet est de désigner les personnes qui vont travailler dans le projet : les ressources.

Il y a ceux qui vont y travailler de bout en bout et ceux qui interviendront sur une partie du projet.

Utiliser des ressources internes à l’entreprise qui a décidé du projet est la première idée qui vient à l’esprit.

Qui sont les ressources internes ?

Pour un projet informatique, le service informatique est sollicité. C’est son travail habituel. Les informaticiens sont là pour cela. Ils en ont l’habitude.

Cependant, si la finalité du projet est la mise à disposition d’utilisateurs fonctionnels un logiciel ou un matériel alors les utilisateurs doivent être représentés dans le projet.

En général, le responsable hiérarchique, chef de service ou directeur, est impliqué dans le projet, dans la mesure où il décide du temps qu’il accorde à son ou ses collaborateurs pour travailler dans le projet.

Le meilleur choix est celui qui consiste à désigner l’utilisateur final ou l’un des futurs utilisateurs, celui qui sera confronté aux résultats du projet.

Il faut qu’il soit motivé et convaincu que son apport dans le projet sera déterminant pour sa réussite.

Comment motiver la ressource interne ?

Le Chef de projet se verra amener à le motiver car cet utilisateur considérera ses activités dans le projet comme un surcroît de travail, car il privilégiera son travail quotidien aux tâches du projet.

Le représentant des « fonctionnels » dans un projet a pour tâches :

• D’expliquer le fonctionnement actuel et futur des activités à informatiser ou à améliorer
• De participer au paramétrage du logiciel
• De définir les résultats attendus, tant dans les saisies des informations que leurs traitements et la restitution des résultats, sous forme d’écrans de saisie ou de lecture, d’éditions ; etc.
• De tester les programmes et de vérifier que les résultats soient conformes aux attentes
• De valider le travail des informaticiens
• De rédiger les manuels utilisateurs ou d’y prendre part, de façon à ce que le vocabulaire utilisé soit son propre langage professionnel et non pas celui des informaticiens
• De former ou/et d’informer sa hiérarchie et ses collègues, futurs utilisateurs, de l’avancement du projet

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Rôle des acteurs majeurs dans un projet
Ajouter des ressources en cours de projet ou le principe chinois
Estimez la charge de travail, le coût et l’implication à leurs justes valeurs

Stress : maladie contagieuse ou faute du management ?
Devise 033 : ça ne fait pas de mal de flatter son patron
Management de projet informatique : Neuf erreurs les plus courantes du Chef de projet

Autres Informatique :

Récapitulatif 5 Informatique

Rôle des acteurs majeurs dans un projet

source : Wikimedia

Désigner, nommer une ressource dans un projet, c’est désigner les personnes qui vont travailler dans le projet, c’est-à-dire exécuter les tâches à réaliser pour mener le projet à bien.

La nomination des ressources est une des premières tâches du chef de projet.

Lorsque le projet est important, pour la stratégie de l’entreprise, la Direction créé un Comité de Pilotage.

Le Comité de Pilotage,

composé généralement de la Direction Générale ou/et du PDG, et des Responsables fonctionnels concernés, en plus du Chef de Projet

• définie les limites du projet, c’est-à-dire les objectifs du projet,
• fixe un budget,
• nomme le Chef de projet

A son tour, le Chef de projet,

• découpe le projet en tâches, plus ou moins élémentaires selon l’ampleur du projet
• désigne les ressources matérielles et humaines, nécessaires pour l’exécution des tâches
• estime et calcule la durée des tâches et fixe les points de contrôle et la date de fin du projet

NB : La date de fin du projet peut être l’un des objectifs fixés par le Comité de Pilotage ou Comité de Projet, en anglais Steering Comitee, à moins que des événements extérieurs imposent la date de fin, par exemple, la date de début d’une nouvelle réglementation ou d’une loi.

Souvent, la notion de projet démarre avec la maîtrise d’œuvre.

A partir d’un cahier des charges, le Chef de projet démarre le projet.

Néanmoins, pour les projets importants, la maîtrise d’ouvrage fait souvent partie du projet. C’est la partie en amont du projet ou au début du projet qui permet de définir le besoin et de rédiger le cahier des charges. La maîtrise d’ouvrage est assimilée au donneur d’ordres.

A partir d’une seule analyse de besoins, plusieurs projets peuvent être définis et mis en œuvre, l’un après l’autre ou en parallèle.

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Plan compte rendu Comité de projet
Organisation de la Gestion de Projet
Composition d’une équipe de projet : juniors et seniors

A savoir sur la gestion des ressources pour un chef de projet
Evaluation de projet : L’échelle européenne
Le rôle des ressources internes dans un projet

Autres Informatique :

Récapitulatif 5 Informatique

ITIL CMM Méthode de gestion de projet libération ou contrainte

Que ce soit CMM, méthode maintenant historique, ou ITIL, plus un catalogue de bonnes pratiques, la gestion de projet fait l’objet d’un ensemble de méthodologies qui permet de suivre des principes.

C’est une libération pour l’esprit des chefs de projet dans la mesure où une bonne liste de tâches à accomplir, une liste de documents à fournir, etc. permet de gagner du temps dans l’organisation et le déroulement d’un projet.

Par contre, ces méthodes apportent aussi leurs contraintes, si le chef de projet les suit à la lettre.

Plus le projet est important en nombre de jours de travail, plus il est important d’appliquer une méthode.
La coordination entre les différents acteurs dans le projet est plus importante dans les grands projets.

Pour des projets de moindre durée, c’est-à-dire inférieurs à 250 jours, les méthodes suivies très précisément peuvent amener une charge supplémentaire, pas toujours justifiée, aux yeux des décideurs, et plus précisément aux yeux des payeurs.

Un peu moins de formaliste, un peu moins de documents qui, certes intéressants, n’apportent pas grand-chose pour prendre des décisions et engranger du savoir-faire, est possible et même est souhaité par celui qui paye.

C’est pourquoi, le chef de projet, doit, impérativement, adapter d’une ou plusieurs méthodes de gestion à son projet.

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Les projets dérapent sur les délais, les coûts ou/et le contenu
Bien définir son besoin
Pas de précipitation au début d’un projet pour respecter les délais

Estimez la charge de travail, le coût et l’implication à leurs justes valeurs
Évolution du besoin en cours de projet
Composition d’une équipe de projet : juniors et seniors

Autres Informatique :

Récapitulatif 5 Informatique

Estimez la charge de travail, le coût et l’implication à leurs justes valeurs

Une des erreurs très répandues dans la gestion de projet, informatique ou pas, est de sous-estimer la charge de travail et ses implications financières et humaines.

Pour diminuer les coûts liés à un projet, un moyen est souvent utilisé, à savoir de prendre en charge en interne une partie des travaux. L’idée en soi est intéressante. Elle nécessite que les ressources internes soient à même d’exécuter ces tâches et surtout qu’elles soient disponibles et impliquées.

Or, s’il est habituel de disposer des informaticiens dans un projet, il est aussi indispensable d’y impliquer des fonctionnels. Ce travail de projet s’ajoute à leur travail habituel et il y a des conflits d’intérêts. D’un côté assurer le travail au quotidien, qui justifie son poste de travail à plein temps, de l’autre, une surcharge de travail causée par un projet pour l’avenir dont l’utilité, pas toujours bien expliquée ou bien comprise, est parfois incompatible.

Essayez de mettre en place un progiciel de gestion de la relation client (CRM) alors que les commerciaux sont sur la route en quasi permanence et vous comprendrez les difficultés rencontrées par un chef de projet quand il n’a pas d’interlocuteur interne sous la main. Le retard est assuré.

Donc, dès la conception du projet, il vaut mieux prévoir de surdimensionner légèrement les besoin en ressources. Il est préférable de supprimer du temps prévu avec des ressources que d’en rajouter. De même, en ajoutant 20% au budget, un éventuel surcoût pourra être intégré au budget initial.

Il est préférable d’indiquer, lorsque le projet s’est bien déroulé, que vous avez fait des économies et que vous avez réussi à anticiper la date de fin du projet que l’inverse. Rappelez-vous, du retard, il y en aura, la question en est l’ampleur. Néanmoins, par expérience de plus de vingt ans de gestion de projets, je n’ai jamais vu un projet informatique finir par anticipation !

Lorsque, en tant que chef de projet, vous constatez un dérapage, alors agissez tout de suite auprès du Comité de projet, composé des décideurs de l’entreprise pour trouver des solutions, des arbitrages pour mettre à disposition les ressources qui conviennent sans trop déranger le travail au quotidien, et aussi pour prendre des décisions.
Le comité de projet est là pour cela. Et tant pis, si certaines susceptibilités internes sont froissées par votre manque de tact.
Une bonne explication pour rappeler que vous, vous êtes jugé sur le résultat du projet, suffit généralement pour motiver les troupes et pour éliminer les personnes les moins convaincues. Cela peut aussi leur coûter leur place et ils y réfléchiront sérieusement.

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Les projets dérapent sur les délais, les coûts ou/et le contenu
Bien définir son besoin
Pas de précipitation au début d’un projet pour respecter les délais

Évolution du besoin en cours de projet
Organisation de la qualification en développement informatique
Les 11 phases du déroulement d’un projet informatique

Autres informatique :

Récapitulatif 5 Informatique

Questions préliminaires liées au Management de projet

Avant de se lancer dans un projet, le Chef de projet doit connaître les conditions dans lesquelles il va travailler.

Qu’il soit salarié ou indépendant, il faut qu’il se renseigne sur l’environnement du projet pour bien le mener à bout.

Pour cela, il faut qu’il pose des questions sur :

• Les objectifs du projet, la mission
• Les moyens de planification
• La structure du déroulement du projet
• La mise en œuvre du projet
• Les outils et moyens disponibles
• L’entreprise, maître d’ouvrage

Il faut aussi qu’il réponde à des critères de choix pour lui-même :

• Son expérience
• Des questions personnelles supplémentaires

Objectifs / mission

• Les objectifs du projet du donneur d’ordre sont-ils connus ?
• Les circonstances (par exemple, conditions d’installation) sont-elles annoncées ?
• La mission du donneur d’ordre dans chaque phase du projet est-elle claire ?
• Pouvez-vous participer à la planification des dates limites de phase et de fin de projet ?
• Êtes-vous impliqué à temps à la formulation des objectifs et des tâches ?

Planification

• Éventuelles perturbations sont-elles intégrées dans la planification ?
• Les charges de base sont-elles automatiquement prises en compte lors de la planification ?
• L’ordre des opérations optimal est-il fixé et pris en charge ?
• Je prends en compte la capacité des membres de l’équipe lors de la planification
• Je prends en compte la capacité des membres de l’équipe lors de l’exécution

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

A savoir sur la gestion des ressources pour un chef de projet
Contraintes Priorités et rapports dans la gestion de projets
Organisation de la Gestion de Projet

Plan compte rendu Comité de projet
Merise Méthode de gestion de projet obsolète
Qualification de logiciel et qualité informatique de gestion

Autres Informatique :

Récapitulatif 1 Informatique

Mesures à prendre en cas d’écart dans le planning d’un projet

Compas de Léaonard de Vinci

Les écarts dans un projet sont caractérisées clairement par :

• Des retards dans le planning et / ou
• Des dépassements de coûts et / ou
• Des retraits ou ajouts dans le système

Les écarts suivants sont le plus souvent constatés :

• a) La charge de travail a été mal (trop basse) estimée
• b) Le personnel, y compris du côté des spécialistes du domaine concerné, n’était pas autant disponible que ce qui était envisagé
• c) La qualité visée dans le développement du logiciel n’a pas été atteinte

Les mesures suivantes peuvent être prises :

Pour a), quand la charge de travail a été mal estimée

Le chef de projet / l’équipe de projet devrait reconnaître des erreurs dans l’estimation. Les causes des erreurs doivent d’abord être analysées. Avant une nouvelle estimation est de règle que les causes de l’insuffisance des progrès du projet soient incorporées dans la mesure du possible (par exemple, le mauvais niveau de formation de certains salariés, des sous-activités).

Pour b), quand le personnel n’était pas suffisamment disponible

Les mesures suivantes peuvent être, tout ou partie, prises :

• Intégrer des collaborateurs supplémentaires (en fonction de la phase et de l’avancement du projet)

=> Conséquences : augmentation du budget, augmentation de la durée par l’apprentissage du sujet par les nouveaux collaborateurs et les besoins de communication au cœur d’une équipe agrandie.
Plus cette mesure est prise tard dans le déroulement du projet, plus il est incertain, sous certaines conditions, que ces mesures apportent des avantages supplémentaires sans charge

• Aller jusqu’à 100% du temps de collaborateurs qui n’étaient pas entièrement dédié au projet

=> Conséquences : augmentation du budget

• Faire faire des heures supplémentaires aux collaborateurs prêts à les faire

=> Conséquences : augmentation du budget, mesure possible à titre temporaire seulement

• Repousser la date limite, c’est-à-dire la livraison du système

=> Conséquences : augmentation du budget, le bénéfice du projet arrive plus tard, (impact sur le comparatif entre coûts et bénéfices du projet attendus), ceci pose problème en cas de date limite fixe, par exemple, en début d’exercice

• Réduire la solution, c’est-à-dire renoncer à certains résultats ou repousser leur réalisation à une date ultérieure

=> Conséquences : une partie des avantages attendus par le projet ne s’applique pas (ou le sera plus tard), ce qui désavantage les utilisateurs dans le domaine concerné

Pour c), quand la qualité n’a pas été atteinte

Le critère de la qualité sont les livrables des résultats de phases

Des manques vont se faire dans la documentation utilisateur, qui n’est plus rédigée dans les premières phases du développement de système et, le cas échéant, dans les phases ultérieures du projet. Il ne faut cependant pas perdre de vue que chaque fois qu’il y a un travail supplémentaire – n’était pas encore prévu – il y a une charge supplémentaire.

Des lacunes dans les exécutables, dans la documentation ou un mauvais Guide de l’utilisateur et une insuffisance dans la formation (documents de formation) ont un impact très négatif sur l’acceptation du système.

Ensuite, il doit encore être dit que l’alternative la plus dangereuse lors de l’apparition d’écart est de ne rien faire avec l’espoir que le temps perdu serait rattrapé dans les phases suivantes ou dans les autres modules du projet.

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Prendre des mesures, les cinq types de mesures
Organisation de la Gestion de Projet
Suivi de hotline ou de projet

Du découpage d’un projet en tâches
Contraintes Priorités et rapports dans la gestion de projets
Règles et axiomes d’un chef de projet

Autres Informatique et Management :

Récapitulatif 1 Informatique
Récapitulatif 1-2 Management

Tous les articles de cette catégorie sont listés dans la page Informatique de ce blog

Contraintes Priorités et rapports dans la gestion de projets

Les principales contraintes d’un projet sont :

Le budget, le délai et la qualité. sont interdépendants, on ne peut pas fixer les trois.

Le seul degré de liberté d’un chef de projet est la qualité, car coûts et délais sont fixes, imposés par le client ou la hiérarchie.

Le chef de projet fixe les priorités dans les fonctions, de préférence celles qui soient les plus rentables pour l’entreprise.

Les priorités sont à fixer, dans l’ordre des critères suivants :

1. La loi du plus fort

C’est-à-dire celles qui sont imposées par la hiérarchie, en commençant par le sommet de celle-ci, ou par le client.

Toutefois, avec diplomatie et des arguments irréfutables, ces priorités peuvent être mises au second plan par la hiérarchie. Tout dépend du degré de confiance qu’elle vous fait.

S’il s’agit d’un client externe, ne cherchez pas à lui faire changer d’avis, puisqu’il vous paye pour ses priorités. Vous avez, par contre, un devoir de conseils, si vous jugez qu’elles sont inadaptées pour son entreprise.

2. Les projets ou les fonctions qui rapportent à l’entreprise

Un calcul du Retour sur Investissements, ou ROI (Return Of Investments) vous permet de les faire ressortir. Dans ce cas, vous devez vous assurez que le montant des investissements est compatible avec la date de fin du projet, autrement dit, que le financement du projet, sur fond propre ou par un financement externe, soit bien assuré sur la durée du projet, phase de stabilisation incluse.

3. Les projets ou les fonctions qui font faire des économies à l’entreprise

Les remarques sont identiques à celles des projets qui rapportent, avec un avantage cependant : il est plus facile de calculer des économies, principalement sur la diminution des dysfonctionnements, que de faire de la prospective sur les gains financiers attendus dans le premier cas.

4. Les autres projets

sont généralement mis en priorité 3, c’est-à-dire qu’ils ont très peu de chance de voir le jour. Ils sont souvent la justification de la charge de travail des équipes informatiques et de la nécessité de conserver une équipe.
La charge de travail que représente la maintenance prend le pas sur les projets de cette priorité

Plus la structure de l’entreprise est grande, plus le nombre de projets à faire ou en cours est important. C’est pourquoi, le niveau de vision du projet dépend du niveau de la hiérarchie.

Exemple :

• 1 fiche de travail pour la ressource de base
• 1 projet sur une page A4 pour le chef de projet
• 5 projets sur une page A4 pour le chef de développement (peu importe la désignation dans l’entreprise)
• 20 projets sur une page A4 pour le directeur technique, le chef de service, la hiérarchie

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

A savoir sur la gestion des ressources pour un chef de projet
Liste des Coûts et Produits des projets informatiques
Organisation de la Gestion de Projet

Questions préliminaires liées au Management de projet
Plan compte rendu Comité de projet
Suivi de hotline ou de projet

Autres Informatique :

Récapitulatif 1 Informatique

Du découpage d’un projet en tâches

Toute tâche doit être documentée

C’est en fonction de l’ampleur de la tâche que la description est plus ou moins importante.
Les contraintes dans les interfaces avec les autres tâches doivent figurer dans les spécifications, qu’il s’agisse d’une tâche de développement, de tests, d’une installation de matériel ou d’une réunion d’étape.

Le découpage d’un projet en étapes, puis en phases, puis en tâches élémentaires, est du ressort de l’expérience du chef de projet.

Plus on divise le temps et plus la prévision et les volumes augmentent dans le temps.

La meilleure méthode d’estimation est donc l’analogie

avec d’autres projets, qu’ils aient été effectués par le chef de projet ou par un de ses collègues.

Une étape dans un projet est un tout : spécifications, documentation, livraison des programmes.

Une étape fait partie d’une phase pour laquelle il y a une étude préalable.

La méthode d’estimation COCOMO

donne un aperçu des facteurs critiques en fonction de la taille du projet :

• Petits projets : Aspects techniques
• Moyens projets : Gestion de projet
• Grands projets : Assurance qualité

Lorsqu’un chef de projet procède au découpage de son projet en tâches, il doit faire en sorte que les tâches du chemin critique aient le moins d’imprécision dans l’estimation de la durée.

Autres conseils sur les tâches :

Au début d’un projet, exigez un diagramme de charge, c’est-à-dire l’occupation des personnes sur le temps.

La complexité augmente de façon exponentielle avec le temps.

4 programmes de 5 000 lignes sont moins complexes qu’un programme de 20 000 lignes. Privilégiez le découpage des gros programmes en plus petits.

La codification d’un programme contient le texte de la spécification à programmer, la documentation technique validée et la documentation fonctionnelle validée pour les utilisateurs et le code proprement dit.

Si un seul de ces composants manque alors la tâche de codification n’est pas terminée.

Philippe Garin

Pour booster votre management de projet, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

De la planification d’un projet
Mesures à prendre en cas d’écart dans le planning d’un projet
Ajouter des ressources en cours de projet ou le principe chinois

Composition d’une équipe de projet : juniors et seniors
Règles et axiomes d’un chef de projet
Lois de programmation des ordinateurs

Autres Informatique :

Récapitulatif 1 Informatique

Méthode Jackson de développement

Jackson a inventé tout un système qui a servi pour le développement informatique.

Andrew Jackson

I. Etude technique

A. Introduction

B. Modèle physique des données

C. Conception détaillée du logiciel

1. Conception de l’architecture du logiciel

a) Typologie des fonctions types

(1) Spécifications utilisateurs

• • Fonctions du logiciel
  • Description de l’écran
  • Description du traitement
  • Diagramme de répartition des tâches homme / machine
  • Caractéristiques de fonctionnement
    • (i) Facteurs relatifs à l’environnement d’exploitation
    • Confidentialité, couplabilité, maniabilité, robustesse
    • (ii) Facteurs liés à l’environnement de maintenance et de suivi
    • Maintenabilité, adaptibilité, portabilité

(2) Contraintes techniques

b) Définition de composantes types

Primitives technologiques, fonctionnelles

(1) Niveaux d’abstraction

Couche conceptuelle, logique, physique

(2) Couplage / Cohésion

• • (a) Couplage
    • (i) 1er niveau de couplage – data coupling
    • (ii) 2ème niveau de couplage – stamp coupling
    • (iii) 3ème niveau de couplage – control coupling
    • (iv) 4ème niveau de couplage – content coupling
  • (b)Cohésion
    • (i) 1er niveau de cohésion – functionnaly cohesion
    • (ii) 2ème niveau de cohésion – séquential cohesion
    • (iii) 3ème niveau de cohésion – communicational cohesion
    • (iv) 4ème niveau de cohésion – procedural conhesion
    • (v) 5ème niveau de cohésion – temporal cohesion
    • (vi) 6ème niveau de cohésion logical cohesion

c) Modèles de logiciel

Modèle logique, physique

d) Directive d’utilisation

e) Directive d’exploitation

f) Directives de développement

2. Analyse du logiciel

Type traitement, entrée / sortie

D. Stratégie de production du logiciel

1. Planification de la production du logiciel

Définition des tâches, ordonnancement, affectation du personnel, charge de réalisation, réservation des moyens matériels.

2. Stratégie / planning de qualification du logiciel

Intégration descendante, ascendante

II. Production du logiciel

A. Introduction

B. Codage et documentation interne

C. Analyse des modules par inspection structurée

D. Conception des jeux d’essais internes

E. Intégration et tests internes

F. Coordination avec la confection des jeux d’essais

G. Etablissement de la documentation

III. Tests

A. Introduction

Objectifs, objets, participants, tests effectués tout au long du cycle de vue du produit

B. Qui exécute les tests

Analyste-programmeur, utilisateur, centre de calcul, centre de contrôle

C. Définition des procédés de tests

Moniteur de test

1. Analyse statique

a) Inspection

Préparation, exécution, correction

2. Analyse symbolique

3. Analyse dynamique

a) Approche boite noire – tests fonctionnels

Tests aléatoires, d’incidents simulés, de domaine

b) Approche boite blanche – tests structurels

Taux de couverture, branche de programme, de chemin, de décision, contrôleur de déroulement (débugger)
Couverture des instructions, des branchements, des circuits

D. Stratégie de test

1. Méthode globale

2. Méthode descendante

3. Méthode ascendante

4. Méthode mixte

E. Phases de test

1. Test d’élément

2. Test d’intégration

Test d’intégration pure, étendu

3. Test du système

4. Test d’acceptation

a) Test en laboratoire

b) Test d’installation pilote

c) Test d’exploitation en parallèle

5. Test de sécurité / de panne

6. Autres tests

IV. Méthode de structuration Jackson

A. Introduction

B. Formalisme

Structogramme

C. Principes de base

Structurer les données, le programme, lister et attribuer les opérations, écrire le teste structurel / pseudo-code / programme

1. Introduction

2. Structure des données

3. Structure du programme

4. Liste / attribution des opérations

5. Ecriture du texte structurel / pseudo-code / programme

D. Types de programmes

1. Programme de base

2. Traitement de groupes

3. Traitement des concordances / matching

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Les étapes du développement d’application
Organisation de la qualification en développement informatique
Fonction de développeur

Fonction Analyste Programmeur
Java un langage et non une danse
Limites et réalités du partenariat pour un développement informatique spécifique

Autres Informatiques :

Récapitulatif 1 Informatique

Règles et axiomes d’un chef de projet en trois langues

Quelques règles et axiomes d’un chef de projet informatique

en trois langues

High-Tech Project Manager Rules and Axioms

1. You don’t have to be mad to work here, but it’s helps.
2. Give orders verbally. Never write anything down that might be used in evidence against you.
3. Whenever possible form a committee.
4. Do not believe in miracles. Relay on them.
5. Once a product is fouled up, anything done to improve it only makes it worse.
6. Any given product, once running, is obsolete.
7. All products cost more and take longer to produce.
8. If a product is useless, it will be documented.
9. Programme complexity grows until it exceeds that capacity of the programmers who must maintain it.
10. A user never knows what he wants, but always what he does not want.
11. If a product is useful, it will have to be changed.
12. When a programmer declares the system works, this means that it has worked and will work again some day.
13. The length of any meeting rises with the square number of the people present.
14. Most problems are caused by solutions.
15. Walk at a fast pace when out of the office, this keeps questions from subordinates at a minimum.
16. Never trust statistics that you have not forged yourself.
17. Electronic Data Processing is the truth, don’t be misled by facts.

Règles et Axiomes d’un Chef de Projet High Tech

1. Vous n’avez pas à être fou pour venir travailler ici, mais c’est utile.
2. Donner des ordres verbalement. Ne jamais écrire quoi que ce soit qui pourrait être utilisé comme moyen de preuve contre vous.

3. Dans la mesure du possible formez un comité.
4. Ne croyez pas aux miracles. Comptez sur eux.
5. Une fois qu’un produit est bloquée, faire quelque chose pour l’améliorer ne fait qu’empirer les choses.

6. Tout produit donné, une fois en cours d’exécution, est obsolète.
7. Tous les produits coûtent plus cher et prennent plus de temps à produire.
8. Si un produit est inutile, il sera documenté.

9. La complexité d’un programme augmente jusqu’à ce qu’il dépasse la capacité du programmeur qui doit le maintenir.
10. Un utilisateur ne sait jamais ce qu’il veut, mais toujours ce qu’il ne veut pas.

11. Si un produit est utile, il devra être changé.
12. Quand un programmeur déclare que le système fonctionne, cela signifie qu’il a bien fonctionné et qu’il fonctionnera de nouveau un jour.

13. La durée de la réunion augmente avec le carré du nombre de personnes présentes.
14. La plupart des problèmes sont causés par des solutions.
15. Marchez à un rythme rapide quand vous sortez du bureau, cela diminuera le nombre de questions des subordonnés.

16. Ne faites jamais confiance à des statistiques que vous n’avez pas faites vous-même.
17. Le traitement électronique des données est la vérité, ne soyez pas induit en erreur par les faits.

Regeln und Axiome von einem High Tech Projektleiter

1. Sie müssen nicht verrückt sein, um hier zu arbeiten, aber es ist nützlich.
2. Aufträge mündlich geben. Nie schreiben, was immer die verwendet werden könnten, als Beweismittel gegen Sie.
3. Soweit möglich, einen Ausschuss bilden.
4. Glauben Sie nicht an Wunder. Zählen Sie auf ihnen.
5. Sobald ein Produkt sicher ist, etwas für die Verbesserung nicht nur verschlimmern.
6. Jedes Produkt, das einmal ausgeführt wird, ist veraltet.
7. Je mehr ein Produkt teuer ist um so mehr Zeit brauchen Sie es zu produzieren.
8. Wenn ein Produkt nicht notwendig ist, wird es dokumentiert.
9. Die Komplexität eines Programms wächst, bis er über die Fähigkeit des Programmierers, ihn zu halten.
10. Ein Benutzer kann nie wissen, was er will, aber immer, was er nicht will.
11. Wenn ein Produkt anwesen ist, muss es geändert werden.
12. Wenn ein Programmierer aussagt, dass das System funktioniert, bedeutet das, dass es gut funktioniert hat, und es wieder laufen wird.
13. Die Dauer der Sitzung steigt mit dem Quadrat der Zahl der anwesenden Personen.
14. Die meisten Probleme werden durch Lösungen erzeugen.
15. Gehen Sie mit einem schnellen Schritt, wenn Sie das Büro, das reduziert die Anzahl der Fragen von Untergebenen.
16. Vertrauen Sie nie die Statistiken, die Sie nicht selbst gemacht haben.
17. Die elektronische Verarbeitung der Daten ist die Wahrheit, seien Sie nicht in die Irre geführt von den Tatsachen.

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément : 

Les techniciens et les commerciaux
Le succès, c’est…
Le Petit Chaperon Rouge raconté par un informaticien

MMS en amour
Blanc noir piou piou
My boss and i Mon chef et moi Mein chef und ich

Autres Humour :

Récapitulatif 1 Humour