Sine Qua Non of Project Management

Use issue tracker

If what you’re doing can potentially be called a project, then the very first thing you need to do is to create an issue (or task) tracker. Not a new Word file, but a new project in a dedicated issue tracking software (that you know how to use).

As outlined in all of the project managment books, the issue tracker is a place where you can write down all the tasks that need to be done, and then mark them as done when they’re done.

In order for this to actually help you manage the project, you need some rules that really, really shouldn’t be broken by anybody. What’s more, the whole team should enforce these rules as other communication channels sound a siren’s call of simplicity and lack of transparancy. That’s how we get to the first rule:

If it’s not in the issue tracker, then it doesn’t exist

This is the most important rule. If you don’t follow it, then you’re not doing project management. You’re just doing someting random and hoping for the best.

The rule doesn’t imply that you can’t take a call from the client about an outage. It just means that as soon you put down the phone, you need to create an issue in the issue tracker. All work starts if and only if an issue exists in the issue tracker.

More broadly you can have a rule that if it’s not written down, it doesn’t exist and never has.

Everybody on the team must always be on the lookout for email/mail/chat/verbal requests that don’t have their counterpart in the issue tracker. This extends to additional information gathered trough any channel: any additional information should be added to the issue tracker.

A single issue is a single issue

People love to write in multiple points. They are doing this as a single stream of thought and it ends in one single issue. What is easy for issue writer, is not easy for project manager or developer. Different points from the same issue:

Each point will certainly have different comments that have a tendency to quickly evolve to neverending, opaque discussion, commonly seen in email threads.

To avoid this problem, you need to take great care in writing simple, undivisible issues. Each time you start listing things in an issue, this is a sign that you should be writing mutiple issues.

As people work on the issue, they will naturally discover new things that need to be done. It’s tempting to just keep ammending the issue, but this is a mistake. Instead, you should create a new issue and link it to the original one. This way, you can keep the original issue simple and focused, while still having a clear connection between the two.

The person who is assigned an issue is responsible for moving it to its final resolution

If the issue is assigned to you, then you are responsible for either fixing the issue, adding information to the issue, checking the issue or reassigning the issue to someone else who will work on it. If you go to a vacation, make a triage of issues, select the ones that you’ll keep for after vacation and reassign the ones that are left.

Issues workflow

There are many different workflows that people use to manage issues. One the most basic ones is the following:

Some tools allow automatic reassignment of the issue once its status changes, but if not, then it’s up to the person who is working on the issue to reassign it to the next person in the chain. For example, if a developer fixes the issue, then they should reassign it to the original reporter. If the original reporter finds that the issue is not resolved, then they should reassign it back to the developer.

That brings us to the next few interrelated rules:

The person writing the issue should understand it well enough to validate the resolution

As per workflow outline above, the one who wrote down the issue is the one who is responsible for validating the resolution - and that obviously can’t happend if they don’t understand the issue.

Commonly issues originate outside of the organization. For example, a client or a user may report a problem. Before this becomes an issue, a member of the team needs to understand it well enough to write it down. Typically this means that the person who is writing the issue should be able to reproduce the issue (and obviously write down all the steps to reproduce it).

Write issues for non-all-knowing developers

Any semi-competent reader (of the issue) should easily reproduce the issue based on information in your report. Being part of the original development team should not be a requirement to understand the issue. Describe how things currently work (perhaps steps to reproduce, actual result) and how they should work (expected state). The report should clearly answer how the test was performed and where the defect occurred exactly as well as what the defect is.

Sometimes a single word in the title is enough for the developer to understand the issue. But much more likely it will cause a to-and-fro. And the same shorthand description (that caused moderate frustration in the previous sentence) will absolutely certainly loose all meaning for a team member three months down the line and it will be a complete giberrish for any external observer. So, don’t do it.

Respond to requests for additional information promptly

You want the issue to be resolved quickly, right?

Don’t bogart that joint (issue)

Sometimes issues get assigned to people who are not the best suited to resolve them. This is not a problem. The problem is when the issue is not reassigned to the right person (quickly).

If you’re not the right person to resolve the issue, then reassign it to the right person or back to where it came from.

If you’re missing information, then ask for it.

In both cases, don’t sit on the issue - take a quick look at the newly assigned issues at least once a day and ask yourself whether you’re the right person and whether you have all the information needed.

Bonus rules

Don’t call an issue a bug

It might be a bug, it might be a misundestanding, it might be a feature request. It doesn’t matter. It’s an issue until it’s proven a bug. This rule is also a tip of the iceberg of proper communication tone - harsh words, sarcasm and belittling are not welcome in any modern organization. They are also not conductive to a quick resolution.

Don’t ask how it’s possible that we have an issue. Issues are inevitable and not always easy to fix.

Always include un-cropped screenshot

Un-cropped screenshot contains a wealth of information. Including, but not limited to: browser version, URL, date, time, windows version, scroll position. Developers don’t care if you have Facebook open on another tab. But screenshot cropped to 100x100 doesn’t convey any information. Issues without screenshot should be rejected. In rare cases when it’s hard to attain the un-cropped screenshot, a team member can try to replicate the problem and add screenshot. But if that is unsuccessful, then the issue should be really bounced back to original reporter. That being said, if the screenshot doesn’t include the URL (as is the case on mobile devices), write the url in description.

Did I mention that a picture is worth a thousand words?

Write a concise title that summarizes the issue

Any non-trivial project will have some kind of a board where issues are listed. If the issues have good titles, then it will be easy to have an overview of the project. This will save a lot of uncessary clicks and scrolling; ultimately helping the issues to be resolved faster.

Search whether the issue is already reported

It’s not always obivous whether the issue is already reported, especially if it was already resolved. But investigating a little bit of time into this question, you will make your team happier. Related:

Watch your spelling

Not all search engines will help find a bug if the spelling is wrong. As an extreme example, when the issue title says “a dog”, but the screenshot shows “a cat”, the team will certainly use time to figure out what the hell this means.

Use English language

We live in globalized world. In three months your management may hire new developer from Lesotho or contract a consultant from Slovenia. If you’re not using English, then you’re excluding them from the conversation.