about the importance of signatures in projects

When I read Tim Ingram-Smith’s post on PMHUT, I tried to compare his experience with external customers’ projects with mine in internal information technology projects. In fact, our colleagues’ relationship between computer specialists in the company and the business users instead of a customer-supplier relationship between two companies does change the situation but not as much as one could believe at first sight.

The most successful projects on which I worked had very clear, documented written objectives and strong commitment of the top management. It was for example the case during the Implementation of an Enterprise Resource Planning (ERP) software package globally in 18 months at a large multinational company. The director of the program (which I ran the PMO) made sure of this clarity of objectives by documenting them and having them signed off by the executive committee of the program and by his sponsor, the Chief Financial Officer of the company. This initialization of the program was critical to our success: it provided a clear scope, agreed and measurable objectives, defined and endorsed means for internal and external resources, and commitments to assistance in change management of key executives.

This ERP deployment program also contained a wide ranging optimization aspect and standardization of processes accompanied by functional reorganizations of the finance departments. All financial processes which were redefined by the team project were manually signed by the people in charge of these operational functions in the company (countries and regions financial controllers; responsible for accounts department, for the invoicing, the purchases…).

A manual signature reflects to my opinion a much stronger commitment than an email approval. Personally, before signing manually a document, I read it in a very attentive manner, even when I ask to a domain expert on the team to verify the technical contents. My personal feeling remains that a manual signature has more value than an electronic one. I realize that it is certainly an erroneous perception since nowadays a simple SMS can be taken into account in front of a court, but I am certainly not the only one to be a victim of this perception. Will it change with the generation Y that was born with internet and mobile communications?

As Tim mentions in his article, the temptations are numerous to start without formal sign-off. We also experiment these on internal projects, notably the excuse of critical due dates, pressure from management and colleagues, and fear to leave some employees idle:

1. Compulsory delays: always bad reasons! “Any solution proposal which cannot be ready by January 1st is of no interest to us!”. I was a witness, and I admit even a stakeholder, of numerous decisions where the choice of solutions was based mainly on the projected availability criteria. Certain other components would have better met the needs businesses but seemed to take too long to build. In computing, a typical example is to try by all means to reuse an application developed in a service for a precise purpose in other circumstances and for other objectives. “This application works perfectly in Europe, there is no reason why it wouldn’t work in Asia where we sell the same products and services”. Indeed, it appears logical and attractive: less development and testing, skills availability, speed to get the solution … Regrettably, the time required to tailor the solution to the new context is very often under-estimated and, furthermore, the adequacy of the solution to the needs of its future users widely over-estimated with a limited consideration of contexts, work practices, and difference in culture. It often results a high dissatisfaction of the new users and, at the end of the day, a launch date comparable to the other solutions we could have chosen without such an initial focus on time.

2. Pressure from management and colleagues. There also, even if these pressures come from sincere convictions of the persons who support their “good solution”, they often the result from partial understanding of the situation and objectives of the project. They are also tinged with considerations more down-to-earth such as availability of the skills required for each solution, internal power play, desire to develop new skills in a department, allocation of resources at the level of the portfolio of projects. We cannot ignore them, but they do shouldn’t biases our vision and take us away from agreed selection criteria for the best solution for our project.

3. Available resources. Another element than Tim mentions in his article and which is very important: the imperious desire to use the available and unused resources is very strong and justifiable from the point of view of the management of the company. But, from the point of view of the project: Do these resources have the required skills? If not, how long will it take to develop them and is it even feasible? If they are available and have the skills, is it a sufficient reason to start without formal approval of the project? My experience on the subject is mixed. In fact, if a strong mutual trust exists between business and IT, we can start projects of reasonable size, prototypes, or incremental development without formal signature in “agile” development mode. But, on any big computing project, it is worth it securing the approvals of all parties before starting. Otherwise, we run the risk of having to undo and then redo (if we still can do so) what could have been done first shot with a better alignment on the objectives.

One of the senior consultants I had the chance to work with used to say:

“If you do not take the time to do it right the first time, then tell me when you will take time to redo it! Because, you shall have no doubt, it will be necessary to redo it.”

importance des signatures formelles sur les projets

