As a support technician in a past life, I found myself handling a variety of issues. In the support arena, our mantra was document, document, and then document some more. This would greatly assist the entire team in determining if it was an environmental issue, upgrade issue, product issue, or something that was "working as designed" (often the acronym used was it is “WAD” from Engineering). News flash; most of us don’t like documenting! So what keeps me motivated to actually do it? VALUE! Well written documentation provides transparency, clarity, and can help initiate participation that sometimes cannot be accomplished without scheduling multiple team meetings.
Issue documentation doesn’t need to be absolutely perfect the first time around. A key in being successful can be the questions that are asked in the initial discovery of the issue. An example being to ask the version number(s) if you are informed something works differently in another version. One of the best arenas to document issues that I have also utilized is just working internally with co-workers. This helps to confirm an issue relevance, significance and/or clarity.
Here are some simple guidelines I have stuck by over the years for strong issue documentation:
Do’s:
-
Identify the symptom(s) of the issue and denote any temporary change or "workaround" that has been put in place.
-
Get a clear description of the problem. A handy template I sometimes reference is the list of issues resolved in any given Kronos service pack. The title of any issue provides a super example to start from. Having “steps to reproduce” helps immensely.
-
Identify the business impact (aka priority) of the issue if there is one. One low priority example could be a system log file not consistently updating. A high priority impact example could be something that would impact payroll processing.
-
Assess environmental change that might affect Kronos. Some help desk systems at companies will typically ask some generic questions when phone support is called in. It helps to have the information first. Some examples could include:
Has anything changed recently?
Does this happen in test and not in production?
Is the issue apparent to just one individual PC?
Has the issue been reproduced?
-
Ask if anyone else has experienced the same issue. They may already have a solution! A quick internet search can also provide favorable results. Additionally, the Kronos fans forum (a Yahoo! group sponsored by Improvizations) provides an excellent opportunity to network with other Kronos administrators.
-
Gather information about the environment to demonstrate the issue. Some basic examples could include:
-
Screen shots (the old adage, "a picture is worth a thousand words" still applies!)
-
Computer hardware/software installed with Kronos
-
Number of data collection devices (time clocks) and communication method
-
Any pertinent log files (WFC, database server, or Jboss or other application server logs)).
-
What licensed software is in use (e.g. Kronos Timekeeper, Kronos HRPR or Scheduler).
Dont’s:
-
Don't introduce a complicated workaround. For example, if the solution requires more steps, it will not be handled favorably in most cases.
-
Don’t “over-document”. Keep it simple! One mental trick that I use: Read the issue document in its entirety from the vantage that it is someone other than you. Do you understand the issue? Can you reproduce it based on the document?
-
Don’t let the document become “stale”. Follow-ups or updates are very beneficial. Even if it is not a resolution, it helps to have a reminder in the document if it is for your own use.
Best of success in your Kronos issue documentation efforts! May they be fruitful and ultimately lead to clear resolution.
Comments