Blog of a Boston-based IT Consultant

There are a million flavors of Issue and Task Logs. There are also a lot of nice software products out there to help you track bugs, manage work packages, and keep a tight grip on your project. However, some organizations have young PM/BA efforts and cannot afford or do not quite yet have the need for something robust and keep a tight grip on your project. However, some organizations have young PM/BA efforts and cannot afford or do not quite yet have the need for something robust and comprehensive. Sometimes you have a conference call and six or seven pages of notes that need to be translated into something portable and understandable. In that case, I recommend Excel.

This particular .xls is something I just created off the cuff. It would be most suitable for a small team that had scrum meetings in the morning (even if they are not called scrum meetings and people just get in a room and talk). You may have no use for the ‘Severity” column. You may want to put a lot more detail in the “Notes” field. The point is, keep it modular, keep it simple, keep it unambiguous, and let your team dictate how it is structured.

This Issue/Task Log would be one tab in an Excel workbook. In some cases, I may have a seperate worksheet within the workbook for UAT tracking, Task Identification, and Risk Management. Most likely, I will break the more unruly sections out into their own workbook or even Word document. This is documentation on a budget. I know there are pretty slick tools out there, but Excel works just fine for small projects. Of course, once the project hits a certain size, you will want to implement Bugzilla or some other bug tracking software. What I depict here would not be relevant for a shop that is running Team Foundation Server or other project-oriented development tools/environments.

When issues arise, it is not always apparent if it is a bug, a question, a point of ambiguity, or something out of scope. I like this format because the initial page can capture anything, and it allows you to remain agile.

The Task List is much more stringent, and if you are maintaining it manually you have to be disciplined. If you slack off for even a few days, it may be impossible to adhere to traceability practices. That is what this is all about, really: traceability. These types of manual documents are as useful at the project’s end as they are during execution.

Items move from Open to QA as they are addressed and tested at least briefly by someone on the team. I generally have a UAT tab to track testing, and work on it with the client in a GoToMeeting or in person. I actually create a new tab for each UAT session for accountability, to reveal flaws in code, and because really, every few sessions you should go back and retest EVERYTHING. Sometimes a fix will break something else, as you know.

In this particular example, as issues pass UAT, they move from QA to Closed, and get pushed down the bottom of the list, greyed out, and segregated. This is an arbitrary way of maintaining the document, and if I am going to be honest, it does not particularly appeal to me. Still, this document is not only (or even mostly) for me. It is for the team. One of the developers gets thrown by not having open items together in one lump. They freak out about it. I personally do not like moving the items. It makes Issue “6″ harder to find because the Excel row numbers are confusing and because unless issue numbers are sequential, I don’t know any easy way to order them.

This, however, is an example of a small project, and if the team likes it, I will produce and maintain it.

The filename is always at the top. I like to do this. The “Effort Identifier” could be the project name, or something like “May Maintenance”.

Don’t forget that Action Items become Agenda Items pretty happily and that depending upon the buzzwords at your organiztion,”Severity” can become “Prioirity”, have a MoSCoW status, or something else. This is built to be tweaked. Adaptive.

I am sure you will notice that I reference other documents within this worksheet. If you do not have a comprehensive tool, you will have to create one with what you do have. This allows for Object-Oriented Documentation. The Risk Assessment Worksheet will probably live in a distinct Excel worksheet, because it will undergo many iterations and will likely be in front of a different audience than this document. Please see my post about Risk Management for a nice Risk Management template that is easy for almost all audiences to understand.

The worksheet I show above is not the only way to track issues, and it is certainly not the best, but in a pinch, you can do something similar. I dont imagine there is anything very novel in this post, but I hope someone finds it useful. Keeping track of tasks does not have to be difficult.

If for some reason you wanted to download this little template, you can do so by clicking the Simple Issue Log link.

Best,

Josh

Project Management | RSS 2.0 | Comment it , or trackback this post.