Comment puis-je faire une bonne présentation aux parties prenantes importantes et non techniques?

À la fin du mois, je dois faire une présentation sur un projet logiciel sur lequel j'ai travaillé moi-même et qui décidera essentiellement si j'obtiendrai ou non un emploi à temps plein dans l'entreprise Je suis un employé temporaire pour l'instant. Je ferai ma présentation au président de notre département et à deux vice-présidents. Le président a moins de connaissances en programmation que les deux autres vice-présidents et est finalement la personne que je dois impressionner.

Quelles sont les choses les plus importantes que je dois transmettre dans la présentation? Mon manager m'a déjà dit de mettre l'accent sur les choses suivantes:

1. Je pilote ce projet dans la bonne direction et je maîtrise tout.
2. Je termine ce projet dans les délais.

Sur quelles autres choses dois-je me concentrer lors de ma présentation pour me faire passer pour le plus louable possible? Je pense à souligner les efforts que je fais au niveau de la conception pour réduire le risque et l'incertitude dans le logiciel (deux choses que j'imagine sont très importantes pour les plus hauts).

Une chose qui m'inquiète particulièrement est de trouver le bon équilibre entre les détails techniques et non techniques dans la présentation. Si je n'inclus aucun détail technique, le président de notre département ne connaîtra pas toutes les fonctionnalités "sous le capot" qui sont dans le logiciel, mais si je suis trop technique, il pourrait se perdre et ne pas comprendre points importants de la présentation.

Des conseils seraient appréciés.

Connaissez votre public.

Vous avez déjà conquis la règle numéro 1 de la prise de parole en public - vous avez évalué l'expertise technique des personnes à qui vous allez parler et votre présentation doit être adaptée en conséquence. Ne vous inquiétez pas de faire ressortir votre présentation avec beaucoup de techno-garble et leet-parler.

Une grande tentation face aux grosses perruques est d'essayer vraiment de les WOW avec votre impressionnant dictionnaire de concepts techniques, de théories et d'applications. L'idée étant, bien sûr, que si vous avez suffisamment embrouillé le patron , vous devez bien sûr être qualifié pour ce poste!

Cela fonctionnera même, probablement, à court terme pour vous trouver le poste à temps plein que vous recherchez. Le président, cependant, s'éloignera sans aucun doute de la réunion en pensant: "Je ne sais pas de quoi ce type parlait", et vous pouvez parier votre vie qui sera l'impression qu'il a de vous pour le reste de votre vie .

Pourquoi est-ce mauvais? Dans le monde des affaires, les PDG, les présidents, etc. recherchent des personnes avec lesquelles ils peuvent communiquer. Oui, il est important d'avoir dans les tranchées des geeks très performants et techniquement avancés qui peuvent déboguer du code C qui s'interface avec un port série personnalisé, mais devinez quoi? Ils s'en moquent. Tout ce qui leur importe, c'est que vous ayez le contrôle et qu'ils puissent vous faire confiance . Le chemin le plus sûr dans les cercles intérieurs (promotion, argent, gloire, butin) est une communication efficace avec les plus hauts gradés.

Voici le conseil: concentrez-vous sur vos réalisations avec l'entreprise à ce jour. Ne creusez pas dans les écrous, les boulons et le câblage - leurs yeux s'émailleront et vous ne serez qu'un autre programmeur pour eux. Passez du temps à parler de choses qu’ils peuvent comprendre et demandez à vos patrons de vous quitter avec la confiance nécessaire pour dire: «Je fais confiance à cet homme pour faire le travail».

L'une des choses les plus importantes que vous devez garder à l'esprit est de ne pas survendre. Présenter trop d'informations, en particulier lorsqu'il s'agit d'un projet technique présenté à du personnel non technique, perdra rapidement votre audience. Faites de votre mieux pour vous assurer que chaque sujet dont vous discutez est important pour la «vue d'ensemble».

Quant à la «vue d'ensemble», la gestion non technique essaie généralement de traduire la discussion technique en termes de coût, de temps et de qualité.

