Tag Archives: Process Improvement

A Cold War that’ll Give You an Ice Cream Headache

Running contrary to the New Year’s notion of doing better for several years running is the McDonald’s Ice Cream machine, a notoriously finicky piece of equipment that has its own online dashboard of failure. And if the efficiency experts in your life don’t gnash their teeth at that, they likely will when they read Andy Greenberg’s article in Wired.

Photo: Gabriela Hasbun

It’s really infuriating to see miserable experiences be standardized, but to see the lengths to which people go to preserve a sucky status quo, well, it may not be surprising, but it is dispiriting (that said, it’s a fascinating read).

Security Theater and the Future of the TSA

I suppose I should have posted this with Thanksgiving and the start of the holiday travel season, but hey, delays are to be expected with the TSA, right?Dylan Mathews over at Vox argues that the eliminating the TSA may, in fact, save lives.

And if that’s too dry, you can always check out Adam Conover of “Adam Ruins Everything” as he debunks the security theater of the TSA.

Man, I’m glad I don’t have to travel much these days.

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?