Patrons d'apprentissage/Un guide rapide pour des projets ratés

This page is a translated version of the page Learning patterns/A short guide to bad projects and the translation is 73% complete.
Une fiche pratique pourorganizational
Un guide rapide pour des projets ratés
problèmeTout se passe trop bien ? Votre équipe s’ennuie ? Vous êtes sur le point d’organiser un projet parfait ? Pas d’inquiétude ! Voici un guide d’erreurs parmi lesquelles piocher ! Sentez-vous libre d’utiliser, de partager et compléter !
solutionIl suffit de suivre les quelques conseils de ce patron d’apprentissage et vous n’aurez plus jamais à vous inquiéter de faire un projet parfait. Choisissez les erreurs qui vous semblent les plus sympas et stimulantes pour vous et votre équipe !
créateur ou créatriceClaudia.GaradKaarel Vaidla (WM EE)
Approuver
créé le10:28, 26 September 2016 (UTC)
statut :DRAFT

Quel est le problème à résoudre ?

Ce learning pattern est le deuxième d'une série pour vous aider à tout faire foirer. Alors que le premier porte sur les événements, celui-ci a une portée plus large et fournit des instructions sur la façon d'exécuter des projets vraiment ratés. Ce learning pattern est le résultat d’une session de collaboration au cours de la conférence CEE 2016 en Arménie et rassemble l’expérience de Wikimédiens d’horizons variés du Wikiverse.

Quelle est la solution?

Un projet sans problèmes ou incidents de parcours est − avouons-le − ennuyeux. Vous êtes à la recherche de quelques stupides erreurs faites maison (qui pourraient être évitées, mais ne l’ont pas été) pour générer un petit défi à résoudre ici et là. Sentez-vous libre d’utiliser, de partager et compléter !

Vue d’ensemble

Conditions générales
  • Créez une atmosphère de travail toxique
  • Assurez vous que l’infrastructure soit vraiment mauvaise
  • Ignorez systématiquement les dates butoir
  • Ne prenez jamais de décision, de mesure, ou vos responsabilités
  • Créez des budgets et des estimations temporelles beaucoup trop optimistes
  • Sous-estimez les probabilités et l’importance des risques
  • Ignorez les risques légaux
  • Utilisez des technologies chères, peu fiables, difficiles à comprendre, et non maintenues, qui ont des performances médiocres, et qui ont des failles de sécurité connues
  • Frequently disregard standard operating procedures and established best practices.
Équipe
  • Confiez toute la charge de travail à UNE personne
  • Vous n’avez pas besoin d’une quelconque expertise pour exécuter un projet, choisissez simplement les gens que vous aimez bien
  • Gardez la communication dans l’équipe du projet au minimum
  • Partez du principe que les gens feront des choses pour vous − pas besoin de leur demander avant
  • Ajoutez et retirez des personnes d’une équipe sans avertir ou consulter les autres.
  • Assign critical parts of the project to someone who is also working on other important projects so that the person is spread too thinly to be effective at anything.
  • Dépensez beaucoup de temps sur des questions futiles
  • Quand quelque chose ne va pas, concentrez vous sur l’identification du coupable plutôt que la résolution du problème
  • Dites que vous serez disponible, puis ne répondez plus. Répétez à souhait
  • Have vague and/or conflicting expectations for priorities and performance. There is a bonus for assigning multiple managers with competing priorities to supervise one person.
Communication
  • Ne posez pas de questions
  • Gardez votre projet secret du plus grand nombre de parties prenantes que possible
  • Ignorez les préoccupations et les retours, internes et externes
  • Concentrez vous sur le négatif − ne faites que des retours déroutants
  • Évitez toute forme de documentation du projet
  • Start work without a communications plan.
  • Wait until the last minute to request feedback, or request feedback only after significant amounts of time and money have been expended.
Enseignements
  • Posez-vous la question du POURQUOI du projet qu’une fois terminé
  • Partez du principe que vous savez tout sur tout
  • Un précédent projet a échoué ? Refaites le même à l’identique !
  • Ou encore mieux : ne cherchez jamais de projets similaires réalisés par d’autres personnes. Si vous avez vent d’un projet réussi, faites tout différemment.
  • Ne documentez pas ce que vous apprenez

Explications détaillées

It is impossible to make anything foolproof because fools are so ingenious.

- Artur Bloch, Murphy’s Second Corollary