En lisant l’article de Tim In gram-Smith sur PMHUT, traduit ci-dessous, j’ai essayé de comparer son vécu avec ses clients externes à mon expérience en informatique interne à l’entreprise. En fait, je dois reconnaître que notre position de collègues entre informaticiens de l’entreprise et business en lieu et place d’une relation client-fournisseur entre deux entreprises change un peu la donne mais pas autant que l’on pourrait le croire de prime abord.

Les projets les plus réussis sur lesquels j’ai travaillé avaient des objectifs très clairs, documentés par écrit et un engagement fort du management. Ce fut par exemple le cas lors de l’implémentation d’un progiciel de gestion intégré (Enterprise Resource Planning – ERP) au niveau mondial en 18 mois dans une grande multinationale. Le directeur du programme (dont je dirigeais le PMO) s’est assuré de cette clarté d’objectifs en les documentant et les faisant signer par le comité exécutif du programme et par son sponsor, le directeur financier de l’entreprise. Cette initialisation du programme a été critique à notre réussite: Il nous a fourni un périmètre clair, des objectifs agréés et mesurables, des moyens définis et approuvés aussi bien pour les ressources internes que externes, et des engagements de support au changement du top management.

Ce programme de déploiement d’ERP comportait également un large volet optimisation et unification des processus et réorganisations des fonctions de la finance. Tous les processus financiers qui furent redéfinis par l’équipe projet ont été signés manuellement par les responsables métier de l’entreprise (contrôleurs financiers des pays, des régions et centraux; responsables de la comptabilité, de la facturation, des achats…).

Une signature manuelle reflète à mon avis un engagement beaucoup plus fort qu’un email d’approbation. Personnellement, avant de signer manuellement un document, je le lis de manière très attentive, même quand je demande à un expert du domaine en question de mon équipe de vérifier le contenu technique ou métier. Car mon sentiment reste qu’une signature manuelle a plus de valeur qu’une approbation électronique. Je réalise qu’il s’agit très certainement d’une perception erronée puisque de nos jours de simples SMS peuvent être pris en compte devant un tribunal, mais je ne suis certainement pas le seul à être victime de cette perception. Cela changera-t-il avec la génération Y née avec Internet et les communications mobiles?

Comme Tim le mentionne dans son article, les tentations sont nombreuses de démarrer sans signatures formelles. Nous les expérimentons également sur les projets internes, notamment l’excuse des délais imposés, la pression du management et des collègues, et la peur de laisser des employés inoccupés:

1. délais imposés: toujours de mauvaises raisons ! “Toute proposition de solution qui ne peut être prête pour le 1^er janvier ne nous intéresse pas!”. J’ai été témoin, et même partie prenante je le reconnais, de nombreuses décisions de choix de projets ou de solutions techniques basées sur des critères de disponibilité prévisionnelle. Certains composants auraient mieux répondu aux besoins business mais semblaient prendre trop de temps. En informatique, un exemple typique est d’essayer à tout prix de réutiliser une application développée dans un service pour un but précis dans d’autres circonstances et pour d’autres objectifs. “Cette application marche bien en Europe, il n’y a pas de raison pour qu’elle ne marche pas en Asie où nous commercialisation les mêmes produits…”. En effet, cela paraît logique et séduisant: moins de développement et de tests, disponibilité des compétences, rapidité d’obtention de la solution… Hélas, le temps d’adaptation de la solution au nouveau contexte est trop souvent sous estimé et, de plus, l’adéquation de la solution aux besoins de ses futurs utilisateurs largement surestimée avec une prise en compte limitée des contextes, marchés, et cultures différentes. Il en résulte souvent une insatisfaction des nouveaux utilisateurs, ou des délais de mise en service proches au final des autres solutions qui auraient pu être choisies sans ce focus initial sur les délais.

2. pression du management et des collègues. Là aussi, même si ces pressions partent de convictions sincères des personnes de supporter la “bonne solution”, elles sont souvent le résultat de vues partielles de la situation ou des objectifs complets du projet. Elles sont aussi teintées de considérations plus terre à terre de disponibilité des compétences requises pour chaque solution, de luttes de pouvoir interne, de désir de développement de nouvelles compétences dans son département, d’affectation des ressources au niveau global du portefeuille de projets ou de l’entreprise. On ne peut les ignorer, mais elles ne doivent pas obscurcir notre vision et nous éloigner des critères agréés de choix de la meilleure solution pour votre projet.

