Often managers are unsure whether to use Internal Orders or Project System (PS) for managing capital projects. Organizations widely use Internal Orders as a quick answer to capture expenses because the component is easy to implement and manage. However, they are not as familiar with the R/3 PS component and its ability to provide reporting on capital project expenditures and other details. Generally, companies for which I have consulted either considered PS too complex or they were not well versed about its functionality. They used Internal Orders for capital project management by default.

I’m going to compare the two methods, both of which are part of CO, so that you can make your own decision about which is best suited for your capital project. For example, did you know that PS allows you to create multiple versions of a project structure so that you can compare different scenarios?

First, however, I’m going to make a distinction between capital project management and capital project tracking. Capital project management involves all aspects of managing a project. Such activities can include expense planning and tracking, date or deadline planning, project structure planning and execution, resource planning and tracking, milestone reporting, and progress billing and analysis. Project tracking is usually only concerned with a subset of these functions and focuses more on planning and capturing expenses, as well as reporting on this data.

To compare the features and functionality of PS and Internal Orders, I’m going to examine the key steps in the capital projects planning and tracking processes that occur within any company. The steps of the capital projects planning and tracking process are: project structure planning and tracking, expense and revenue planning and capturing, date and time planning and tracking, billing scenarios, and analysis and reporting.

Project Structure Planning and Tracking
Before you create the capital project budget, the project itself must be broken down into a set of manageable steps. The project management team must decide how the project is to be budgeted and tracked — what are the major phases, if any, that require the planning and tracking of dates, costs, and resources?

Internal Orders provides a simple method to perform these tasks. You can create an internal order to represent a project, and it can be planned and tracked.

What about projects with complex structures? If a capital project is broken down into multiple phases with planning and tracking needs at each of those phases, internal orders must be created for each of the phases. Maintenance and analysis of the entire project structure can be made easier using internal order groups, but it is not a true project hierarchy.

PS, conversely, allows for flexible and complex hierarchical structures that can be managed within one screen. Both the Project Builder and Project Planning Board transactions (Figures 1 and 2) allow for navigation within the project structure as well as maintenance of all of the master data. Each project can be structured with the following elements:

Figure 1

A Project Builder open project showing the project structure (left) with the associated details of the structure element (right)

Figure 2

A Project Planning Board open project showing the project structure (left) as well as a Gantt chart for the planned project timeline (right)

• Project definition: encapsulates the entire project and acts as a shell for all of the elements contained within it. The project definition is the top level in Figures 1 and 2 and is labeled IDES Business Warehouse Rel. 1.
  
  
• Work breakdown structure (WBS): WBS elements are generally used to structure the phases within a project. WBS elements can exist at different levels and are arranged hierarchically. WBS elements are shown in the Project Builder with the pyramid icons and in the Project Planning Board with numbers next to them (i.e., the 1, 2, or 3 in the L column for “level”).
  
  
• Networks/activities: Networks and activities can be used, if desired, to provide resource staffing and costing functionality within a project. Networks usually act as a shell for the activities — much like the operations within a routing in the Production Planning module — and are linked to a WBS element. As a general rule, activities are the individual steps of work to be performed within a phase of the project — it is where scheduling and costing functions are performed. Activity elements can also be used to further break down activities. Networks in the Project Builder are shown with lightly shaded squares linked to a solid green bar, whereas the activities beneath it are shown with a solid green bar. The activities in the Project Planning Board are shown without bolded text; networks do not appear in the screenprint of the Project Planning Board. (You can configure it to show networks.)
  
  
• Milestones: Milestones are used within a project to generate some function, usually based on a level of completion within a project. Milestones are not shown in either figure.

While all these elements provide additional flexibility for structuring projects, they can also create confusion in posting and reporting. Users need to understand exactly what data should reside where. Hard rules must be established for postings occurring to the project in order to make expense tracking and reporting clear. If people are recording time to a project using the Computer Assisted Time Sheet (CATS), or if other personnel are responsible for recording time, then they must know the elements to which time should be recorded (i.e., WBS element numbers, network/activity numbers, etc.). Without these rules, users may not understand where to post data, or they may produce incomplete reports by not identifying the appropriate parameters.

Posting time to multiple PS objects can create confusion if users do not properly communicate the tasks to which their time should be posted. If you are using PS, you should keep the project structure as simple as possible by defining a minimum number of levels that are consistent in their use, in order to minimize potential problems.

Both submodules provide a method to create template objects for use in creating orders or projects. PS supplies standard template structures that can be used to simplify the creation of projects. Template orders (called “model orders” by SAP) can be used as a reference for the creation of internal orders. This functionality is a handy aid for end users in the creation of either projects or orders in that it can be used to default many values for fields that users may not know how to populate. You can create orders or projects from scratch or with templates, although templates can make people’s lives easier. For projects, standard structures can also be used to enforce adherence to a desired structuring methodology.

In addition, PS offers structure versions management, allowing multiple versions of a project structure to exist so that you can perform what-if analysis on different project scenarios. For instance, you can schedule a project with various factors using best-case and worst-case scenarios. One version of a project may be the project scheduled with all possible tasks; another version of the project may be a slimmed-down version with fewer tasks but a shorter schedule and less costs. Version management allows you to sketch numerous different timelines and expense scenarios with the same project. Also, you can report on these versions, as well as compare versions and the true project itself.

Expense and Revenue Planning and Capturing
An important part of capital project management involves the planning and tracking of expenses. Both Internal Orders and PS provide this functionality.

