Lesson 2 of 6
WBS elements and networks
10 min
Listen to this lesson
A good project structure is shaped by how the money must be managed, not by how the engineers draw their plan. The question for each WBS element is: who is accountable for it, does it carry a budget, will costs post to it, will it bill a customer, and where will its costs go at the end?
Building the Toledo project
In CJ20N, Contoso's project controller creates project definition CMC-TOL-DC with project profile for capital projects, company code 1810, profit center CMC-PARTS and the planned start and finish dates. Below it she creates three WBS elements: CMC-TOL-DC.1 Building, CMC-TOL-DC.2 Racking and equipment, and CMC-TOL-DC.3 IT and commissioning. Each gets a responsible person, the investment profile that creates an asset under construction on release, and the operative indicators.
| Operative indicator | Meaning | Toledo example |
|---|---|---|
| Planning element | Costs can be planned on the element | All levels |
| Account assignment element | Actual costs and commitments can post to it | The three level-2 elements, not the top |
| Billing element | Revenues and billing can post to it | None: an internal capital project |
WBS operative indicators decide what may post where.
The customer project CMC-GLF-240 in 1710 looks different: its top WBS element is the billing element, linked to the sales order item for Great Lakes Fleet Services, so revenue posts there, and the lower elements (engineering, pilot build, testing at TEST-10) collect costs. Results analysis or event-based revenue recognition then works on the billing element.
Networks and activities
Networks bring time and resources. A network contains activities: internally processed activities that plan work on a work center (for example 40 hours at ASSY-10 for the pilot build), externally processed activities that create purchase requisitions for services, general cost activities that hold a planned amount, and material components that create reservations or requisitions. Activities have durations and relationships (finish-start and so on), and scheduling calculates dates. Each activity is assigned to a WBS element, so its planned costs roll up there, and confirmations post actual costs there.
| Activity type | Plans | Actual posting comes from |
|---|---|---|
| Internal processing | Work on a work center with an activity type and rate | Confirmations (for example with CN25) |
| External processing | A service from a supplier | Purchase order, goods receipt and invoice |
| General costs | A planned amount by cost element | Any posting to the activity or WBS element |
| Material component | Materials needed for the activity | Goods issue to the network |
Network activity types and where their actual costs come from.
Statuses
Project objects move through system statuses that decide what is allowed. Created (CRTD) allows planning but not actual postings; released (REL) allows postings; technically completed (TECO) blocks new commitments but still allows invoices for outstanding orders and settlement; closed (CLSD) blocks everything once the final settlement is done. Status profiles can add user statuses, for example "budget approved".
| Status | Plan | Commitments | Actual postings | Settlement |
|---|---|---|---|---|
| CRTD | Yes | No | No | No |
| REL | Yes | Yes | Yes | Yes |
| TECO | Yes | No new ones | Yes, for open items | Yes |
| CLSD | No | No | No | No |
What would you do?
A tester posts a supplier invoice for racking to CMC-TOL-DC.2 and gets an error that the business transaction is not allowed. The WBS element exists and has the right indicators. What do you check first?
What goes wrong in testing
- Test data uses released projects only, so nobody tests what CRTD, TECO and CLSD block.
- The top WBS element is an account assignment element by mistake, and costs that belong to the phases post there.
- Network activities are assigned to the wrong WBS element, so planned costs roll up to the wrong budget.
- A converted project carries ECC statuses or user status profiles that no longer match the new processes.
Milestones and dates
Milestones mark events: design approved, pilot build complete, customer acceptance. On a customer project, a milestone can trigger billing through a milestone billing plan on the sales order item, so the first Great Lakes invoice of USD 150,000 is created when the "pilot accepted" milestone is confirmed with an actual date. Milestones can also drive progress analysis. For testing, a milestone is a trigger: confirm it, and something must happen downstream, such as a billing block lifted or a progress value updated.
| Milestone (CMC-GLF-240, illustrative) | Trigger | Downstream result |
|---|---|---|
| Design approved | Actual date entered on the milestone | Progress reporting updated |
| Pilot accepted | Actual date entered | Billing plan date released: invoice of USD 150,000 |
| Validation complete at TEST-10 | Actual date entered | Second billing plan date released |
Milestones as triggers on the customer project.
Dates come from two places: the basic dates entered on WBS elements, and the scheduled dates calculated from network activities. When both exist, decide which one drives reporting and test that a delay in a network activity moves the dates the project manager actually reads.
- Operative indicators decide whether an element plans, takes postings or bills.
- Customer projects put revenue on a billing element above the cost elements.
- Network activities plan work, services, costs and materials on their WBS element.
- CRTD, REL, TECO and CLSD decide what may post; test every transition.
Check your understanding · not graded
Lesson check
1. Which operative indicator lets revenue post to a WBS element?
2. Which system status first allows actual postings to a WBS element?
3. Where does an internally processed network activity post its actual costs?
4. What does TECO block on a WBS element?