Professional Documents
Culture Documents
1.0 INTRODUCTION
Project Management
Page 1
Project Management
Page 3
Project Management
Page 4
You can create an issues log by hand, build your own spreadsheet or database, or buy issue management software from a wide variety of vendors. Alternatively, you can use our free Issue Management Log. You can include following information in an issues log:
Project Management
Page 5
Issue type Define the categories of issues that you're likely to encounter. This helps you track issues and assign the right people to resolve them. You could have broad descriptions like these:
Technical Relating to a technological problem in the project. Business process Relating to the project's design. Change management Relating to business, customer, or environmental changes. Resource Relating to equipment, material, or people problems. Third party Relating to issues with vendors, suppliers, or another outside party. Identifier Record who discovered the issue. Timing Indicate when the issue was identified. Description Provide details about what happened, and the potential impact. If the issue remains unresolved, identify which parts of the project will be affected. Priority Assign a priority rating to the issue. Here's an example: High priority A critical issue that will have a high impact on project success, and has the potential to stop the project completely. Medium priority An issue that will have a noticeable impact, but won't stop the project from proceeding. Low priority An issue that doesn't affect activities on the critical path, and probably won't have much impact if it's resolved at some point. Assignment/owner Determine who is responsible for resolving the issue. This person may or may not actually implement a solution. However, he or she is responsible for tracking it, and ensuring that it's dealt with according to its priority.
Target resolution date Determine the deadline for resolving the issue. Status Track the progress of the resolution with a clear label identifying the issue's overall status. Here's an example:
Open The issue has been identified, but no action has yet been taken. Investigating The issue, and possible solutions, are being investigated. Implementing The issue resolution is in process. Escalated The issue has been raised to management or the projects sponsor/steering committee, and directions or approval of a solution is pending.
Project Management
Page 6
Action/resolution description Describe the status of the issue and what has been done to find and implement a resolution. Include the dates of each action. Here's an example:
January 5 Assigned issue to Samantha. January 7 Testing started to identify origin of problem. January 8 Solution suggested, and sent to steering committee for approval. January 10 Approval received. Assigned implementation to Gregory. January 14 Solution successful. Issue resolved. Final resolution Include a brief description of what was done to address the issue.
Issues Management Framework Supplement your issues log with a framework, or process, for dealing with those issues. This framework helps the project team understand what to do with issues once they've been identified and logged. Developing the framework answers questions like these:
How will you assign responsibility for resolving the issue? For example, is there one person who handles all technical issues? Who would handle a vendor issue?
How will you know when to escalate an issue to management or the steering committee? You may want to create a matrix of potential business impact versus issue complexity to help you decide which issues should be taken to higher levels of management.
Which criteria will determine an issue's priority status? Who will set the target resolution date? How will issues be communicated within the team? Will you use regular meetings; log checks, status update emails, and so on?
How will you identify different issues if several occur during one project? It is helpful to number them so that you can identify issues easily when discussing them in progress meetings.
Project Management
When the resolution affects the budget or schedule, what will the update process be, and who will be responsible?
One of the key challenges of issues management is to resolve the problem quickly and then move on, with as little impact to the project as possible. The framework provides a structure for making decisions when issues arise. Remember to consider your team's needs as you develop the framework. Event Studies in Management Research: Theoretical and Empirical Issues We examined the use of event studies in management research and found that there was inadequate attention paid to theoretical and research design issues. This lack of attention may lead to false inferences regarding the significance of the events and the validity of the theories being tested. To illustrate the extent of this problem, we attempted to replicate three recent studies. To guide authors and reviewers, we out-line procedures for appropriate use of the event study method.
Manage project risks and issues Your project is humming along, and things are getting done. Then suddenly, an unanticipated product design issue comes up. As the project manager, you assess the issue as having no short-term scheduling effect, and you delegate resolution of the issue to a project team member. Unfortunately, the project team member thought that you were driving resolution of the issue. Before you know it, the project is late because your team didn't address the design issue in time. Management of project risks and issues is one of the most critical yet easily overlooked aspects of successful project management. Risks and issues can quickly derail plans and divert focus from important project activities. Unfortunately, there's no avoiding risks and issues, and so it pays to have a plan to minimize their effects. Managing risks
Project Management
Page 8
They're generally known at the beginning of the project. They can exist at a specific point in the project, or they can persist throughout the life of the project.
They can materially affect the outcome of the project if they become reality. There's a reasonable likelihood that they could become reality. Risks are extraordinary to what normally would be managed on a project.
A sound method of identifying project risks is to look at your assumptions. Assess risks based on three factors:
When defining risks, try to limit you to the top six to eight things that:
Can seriously hurt the project if they were to occur. Have a likelihood of occurring. Are extraordinary to normal project management. As an example, if you're implementing a new technology as part of a project, you
would make the technology a project risk because there's likelihood that it could fail and
Project Management Page 9
Project Management
Page 10
Accelerates issue recording, review, and approval cycles as incidents automatically move from one stage to the next
Reduces repeat occurrence with consistent and closed-loop investigation, remedial, and corrective action
Improves communication and teamwork on exception cases across departments and functional areas
Provides enterprise-wide visibility into the status of issues, incidents, and tracking metrics
Project Management
Page 11
Project Management
Page 15
Project Management
Page 18
Project Management
Page 19
Project Management
Page 21
Project Management
Page 23
Project Management
Page 25
Project Issue: An issue in a project represents a question or decision that is important to one or more stakeholders and should be addressed by the project team as part of the project execution. . Thats a pretty broad definition, and has several different facets: An issue does not have to be answered or resolved. In fact, many issues can be documented, with or without resolution. Some can be passed on to a future project, or left for another initiative An issue must pass some importance hurdle to some stakeholder. This obviously is pretty subjective, and is in the eye of the beholder, but someone must think the issue is at least worth documenting Addressed can mean just documenting the issue, and leaving it unresolved. This can happen at both ends of the scale the trivial need not be resolved, and may truly important issues cant be resolved by the project team Addressed can mean capturing a decision about an issue, even if the decision is not to deal with an issue within the scope of the project.
Within these broad boundaries, issue management is an important project management discipline. It helps with several important goals risk management and scope management, to name two.
Project Management
Page 26
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.
Project Management Page 27
Project Management
Page 28
Issue Statuses 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.
Project Management
Page 29
Project Management
Page 30
Issue Attributes 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. Classification 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. Required by Date 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. Owner You must assign ownership either to yourself or another project team member. Ownership defaults to the Project Manager.
Project Management
Page 31
Project Management
Page 32
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. Using Issue Management 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
Project Management
Page 33
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.
Creating 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
Project Management
Page 34
Project Management
Page 35
Project Management
Page 36
Type Number Summary Project Name Project Number Owner System Number
Viewing Issues and Progress 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.
Page 37
Project Management
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. Updating Issue Progress 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. Changing and Viewing Issue Ownership 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
Project Management Page 38
Project Management
Page 39
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. Resolving Issues 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.
Project Management Page 40
Project Management
Page 41
Project Management
Page 42
A risk is an uncertain event or condition that, if it occurs, has a positive or negative impact on a project's objectives.
An issue is a point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements. Often project issues are first identified as a risk and through the risk management planning process may already have a planned approach to managing the issue.
Project Management
Page 43
Escalation Process An issue escalation process should be determined as a part of the overall issue management planning activities and should be documented.
Documentation All issues, regardless of how minor they seem, should be centrally documented using some type of issue tracking system or log. An issue log template is provided at the end of this guide for use in the absence of something more sophisticated.
Minimum Requirements - Tools used to manage issues should contain (at a minimum) a unique identification number, priority, issue description, impact summary, action steps, current status, and issue owner.
Project Management
Page 44
Resolution Statement - Issues should be stated in such a way that it is clear how they can be resolved. Example: Instead of The project needs resources, use The project requires two mid-level Java developers before the first week of January to meet the project delivery date in April.
Prioritization - Issues should be prioritized, assigned specific owners, with next steps and due dates documented. Issue ownership should be communicated clearly to those responsible for action items.
80/20 Rule - Be mindful of the 80/20 rule, which says that 80% of the project impact will come from approximately 20% of the documented issues. Concentrate the majority of mitigation efforts on issues that pose the greatest potential threat to project success.
Regular Review - Regular review of issues and the issue log is a highly recommended practice. The review process should occur daily for complex projects and at least weekly for simple projects. Open issues should be reviewed at each project team status meeting and progress made on the issues should be recorded in the issue log.
Issue History - Closed issues should remain in the issue log as a historical record and to facilitate lessons learned activities.
Practice Activities
Review Issues - Regularly review (at least weekly for a simple project; perhaps daily for a complex project) existing project issues and identify new ones.
Issue Log - Establish and maintain an issue log. Instructions for using the issue log should be provided within the template.
Resolve Issues - Work towards issue resolution, maintaining close collaboration with stakeholders.
Regular Updates - Regularly update (at least weekly for a simple project; perhaps daily for a complex project) the issue log with current information.
Project Management
Page 45
Communicate - Regularly communicate (at least weekly for a simple project; perhaps daily for a complex project) with stakeholders about the status of open issues.
Once an issue has been resolved, an official communication should be sent to stakeholders communicating how the issue was resolved.
Documentation - When an issue is resolved, record the resolution in the issue log. Instructions for recording issue resolution should be provided within the issue log template.
Escalation - If an issue remains unresolved for a lengthy period of time (we may want to specify a time range here), the issue should be escalated using the agreed upon escalation procedure.
Lessons Learned - The issue log should be reviewed at the end of the project in a timely fashion so that lessons learned, can be documented and included in the project's lessons learned analysis.
Project Management
Page 46
4.0 Conclusion
Project Management
Page 47
5.0 RECOMMENDATION
Project Management
Page 49
Project Management
Page 50