Dans cet esprit, vous pouvez mentionner les principales décisions que vous avez prises dans le projet et mettre en évidence les avantages de ces décisions en termes de coût, de temps et / ou de qualité. Essayez de choisir entre 3 et 4 décisions clés et gardez votre discussion de ces décisions brève. S'ils veulent plus d'informations, ils demanderont (soyez prêts à répondre!).

Je recommande également fortement que vous exécutiez votre présentation par un ami non technique au préalable et que vous obteniez leur avis. Il est très facile de penser que vous n'êtes pas technique alors qu'en fait vous utilisez encore beaucoup trop de jargon. Moins votre ami est technique, mieux c'est. Essayez de trouver quelqu'un qui peut à peine allumer un ordinateur, et encore moins un programme. S'ils peuvent suivre l'essentiel de ce que vous dites, vous êtes en bonne forme.

J'ai trouvé que la plupart des techniciens (y compris moi-même) ont tendance à être trop techniques. Il y a de fortes chances que vous soyez surpris du peu de choses techniques qu'ils peuvent suivre. Par exemple, si vous voulez expliquer que vous réduisez les risques et l'incertitude, dites très clairement que tous les projets comportent des risques et de l'incertitude, pas seulement le vôtre, car ce n'est pas un slam dunk qu'ils le savent.

Si le risque et l'incertitude découlent de problèmes non techniques et que la direction s'en préoccupe ou, du moins, en est consciente, il faut absolument inclure ce que vous avez fait.

Soulignez également le positif, car il enlèvera au moins autant de votre ton que tout ce que vous dites. Alors ne passez pas beaucoup de temps sur le risque et l'incertitude. Si vous avez besoin d'évoquer cela pour vous couvrir plus tard pour des choses hors de votre contrôle, vous voudrez peut-être couvrir ce dont vous aurez besoin d'autres personnes pour terminer la tâche dans les délais. Étant donné que pour la plupart des projets, d'autres personnes ne faisant pas ce dont elles ont besoin en temps opportun sont une possibilité réelle, cela réduit les chances que vous en soyez blâmé.

Bien que les personnes techniques se rendront compte de l'importance clé des fonctionnalités «sous le capot», les personnes non techniques ne le feront pas. Vous ne pouvez probablement pas faire plus que de dire que ce projet a des problèmes techniques sur lesquels il était important de passer du temps, comme les foozbars, les whats et les bla blas, mais vous faites tout cela et les choses sont dans les délais.

Eh bien, la description de votre projet est très vague, mais je vais essayer.

J'imagine que l'application que vous avez créée est soit un remplacement d'une application différente, soit un outil pour automatiser un processus qui a été ou est encore exécuté manuellement.
Faites une analyse de cas pour différents scénarios en comparant le flux de travail avant et après l'introduction de votre logiciel. Ce que j'aimerais voir:

• montrer comment vous avez rationalisé des scénarios très courants
• afficher les versions, qui avaient des défauts dans l'expérience utilisateur et comment vous les avez améliorées. montrer comment vous avez mis en œuvre les commentaires qui vous ont été fournis.
• affichez des chiffres ou des tableaux comparant le temps, la productivité, les fonctionnalités, etc. avant et après. Voici ce que j'entends "Par l'utilisation de static noiseet more static noisenous avons diminué le temps nécessaire pour faire X de Y% "

Personnellement, je me fiche de ce qui se passe sous le capot et vos managers s'en soucient encore moins (j'y consacre beaucoup de temps et j'aime ça, mais je sais que je ne génère pas de valeur en jouant avec des choses que personne verra jamais). Un produit logiciel (composant, bibliothèque, framework ou application) doit être utilisable (robuste, rapide, flexible, prévisible) et raisonnablement évolutif.

