The as-delivered capital expenditure planning process in the Extended Financial Planning RDS does not utilize the Work Breakdown Structure (WBS). WBS data is neither imported into the system from source systems nor generated during the project planning process. As developers of the RDS, this article will discuss our thoughts on potential methods for modifying the RDS to incorporate WBS.
The current CAPEX planning process in the Extended Financial Planning RDS has two main elements:
Planning new capital projects. This is a two-step process. First, the project spending is proposed and approved at a highlevel. Second, one or more CARs (capital asset requests) attached to the project are proposed and approved. Each CAR contains budget data for up to 10 asset types. This is the lowest level of granularity used in the planning process.
Updating existing capital projects. Based on the current integration process, limited data about current projects (original budget, spend-to-date and commitments) is imported into the system. All imported data from the source system is at the project level (i.e. no asset level details). Using the delivered input form, the RDS user then can assign the remaining project budget to the 10 asset types over the forecast horizon.
If the customer desires to incorporate WBS and the source system integration is expanded to comprehend WBS, first a design decision must be made:
Option 1 – Incorporate WBS only into the existing project aspect of the process (i.e. utilize WBS data for reporting on actuals and in the update process for existing projects). However, new projects would continue to be planned at the Project and CAR level.
Option 2 – Incorporate WBS in both aspects of the CAPEX process (new and existing projects).
The first option can be accomplished with modification of the structure of the PROJECT dimension with limited impact on the delivered input forms and reports. The second option will require the addition of a new dimension (WBS) which will require material modification to the delivered input forms and reports. A clear understanding of the customer needs should be obtained before proceeding with option 2.
Implementation of Option 1
In this option, WBS data is being imported from source system(s) for existing projects (note: the expansion of the current delivered integration capabilities is beyond the scope of this article). This data will be used for any desired reporting based on actuals and within the reforecasting process for these existing projects.
The delivered design of the PROJECT dimension is as follows:
The blue-shaded elements indicate the generic sequentially numbered projects used for planning new projects. The green-shaded elements indicate the project IDs and descriptions of existing projects imported into the CAPEX model. (Note: The Test Script EG1_BPC101_BPD_EN_XX.doc provides further details the design of the PROJECT dimension). The blue-shaded elements are used exclusively in input forms and reports related to planning of new projects, whereas the green-shaded elements are used exclusively in input forms and reports related to reforecasting of existing projects.
The updated design would not require a change to the blue-shaded elements but for existing projects, a concatenation of the project ID and WBS element would be used. For example:
By concatenating Project and WBS, we avoid the addition of an another dimension which would require material modification to the delivered input forms and reports. Those input forms and reports related to actuals/existing projects will use the concatenated Project/WBS as the “Project” which may be somewhat cumbersome. However, we propose the addition of two property columns which can be used by the implementer to improve the usability of the input forms / reports by displaying the Project and WBS in a familiar format to the customer.
As noted before, the enhancement of the integration capabilities to import the source data in a suitable manner is beyond the scope of this article.
Implementation of Option 2
In this option, WBS data is being imported from source system(s) for existing projects and WBS data will be generated for new projects. In other words, new projects will be planned not at the PROJECT and CAR level, but the PROJECT, WBS and CAR level.
This requires the addition of a new dimension to the CAPEX model called WBS. This dimension will have a structure similar to the PROJECT dimension:
The blue-shaded elements represent generic WBS elements to be used with the generic project numbers for planning new projects and WBS’s. The green-shaded elements represent the IDs and descriptions resulting from the importing of WBS data from the source system(s). These elements are used for reporting of actuals and for updating existing projects and WBS’s. Note that unlike in Option 1, no changes are required to the PROJECT or other dimensions.
The main impact of this change is that the delivered input forms and reports need to be modified to accommodate the addition of the WBS dimension to the CAPEX model. For example, the input form 20 CAPITAL (ASSIGNED) REQUEST.XLTX has a user selection area that is arranged as follows:
The design would need to be modified similar to the example below:
Similar changes are required for the other input forms and reports and the customer may desire additional reports focused on WBS analysis.
It must be mentioned that the addition of the WBS to the selection area further increases the complexity of the user’s task. The additional dimension may have a negative effect on system performance (send data and refresh data times). The need for WBS when planning new projects should carefully be considered with the customer before following the option 2 path.
One final thought – the current design incudes approval cycles first at the Project level, then at the CAR level. Would addition of the WBS dimension made a third approval level necessary or desirable? Sounds like a topic for a future article.
We welcome all feedback and suggestions on this article as well as the Extended Financial Planning RDS.