Managing projects can be difficult. Checklists help. They provide structure and help extract information from people. Extracting information is what it’s all about. In order to make decisions, we need as much information as possible. That’s why I created these checklists…
More facts = better decisions
Clarifying the goals & the big picture is critical before starting on any project. If you think of a website as a house, you’ll quickly get the idea (as will clients for that matter too). In order for a property developer to build you a house, they need to know what kind of house you want, where you want it, what your budget is, what your deadline is etc…
Nobody contacts a property developer and says “I want you to build me a house, how much will it cost and how long will it take?”. I believe there’s no such thing as a silly question, but this is the type of question that comes close to changing my belief. There’s no quick or easy way to respond to it. The response you want to give is one that will educate the person asking the question on why it’s an impossible question to answer. Sometimes they’ll respect that response and realise you know what you’re talking about (which builds confidence / trust)… sometimes they won’t accept it and will continue to go from developer to developer until they hear what they want to hear – numbers. Not just any numbers, specific numbers. However, in order to talk numbers, you need to provide details. If you don’t provide details, somebody has to make lots of assumptions and that tends to be the source of all problems down the line.
The house analogy is the shortest answer I can think of that (a) educates the client and gets them thinking differently about web development (b) doesn’t come across as completely dismissive. I use checklists myself on all projects but it’s always on a case by case basis. I decided I’d publish generic checklists on this site though both for my own benefit and for the benefit of other web developers / clients / project managers looking to get a handle on the type of thing that may be involved in a web based project.
Silencing the back seat drivers
One thing that education has taught me is that the more you learn, the more you realise there’s an awful lot you don’t know. Or as Plato put it, “I know that I know nothing”. This realisation is what makes you respect other professions… because although it may sound easy and you think you know as much as everyone else or could easily do their job if you wanted, you have to question why you’re not doing it yourself if you know so much.
The easiest real world comparison i can think of would be back seat drivers who don’t drive themselves. They can’t drive, yet they issue instructions to someone with a full licence who may have been driving for decades with no penalty points or insurance claims to their name. This is the equivalent of me (someone working in IT) telling a dentist to make sure they check my back teeth properly or to be careful taking that bad tooth out. Just because I have teeth doesn’t make me an expert in teeth. So if I’m sitting beside someone who has spent decades dealing with teeth and years studying for all sorts of academic qualifications, I’m not going to challenge their knowledge and opinion on something they’re doing unless I’ve a damn good case. What they’re saying and doing is stuff that I’m paying for because I don’t have the skills or knowledge to do it myself.
However, some people don’t realise this and prefer to start digging holes for themselves by voicing their casual knowledge on a subject matter that is much more complex than they realise. This IT stuff can get very complex, very quickly and these checklists aren’t designed to confuse people, but rather to highlight how much *can* be involved in just a single project. There’s usually two types of reactions to these lists:
- “Oh shit, there’s a lot here I haven’t thought about and I feel completely lost” and that’s the lightbulb moment where the backseat driver usually realises they ought to stay quiet, at least until they know enough to carry a conversation on what they’re talking about. They might recognise some words and the rest becomes a bit too complex / technical. If the majority of the questions / topics on the checklists make no sense, then the job of a web developer or project manager changes. It now becomes ‘teacher’ and the back seat driver becomes a student.
- “yes, no, yes, no, no, yes, yes” – in other words, the client knows exactly what they want and are well prepared… they may not even be interested at all in IT, but most importantly they understand why they need a website.. once people know they *need* something, they tend to be fully engaged and have already invested time in researching competitor websites, talking with colleagues about it etc…
Both are actually great responses, mainly because they both prevent problems from occurring down the line. No.1 probably needs more time and may need to be educated on why all of these topics are important and how all of them could benefit the business / project etc… the irony here is that this person is now doing what a good project manager will do – equip themselves with knowledge and all the facts before making decisions and jumping to conclusions. No.2 is ready to roll and it’s simply a case of approving a quote, signing a contract and getting things started.
Fixing problems before they occur
They’re the reasons why I’ve created an entire section on this site dedicated to web project management checklists. To educate as many people as possible on what’s involved in building a site and to anticipate / prevent problems from occurring. Knowledge is power so stocking up on as much knowledge as possible in advance of starting a project is a wise idea regardless of what your role is in the project. Covering all of these topics, even if it’s for a few seconds, may save lots of headaches down the road. Right now, I only have 3 checklists up but I’ll be adding more:
I’m making the lists public simply because I’ll use them myself and I want to be able to access them easily. If they’re public, that also means I’ll also be forced in to updating them and keeping them tidy. By the time I’m finished, there’ll probably be dozens of checklists containing hundreds of questions / topics for discussion.