Tag Archives: Project Management

Eschewing “To-Do” and Using a Done List

I have been dealing with a number of deadlines for the past few weeks from Team J to my own writing… and of course, with my project management hat on, I’m always looking for ways to manage the lists and lists and lists of to-dos more effectively.

I’m sure I’m not the only project manager who gets calm by organizing or revising a to-do list. For all there is to do, it does feel like bringing some order to the chaos. But at the same time, there’s usually a lot to do. Frankly, looking at my lists in Workflowy, I have no idea when I’m going to get to everything. Some days, it really, really helps to total up all the different things you’ve done.

(For parents, this goes double.)

So when I read L.V. Anderson’s article a couple weeks ago about trying to have a “Done List,” I have to say it resonated.

Of course, I only had a chance to post this now. But then again, now I get to put this post on my “Done List.”


The Differences between a Policy, Process, Procedure, and Work Instruction

After last month’s deep dive into the realm of writing, I suppose it’s only fair that I touch on the fine art of producing and project management.

Simply put, just as a “risk” and an “issue” are different in the land of project management, so too are documents like a Policy, a Process, a Procedure, and a Work Instruction.

On a very basic level, you could think of them as increasingly detailed versions of the same picture. So:

Policy –> Process –> Procedure –> Work Instruction

However, beyond a simple “high altitude to low altitude” example, there are also considerations as to who your audience is and what you want to accomplish. You don’t need all four levels of documentation.

Explaining where and when you should go that deep can be tricky, which was why I was happy to see someone take a stab at it. Please consult this brief but handy guide to the difference between all four.

I like it enough, that I can kind of forgive them using “it’s” instead of correctly using “its.” Kind of, but not quite.

But before I digress too much about proofreading documentation, I wanted to get back to the importance of defining what level of documentation you need.

I spent a couple years creating and revising business processes for a couple different clients. For one of them, I had the luck of working with an “ITIL Jedi Master” which, though apt, was not his official title.

It was developing documentation for this client where I truly came to appreciate the different goals and different audiences of the four types of documentation.

You always need some form of policy — and luckily, in most organizations, someone has done that. (I say “luckily” — you’ll find many people in the trenches resent the existing policy and their de facto procedures are designed to undercut said policy). You might even have process. The tricky part often comes with procedure and work instruction. Because the differences between process, procedure, and work instruction can seem abstract, you will often find one document trying to fulfill the objective of all three document types — and failing spectacularly. Not only that, the people who need to sign off on the process don’t care about the work instruction level — and can often get confused by it. The cutoff between the procedure and the work instruction level can be very tricky. That’s why I like the example above.

Here’s an example: one of the areas we did a lot of documentation and service improvements was an IT Operations department. We had IT Operations staff who needed the work instruction level of detail for many tasks because they were both entry-level positions with a reasonable rate of turnover and because if very specific instructions were not followed, mayhem could ensue. In some cases, by re-doing a process flow, we were able to identify the process steps that were taking a long time. Re-doing and getting management buy-in on the revised processes gave us the authority we needed to examine what was working and what wasn’t working on the procedure and work instruction level. We could target which work instructions to revise and replace for the biggest bang for our buck in terms of service levels. It wasn’t easy, but by separating the documentation levels — both who the audience was and who needed to sign off on them, we were able to have more far reaching improvements to┬áIT services than we would have otherwise.

You will always find people in an organization that dislike dealing with documentation. Usually, this resistance has one of two causes:

  1. They are the keeper of tribal knowledge related to this procedure or work instruction and feel it is tied to their job security
  2. They have never seen documentation help them

Note that these two causes are not mutually exclusive. Also, consider how much #2 can be because the documentation tries to be a policy, process, procedure, work instruction.

You need to validate policy and get buy-in on process, especially if it’s a revision to the process, but once you have that, you may be surprised how much can be turned around by tactical improvements at the work instruction level. Once word gets around about how you’re helping eliminate headaches, the proponents of tribal knowledge may remain, but have fewer allies.

All right, that’s probably wonky enough for this time of year. Why don’t you go to that new space movie?