Conditions générales
Créez une atmosphère de travail toxique Motivating and supportive working atmosphere is only for the weak, right? You are strong, right? A good background setting is a proper “it-is-not-possible-mentality” which should be shared with all team members from the beginning of the project and throughout its activities. And if things do go wrong, it is so good to add some “told-you-so-communication” to the mix. By implementing this wonderful approach you can feel the tension growing and air thickening and thus project management becoming much more interesting!
Assurez vous que l’infrastructure soit vraiment mauvaise Atmosphere may be important in creation of general background for a project, but infrastructure is its backbone. Nothing is as boring as to work with projects with good infrastructure, but if you start meddling with cornerstones of the general structure, things get much more interesting. Mix up financial management and communication processes, cancel all contracts and agreements related to the project ... Actually make sure there is no clear structure at all, because improvisation skill is what separates wheat from chaff!
Ignorez systématiquement les dates butoir On a dû vous dire que le planning est vraiment importante pour un projet. C’est vrai, mais souvenez-vous que le planning c’est bon pour les bonnets de nuit. Vous devez « aimer le bruissement qu’elles font en disparaissant »[1] et voir vos partenaires et équipiers devenir fous avec les rapports manquant et les activités annulées. Serez-vous capable de supporter le stress à l’état pur ? Rappelez-vous que le meilleur et le plus célèbre des leaders est celui qui sauve l’équipe au dernier moment… ou même après !
Ne prenez jamais de décision, de mesure, ou vos responsabilités You know the story about Everybody, Somebody, Anybody and Nobody? You probably understood the first time you heard it that it is much more interesting in real life situations than being just a story. Probably you started thinking about situations when similar thing happened to some project you were involved with. So why not to make this story a mantra of the project team and implement principles of indecisiveness, inactivity and irresponsibility. Threefold increase in interestingness of project guaranteed! Because “left to themselves, things tend to go from bad to worse”[2] and this is when excitement begins.


Équipe
Confiez toute la charge de travail à UNE personne Delegating is for fools and lazy people - so just do as many things or even better everything yourself. Yes, it might be a bit risky for the project, as things would go downhill when you get sick or have not enough time to do all the things you wanted to do, but that can be dealt with by luring yourself into the belief that you are in control of all this. So no need to worry! In case it can’t be avoided (e.g. when you decide you need a little break after all) you could also put the workload on one (and only ONE) other person, ideally a control freak like yourself, who always tends to have too much on his or her plate anyhow (so they are used to it). Loads of fun guaranteed for at least one person and if there are other stakeholders - it is time to take out the popcorn and to enjoy the show!
Vous n’avez pas besoin d’une quelconque expertise pour exécuter un projet, choisissez simplement les gens que vous aimez bien Gardez la communication dans l’équipe du projet au minimum
Gardez la communication dans l’équipe du projet au minimum A little less conversation, a little more action please! Communication takes too much time and it can be tiring to get crucial information from people and to people. So let everybody focus on their tasks! Misunderstandings and bottlenecks may not be so easy to deal with once they occur, but challenges can be overcome with some more action! No need to waste time trying to prevent them beforehand. This is what boring people do.
Partez du principe que les gens feront des choses pour vous − pas besoin de leur demander avant If people did things for you in the past (updating wikipages, programming websites, being mentors at an edit-a-thon for newbies etc.) there is no reason not to assume they wouldn’t do it again. So why waste your and their time by double checking that they are actually willing to help you out or even have a leading role in your project. Just assume they know what to do and when - what could possibly go wrong?
Communication
Ne pas poser de questions You know everything - and even if you don’t, do not ever admit it! This would be a sign of lacking self-confidence, but you believe in yourself, right? Asking questions to make informed decisions would also look like a sign of lack of expertise. Instead improvise! Make uninformed and thus wrong decisions! Do work that has already been done by others! Take your time near deadlines, shut yourself in your office in an attempt to make sense of stuff you don’t understand yourself! Make your life and that of your team members living hell! Just make sure to stick to that simple rule and make your projects much more fun.
Gardez votre projet secret du plus grand nombre de parties prenantes que possible Working collaboratively with partner organizations, contractors and volunteers sounds nice on paper - but things get complicated because other people don’t necessarily share your view or approach on the project, or might ask some too valid and thus extremely annoying questions about crucial aspects of the project. So cover it up, keep it on the hush - there is no rush in sharing the cup. Also, making sure your funders know in advance that you need resources from them (and when and how much) is completely overrated. The project is so good that they just have to fund it and keep funding, because even you don’t know how long it will last and how much will it cost. Telling the secret beforehand would ruin the wonderful surprise!
Ignorez les préoccupations et les retours, internes et externes This goes hand in hand with keeping your plans secret from other stakeholders - the fewer people know about your project, the less risk you run to get insightful, helpful, or constructive feedback. In case this feedback still makes it through to you, just ignore it. Remember: You know best! You might not run a perfect or even good project - but you did it your way - just like Frankie Boy. And every project team member and stakeholder should know that it’s your way or the highway!
Concentrez-vous sur le négatif et rejetez la faute à droite et à gauche Make sure not to waste time on complimenting your fellow team members on their big and small successes during the project or spreading confidence and assurance when your team is in need of it. Rather make sure to point out every little flaw in the project or other people’s work - ideally more than once of course. Never let go of the chance to emphasise lack of competence of other project team members. Continuous criticism will toughen up the project team and increase your self-esteem, so focusing only on the negative only has positive effects, right? And hopefully your negative attitude is contagious and gets the blame game ball rolling. And once it has started it won’t stop. Extreme fun guaranteed, because the blame game is not one of the favorites of people all around the world for no reason!
Évitez toute forme de documentation du projet After the project is finished don’t invest your precious time in documenting your project or your learnings and experiences. In case you will run a similar project in future you’ll surely remember all the details or happily invest time to trace them back and everybody else can figure out how things work themselves. There is a little explorer in everyone of us, right? And reporting is only for insecure project managers anyway. You know how well you have done and that “practice is the sole criterion of truth”[3]. Let the results speak for themselves!