Si je vous ai engagé, je veux être convaincu que vous appréciez ces qualités. J'aimerais que vous m'expliquiez par quels moyens vous essayez de les atteindre et pourquoi vous avez choisi ces moyens. Je veux voir que vous utilisez de bons outils. Montrez-moi les statistiques du tracker de projets. Donnez-moi un aperçu des méthodologies de développement que vous utilisez, expliquez-les brièvement et leurs avantages (pour à peu près tout sur terre, il existe une doublure fantaisie-shmancy qui la rend convaincante). Montrez-moi comment travailler avec vous sera agréable, comment vous pourrez réagir à mes besoins en constante évolution et comment la communication avec vous est très agréable, car vous ne vous contentez pas de me fournir des détails techniques, mais vous proposez des solutions, bien sûr sont mis en œuvre au niveau technique, mais que vous pourrez représenter en des termes que je comprends et qui me concernent.

Envisagez de structurer le preso comme une histoire de journal: des choses importantes d'abord (prévoyez de commencer tard, et coupez-vous tôt), et couvrez qui, quoi, pourquoi, quand, où et comment. J'aime les modèles d'une seule page de One Minute Manager, ils me forcent à bien faire bouillir les choses.

Re style de présentation:

• Écris-le et pratique à l'avance. Faites une vidéo de vous-même, regardez-la le lendemain matin. Répétez.
• Allez à votre propre rythme (certaines personnes fonctionnent mieux si elles font une pause et tourbillonnent leur café, mais pouvez-vous imaginer un Robin Williams lent?), Mais incorporez quelques pauses et retraitements prévus pour les points importants. Le timing ... c'est difficile, il faut de la pratique.
• ne faites pas, ne faites pas de PPT vous vous tenez là et lisez. Ne faites pas de PPT, vous pourriez vous tenir là et lire, car c'est exactement ce que vous ferez. Utilisez le PPT pour afficher des graphiques, pour afficher uniquement le mot clé ou deux. Vous voulez qu'ils se concentrent sur vous, pas sur le preso. La recommandation 10/20/30 Kawasaki est bonne.
• Entrainez-vous à l'avance :) afin que vous ayez quelques cycles de rechange pour établir un contact visuel, regarder les indices pour s'adapter, et ainsi vous savez ce que vous laissez tomber s'ils commencent à vous tirer hors piste.

Concernant le contenu:

