How to make sure your web-related project FAILs +

Image taken from http://www.manast.com/2007/10/17/study-fail/

A quick checklist of what to do when you want your web project to FAIL (if not instantly, then over a prolonged period of time during which no one involved will be happy):

  • under no circumstances are you to acquire a staging/testing server with the same setup as the production machine(s) — what a waste of resources! The bang-for-buck ratio clearly steers in the branded coffee mugs and t-shirts direction;
  • outsource your office IT infrastructure;
  • make sure your dev team is understaffed and make sure you over-budget in the bullshit departments — after all, they’re the cream of the crop, bringing in the money with every little thing they do;
  • tolerate a lot of bullshit, incompetence and poor quality work for sustained periods of time — that way you’ll make sure that anyone actually worth a damn within the team/company — leaves.
  • make sure to add additional hoops & hurdles which get in the way of your developers getting things done; These include, but aren’t limited to:
    • have them work behind very restrictive firewalls and/or proxies;
    • do not enable VPN access into the company network;
    • while you’re at it, make sure to limit their mailbox sizes too, so they cannot access work stuff from home with OWA either;
    • for God’s sake, never give them administrative or power user privileges on their machines;
  • don’t do any usability tests/studies, focus groups, alpha/beta previews and other silly shenanigans (which require experts in their respective fields and time to process properly) — have sales, marketing and other departments chime in with what they know “just works and looks great”;
  • have a strong business plan somewhere along the lines of: “we’ll sell advertising space”. Then proceed to evaluate the project’s success on the number of banners sold, their CTRs, page views, bounce rate and similar minutiae that are completely irrelevant and easily faked/bought anyways;
  • keep looking over your shoulder constantly in fright of competition; if you look hard and often enough, there’s a strong chance you won’t get any; If God hates you and decides to strike down upon You (with Furious Vengeance), absolutely make sure to completely ignore them. Ignore the mistakes they’ve made, do not learn from what they did right, and stick to your (time and time again) proven business plan from above; If that doesn’t work, try adding extra banner positions.
  • ignore real users’ feedback;
  • invest in or bet on a software solution / technology that you know nothing about, that your developers haven’t had a chance to work with / test fully yet (or for which you’re unable to hire additional (proficient) developers); bonus points awarded for the software/technology still being in the concept stages (with nothing but .pps slides to show for and a vague alpha/beta release date) and you committing your team to an impossible go-live deadline;
  • make sure non-technical people are managing technical people;
  • ignore backups;
  • have looong, boring, unproductive meetings;
  • institute weekly and/or monthly reporting on as many levels as possible; it doesn’t really matter that the report contents are bullshit and no real work was done; Make sure to explain that it’s not because you have no confidence, or that you’re afraid to relinquish control (your strong urge to know and micro-manage everything) — it’s because the higher-ups said so, and that’s just how it’s done.

2 Responses to “How to make sure your web-related project FAILs”

  1. make sure non-technical people are managing technical people

    Personally, my favorite :).

    One of the saddest moments of my life as a developer happened when certain manager of relatively big programming team (approx 15 developers) asked why do programmers need to do unit testing, what good was it for and said it was just a waste of time. (and the manager was actually supposed to be tech-savvy)

    But, I do have a question – how to defend this position? I mean, some executive could say this misses the point – along the lines of “You don’t have to be a mechanic to drive a car” reasoning.

    I would say that non-technical manager just doesn’t understand the needs and modus operandi of tech people responsible for the nitty gritty part of the job, but still, I believe there are skilled non-technical people who can successfully lead techies, based on their great leadership, communication and people skills.

    Still, I haven’t met in person such a competent manager. It seems that the more non-technical they are, the more intimidating the knowledge of their team seems. Not to mention difficulties in explaining why something should be done.

  2. Amen.