Enseignements
Posez-vous la question du POURQUOI du projet qu’une fois terminé Project management is not philosophy 101 - asking yourself esoteric questions like “Why should we do this project?”, “What is the goal?”, “How we should reach it?, “What is the logic behind our action model?” etc. is just a giant waste of time. It is the same as to ask oneself “Why is there something rather than nothing?”, yada yada yada, blah, blah, blah. Time is gold and there is no need to waste valuable project time on impractical philosophical questions. Acting is much more interesting. And if someone happens to ask some questions, then there is enough time to come up with an answer to them after the project.
Partez du principe que vous savez tout sur tout Learnings? Why bother when you already know it all. It’s also bad for your image because it would mean admitting your work is not perfect and that there were mistakes and shortcomings. Of course a failed project is also not exactly building positive reputation, but then you can always blame it on the circumstances (popular: the weather or force majeure) or others, ideally people who are not present and can’t defend themselves (popular: incompetent politicians, mischievous pixies).
Un précédent projet a échoué ? Refaites le même à l’identique ! All mistakes have been done before but not by everybody - so just because other failed with a certain approach it doesn’t mean you can’t do it again. The best and easiest way to run a bad project is to copy previous bad projects and epic fails - you can’t go wrong with that! So are you smart enough to escape from pitfalls that have ruined other projects? Can you kill the Minotaur and escape without Ariadne’s thread? Challenge accepted!
Ou − encore mieux : ne cherchez jamais de projets similaires réalisés par d’autres personnes. Si vous avez vent d’un projet réussi, faites tout différemment. You can’t stop people from giving you advice or sharing their experiences with you. Especially, if they did similar projects the temptation for them is just too high. But that doesn’t mean you have to follow that - actually it’s probably better to do the exact opposite just to prove a point. After all, just copying a recipe for success is for beginners, you want to challenge yourself like a real pro and encounter and tackle every possible challenge and mistake yourself - at all costs!

Quand utiliser

The mistakes can be applied to any project, program or annual plan! Enjoy more exciting project experiences!

Examples

Grants:IEG/Motivational and educational video to introduce Wikimedia[4] suffered from highly optimistic estimates for time and budget requirements, and was largely dependent on the availability of one person who was working on multiple projects.

Soutiens

--Anna Torres (WMAR) (talk) 00:49, 27 September 2016 (UTC)[reply]

I do love the description of this learning patter, it really does show the worst scenario in every perspective. --Liang(WMTW) (talk) 03:47, 4 October 2016 (UTC)[reply]

I have successfully applied this pattern in many situations. --Daniel Charms (talk) 21:26, 16 November 2016 (UTC)[reply]

This learning pattern provides some excellent advice, and I have added a few suggestions of my own based on recent experiences as well as general observations about projects inside and outside of the Wikimedia universe. --Pine 20:43, 29 August 2017 (UTC)[reply]

One of the most lovely and instructive learning patterns ever. :) Spiritia 20:32, 18 May 2018 (UTC)[reply]

  • This accurately describes much of my work. Bonus points for projects adding unnecessary dependencies or with dependencies that are impossible to meet. Also scope creep. -— Isarra 19:38, 9 January 2019 (UTC)[reply]

Voir aussi

Patrons liés

Liens externes

Références

  1. Douglas Adams
  2. Artur Bloch, Murphy’s First Corollary
  3. Karl Marx
  4. Grants:IEG/Motivational and educational video to introduce Wikimedia/Final