• Après le résumé du journal, couvrez les exigences - et incluez certaines exigences différées (choses que vous avez apprises mais qui ne rentrent pas dans la portée de l'effort actuel) ... incluez certaines choses que vous considérez comme des exigences au début mais que vous avez pu éliminer comme vous enquêté.
• Énoncez les principaux risques en termes commerciaux - ils ne se soucient pas du risque que «les données RDF ne soient pas bien réparties», ils se soucient du fait que vous considérez le risque «la mise à l'échelle du modèle de données nécessitera un remaniement si nous obtenons des données clients de plus en plus complexes» vous avez une réponse pour chaque risque: comment sauront-ils si l'événement à risque se produit (quelle est votre métrique) et qu'avez-vous déjà fait à ce sujet, que l'équipe pourra-t-elle faire si cela se produit.
• Il se peut qu'un risque ne soit toujours pas bien défini, qu'il soit sous-géré ou qu'il soit catastrophique et irréversible s'il se produit - dites-le. Jusqu'où vous allez dans la pile des risques dépend du sujet (médical? Jeux?) C'est donc un domaine où votre jugement montrera.

Sous-texte: vous avez travaillé par vous-même et c'est toujours un peu effrayant pour la direction - alors, assurez-vous d'inclure des indicateurs de la façon dont vous avez tenu les autres informés des progrès, comment vous avez appris les exigences énoncées et réelles. La direction estime que la partie technique est fastidieuse et a besoin de personnes intelligentes, mais est finalement toujours faisable ... les entreprises réussissent rarement ou échouent en fonction de leurs compétences techniques, et elles le savent, alors n'essayez pas trop de les impressionner, ne le faites pas essayez de leur enseigner les technologies. Au lieu de cela, impressionnez-les par la façon dont vous étudiez et formulez un problème, catalysez une discussion, communiquez vos progrès.

Les deux préoccupations majeures ne nécessitent rien de technique pour la direction et la rapidité de votre progression. Obtenez des commentaires d'autres personnes impliquées. Vous ne voulez pas de questions ou de préoccupations surprises lors de la présentation.

Concentrez-vous sur la direction du projet. Ils peuvent avoir besoin d'un rappel sur ce dont il s'agit ou ils peuvent ne pas avoir été impliqués dans la planification. Donne des exemples de la façon dont vous accomplissez cela.

Présentez les jalons du projet et vos performances. Mentionnez tout changement de spécification susceptible d'avoir modifié la chronologie.

N'évitez pas de mentionner des problèmes dans le projet. La clé est de savoir comment vous avez pu les surmonter. Cela devrait leur donner un aperçu de votre capacité à relever les défis futurs.

Parlez lentement. Sois calme. N'oubliez pas de respirer.

Bien que vous puissiez mettre en évidence les décisions prises, les technologies utilisées et les problèmes résolus, la haute direction se concentrera généralement sur les problèmes de résultat:

• La mise en œuvre de ce projet, de cette façon, nous aide à faire des affaires plus rapidement, mieux et à moindre coût ...
• Le coût estimé de ce projet est X, les économies à court terme sont Y et les économies à long terme sont Z. (Vous pouvez vous en sortir avec X étant supérieur à Y, mais il vaut mieux être inférieur à Z)

Certains des meilleurs points seront si, pendant que vous travailliez sur le projet, vous trouviez des moyens d'augmenter les économies ou les performances par rapport à la conception originale du projet. Nous pouvons espérer / supposer que le projet ne serait pas démarré à moins que la direction ne pense qu'elle allait faire / économiser de l'argent ... si vous augmentiez le résultat, c'est encore mieux.

Ces types de métriques sont importants car une chose qu'ils examinent est le coût de votre maintien, et vous demandez si l'avantage de le faire va ajouter ou soustraire de la ligne de fond.

La règle 10/20/30 de PowerPoint de Guy Kawasaki serait ma suggestion si vous utilisez PowerPoint dans votre présentation car les principes qu'il décrit sont assez bons pour avoir seulement 10 diapositives, 20 minutes, etc.

Quelques éléments que vous pouvez également considérer:

Amusez-les. Ne soyez pas un clown mais un peu de passion ou d' humour leur fera porter plus d'attention.

Ralentissez votre discours et ajoutez des pauses pour mettre l'accent.

Établissez un contact visuel avec tout le monde dans la pièce, pas seulement le décideur ou le patron, car d'autres peuvent également avoir une influence sur le patron ...

Essayez d'avoir des histoires .. Parlez-leur des choses amusantes qui vous sont arrivées pendant le projet, ou même des mauvaises .. Faites-leur vivre l'ambiance avec vous ...

Résumer , Résumer, Résumer ... les garder toujours avec vous ...

Un bon indice: insister sur les problèmes techniques avec lesquels ils peuvent faire un suivi .. Faites-leur sentir qu'ils comprennent également la partie technique .. Cela leur donnera une bonne sensation ...

Utilisez autant de déclarations que possible une bonne question ...

Tu as écrit,

"Une chose qui m'inquiète particulièrement est de trouver le bon équilibre entre les détails techniques et non techniques dans la présentation."

Garr Reynolds est l'un des principaux experts de l'art de la présentation, et dans l'un de ses articles de blog de 2005 (toujours d'actualité), il compare les styles de présentation de Steve Jobs et Bill Gates. Même si vous ne lisez pas l'article perspicace, vous pouvez obtenir un indice à partir des captures d'écran comparant le diaporama de Bill et le diaporama de Steve quant à la présentation la plus convaincante et celle qui est la plus susceptible d'endormir le public (indice: celui avec toutes les puces et le style exagéré).

http://presentationzen.blogs.com/presentationzen/2005/11/the_zen_estheti.html

Depuis 2005, Bill a amélioré son style de présentation, et Garr couvre les améliorations de Bill dans un blog de 2010.

http://www.presentationzen.com/presentationzen/2010/08/the-naked-transformation-of-bill-gates-the-presenter.html