Issues Management

Home Solutions Issues Management

Understanding Issues Management

A Proper Resolution Process Increases Productivity

By implementing a proper Change Process, you are able to optimize workflow and maximize the productivity of your entire team. FIT achieves optimal workflow by maintaining proper ownership and keeping individuals aware of their most immediate responsibilities.

Action Items can be grouped, reviewed and summarized instantly, at any time. This includes details, instructions, attachments and anything else that is needed to comprehend or reproduce a problem that needs to be solved. In addition, documentation is available in the future for review, or to see how similar situations were resolved in the past.

What is Issues Management?

A development team is made up of individuals with different roles, abilities and responsibilities. The success of a team depends on the ability they have to coordinate these roles and responsibilities, and effectively pass information between each member. A team will be working on a number of issues at any given time and each issue can pass through numerous states until it is successfully solved or completed. This is Change Management

Issues Management is the process of organizing and managing these states, recording the history of the issue as it passes from one state to another. Effective management provides a history of the entire process and the activities that each team member performed at a specific state. When issues are properly tracked and documented, individuals performing each step are able to solve problems much more effectively, and the entire process becomes much easier to manage.

FIT encapsulates the “Change process” and allows team members to group and compare issues with common states or elements. FIT Tracking Solutions are extremely flexible and allow complex customization for specific needs. The filter, report and chart features provide powerful tools to compare activities and track the status of issues within your group or team.

The Change Process

A change process is the set of rules that exist to control workflow. These rules define a set of states and determine how an issue can pass from one state to another. This includes not only the path that the issue can take, but also the states that specific users are allowed to assign to an issue.

The default behaviour of FIT is to allow our customers to follow their own change process. When FIT is installed, a default process is put in place to allow the product to function immediately. This includes a common set of states that are outlined in the diagram below. FIT Tracking Solutions can then be configured to meet any needs.

Our default process begins in the “Open” state and progresses to “Ready for Retest” and then onto “Closed”. Closed issues are then hidden by default in the system. If the issue is not tested successfully, it is then sent back to the open state to start the process again. An issue can become “Deferred” at anytime and remains in that state until the user is ready to address it.

Default Process

Simple Example

  1. A bug is often raised by a tester. A description of the bug is written, including the environment, product revision, and instruction on how to reproduce it (if possible). The bug is then assigned to the project manager to determine which department is responsible. The bug is marked as “Open”, and immediately begins a history trail within the system.
  2. The project manager is notified that a new bug has entered the system. Immediately, the manager determines who should be handling the fix for the bug. The bug is then re-assigned to the correct developer who can fix the problem.
  3. The developer reproduces the bug using the information provided by users who defined and directed the bug to him/her. Then the bug is fixed and its status changes to “Ready for Retest”. The developer passes the fixed bug to the testing or QA department.
  4. The tester is notified about being assigned a bug, and tests the bug to see if the newest fix is working properly. If it passes, the tester moves the bug to “Closed” , or marks it as “Rejected”, if it still does not pass the testing phase. A “Rejected” bug will go back to the developer, who must attempt to fix it again. At any time during this bug fix, the exact status and history of the fix are available to everyone in the system. This information is also easily available for creating reports of outstanding issues. At any stage in this process, there is a full history trail and accountability record as illustrated below (this is also the actual email notification format that is passed to each individual as they are incrementally assigned the issue):

Process example

Advanced Process Options

As customers have made requests, we have begun to add customizations to allow customers to restrict the process in a few ways. The following configurable strings have been added:

sDefaultStatus allows you to set the default status on the New Bug screen. This is useful if you need to change the set of states in your change process.

sRestrictStatus is used to control the actions of some users. This string contains a status list (separated by commas), which cannot be set by any users, with the exception of an admin user or the creator of the issue. All other users will not see these status types as valid options for status on the modify pages. The default for this string is “Closed”, and the option is turned on in the Server Configuration menu.

You are free to structure the states of your process in any way that you like. The states can be changed on the Admin -> Default Fields menu under the Status heading.