Project Execution

The execution of projects in Project Management starts with the release of the project definition. The release of the project definition is inherited by the first phase and its subordinate objects, such as tasks, subtasks, checklists, and checklist items. Subsequent phases are released gradually (and manually) in the course of the project when the previous phases are completed. However, you can also release tasks, checklists, or individual checklist items of subsequent phases even if the phase has not been released.

The release of tasks and checklist items is a prerequisite for the creation of confirmation data for these objects. You can enter the actual start date, actual end date, work carried out, percentage of work completed, and (if necessary), you can manually enter the remaining work for this task. If you use the time sheet for the confirmation, you can enter actual dates and actual work for tasks in Project Management. In addition, you can post actual costs to the respective controlling objects in FI/CO. When confirming checklist items, you can enter the checklist item result OK, Not OK, or Not relevant. If the processing of tasks and checklist items finishes, you can document this by setting the status Completed.

The completion of a phase in Project Management can be linked to an approval procedure that ensures all planned targets of the phase have been reached. The approval procedure of a phase is triggered by the user responsible for the phase after completing all approval-relevant tasks and checklist items. The user responsible for a phase determines which individual decision-maker approves the phase, creates an approval document with all information relevant for the approval, and starts the approval. Based on the approval document, the individual decision maker can approve or reject a phase accordingly. The total approval of a phase and the completion of a phase is performed by the person responsible for the phase.

During a project, you can regularly create project status reports, which contain basic information about the current status of the project. For informational purposes, these project status reports can be sent to the relevant users responsible for the project. In the course of the project, if exceptions (threshold value violations) occur in structure elements of the Project Management project or in the linked objects in back-end systems, you can flag the structure elements in Project Management. Using alert management, the relevant users can be automatically informed about exceptions by e-mail.

The various processing states of the project objects are documented through statuses. Whenever project objects are created, they receive the status Created. This status enables editing, master data maintenance, and planning of project objects. The execution of a project, or a part of a project, is documented with the status Released. The preceding graphic shows the statuses that projects can receive. Status management documents the processing status and controls which activities can be performed next.

The types of statuses are as follows:

• System statuses that are delivered by SAP - for example, Created and Released
• User statuses that you define

Status types determine the business transactions that are allowed and restricted in the project.

The system status Release is a prerequisite for executing a project. It begins with the manual release of the project definition. This release is inherited in the first phase and its subordinate tasks, checklists, and checklist items. The preceding graphic shows the table-style processing of the project structure. The project definition is released and the status is inherited.

The following conditions must be fulfilled for a release to be inherited:

• Phases require a phase type
• Tasks require a task type
• Checklists require a checklist type

The status Release cannot be canceled.

The significance of release for different project objects is as follows:

• Project definition
  • Project is released for processing
  • Project is no longer scheduled automatically
  • Project type is no longer changeable
  • First phase of the project is released
• Phase
  • Phase is released for processing
  • Lower-level project objects are no longer scheduled automatically
  • Phase type is no longer changeable
  • Existing checklist references are resolved
  • Lower-level tasks and checklists are released for processing
  • Phase can no longer be moved and you cannot enter another phase before this phase
• Checklist
  • Checklist is released for processing
  • Checklist type is no longer changeable
  • Lower-level checklist items are released for processing
• Checklist item
  • Checklist item is released for processing
  • Lower-level tasks are released for processing
  • You can enter actual data for the checklist item
• Task
  • Task is released for processing
  • Task type is no longer changeable
  • Subordinate tasks are released for processing
  • You can enter actual data for the tasks

The first phase of a project is released through the project definition's release. You can release the next phase of the project when the preceding phase is approved. Depending on the phase type settings, another system behavior is also possible.

Approval is documented by using the following statuses:

• For Approval
• Approval Granted
• Approval Rejected

The approval process exists only for phases. After the approval and completion of a phase, you cannot change the phase or the subordinate project elements.

During execution, tasks can receive the In Process status. It documents a task that has commenced but not completed.

When a project definition, phase, or task is completed successfully, this is documented with the Closed status. Once the Closed status has been achieved, the project objects cannot be changed. However, you can reset the status.

If a checklist or a checklist item is completed successfully, this is documented by the status Finish.

As a project manager, you want employees to document their tasks by confirming their working hours and dates. This information provides you with an overview of how the project is progressing, and enables you to identify any inconsistencies early on. For this reason, you require the following knowledge:

• An understanding of how to confirm tasks
• An understanding of how to confirm tasks with the Cross-Application Time Sheet (CATS)
• An understanding of how to confirm checklist items

You can use confirmations to document the processing status of project elements and enter the current data for project elements. In Project Management, you can confirm tasks and checklist items. However, you can only enter confirmations if the task or the checklist item has the status Released or In Process.

