Tame Your Projects with an Issues Log
Become a project management deity by expecting the unexpected. Get-It-Done Guy explains how.
Page 1 of 2
In an earlier episode on using a visual timeline, we explored how the right visualization can help you understand how you expect your project to unfold. But you’re trying to tame Fate, which means the best laid plans of mice and men might end up involving cats, women, and intersex. Be prepared.
When coaching Bernice, Europa, and Melvin through the build out of Green Growing Things’ expansion store, the project hit a snag. A few weeks ago, Melvin reported, “The Audrey 2s are demanding Persian rugs for their area of the store. They say they’re tired of living like they’re on skid row.” Unfortunately, nothing seems to have happened since. .
Give Unexpected Issues a Home
As their coach, it was obvious what was going on: Fate had thrown a monkey wrench into their plans. They were using their project plan to guide them, but their project plan didn’t include anything about Persian rugs. After Melvin brought it up at the meeting, everyone assumed someone else was taking care of it. The team didn’t have a good way to make sure the unexpected got handled.
So I introduced them to the Issues Log. An issues log is a shared list of all the issues the team has encountered, and what’s happening with them. An issue is anything that causes or will cause the project to stall. Like when the Audrey 2s refuse to move in without Persian rugs. I could understand it if there were a chemical sensitivity issue, but this is just a bunch of carniverous plants throwing their weight around.
An issues log is simply a numbered list of issues. When Melvin—or anyone else—brings up an issue, the team leader records it in the issues log and later uses the issues log to run team meetings. Europa, ever the over-achiever, jumped at the chance to be the “owner” of the issues log. I explained that it should live in a shared document so everyone can review it. Use a table in a word processor document or a spreadsheet. Each row is one issue. You can use a full database if you need to, but I like the simplicity of a single table.
Number Issues as They Arrive
When an issue comes up, big or small, add it to the issues log and number it. Never reuse a number within a project. Europa dutifully added Audrey 2s demand Persian rug is issue #1 in the issue log. The rest of the team chimed in. Soon, issue #2 was Neon store signs aren’t allowed in the historical district. Issue #3 was Basement wall is leaking red glowing radioactive ooze into the storeroom.
Giving each issue a number lets you refer to it unambiguously. If issue #86 is Basement wall is leaking green radioactive ooze, everyone knows the difference between issue #3 and issue #86. Without the numbers, Bernice would say “How’s the ooze situation coming?” and some people would discuss red ooze, while others would discuss green.
Numbers have a psychological role, as well. When an issue comes up, the team must decide if it’s important enough to deserve a number. It sounds small, but it encourages enough thought that you can discard trivial matters.