3. ressources disponibles. Autre élément que Tim mentionne dans son article et qui est très important: Le sentiment de devoir à tout prix utiliser les ressources disponibles et non affectées qui est très fort et assez légitime du point de vue du management de l’entreprise. Mais, du point de vue du projet: ces ressources ont-elles les compétences requises? Sinon, combien de temps faudra-t-il passer à les former et cela est-il même faisable? Si elles sont disponibles et ont les compétences, est-ce une raison suffisante pour démarrer sans approbation formelle du projet? Mon expérience sur le sujet est mitigée. En fait, si l’on se connait bien et qu’une confiance réciproque forte existe entre business et informatique, on peut démarrer des projets de tailles réduites, des prototypages, du développement incrémental sans signature formelle et en mode développement “agile”. Mais, sur tout gros projet informatique, cela vaut le coup de sécuriser les approbations de toutes les parties avant de démarrer sous peine de devoir défaire puis refaire (tant est que l’on en ait encore les moyens) ce qui aurait été réalisé sans alignement total sur les objectifs.

Comme le disait l’un des consultants senior avec lequel j’ai eu la chance de travailler: “Si vous ne prenez pas le temps maintenant de bien faire les choses, dites moi quand vous prendrez le temps de les refaire ! Car, n’ayez aucun doute, il vous faudra les refaire.”

Les dangers à agir sans signature formelle pour le projet

http://www.pmhut.com/the-perils-of-proceeding-without-project-sign-off

Par Tim Ingram-Smith

Un des pièges du management de projet dans lequel je suis tombé plusieurs fois est de procéder sans signature complète du client ou du sponsor du projet. Souvent la mission proposée a un tel sentiment d’urgence qu’en tant que chef de projet, cherchant toujours à répondre au besoin urgent du client, je me suis embarqué sur un projet ou un produit sans une approbation claire et définitive.

Peut-être il y avait un impératif de délai, ou un lancement de produit, ou un point de rencontre avec une autre partie de développement, ou autres “ne peuvent pas être décalés”, une raison pour laquelle on “doit commencer tout de suite”; peut-être était-ce simplement qu’après tant de discussions et revues et présentations comité exécutif et à retravailler le contenu et les coûts et tant de personnes impliquées et le client hurlant presque pour commencer, que j’étais certain que le projet devait être commencé, dans la seconde.

Voici ce que je fais maintenant – je me retiens!

Peu importe à quel point je pensais être utile, ni combien l’urgence à commencer était mentionnée, je me rends compte que je ne devrais pas entamer de travail facturable avant que le client ou le sponsor de projet n’ait littéralement signé.

Démarrer le projet sans signature formelle est comme se mettre en route pour rencontrer quelqu’un alors qu’il n’a pas encore confirmé son adresse exacte : il m’est arrivé de partir sur une mauvaise route et de dépenser beaucoup de temps en aller-retour pour essayer de trouver le bon endroit.

Quand je passe outre cette signature, il se produit toujours (après un travail substantiel) que le client ne m’a pas en fait donné le feu vert, pas approuvé la portée, pas approuvé le financement, n’acceptera pas le livrable et voudra tout refaire, à partir de zéro. J’ai brûlé de l’argent, consommé de l’énergie, embarrassé mon équipe, ennuyé mon client et mis un bâton pour me battre dans les mains de mon patron – et je peux me passer de toutes ces choses!

Je dis au client, nous aimerions commencer, nous sommes prêts à y aller, pourriez vous s’il vous plaît juste signer et retourner cette commande de travail qui nous autorise à progresser.

Bien sûr, il en ressort souvent, que le client n’est pas tout à fait prêt à y aller, il n’a pas sécurisé l’approbation en interne et n’est pas entièrement à l’aise avec le contenu, il ne peut pas signer le bon de commande. Et c’est exactement pourquoi je ne dois pas procéder sans signature.

