Wikimedia Meta-Wiki

Learning patterns/A short guide to bad projects

< Learning patterns
Translate this page
Other languages:
A learning pattern fororganizational
A short guide to bad projects
problemEverything is running too smoothly? Your team is bored? You’re just about to run an impeccable project? Not to worry! Here comes a digest of mistakes for you to choose from! Feel free to use, share and complement!
solutionJust follow the few simple instructions in this learning pattern and you don’t have to worry about throwing the perfect project ever again. Pick the mistakes that seem most sexy and challenging for you and your team!
endorse
created on10:28, 26 September 2016 (UTC)
status:DRAFT

What problem does this solve?

This learning pattern is the second in a series of patterns helping you to screw things up. While the first pattern focused on events, this one takes a broader approach and provides instructions on how to run really bad projects. The learning pattern is the result of a collaborative session during the 2016 CEE meeting in Armenia and comprises the experience of Wikimedians from many different corners of the Wikiverse.

What is the solution?

A smooth project with no hiccups or bumps along the road is - let’s face it - boring. What you are looking for is some stupid home-made mistakes (that could be avoided but were not) which generate a little challenge here and there to solve. Feel free to use, share and complement!

Short overview

General conditions
  • Create a poisonous working atmosphere.
  • Make sure there is really bad infrastructure.
  • Always ignore deadlines.
  • Never decide anything nor take action nor responsibility.
  • Create budgets and time estimates that are highly optimistic.
  • Underestimate the probabilities and significance of risks.
  • Ignore legal risks.
  • Use technologies that are expensive, unreliable, difficult to learn, and not maintained; have poor performance; and have publicly known security and privacy vulnerabilities.
  • Frequently disregard standard operating procedures and established best practices.
Team
  • Put all work on ONE person, or on a small number of volunteers, for a long and complex project.
  • You don’t need actual expertise to run a project so just chose the people you like best.
  • Keep the communication in the project team at a minimum.
  • Just expect people to do things for you - no need to ask them before.
  • Add or remove people from the team without notifying or consulting others.
  • 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.
  • Spend significant amounts of time on bikeshedding.
  • When something goes wrong, focus on blaming someone rather than fixing the problem.
  • Say that you'll be available and then become unresponsive. Do this repeatedly.
  • 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
  • Don’t ask questions.
  • Keep your project secret from as many stakeholders as possible.
  • Ignore all concerns and feedback from inside and outside the team.
  • Focus on the negative - give disruptive feedback, or minimize the negative and focus on the positive so much that problems are not addressed.
  • Avoid all documentation about the project.
  • 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.
Learnings
  • Ask yourself WHY you do this project only when it's done.
  • Assume that you know it all.
  • A previous project failed? Redo it with no changes!
  • Or - even better: Never look for similar projects done by other people. If you happen to be aware of a successful one, do everything different.
  • Don't document what you learn.

More detailed explanation

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

- Artur Bloch, Murphy’s Second Corollary

General conditions
Create a poisonous working atmosphere 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!
Make sure there is really bad infrastructure 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!
Always ignore deadlines You may have heard that timeline is really important for projects. That is true, but remember that following the timeline is only for boring people. You have to “like the whooshing sound they make as they fly by”[1] and to see your partners and team members go mad about missing reports and undone activities. Are you strong enough to endure the real stress? Remember that the best and most renowned leader is the one who saves the team on the last minute … or even later!
Never decide anything nor take action nor responsibility 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.


Team
Put all work on ONE person 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!
You don’t need actual expertise to run a project so just choose the people you like best Financial, organizational, or technical expertise is generally overrated - so in case you missing some of it in your team, don’t let that bother you. There is nothing that can’t be solved with a bit of googling and research! And after all you have managed many unsuccessful projects before and you learn best from the mistakes you make, right? So you don’t actually need background knowledge and skills that could save you and your team time, money, and the sensation of being overwhelmed by some tasks. And admit it, having experts on your team who already know how to do things would be really boring. It is much more fun to figure it all out yourselves.
Keep the communication in the project team at a 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.
Just expect people to do things for you - no need to ask them before 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
Don’t ask 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.
Keep your project secret from as many stakeholders as 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!
Ignore all concerns and feedback from inside and outside the team 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!
Focus on the negative and get the blame game going 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!
Avoid all documentation about the project 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!


Learnings
Ask yourself WHY you do this project only when it's done 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.
Assume you know it all 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).
A previous project failed? Redo it with no changes! 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!
Or - even better: Never look for similar projects done by other people. If you happen to be aware of a successful one, do everything different. 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!

When to use

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.

Endorsements

--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]

Anthere (talk) 10:04, 13 June 2017 (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]

See also

References

  1. ↑ Douglas Adams
  2. ↑ Artur Bloch, Murphy’s First Corollary
  3. ↑ Karl Marx
  4. ↑ Grants:IEG/Motivational and educational video to introduce Wikimedia/Final
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Learning_patterns/A_short_guide_to_bad_projects/en&oldid=27773837"