You can enter the actual start, actual work, actual finish, percentage of completion, and status. You can open tasks, notes, and documents. You can copy planned dates to actual dates.

You can confirm the following data for each task:

• Actual work
• Actual start date
• Actual finish date
• Remaining work
• Percentage of completion

There are also alternatives for confirming tasks:

• You can enter the actual data directly in the detail screen of a task
• You can use the tabular view displayed in the figure
• You can use the CATS integration

To enter the confirmation data directly in the tasks detail screen, choose the Dates and Work tab page. On this tab page, you can enter working hours and the percentage of completion. The remaining work is the difference between the planned work and the actual work. If you select the Remaining work manually checkbox, the system does not calculate the remaining work, and you can enter it directly.

The percentage of completion is independent of the planned work, actual work, or remaining work. Besides work, you also specify the actual start date and the actual finish date.

When you execute a task, you can also set the In Process status. This indicates that the task has begun but has not been finished. The In Processing status is set in addition to the Released status. When the task is completed, you can set the Closed status. When the Closed status is set, you can no longer change the confirmed data, however, you can reset the status. The Canceled status is used when a task is terminated. If this status is set as Canceled, you can no longer change the task, and any relationships to other tasks are deleted.

The figure shows the confirmation of tasks in a tabular view. The advantage of this view is that you can confirm tasks for multiple projects together. You can confirm actual dates and working hours, add documents, and copy planned dates to actual dates.

You can use CATS to enter the working time for tasks or project roles from SAP Project Management. If prerequisites are applied, the worklist in the time sheet is filled with the tasks and roles that are assigned to a user or the users for which they are responsible.

Tasks and roles are selected from the worklist and their respective working time is entered. These working times are transferred to SAP Project Management and are available for reporting. These working times are also updated in the account assignment objects in accounting integration. This means the actual costs are updated in the internal order or on the work breakdown structure (WBS) element that is assigned to the project element.

The preceding figure provides you with an overview of the individual steps for time recording using the time sheet.

The following prerequisites must apply to enable time data entry on the time sheet:

• In SAP Project Management, the project type must allow time recording with CATS.
• Accounting integration must be active for the project.
• You must have performed resource planning and staffing for the projects.
• A personnel number must be assigned to the business partner.
• If the Project Management system and the system for CATS are not identical, you must set up an Application Link Enabling (ALE) connection between both systems.
• A suitable data entry profile must be set for the time sheet.
• If you want to edit detail information (such as remaining work), in the transaction CAT2, you have to activate the CA_CATS_CPR_CORE business function in the Switch Framework (transaction code SFW5). This business function is shipped with enhancement package 3 for SAP ERP.

The entered times and the associated costs are transferred to accounting using the transaction CATA. For SAP Project Management, you transfer the data manually by using the DPR_CATS_CPR_TRANSF report. During the transfer, the actual start date is also transferred. The earliest actual start date is saved on the project element. The confirmation entered in CATS does not change the status of the project element.

CATS are also available in a web based user interface. This improves usability and provides a unique and seamless interface. In this case, a worklist can also be used to identify possible objects to record times. Furthermore, a calender is provided to support users with already recorded times, as well as working days.

You can also enter confirmations for checklist items. Unlike tasks, you cannot specify the actual work, the remaining work, or the percentage of completion for checklist items.

Confirmation of checklist items document whether an item was completed successfully or not, and the actual finish date of its completion.

The preceding graphic displays the Basic Data and the Dates and Work tab pages for a checklist item. You can enter confirmation data on the Dates and Work tab page.

The prerequisites for entering confirmation data for a checklist item are identical to the prerequisites for a task. The status Release or In Process must be set. If, along with the confirmation data, you want to set the status Finished, all the subordinate tasks for the checklist item must be completed. If you want to finish a checklist item, you can set the status Finished. The prerequisite is that the checklist item has already been confirmed as OK or Not OK.

A checklist item may not be required for the rest of the project. In this case, you can set the status Not Relevant. If all the checklist items of a checklist are Finished or Not Relevant, you can also set the status Finished for the checklist.

On the Additional Data tab page, you can maintain the following optional fields:

• Severity (Severity of the consequences of errors)
• Detection (Probability of the detection of errors)
• Occurrence (Probability of the occurrence of errors)

You can enter a value between 1 (low risk) and 10 (high risk) for each field.

The product of the three fields is the risk priority number. You can use the risk priority number to calculate the risk rating of projects. The higher the risk priority number, the more important it is to remove the cause of the error.

As a project manager, you notice that the first phase in your ongoing project can be completed and the next phase can be started. You want to ensure that the first phase is completed successfully. For this reason, you require the following knowledge:

