Should I file my checklists as documentation?

Question

I keep lots of little checklists of to-do stuff. I used to keep them on a legal pad and I threw away the pages when they were done. Now I use an iPad app, so my history is always stored,but I don't save it in any form of official documentation.

I'm a programmer so most of my work is documented via version control, but there's lots of little fixes to non-version controlled software, database changes and check-ups I do as I fill a sort of support role as well.

We've been trying to document what we do in my department more so the idea came to me, but my changes aren't the ones that have been causing problems.

Should I keep my task list as a sort of official documentation? How would I make sure it's actually useful for someone other than me?

Answer 1

It sounds like your department is trying to keep better track of who is doing what and what is being done, so towards that end I would say yes, you should keep them. That said, it sounds like in the format they are in, they will not be useful to many other people, as they may be random collections of big and little tasks with little associated information or tags.

If there is a concerted effort in your department to track and document more, it does sound like a good time to begin using software for this. One of the huge benefits of using a service like Fogbugz, Teambox, Trello, Pivotal Tracker, etc, is that everything you do becomes searchable to both yourself and any current or future team members. Want to see the first time someone dealt with a particular issue, or if it comes up often? Search for it, and see what comes up.

Personally, I implemented Teambox in my workplace, and I encourage my coworkers to use it for collaborative tasks. But I also use it myself for things that only I need to keep track of, knowing that whoever is in my role in the future (even if it's me!) may appreciate this history of how certain things were handled before.

Many of these systems are fairly quick and easy to use and integrate a commenting stream do that updates and discussions around a task are stored with that task. Also, if there are repeatable task lists, many of these systems let you store them as a template.

Answer 2

I had kind of the same situation at my previous employer. I ended up just starting to write up in our wiki each time I had a new non-trivial support issue I had to deal with. It was somewhat enlightening, as there was a significant amount of information that I had just internalized. Even the tiny issues really assume that you have at least some level of institutional knowledge.

It's a pain to do when you start, but afterwards, it's kinda nice as you can take a vacation and maybe get one phone call instead of 3-4 a day. :)

Answer 3

I would say you should document everything you do. If the only documentation is the checklist then yes, it should be saved somehow.

A note on terminology though, I'm not talking about "documentation" in the sense of someone else referring to it later, I'm talking about a record of your activities, suitable for mentioning at your performance review. Keeping a list of what you've done will help you put together a statement of accomplishments, and if you've missed important goals it will give you an idea of what other tasks came up that made the goals/deadlines slip.

Answer 4

Maybe. I think the place they would be most useful would be training staff to take on new tasks that they are unfamiliar with. For example, trouble shooting a specific class of problems might involve walking through some steps and using a checklist to eliminate certain situations. A checklist might also be good for tasks such as complicated code deployments or server changes. I've seen simple checklists in the documentation for developer setup guides for setting up the environment for more complex projects.

The downside of a checklist is when the person following it is unknowingly on an instance of the task that deviates a bit from what the checklist assumes. Hopefully though, that won't happen until after the person is skilled enough to not need the checklist and make their own decisions.

You also want to avoid having people become entirely dependent on the checklist, so maybe don't make it too detailed - maybe write it more as a high-level guidline, unless the specific task will not change and the deep detail is necessary.

Answer 5

You should check your companies document retention policy. Some companies may require you retain them, some require that you do not. The reason is after a certain amount of time they can be considered discover-able documents for legal proceedings. These vary by company. I have worked at companies that considered any document over 5 years a record that required retention. Even if it was a menu used for take out that had a not scribbled on it.

From Wikipedia

The retention period of a document is an aspect of records management. It represents the period of time a document should be kept or "retained" both electronically and in paper format. At the termination of the retention period, the document is usually destroyed. The term is generally used by accountants and tax professionals whose occupation involves dealing with legal documents that only need to remain in existence for a certain amount of time. The retention period varies for different types of records. For example, business incorporation documents have a permanent retention period (meaning that they should be retained and never be destroyed), but receipts for tax-deductible purchases by an individual taxpayer usually have a three-year retention period (and can often be safely discarded after that point.) The length of the retention period vary by industry and are based on the likelihood that the document will be needed at some point in the future for ligitation reasons. Records that will serve no further purpose (as determined by the length of their retention period) are destroyed for space issues, usually by paper shredders.

Answer 6

To answer your last question first, you will only know if other people are interested after you document it somewhere others can see it.

My suggestion: document it on a wiki where everyone can see it. You can either put it on a page as an "official" procedure for your position or on a personal page. But then at least other people can see it when you are away and take over your tasks. And people in similiar positions across the company can peer review it and exchange ideas.

The key is keeping it public and easy to update (and access, even via your iPad).

Answer 7

Do you have a case tracking system like Bugzilla or FogBugz? I work on a programming team and we use our FogBugz instances for general tasks in addition to bugs/feature requests and it works pretty well.