Attendre le feu vert n’est pas toujours facile : le projet peut être vraiment urgent, mes experts techniques peuvent être disponibles seulement pendant une petite fenêtre de temps avant qu’ils ne soient utilisés ailleurs, ou peut-être mes ressources brûlent des dollars internes en attendant le client. Mais ce n’est pas une raison valable pour  dépenser effort, énergie et bonne volonté sur un chemin qui atteindrait une issue non satisfaisante. Donc j’essaye de garder mes ressources déployées sur d’autres activités productives aussi longtemps que possible, et de changer rapidement leur affectation quand l’accord est signé.

Un document signé a beaucoup plus de valeur pour toutes les parties que de “la bonne volonté”: il décrit la tâche, il montre le chemin, il détaille l’accord entre les parties, c’est exécutoire devant une cour et c’est le socle de mon autorité de chef de projet.

Avec la commande de travaux ou le bon de commande en place, sécurisé par une signature du contenu et du plan de travail, le projet en entier se portera beaucoup mieux.

an experience of the advantages of project portfolio management

During the implementation of a portfolio management approach for information technology projects at Equant (a few years ago), I noticed that the most important benefits for us were the following ones…

read the full article at: http://bit.ly/3w7GMB

What is your own experience?

Planifier des réunions / agreeAdate

Schedule conference calls, meetings and events the easy way.

agreeAdate saves you time and money by avoiding telephone and email tag to find when people are free. Just send invitations to collect availability and then make your choice from the results.

Free and easy to use with reminders, confirmations, ability to provide conference call details, understanding timezones… What else ?

Document Summarization / Résumer rapidement un document Anglais

http://www.greatsummary.com/

Un site utile pour réaliser rapidement des résumés certes approximatifs mais qui peuvent néanmoins vous permettre de décider si vous souhaitez ou non investir le temps nécessaire à la lecture complète du document (ou de la page web).

Quickly get the gist of a document, webpage, or any text selection of your choice. Identify the key topics of a document while eliminating redundant information

dictionnaires Larousse en ligne Français et bilingues (4) pour vos traductions !

http://www.larousse.fr/dictionnaires

5 dictionnaires de français pour une meilleure maîtrise de la langue !

1. Dictionnaire de français: 135 000 définitions et 6 000 articles pour déjouer tous les pièges de la langue
2. Dictionnaire des synonymes et contraires: 92 000 synonymes et 29 000 contraires
3. Dictionnaire des expressions: 34 000 expressions
4. Dictionnaire des homonymes:  15 000 homonymes
5. Dictionnaire des citations: 9 000 citations

Plus: toutes les conjugaisons: 9 600 verbes conjugués à tous les temps et tous les modes

Et 4 dictionnaires bilingues:

• Anglais
• Allemand
• Espagnol
• Italien

• Dictionnaire de français

  135 000 définitions et 6 000 articles pour déjouer tous les pièges de la langue

• Dictionnaire des synonymes et contraires

  92 000 synonymes et 29 000 contraires

• Dictionnaire des expressions

  34 000 expressions

• Dictionnaire des homonymes

  15 000 homonymes

• Dictionnaire des citations

  9 000 citations

• Toutes les conjugaisons

  9 600 verbes conjugués à tous les temps et tous les modes

gérer les conversations difficiles pour les Chefs de projet

Article original de Bruce McGraw

http://www.pmhut.com/dealing-with-difficult-conversations-for-project-managers

Que ce soit un développeur sous-performant, un paresseux dans l’équipe, un comportement inadéquat, ou une prima donna dans l’équipe qui énerve tout le monde, il y a des moments dans la vie de tout chef de projet Où il ou elle doit avoir une conversation difficile avec un membre de l’équipe projet. Ces conversations sont toujours difficiles parce que vous allez dire quelque chose que l’autre personne ne veut pas entendre. Vous demanderez au salarié de changer son comportement et ce n’est pas une chose qui motive les gens.

Commençons par le début

Demandez-vous :  Qu’est-ce qui vous fait penser qu’il y a un problème qui exige d’avoir une conversation difficile ? Les temps impartis sont-ils dépassés ? Le travail en souffre-t-il ? Y-a-t-il un échange de mots ou e-mails coléreux ? Quelqu’un s’est-il plaint ? Avez-vous vu un problème ou en avez entendu parler par radio moquette ? Éteignez-vous constamment des départs d’incendie autour de ce salarié ? Prenez des notes. Soyez spécifique.

• Ce qui est arrivé
• Quand
• Combien de fois
• Qui a été impliqué
• Quel était l’impact

Décidez ensuite de celui à qui appartient ce problème. Certains problèmes doivent être attaqués au niveau de l’organisation, Même si êtes responsables d’initier l’action. Ces problèmes incluent la violation de lois ou des règles de l’entreprise. À part cela, les problèmes qui ont un impact sur votre équipe et l’atteinte de vos objectifs relèvent de votre responsabilité et exigent que vous ayez cette conversation difficile.

Préparez-vous pour la réunion

Prévoyez un endroit qui protège la confidentialité. Selon le problème à discuter, vous pouvez vouloir organiser la réunion de manière quelque peu informelle — aucune barrière comme un bureau entre les personnes. Vérifiez vos notes et soyez prêt à fournir des informations spécifiques et non pas des généralités à votre salarié. Décidez ce qui serait un résultat bon ou même idéal pour pouvoir aller dans cette direction.

Soyez conscient de votre attitude et de vos suppositions et comment elles  seront perçues.

Une fois que vous êtes préparé — vous avez défini les caractéristiques du problème, vous vous êtes assuré que c’est un problème, savez quels comportements vous voulez voir changés – allez-y. Invitez le salarié à une réunion aussitôt que possible.

Pendant la conversation difficile

Commencer en présentant la situation d’une façon non-menaçante. “Jean, je crois qu’il y a les problèmes qui affectent négativement la performance de notre équipe.”; “Marie, je voudrais votre aide dans la résolution d’un problème dans notre équipe.” Ne faites pas ces déclarations initiales d’une voix qui indique la recherche d’un coupable, mais décrivez plutôt un problème qui doit être résolu. Présentez votre perception du sujet et demandez ensuite des réactions.

Écouter. La partie initiale de la conversation est de la découverte. Le salarié perçoit-il le problème la même façon que d’autres ? Pensent-il que son comportement y contribue ? Par exemple, l’intention de Marie était-elle d’être utile, alors que la perception était qu’elle était trop agressive et interférait ? Joe échouait-il à accomplir ses tâches parce qu’il était préoccupé par la maladie de son épouse, ou ne connaissait-il pas l’outil dont on avait supposé qu’il le maîtrisait, ou a-t-il pensé que la tâche assignée était en dessous de ses capacités ?

Restez concentré sur le résultat recherché — ne rentrez pas dans  un débat et ne devenez pas défensif.

Fournissez un retour sur ce que vous avez entendu

Votre salarié sera plus réceptif à la résolution du problème s’il constate que vous comprenez son point de vue. Paraphrasez ce qu’il a dit et demandez confirmation. Gardez à l’esprit que vous n’exprimez pas votre accord avec lui ou ses perceptions, vous clarifiez la position exposée et indiquez que vous avez écouté.

Prenez garde à ne pas prendre les commentaires personnellement.

Maintenant c’est votre tour

Exposez le problème en termes d’effets en utilisant les informations cueillies dans l’étape 1 (“commençons par le début”). Spécifiez comment vous voulez que des comportements changent et comment vous mesurerez ce changement. Présentez de manière limpide les conséquences d’un échec à changer. Soyez préparé pour de la résistance, colère, attitude défensive, ou reproches. Cependant, ne vous laissez pas entrainer dans ces réponses émotionnelles et d’ auto-protection, ni distraire de là où vous voulez que la réunion vous amène. Quelques autres choses à faire et à ne pas faire:

• Ne faites pas de généralisations des comportements ou des intentions
• Ne faites pas d’accusations
• S’il y a des questions multiples, traitez les une par une
• Faites que le salarié comprenne que vous voulez vraiment que ce problème soit résolu
• Soyez prêt à écouter des alternatives tant qu’elles adressent la résolution du problème
• À la fin de la réunion, récapitulez les changements de comportement attendus
• Planifiez une réunion de suivi si approprié

