Project Checklists

It's time to take a page from the "painfully obvious but never do it" chapter. Project checklists are something that I used to do all the time when working within an agency. Half the time, I felt they were as useless as timesheets. As a freelancer, however, neither could be farther from the truth.

In the beginning

Normally, checklists are good at the beginning of a project and at the end. At the beginning of a project, the checklist is designed to elicit feedback from the client and build a foundation upon which to build. The checklist would be tailored to the type of work that you do and is essentially a list of frequently asked questions.

For example, if you provide HTML services, you'd want to ask your client whether they prefer HTML or XHTML, need files delivered via CD, or a list of target browsers. If you're a programmer, questions might include hosting information, server configuration, programming language, or anything else that facilitates the building process.

The checklist helps ensure that you get all the info you need at once. It prevents a back-and-forth between you and the client and prevents delays that might occur if you find yourself waiting for information.

In the end

At the end of a project, the checklist is normally an internal tool to make sure nothing gets missed before sending something off to the client. Did you test every page in all browsers? Do the pages validate?

Often times, a test matrix would be advantageous. For browser testing, for example, you'd list off the browsers along the top and the pages that require testing along the left. For web applications, you might include various use cases and perform each use case to ensure nothing fails.

It's important to perform the checklist in its entirety before each time you send something to a client. This ensures revisions didn't accidentally introduce an error elsewhere.

Completing the checklist is part of top-notch quality control that, while tedious, will save you time and ensure a happier client.

The downfall

Checklists, however, aren't foolproof. Like any repetitive task, the human brain gets trained to go through the motions. If you constantly skip over an item because you don't do it for 95% of the projects you work on then you'll invariably miss it by not paying attention when you do need it. Likewise, if there's a block of items that you always check, you'll get in the habit of checking them all off and inadvertently check something that you didn't verify.

Revisit your checklist from time to time, removing unused elements and adding missing items. This keeps the checklist from going too stale. An electronic checklist may also be advantageous, especially those where the position of items may not always be consistent (for example, if it hides checkboxes based on type of project). If the items aren't in a predictable location, it forces you to read the items and you'll be less likely to skip over them.

If you have your own tips, please share.

Published December 19, 2006
Categorized as Business
Short URL: https://snook.ca/s/733

Conversation

10 Comments · RSS feed
Philip said on December 20, 2006

I don't use any checklists apart from those that exist in my noggin. After reading your post I may create a generic one and give it a whirl.

The one thing I do do though is keep a ASCII .todo file for each site I work on. I use this for recording all sorts of information but I mainly use it as an aid to development. It's quick, easy and works for me as a checklist in progress.

Jonathan Snook said on December 20, 2006

I, too, use a to-do file to keep track of project specific stuff. I also use the flag option in Outlook to flag emails that have stuff that I need to tackle.

Derek Allard said on December 20, 2006

I try to submit a checklist as part of a larger "recommendations document" that the client signs off on before development really starts. Basically, it becomes a scope document so that everyone knows what is going to get built, and gives me some ammunition against the inevitable scope-creep.

I also keep a file in my root development directory that contains the server and password information (I encrypt it, its safe). This has saved my bacon on several occasions when I thought the project was done, but then needed to log back in for whatever reason and had long since forgotten the information.

Jon said on December 20, 2006

A great topic to write on, but you're right -- if you don't revisit your checklist often, it will get neglected and forgotten. Currently we're using a 'site_info' type file in which we store all the specifics about a particular site, including server config, passwords, and all that goodness (stored securely of course) and that seems to work out well as there can be up to 5 people working on the same project (designer, developer(s), programmer, etc)

At first it's a difficult habit to get into (it was for me, anyway), but the benefits are ever present when all parties involved are up to date on the latest changes.

Nate K said on December 20, 2006

I find a checklist to be very helpful. All projects I am working on have a checklist custom to the needs of the client. This is also proposed in the initial document containing the scope/timeline. As things get checked off, they are shown to the client to show progression. Also, it lets you see it all at the end - and helps plan for future projects.

With my machine, I have a 'todo' smart folder on the desktop that has everything in place for things I need to do. I also flag all messages from a given client as well, and use a smart folder to keep track of all communication with them. This helps avoid scope creep, as well as keeping constant communication.

I tried using the 'todo' list in iCal - but I found I didn't check that as often. My structure now is something that has been working for the past few clients.

This is a good topic, and im interested to see how others handle this as well.

Chris Huff said on December 20, 2006

I do the same as Phillip above. I have a text file that use as a to do list. Keeping a generic checklist for all projects would make a lot of sense though. I've just always made a mental note of all those kinds of things. You make a great point though...we tend to go through the motions and overlook things. I may have to set something like this up.

Indranil said on December 20, 2006

Very good article. I will definitely be using checklists from now on. I used to use them, but never was faithful to them. Perhaps I will go back and give them another chance.

Damian said on December 21, 2006

Nice post. Checklists are extremely important to me from the moment I found Ta-Da. It's really simple and helpful. I share my lists with some of my clients and they can add items and see what's been checked off. And in life in general, it's good to tick items off :)

Michael McCorry said on December 21, 2006

I also keep a .todo file for each project, but it usually doesn't get created until the bulk of the work is done, all the no-brainer stuff is complete, and it comes time to step back, take stock of requirements, and work out what else needs to be done before final approval. That helps me to bring back all the little things that might have slipped my mind while churning through the development part of the project.

I've tried using online to-do apps for this, but it's just too easy to use a txt file. Although I do use RememberTheMilk.com to keep track of what's coming up over the coming months, and ClockingIt.com to keep track of time spent on projects.

Kiper said on December 30, 2006

Good post, Snook.
As your projects grow I think it is impossible to finish them off with quality if you're not using checklists.
It helps you trim your work flow and it gives you material for your client folder.
You never know when a client comes back for more...
And I ALWAYS save all important data on paper since you never know when your computer will crash ;)

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.

Want to learn about scaling CSS for large projects?

I'm available for full and half-day workshops on scalable CSS architecture. I can provide on-site training for your team. Interested?
Get in touch.