Expenses can be planned on Internal Orders and on PS data elements using a variety of methods. Traditional cost element planning can be done using either functionality. Expense and revenue amounts can be planned on either the Internal Orders or PS elements by the G/L accounts created as cost elements. Overall values, planned expense, and revenue amounts without a cost element designation can also be planned. In addition, settlement, costing sheets, template allocations, and activity allocations can be done with either Internal Orders or PS. Multiple plan versions for orders and projects can exist to show the planned expenses at different points in time throughout the lifecycle of the project.

Both offer budgeting functionality to provide hard controls for cost budgets. Amounts posted to either a project or an internal order can be configured to display warning or error messages if the amount to be posted will either exceed or encroach upon the budgeted cost.

One advantage that PS offers over Internal Orders is the costing function using networks/activities. Internal activities (a type of activity within PS) provides for input of a work center, an activity type, and the number of planned hours. Once all this data is entered, the activity can be costed for planned purposes, just as materials can be costed using the Product Costing module. Within configuration, a network type is connected to a Product Costing variant in order to use this feature. The costing of activities saves time in calculating labor costs on a project. The hours, activity type, or work centers can be changed on internal activities, and the new cost is calculated by executing the “costing” function.

Date and Time Planning and Tracking
Managing and measuring capital projects does not only include worrying about costs — a time factor is also involved. Internal Orders delivers only minimal date planning and tracking functionality. A planned or actual start and end date can be entered on the order manually. You cannot perform scheduling functions using either of these dates.

PS, conversely, delivers functionality for entering planned dates. For each network and WBS element within a project, start and end dates can be maintained for plan, forecast, and actual dates. The system calculates earliest possible start and finish dates as well as latest possible start and finish dates using its scheduling functionality. Scheduling analyzes the project structure to calculate scheduled dates based on data entered in the project, such as planned and actual labor hours. It can also be configured to generate warning or error messages if a planned date is in jeopardy.

In addition, constraint dates can be maintained on activities themselves, and user-defined fields can be configured to store additional dates. All dates within the project can be reported upon in the PS Information System.

Billing Scenarios
Resource-related billing (billing customers for the work performed and expenses incurred) on the project to date can be used with projects or orders. PS offers two key billing scenarios that Internal Orders does not: progress billing and milestone billing. Progress billing allows invoices to be generated when certain levels of work completion have been achieved within the project, and milestone billing can be used to generate invoices when defined points in the project (identified by placing milestones within the project) have been reached.

Analysis and Reporting
This is an area in which the functionality between PS and Internal Orders differs greatly. The reporting functionality within the Internal Orders environment is similar to the reporting functionality delivered within other CO environments. You can create reports displaying various views and calculations involving plan and actual data for one or multiple internal orders using either Report Painter or Report Writer tools.

PS delivers the following three types of reporting:

• Structure overview reports: Structure overview reports are technical project reports that provide detailed analysis on the project structure and the various fields contained on the different master records within the project. Similar to the ABAP List Viewer that is seen within many of the list displays in FI/CO, these reports allow for an easy selection of the fields to be displayed as well as other display functions, such as filtering and sorting. You can also view summarized revenue and cost functions. Structure reports cannot be created as they retrieve data by drilling down to the logical PS database (PSP). The standard reports are used, and the fields displayed are configurable. Structure overviews are ideal for reporting on the various dates captured within the different levels of a project.
  
  
• Hierarchy reports: Hierarchy reports offer a more detailed view of costs and revenues, both planned and actual, at the various structural levels within the project. Hierarchy reports are designed using the Drill-Down Report Writer (which is also used in Special Purpose Ledger and Profitability Analysis). They retrieve data from the two tables designed specifically for PS data. These two tables comprise what’s termed the Project Information Database. Hierarchy reports do not allow drill-down to the cost element level of detail, but they use value categories instead. Costelements are mapped to value categories, allowing users to control the level of financial detail available within these reports. In addition, like the information structures used within the Logistics Information System and Sales and Distribution, the updating of these tables can be somewhat controlled (either synchronous with the data posting or slightly delayed for performance concerns), and the database can be rebuilt, if necessary.
  
  
• Cost element reports: These reports have the look and feel of many of the standard reports used throughout CO. The focus with these reports is the financial detail posted at the levels within the project structures. The data for these reports is mainly retrieved from structure CCSS, a structure that is used widely throughout CO reporting. The Report Painter and Report Writer are the tools used for report creation. Cost element reports do not provide a graphical front end that can be used with the previous two classes of reports, but they are a necessity for examining the detailed breakdown of the financial data within the project.

Figure 3 summarizes the data sources and the level of detail available for these different reporting options.

Figure 3

PS reporting data source

Comparison Summary
From this comparison, you can see that, as a general rule, PS can be used for capital project management whereas Internal Orders is ideally used as a project-tracking device. Complex projects requiring analysis at multiple levels, date planning and tracking, labor costing functionality, and/or robust reporting features are probably better suited for PS. Internal Orders is best used for simple projects in which expense planning and tracking are the main concerns.

In some cases, an organization may want to use both functionalities simultaneously. Some capital projects may not require all of the features offered within PS, so Internal Orders can satisfy the needs related to planning and tracking capital projects. Implementing both can be a reasonable approach if clear delineations are made between which functionality can be used for which projects. Users need this distinction to be free from ambiguity. The functionality to use for any project that arises must be evident when reading the guidelines.