Cet article n’est pas sensationnel et ne parle pas d’une grande et nouvelle façon de mieux faire le management de projet–c’est seulement que la gestions des personnes est la chose la plus importante que vous deviez faire!

quels outils Web 2.0 pour les chefs de projet?

Il existe de nombreux outils de collaboration venant du Web 2.0 auxquels les chefs de projet trouveront une grande utilité.

Certains enrichiront des communications, accroîtront la capacité à joindre les contacts de l’équipe projet étendue, permettront de développer de manière collaborative et de stocker la documentation projet ou produit, supporteront la création de réseaux professionnels axés projet, faciliteront le brainstorming et amélioreront la productivité.

lire la suite…

some useful web 2.0 tools for project managers

There are many collaboration tools coming with Web 2.0 that project managers will find usage for. Some will enrich communications, increase reach ability in the extended project team, develop and hold part of the project or product documentation, set up project related professional networks, facilitate brainstorming, and improve productivity.Some can be obtained for free, others for money. Your requirements for confidentiality and security will play a key role in your selection process. Read the full article…

le management de projet: art ou science?

Peut-être ni l’un ni l’autre me répondrez-vous tant cette profession est encore mal comprise et indéfinie pour beaucoup?

Ci-joint un article qui engage la discussion sur le sujet:

Is project management Art or Science? Par Jorge Dominguez

(Article originial sur PMHUT: Http://www.pmhut.com/is-project-management-art-or-science)

Les chefs de projet sont certainement à la fois artistes et scientifiques mais pas dans la signification usuelle de ces mots. Les chefs de projet appliquent artistiquement une science.

La science entre en jeu quand le PM acquiert et embrasse toute la théorie qu’il/elle a appris par l’expérience, la formation, la certification, etc. Les PMs utilisent des structures comme PMBoK ou le PRINCE basées sur les méthodes éprouvées dont on a démontré l’efficacité au travers d’années de mise en œuvre.

Quelques points de science :

• Méthodologies différentes et structures sont disponibles (PMBoK, PRINCE, etc)
• Processus standards et domaines de connaissance
• Meilleures pratiques et techniques uniformément acceptées
• On parle le même langage
• Un jeu de métriques standard qui mesure plusieurs dimensions des projets
• Abondance de modèles de documents de travail

L’Art entre en jeu quand le PM met en œuvre ce qui est important et approprié de cette science par rapport à son projet. Les méthodologies et structures, par exemple, ne vous disent pas comment faire. Elles vous disent seulement ce qui peut être fait (pas nécessairement une mauvaise chose). Vous devez apprendre “le comment” par votre propre expérience ou celles d’autres. L’Art est la partie qui peut en fin de compte faire la différence entre le succès ou l’échec du projet.

Quelques points d’art :

• L’application du bon processus pour le bon projet (pas de réponse universelle)
• Faire en sorte que les choses avancent
• Prendre de bonnes et sages décisions
• S’assurer que le cahier des charges et les pré-requis couvrent tout le périmètre du projet et seulement celui-ci
• Se concentrer sur les priorités, mission, buts, fonctions et tâches critiques du projet
• Savoir que faire quand les choses tournent mal
• Amener un projet à une fin réussie, dans les temps et budget
• Mener l’équipe projet pendant l’exécution
• Diriger des réunions efficaces
• S’occuper de la politique et la bureaucratie de l’organisation pour faire avancer le projet

Avoir presque deux fois plus de points pour l’art que la science ne signifie pas que l’art est ce qui est le plus important: en fait ils sont d’égale importance. Cependant, la plupart des personnes se concentrent sur la science et je veux démontrer qu’il y a aussi un art.

Il se peut que je ne vous laisse qu’à demi satisfaits en ne plongeant pas dans les détails de chacun des susdits points dans cet article à cause de sa brièveté et du fait que chacun d’entre eux est un sujet pour un article entier.

Beaucoup d’entre nous, je pense, savent ou obtenir, et obtiennent, la partie liée à la science. La plupart d’entre nous ne deviendra jamais artiste.