This chapter describes how to manage issues related to projects or tasks in Oracle Projects.
This chapter covers the following topics:
An issue is a concern, problem, or outstanding question on a project or task. Issue management is the process of recording, tracking, and resolving issues. This process often requires the collection of input from various people associated with the project, and other interested parties. Oracle Projects provides you with a centralized issue management system that enables you to manage this process and communicate issues in a consistent and timely manner.
Issue management offers many features, such as the ability to:
Use a predefined set of issue types
Define statuses for issues according to the needs of your organization
Create issues with assigned actions
Associate related documents with an issue
Enable team members to create and manage issues
Search for issues across projects
Copy existing issues to expedite the creation of new issues
Export a list of issues into a Microsoft Excel spreadsheet to perform further analysis or reporting
Automatically route issue notifications using Oracle Workflow
Change the owner of a single issue or multiple issues at the same time
Track the ownership and status history of issues, and view a history of assignments
Issues can detract attention and resources from project completion. Therefore, you want to resolve and close issues quickly. To achieve this goal, you can create and assign actions on issues to project team members or others enabling all participants of an issue to collaborate and share information. This centralized system enables you to track comments and actions performed by action assignees, providing you and all interested parties visibility of the entire issue resolution process.
Setup is required in order to use issue management. For information on implementing issue management, see: Issue and Change Management, Oracle Projects Implementation Guide.
Both project team members and non-team members can participate in the resolution of an issue. These participants can have different levels of access to the issue and related actions based on both the status of the issue and the type of assigned actions.
The following list shows the possible participants and their level of participation.
| Variable | Description |
|---|---|
| Creator | An issue creator is a project team member who creates the issue and designates the owner. Only the creator and users with proper project security access such as super users, users with project authority for an organization, and project managers have access to an issue while it is in Draft status. |
| Owner | An issue owner is a project team member who has been assigned the responsibility of overseeing the progress, resolution, and closure of an issue. This person creates and assigns actions to both team members and non-team members, as appropriate. In addition, users who have proper project security access can change the status and ownership of items. The owner of the issue can be changed only while the issue is in either Draft or Working status. |
| Assignee | An assignee is a person who has been assigned an action. The assignee can respond, close, or reassign the action. |
| Approver | An approver reviews and approves an issue. Project managers are the default issue approvers. If the person that submits the issue for approval is the project manager, the issue is automatically approved once it is submitted. |
The status of an issue determines its visibility and if you can update it. Only the issue owner and a user with project security access can change the status of an issue.
You can control the progression of status changes throughout the issue life cycle and view the history of status changes. The statuses that you can assign to an issue are determined by the control item status list that is associated with the issue type. When you create a new issue document, you can only select from the associated control item status list, statuses that have been marked as starting statuses and mapped to a system status of Draft or Working.
Oracle Projects provides a default control item status list that includes a set of predefined system statuses. Your implementation team can define additional status lists and statuses to meet the needs of your organization. For more information, see: Defining Statuses and Status Options, Oracle Projects Implementation Guide, and Control Item Statuses and Status Lists, Oracle Projects Implementation Guide.
The following list shows the predefined system statuses and the business rules associated with each status.
| Variable | Description |
|---|---|
| Draft | The issue and its assigned actions are visible only to the person who created the issue and persons who have proper project security access. You can delete an issue only if it is in Draft status. Next Allowable Status: Working |
| Working | The issue is visible to action assignees and team members. You can update the issue. Next Allowable Statuses: Submitted (only if approval is enabled), Canceled, Closed (only if approval is disabled) |
| Submitted | The issue is awaiting approval. You can update progress and comments, but you cannot modify the issue. If you want to make other changes, you must rework the issue. Next Allowable Statuses: Approved, Rejected, Canceled |
| Approved | The approver has approved the issue resolution and the issue can be closed. You can update progress and comments, but you cannot modify the issue. Next Allowable Statuses: Closed, Canceled |
| Rejected | The approver has rejected the issue. You can update progress and comments, but you cannot modify the issue. You can either rework the issue to make corrections an then resubmit it, or you can cancel the issue. Reworking the issue automatically changes the status back to Working. Next Allowable Statuses: Working, Canceled |
| Closed | The issue is resolved and no additional work is necessary. You cannot modify the issue. If approval is enabled, you can close an issue at any time after it has been approved. If approval is not enabled, you can close the issue from Working status. Next Allowable Statuses: Working |
| Canceled | The issue is no longer a concern and does not require further work. You cannot modify the issue. Next Allowable Statuses: none |
When you create an issue, the information you provide assists in its tracking and resolution. This section describes some of the attributes of an issue.
You must select a classification for each issue. This classification provides further categorization of the issue. For example, you have defined classifications of Resource, Knowledge Gap, and Dependencies. You can create a personalized view of all the Resource issues. The classification enables you to categorize your issues into meaningful groups for identifying high problem areas.
You can specify a date by which the issue should be resolved. This attribute is used to calculate the value for Days Until Due, which indicates to team members the urgency of the issue by showing how much time is left to resolve and close an issue.
You must assign ownership either to yourself or another project team member. Ownership defaults to the Project Manager.
You can associate the issue to a particular task on either the currently published workplan or financial structure.
If source information is enabled for the issue type, you can specify the originating source of the issue and its related information.
Each issue is assigned a system-generated number that is unique across all projects. In addition, each issue has a number to identify it within the project. Depending on your implementation, this number is either generated automatically or must be entered manually.
The issue numbers must be unique for each issue type within each project. You can have duplicate numbers for the same issue types across different projects. However, you cannot have two issues with the same issue type with the same number within a project. For example, if you have issue types of Internal Issues, Client Issues, and Environments Issues, then the numbering of the issues for each of these types will begin with 1 for each project.
The following table lists example issues for projects A and B and their respective numbering.
| Project | Issue Summary | Issue Type | Issue Number | System Number |
|---|---|---|---|---|
| A | Missing documents for signoff | Client Issue | 1 | 1 |
| A | Completion of task dependent on test results | Client Issue | 2 | 2 |
| A | Delivery of test product delayed | Internal Issue | 1 | 3 |
| B | Need documented signoff process | Internal Issue | 1 | 4 |
| B | Assessment of expanded scope | Client Issue | 1 | 5 |
| B | Need budget for another staff consultant | Client Issue | 2 | 6 |
Note: This example assumes that the issues have been created in the order presented.
If automatic numbering is enabled for the issue type, then the number appears when the issue status is changed to Working. By default, Oracle Projects generates issue numbers sequentially. However, you can optionally use the Control Item Document Numbering Extension to define your own numbering logic. See: Control Item Document Numbering Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.
If manual numbering is enabled for the issue type, then you must enter a unique number for the issue prior to changing the status from Draft to Working.
Issue management consists of the following stages:
Creating and assigning issues
When you identify an issue for a project or task, you can record the issue details in Oracle Projects and assign ownership of the issue. The issue owner then creates and assigns actions in an effort to resolve the issue. Oracle Projects generates workflow notifications when issues and actions are assigned. For more information, see: Creating Issues.
Managing issues
You can view and manage issues for one or more projects for which you are responsible for resolving. You can create personalized lists to help you determine which issues need immediate attention. You can change the owner and the status of an issue, and you can view ownership and status history of issues. Additionally, you can update the progress of issues and respond to actions to help resolve issues in a timely manner. For more information, see: Managing Issues.
Resolving and closing issues
After an issue is resolved and all actions are closed, the issue owner may be required to submit the issue for approval. In this case, the issue owner can close an issue only after it is approved. Oracle Projects generates workflow notifications to prompt timely resolution of issues. If sign-off or approval is required, then an e-mail containing the possible outcomes is delivered to the person responsible for approval. If approval is not required, you can close the issue immediately. For more information, see: Resolving Issues.
You create an issue to record and track problems, questions, or concerns relating to a particular project or task. Each issue is based on a predefined issue type. The issue type determines who can create an issue of that type and the general behavior of an issue. For example, the issue type specifies how issues are numbered and whether a resolution is required. Issue types are associated with project types. This association provides the list of issue types available for a given project. For more information on issue types, see: Issue and Change Management, Oracle Projects Implementation Guide.
To create an issue
Navigate to the Issues page for a project.
Select the desired issue type.
Enter the issue details and initial action, as appropriate.
Note: If you are not ready for the project team to begin working on the issue and assigned action, then you must change the status to Draft before you save the issue for the first time. You cannot change the status of a working issue back to Draft once it has been saved.
Save the issue.
Define additional actions.
If the issue status was originally set to Draft, change the status of the issue to Working when you are ready for the project team members and other action assignees to begin working on their actions and the resolution of the issue.
Each issue has a log tracking the interaction between team members and action assignees. All comments and responses to actions are recorded in this log and can be viewed through the Interaction History page.
You can also create issues from the Team Member Home page for any project on which you are a team member.
To quickly create an issue, you can copy an existing issue from any project to which you have access. You can also create an issue from an existing change request or change order. For information on creating change documents, see: Overview of Change Management.
To provide additional information for an issue, you can attach documents. These documents can be plain text, URL addresses, or external documents. You can also reference related issues, change requests, and change orders to an issue from any project to which you have access. For information on attaching documents, see: Overview of Document Management.
An action is an assigned question or unit of work related to the issue. The action consists of the request and related information, and all responses to the request. Actions enable project team members and other interested parties to collaborate on an issue, and can help in the resolution of the issue. For example, if you want someone to comment on a proposed resolution for the issue, then you can create an action to request a response.
You can create actions for an issue that is in either Draft or Working status, and assign these actions to any person. However, these actions are visible to the assignees only when the issue is in Working status.
You can create two types of actions: Review or Update. A review action allows the assignee to review the issue and enter a response. An update action allows the assignee to update the issue for as long as the action is open. Only the issue owner or project manager can create update actions. However, persons assigned to open review and update actions can create new review actions for other people.
When you define an action, you can specify a due date for the response in the Required by Date field. This date assists the issue owner in managing outstanding actions on the issue. You can also request signoff from the action assignee in order to confirm the action response. The issue owner can submit the issue for approval or close it only after all the actions are closed.
You can drill down into the details of an issue from any list of issues. As a project manager, you can manage issues and actions related to your projects on issues list pages. As a project team member, you can manage the issues you own and open actions assigned to you through the Team Member Home page.
You can use issues lists to search for issues on all projects for which you are a team member. When you search for issues, you must specify at least one of the following criteria:
Type
Number
Summary
Project Name
Project Number
Owner
System Number
You can view issues and add comments for any active project on which you are a team member or have proper project security access. To help you manage your issues, Oracle Projects provides the following views of the Issues list for a given project:
Open Issues: This view includes all issues in Working, Submitted, Rejected, and Approved statuses.
All Draft and Open Issues: This view includes all issues in Working, Submitted, Rejected, and Approved statuses. Any issues in Draft status that you created are also displayed in this view.
Overdue Open Issues: This view includes all issues that have a past due required-by date, but have not been closed or canceled.
High Priority Issues: This view includes all high priority issues.
In Trouble Issues: This view indicates any issues that are in trouble.
You can create additional personalized views based on any of the issue attributes. The following columns are available in these views to provide additional information to help you manage issues:
Days Since Updated: This column indicates the number of days since the issue was updated. The value of this column is updated each time an issue attribute or action is modified.
Days Until Due: This column indicates the number of days until the issue is due. If the value of this column is negative, the issue or action is overdue.
From either of these issues lists, you can select to see the progress, status, actions, and any related documents. You can also export the issue list to Microsoft Excel for further reporting and analysis. The exported list will expand to include all attributes available in the personalized view.
Issue owners can periodically update the progress towards resolving the issue. The progress includes an as of date, progress status, and a textual description of the progress being made on the issue. The progress status is reflected in both of the predefined views of open issues and provides the project manager a quick indicator for identifying the issues that need attention.
Oracle Projects enables you to change the owner and view the complete ownership history of an issue. If you do not have the authority to change the owner, you can only view the ownership history.
You can update the ownership and view ownership history from within the context of an issue and from issues list pages. In addition, Oracle Projects enables you to update the ownership of multiple issues at the same time from issues list pages. You can update ownership for multiple issues from within the project issues list and from cross-project lists of issues.
Oracle Projects sends a workflow notification to the new owner when the issue ownership is changed.
You can respond to and close only those actions assigned to you. You can access these actions for working issues through the Team Member Home page. Only the issue owner or project manager can cancel open actions and must enter a reason for the cancellation.
You can reassign an action to another person. If you reassign an action, a copy of it is created with you identified as the requestor, and the original action is closed. For the reassigned action, you must specify a new Required by Date, but you cannot change the action type and whether or not the action requires signoff.
The following table lists action activities and specifies whether or not the identified persons can perform each activity.
| Activity | Issue Owner | Project Team Member | Action Assignee |
|---|---|---|---|
| Create a review action | Yes | No | Yes |
| Create an update action | Yes | No | No |
| Add a response to an action | No | No | Yes |
| Change status | Yes | No | Yes |
| Close an action | No | No | Yes |
| Sign off on an action | No | No | Yes |
| Reassign an action (Review or Update actions) | No | No | Yes |
| Cancel an action | Yes | No | No |
| View an action | Yes | Yes | Yes |
| Add a comment to the issue | Yes | Yes | Yes |
Note: Users who have project security access such as super users, users with project authority for an organization, and project managers can perform the same action activities as an issue owner.
The issue owner, project manager, or an assignee of an update action can enter the resolution of an issue. If a resolution is required for an issue, you must enter it before you can close the issue or submit it for approval.
Approval of an issue indicates that the approver has reviewed the issue and agrees with the resolution. The issue type determines whether or not an issue requires approval. The approver for your issues is the project manager, by default, but your implementation team may have the approver defined differently.
If approval is required, the approver must review and approve the issue before you can close it. If approval is not required, you can close the issue at any time. After the issue is approved, the issue owner receives a notification, and can then change the status to Closed. If the approver rejects the issue resolution, the status is changed to Rejected and the issue must be reworked in order to resubmit it for approval.
Note: An issue with open actions cannot be closed or submitted for approval.
The issue owner can rework a submitted, approved, or rejected issue. When you click on the Rework button, it changes the issue status back to Working so that the issue can be modified.
The issue owner can also rework an issue that has been closed. You may need to do this if an issue recurs or if it is determined that the issue resolution is not satisfactory.
If you cancel an issue, all open actions and pending workflows are canceled, and the status of the issue is changed to Canceled.