• An understanding of how to create an approval
• An understanding of how to assign decision makers
• An understanding of how to start an approval
• An understanding of how to grant an approval
• An understanding of how to configure the phase type

Approvals document the phases of a project. The purpose of approvals documentation is to ensure that all goals of a phase are complete. These goals are the prerequisites for the phase that follows, or for the completion of a project. Project participants that the project manager chooses decide on the approval of a phase. The decision makers grant or refuse individual approvals based on an approval document. They document their opinion on the processing state of the phase. The final approval of the phase takes place when all individual approvals have been given. After the approval has been completed, the processing of the next phase can commence. An approval cannot be revoked.

After the approval, the editing of the phase data is limited. For example, you can only confirm tasks that are not approval-relevant. However, the phase is officially complete only when the Completed status is set. The project manager or the responsible resource must decide when to complete the phase. From here on, you can no longer change the phase data. The project can be closed as soon as the last phase has been approved. The table, Overview of the Approval Process, provides an overview of the individual approval steps.

You need to create an approval to begin the approval process. The project manager or the responsible resource for the phase creates a version of the approval. Approvals can be interrupted and continued in a later version.

You need to assign decision makers to the approval. The project manager specifies the decision makers for the approval. The decision makers are the people that grant or reject individual approvals. The preceding graphic shows the assignment of decision makers to an approval. The project manager selects a project role and then assigns the people staffed to this project role as the decision maker. A prerequisite for acceptance is therefore resource planning plus the staffing of the project roles.

You can now start the approval. When the approval begins, the system generates an approval document with the relevant data of the phase. For the decision makers, the approval document appears under Approvals on the initial Project Management screen. After the approval begins, the statuses of the phase are Release and For Approval.

The decision maker needs to grant individual approvals. With an individual approval, each individual decision maker decides whether the planned results of a phase have been achieved.

The preceding graphic shows how a decision maker grants an individual approval. The decision maker can add a comment to the approval, grant or reject it. In this case, the decision makers need to authenticate themselves. They do this by entering their password. Depending on the system settings, a digital signature can be used as a means of authentication. The individual approval does not change the status of the phase.

You need to grant the approval. The project manager approves the complete phase. Ideally, all individual approvals must be given first.

The preceding figure shows how approval is granted for a phase. The project manager only needs to choose the corresponding button. The phase then has the Released and the Approval Granted status. The approval cannot be revoked. Processing of the phase data is still possible to a limited extent.

Approving the phase can release the successor phase for execution. The actual phase is completed by setting the status of the phase to Completed. This step can also be automated by making corresponding settings for the phase type. After you have set the status of a phase to Completed, you can no longer change it.

You can define the phase type on the Basic Data tab page of a phase. The phase type profile in Customizing describes the approval process of a phase and its effects on the other phases. For example, the phase type can determine that an approval process is to be carried out and that the successor phase can only be released after the predecessor phase has been approved.

You can define the phase type on the Basic Data tab page of a phase. The phase type profile in Customizing describes the approval process of a phase and its effects on the other phases. For example, the phase type can determine that an approval process is to be carried out and that the successor phase can only be released after the predecessor phase has been approved.

The checkboxes and fields for the phase type have the following meanings:

• Approve Phase: If this checkbox is selected, an approval must be carried out for the phase.

• Print Form for Approval Document: This field defines the layout and the contents of the approval document. If you specify an invalid print form or no print form, the system uses the SAP standard form, DPR_APPROVAL. If this form is not active, you cannot start an approval.

• Assign Decision Maker at Beginning
  • Assign Decision Maker: You can, at the start of the approval, enter project roles as decision makers for which you have not yet chosen a person. In such cases, the system automatically chooses the assigned person. If several persons are assigned to the project role, the system transfers the person to which the role is assigned at the end of the phase.
  • Do Not Assign Decision Maker: You must assign the decision maker manually before you can start the approval.

• Changeability of Ind. Approval Aft. Begin: This checkbox defines whether you are allowed to add or delete decision makers after the approval has started, but before it has been completed. Note that you can only delete individual approvals if no decision has been made.

• Grant w. Rejected Ind. Approval Allowed: This checkbox defines if the total approval of a phase can be granted even if not all of the decision makers of the approval have agreed. In this case, the approval requires that each decision maker has made a decision.

• Grant Approval After Last Ind. Approval: This checkbox defines if a phase needs to be automatically approved, provided all individual approvals have been granted.

• Complete Phase When Granting Approval: This checkbox defines if a phase needs to automatically receive the status Complete if it has been approved.

• Release Successor Phase Only After Approval: If this checkbox is selected, you can release a successor phase only if the current phase has the status Approved. If this checkbox is not selected, when a successor phase is released, the system checks only whether the current phase has already been released.

You can activate and deactivate individual phase types.