Skip to content
April 13, 2007 / Bob Black

The List

It’s notoriously difficult to track the progress of software development projects, because it’s hard to get an idea of exactly how much work is being done. When someone is rocked back in their chair staring blankly at a whiteboard, are they thinking hard, or hardly thinking?

Which is why you’ve got to give customers something tangible to show what’s being done. Consulting firms know this – they produce a hundred pages of documentation for every hour worked (it can seem like that anyway). I’m guessing that’s also why you don’t hear of many consulting firms using a methodology light on documentation, like Crystal Clear (or Yellow) or XP (or any other Agile methodology).

In my case, I document like crazy both to keep my own sanity, and to Cover My Taters (CMT). My favorite form of documentation is the plain old list. I have lists of problems, list of tasks, lists of requests, and at least one of those lists is usually on my second monitor or displayed in a Google Desktop Widget for Quick Reference.

Besides helping me keep my sanity, lists are also great for easily communicating to management what you’re working on. The lists I create for my personal consumption are written in a form of shorthand that only I can make sense of. When I’m ready to create a weekly status report, or other formal documentation deliverable, I take a few minutes to word everything into something presentable.

There’s another reason lists are wonderful – they overcome one of the most confounding problems of communication: the paragraph (and its cousin the runon sentence). A paragraph of more than about 2 sentences causes the eyes to glaze over. People readily admit that they “didn’t read that [long] email”. But for some reason, people will read long lists (within reason).

Consider this paragraph:

My status for last week: I met twice with the Glindberg account to gather requirements for their accounting system. We will be meeting twice a week (on Thursdays and Fridays) through the end of Q2 to finalize initial requirements. I will be scheduling a prototype demo with Glindberg’s management team at the end of the month, and will need assistance from someone on our development team. 

And now consider this list, which I believe is infinitely easier to process:

Last week’s Glindberg status:

  1. Held two requirements meetings
  2. Will be meeting twice a week (Thursdays and Fridays) through Q2 to finalize requirements
  3. Will schedule a prototype demo with Glindberg management at the end of the month
  4. Will need developer assistance during prototype demo

Lists divide up a lot of information into manageable, easier to process, chunks of data. Like sound bytes on paper. They look good, and they make you look good.

I like it a lot.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: