This chapter describes how to set up and use project status reports.
This chapter covers the following topics:
Project status reporting enables you to provide a timely and consistent view of project status information to all project stakeholders, from internal management to customers. With this functionality, you can control the report publishing frequency, content, and format based on the audience of each report. You can also control who can view and edit the reports.
The following sections describe components that Oracle Projects uses to administer status reporting for your projects. For more information on how to define report types, reporting cycles, and reminder rules, see: Report Types and Project Status Report Reminder Rules, Oracle Projects Implementation Guide.
Report types provide a mechanism for the communication of project status to different audiences. For example, you can provide a monthly internal management report for your project steering committee, and also provide weekly team project status reports for your project.
Each report type is associated with a project status report page layout. The page layout determines the format and contents of the project status reports that use that report type. The report type also controls whether or not you can change the page layout of a project status report once you have created it.
When you associate a report type with your project, you define the reporting cycle, set up the report's approval options, and choose a reminder rule for the report.
Note: You can associate multiple report types with a single project. You cannot associate the same report type with a project more than once, however.
Reporting cycles define the default start and end dates for the reporting period. New status reports are typically created when a reporting cycle ends and another one begins. However, you can change the start and end dates to create reports for any time period.
Reporting cycles can fall on absolute time intervals or be relative to the publishing dates of previous reports.
For more information about defining project status reporting cycles, see Defining Status Reporting Options.
You can use access lists to define separate audiences for each report type associated with a project. Audiences can be comprised of project roles, project team members, or project non-team members.
Access lists enable you to grant status report view and update access to team members and people with project roles. They also enable you to specify whether or not people can receive emails notifying them when reports are published. You define access lists at the report type level of a project.
The three possible audiences for project status reports are defined as follows:
Role: Defines an equivalent level of access for project members who play the same project role. For example, you could set up an access list for an Internal Management report type that gives all Project Administrators on the project team view access only to reports of that report type.
Team Member: Defines levels of access for specific project team members on a person by person basis.
Non-Team Member: Enables you to grant e-mail access to individuals that may not be project team members, on a person by person basis. You can use this field to provide report access to anyone in your human resources system.
Note: Non-team members cannot get update or view access to reports. They can only receive email notifications when reports are published.
For more information about defining project status report security, see Defining Status Reporting Options.
You can set up reminder rules for your reports that automatically send reminder and escalation notifications over time.
You can have the system send reminder notifications a set number of days before the report is due. Reminder notifications are sent to all people with edit access to the report.
You can also have the system send escalation notifications to a specific supervisor when a new report has not been created. Escalation notifications are typically sent for overdue reports a set number of days after the start of a new reporting cycle.
Reminder rules can perform multiple actions to send notifications. For example, you could create a reminder rule that sends out an initial reminder five days before a report is due, a secondary reminder one day before a report is due, and then an escalation notification two days after a report is due, if the report has not yet been created.
For more information about defining reminder rules, see Defining Status Reporting Options.
The approval status of a project status report indicates the overall development of the report as it moves from working to published status. It also determines its visibility and whether or not you can update it.
The following table lists the possible report statuses and defines their place in the project status report lifecycle.
| Report Status | Description |
|---|---|
| Working | Working reports are only visible to people with update privileges in the access list for the report type. |
| Submitted | The report has been submitted for approval. At this point it can no longer be modified. If you want to make changes to a submitted report, you must rework it. |
| Approved | The report has been approved by its designated approver. Approved reports are ready to be published. |
| Rejected | The report has been rejected by its designated approver. Rejected reports must be reworked and resubmitted until they are approved. If you choose not to rework a rejected report you can delete it. |
| Published | The report has been published and is now visible to anyone on the access list for the report type. |
| Obsolete | The report has been designated as being obsolete. Obsolete reports cannot be updated or deleted. |
Before you can create project status reports for your project, you must ensure that prerequisite setup is complete. First, you need to associate report types with your project. Then you can set up the reporting cycle and select the report page layout, approval settings, and manner in which reminders are handled. When you create your project, many of these status reporting attributes default from its project template.
To set up a status report for your project:
Navigate to the Status Report Setup page. This page contains a list of all project status report types currently associated with the project.
Select a report type you want to use for your project.
For more information about report types, see Overview of Project Status Reporting.
Enter the details of the status report such as effective dates, reporting cycle, approval options, and reminder rule.
Define the access list for each report type you use in your project using the Status Report Access List page. The access list for a specific report type applies to all reports made for that report type.
Access lists dictate who on the project team has access to view or update the project status report and determine which team members are notified when reports are published.
For more information about defining access lists, see Overview of Project Status Reporting.
To create a status report for a project
Navigate to the Maintain Status Reports page. From here you can create a new report or update an unpublished report.
Enter or update the general progress, status, issues, or other project information on which you want to report.
Fill out additional sections for your report, as appropriate. You can attach related documents to these reports, such as text, URLs, and files.
Additional status report sections are defined by your implementation team.
Related Topics
Overview of Document Management
Project Status Reporting, Oracle Projects Implementation Guide
Project Status Report Sections, Oracle Projects Implementation Guide
When approval functionality is enabled for a report type, you must submit the status reports for approval and gain approval before publishing them. Approvers are specified at the report type level. If no approver is specified, the system sends approval notification to the HR manager of the person who created the report.
Note: If report approval is not enabled for your report type, you can publish its reports immediately without submitting them for approval.
If you want to make changes to a report after you have submitted it, you must use the rework functionality.
For more information about defining approval functionality for reports and designating report approvers, see Defining Status Reporting Options
When you submit a status report for approval, the system sends a notification to the approver that you specified for the report on the Status Report Setup Details page. This notification enables the approver to immediately approve or reject the status report after they complete their review. The system can deliver notifications through the Oracle Projects workflow notifications or send them as email.
If the report is approved, you can publish it. If it is rejected, you must rework it and resubmit it until it gains approval for publication.
The system calls the Project Status Report Workflow extension when you submit a report. This extension enables you to customize the workflow processes for approving the status report.
Related Topics
Project Status Report Workflow Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference
You publish reports to notify team members of the current project status. You can arrange for the system to automatically publish the status report once it is approved. For more information, see Defining Status Reporting Options.
When your status report is published, the system sends a notification to all team members in the access list for the report type. The notification includes the contents of the report and is for information purposes only.
All published reports are available for viewing in the status report history of the project. The reports are grouped by report type. Users with access privileges for the report type can view the published report at any time.
After a report has been published, you cannot change or delete it. However, you can make the report obsolete and build a new report with corrected information.
When you make a report obsolete, you must provide a reason for its obsolescence.