Every organization has a myriad of small-scale goals that need to be accomplished. These goals are recorded in Ketura as issues.
Examples of different issuesAn issue is simply a useful way of recording that someone (such as a customer or a company staff member) wishes something to be accomplished. For example, if a customer requests an enhancement to a product, a Ketura issue would be created to describe the request. Whether work will actually be undertaken on the issue will depend upon whether a project manager schedules the issue by adding it to a project milestone. Typical types of issues include:
The types of issues relevant to you will depend entirely upon the activities that your organization undertakes. Ketura comes with a helpful set of ready-to-use types, but these can be changed and new types can be created, which are then available immediately for you to use.
Information that can be recorded for an issueThe table below shows the information that can be stored about each issue.
| Field | Description | Example |
|---|---|---|
| Summary | A brief (two line) summary of the issue. | ‘Advertising artwork for Xyz Inc’s new product should be created’ |
| Description | A detailed description of the issue, including all relevant background information. Default template text (dependent upon the issue type) can be provided automatically to prompt users for required information. | |
| Topic | This identifies what the issue is about and serves as a way to categorize issues. What happens to an issue from the time it is created is determined by the workflow configured for its topic. A good way to decide what topics should be created is to consider what your organization will want to file issues about. Those things will be candidates for being topics. | A book publisher might create topics for all its books. A software company might create topics for each component that goes into the products that it creates. An accounting firm could create topics for each service that it offer (for example, audit and business assurance, consulting, corporate finance and tax consultancy), or perhaps each of its clients. All three organizations would also create additional topics for things such as their websites, internal administration, marketing materials, etc. |
| Subtopic or topic version | This further identifies what the issue is about. This field may not be appropriate for some topics. The subtopic/version of the topic in which the issue is fixed can be recorded separately. | For a book publisher, there might be subtopics for each edition of its books. Thus, a typographical error could be recorded for a particular edition of a particular book. A software company might use this field to record the version of a software component for which an issue is reported. |
| Type | This identifies what sort of issue is being recorded. The available types can be configured by the system administrator. | ‘Requirement’, ‘Risk’, ‘Defect Report’, ‘Enhancement Request’, ‘Helpdesk Ticket’, ‘Note for Future Review’, ‘Administrative Activity’, etc. |
| State | Identifies how far the issue has progressed in the workflow defined for it. The available states are typically set by the person who administers your Ketura system, although the system comes with several types already defined as a starting point. Each state is either active (issues in the state are still outstanding) or inactive (issue in the state have been dealt with and no longer need to be considered). | ‘New’, ‘Resolved’, ‘Rejected’, ‘In Progress’, etc. |
| Severity | How important the issue is to the person experiencing the problem (or making the request) that resulted in the issue being created. Note that this is for information only, and does not necessarily affect when a manager might schedule an issue to be resolved. | ‘Minor’ (issue isn’t greatly affecting users), ‘Important’ (issue is causing users difficulties), ‘Critical’ (issue is making a product or service unusable), etc. |
| Related contacts | This lists all the people interested in the issue. | |
| Related file attachments | Files (documents, pictures, screenshots, etc) can be attached to each issue. | A screenshot showing a bug in a piece of software, or photos of preliminary designs for some new marketing materials. |
| Related issues | A list of any other issues which are related to the issue. | Duplicate issues. Issues that depend on this one. |
| Desired start and end dates | If an issue resolution is time-sensitive, these dates may be supplied. If either date is unlikely to be met, the system will then display a warning against the issue in any project milestone containing it. | |
| History and comments | An automatically-maintained list of every change made to the issue, who made it, and when. Comments can also be added to the history. |
Several of the fields above are concerned with issue workflow. This is discussed further in Ketura Tour Step 8: Workflow.
