Issue Overview

Issues are used to document and manage events which occur throughout the course of projects and are separate from the Task/Project hierarchy like To-Dos. These events are added as issues because they are not part of the current project plan, but surfaced later as new discoveries which must be addressed in the project. Issues can be added to any other item in Project Insight within the same set of rules for many other items (i.e. Discussion Threads, Files and Folders). Issues are most commonly organized into specific folders or existing tasks. Issues have basic reporting functionality for displaying data fields and applying reporting filters, along with their own Issue Security Rules.

Issue Notifications have unique functions for issue creators and assignees as to the progression of events and/or escalations of the issue. An example of a common issue process is as follows:

1. An Account Manager discovers a new product feature opportunity during the course of the project.

2. The account manager adds the issue, assigning it to the Product Development Manager for consideration in the current project. The issue data fields are modified by Account Manager as follows:

a. Issue Types is Opportunity.

b. Issue Status Types is New.

c. Issue Priority Types is Medium.

d. Issue Resolution Types is Postponed.

e. Issue Severity Types is Minor.

3. The Product Development Manager receives an email notification with a link to the issue which must be reviewed, followed by the acceptance or rejection of the issue.

4. The Product Development Manager accepts the issue, which alerts the issue creator via email that the issue has been accepted. Notes are added to the issue comments by the Product Development Manager that an investigation is underway to determine cost and delivery consequences to the project should the new feature be implemented.

5. The Product Development Manager attaches the issue to a project task within the link to the right of "Project and/or Task." This attached task is the task within which the new feature will have the greatest impact.

6. The Product Development Manager concludes the cost and delivery consequences. Comments are entered into the issue for review by the Account Manager as to the consequences that must be accepted for incorporation of the new feature into the project. The issue data fields are modified as follows:

a. Status Type is In Process.

b. Assigned To is changed back to the Account Manager (this change will automatically email a link to the Account Manager for acceptance).

7. The Account Manager accepts the issue and proceeds to get approvals on cost and delivery changes for the new feature. Upon approval, the Account Manager modifies the issue data fields as follows:

a. Status Type is In Process.

b. Resolution Type is Unresolved.

c. Assigned To is changed back to the Product Development Manager (this change will automatically email a link to the Product development Manager for acceptance).

The Product Development Manager accepts the issue. A baseline is saved for the project prior to making any changes for the new feature. The new task (summary task if more appropriate) resulting from this new feature is attached using the link to the right of "Resolution Project and/or Task." The issue data fields are modified as follows:

a. Status is Complete.

b. Resolution Type is Resolved.

To Close an Issue - any Resource with the Issue Manager Role in their System Roles can change the State of an Issue to Open/Closed. If the User created the Issue they will also be able to change the State to Open/Closed. 

In the above example, the changes to the project schedule and budget are tracked via baseline. References to the issue which caused the change are maintained so that more information is available for future reference as to the reason for the change.