Projects for technical issues and communication to multiple customers

[Logan]

I often have topics where someone reports a technical issue. Then I make this a OmniFocus project with the reporting person in the project title:

Doe, John - Data lake update XYZ fixed

Then this goes it‘s way and I know who I am doing this for.
However, in the mean time one or two other parties report the same issue. Still, I have 1 problem to solve and to keep multiple parties in the loop.

How do you handle such situations in terms of projects, actions and maybe waiting fors?

 

[mcogilvie]

Good question. My initial reaction was to suggest that if the initial bug report comes to you by way of specialized bug tracking software, it may be more efficient to leave it in there and aggregate the bug reports, which may carry different information, et cetera. However, there are many reasons to not use such software, or to have an exterior tracking mechanism (like a GTD project). It seems to me that information about the bug, including who reported it, is project support material. For small projects, this can be stored in the Omnifocus project note field. If you want or need to report to bug reporters that the bug is now fixed, this is a future or pending next action to be completed before closing out the project, and OmniFocus has good mechanisms to handle that. Hope that helps!

 

[cfoley]

I would add the list of people to contact to my project support.

However, having to contact multiple people at the end of a project is unusual for me. If it were a regular occurrence, then I would look for a better solution.

 

[fooddude]

I would take a note and throw it into my inbox. Later when I could think about it, I would make/enter the project. My inbox is cleared daily. In this example I would list the project without any names and put the name in project support. It seems you will have more incoming calls so you will add the names to the list. I would then add the very next action to my contexts. I realize it may default to @Computer, but the very next action might be a call which goes on @phone. I rarely just put something on my project list in real time. It seems difficult to do it on the fly and I just have a project list so I wouldn't list it and try to take notes. It is also easier to break the project down to what done looks like into a sentence, rather than try when I'm on the phone with someone who has an "emergency". It really takes the focus off them to help solve their problem.

 

[schmeggahead]

I often have topics where someone reports a technical issue. Then I make this a OmniFocus project with the reporting person in the project title:

Doe, John - Data lake update XYZ fixed

Then this goes it‘s way and I know who I am doing this for.
However, in the mean time one or two other parties report the same issue. Still, I have 1 problem to solve and to keep multiple parties in the loop.

How do you handle such situations in terms of projects, actions and maybe waiting fors?

When John Doe reported the issue, you already have a full suite of tasks on your plate to bring that ticket to closure. When only John Doe reports the issue, you know everywhere when to use John Doe as input to that next action, such as notify him of closure and where to find that information, in the project title.

When others report the same issue, you also need that information in all the same places where you need John Doe. This is clearly a case of having information (Smith, Jane has the same issue that Doe, John has) and having it available when you need it. It squarely falls in the organize phase, put it with other things that mean the same thing to you.

Project support, the ticketing system (associating tickets to each other), the project entry itself are among available options.

If I was to be in this situation, there were already a reasons that I put a project in my GTD system and there is already a reason I put the affected party in the project title. I would then either add the additional names to the body of the project entry in my list manager or put it in a project support page in Obsidian, linked to a reference entry in my list manager (Apple Reminders). I would keep the original ticket owner in the project title because they are on the primary ticket where all the information would probably be placed.

Hope this helps,
Clayton.

When we put things together that don't mean the same thing to us, we created subconscious ambiguity, that blob will repel us.