Sites are Hard, part 2
tl;dr: In which Ben blames everyone else
Mavens was established in 2009 (it says so on our logo). It's now 2011, and the level of interest any of us actually have in the nitty-gritty of running a website is fairly evident. Fortunately we attract customers by other means. [Surprise and fear - Ed.]
YOU'VE READ THE FIRST PART, RIGHT?
Armed with a document that made sense only to Ben, we decided it was time to regroup and analyse the situation with all relevant stakeholders. While that was happening, Ben went on a five-day bender, in which he attempted to consume his own body weight in cheap milkshakes and jelly.
Waking up with a horrible headache, he found himself in Windsor, outside an agency with a spectacular orange door. Mistaking it for a patisserie, he ducked inside, and soon realised he was in the middle of a design powerhouse. [He broke in, and promised them work so as not to be arrested - Ed.]
Realising that these masters of their trade were available to work for very reasonable prices, he entered into formal negotiations for their services. I mean, who wouldn't want to work with a company represented by a great website? You should go and look at it now. No, seriously, go on.
Jesus, you're lazy. OK, here's a picture to break the monotony.
Look, try not to hold it against them, OK? Websites are hard.
IT HAS A FEEDBACK FORM, YOU KNOW
Anyway, Ben talked them through the documentation, and everyone agreed it was great. Apart from all of it. Ben riposted by crying until they gave in, and gave the project to Andy, allegedly the best designer in the world. Having won Ben's trust and regard through his cogent analysis of the situation [He told him he liked his hair - Ed.], Andy went away and produced some designs. Designs that people actually liked. They looked pretty much like this:
Andy's put some of his designs on his awesome website. We understand he work for cash money.
WHAT HAPPENS IF YOU TURN IT UPSIDE DOWN?
Fortunately, the board had recognised the chance of a website launching, and quickly moved to rescue the situation. After barely weeks of assessment, it was decided that Andy could do better. Sadly, by then Andy had moved onto other projects, but the prospect of further delays was no deterrent in the search for the perfect compromise. The revisions came back, and then was further revised through careful feedback, until it looked something like this:
If Ben hadn't ended up catatonic with rage at this point, things might have deteriorated further. Fortunately, his utter incapacity meant that cooler heads were able to take the designs on to production, to make them into web pages.
There were several things that weren't done very well here, and mostly they were around communications. Some lessons to be learned from Ben's hapless flailing:
- Respect your stakeholders. This can be hard, as they're invariably wrong, but really, the time to fight that battle is when you select who they *are*. Once they're fixed, you need to make them respect the project, and that means listening; lots of listening.
- Respect your development team. You've got professionals who are going to do their best. That means that sometimes, very rarely, you might be wrong. Feel free to argue with them, but try to do it from the perspective of your end user, not your own, or on the basis of your expertise in the field they have a decade more experience than you in.
- Understand your priorities. Don't put something down as an internal project and expect it to get done. It has to be a goal with an objective as important as revenue to the people driving it, or it will always get moved to the bottom of the pile. If you have formal project processes, use them, whether they be agile or waterfall.