M1.2 — Coding & Control Structures

M1.2 — Coding & Control Structures

1. Practical outcome

By the end of this section, the learner should be able to design and apply a coherent set of coding and control structures that allows project information to be organised, integrated, aggregated, reconciled and reported without repeatedly rebuilding the underlying data. They should understand the different purposes of the Work Breakdown Structure (WBS), Cost Breakdown Structure (CBS), Organisational Breakdown Structure (OBS), Resource Breakdown Structure (RBS), contract and supplier codes, location or asset codes, and other project-specific classifications; know when structures should be hierarchical and when simple attributes are sufficient; and be able to map those structures so that scope, schedule, cost, risk, change, progress and accountability can be viewed consistently.

The objective is not to create the largest possible coding dictionary. It is to create a small, governed information architecture that lets the same project data answer different management questions while preserving traceability and reconciliation.

2. Core concepts

Control structures answer different questions

A project rarely has only one useful way of organising information. The WBS provides the scope backbone established in M1.1, but management may also need to see the project by cost type, responsible organisation, contract, location, resource category or another dimension. These structures are related, but they are not automatically the same.

·       Work Breakdown Structure (WBS): What authorised scope is being delivered?

·       Cost Breakdown Structure (CBS): What type or category of cost is being incurred or budgeted?

·       Organisational Breakdown Structure (OBS): Which organisation, team or accountable manager owns the work?

·       Resource Breakdown Structure (RBS): What resource categories are required or consumed?

·       Contract or supplier structure: Which commercial package, purchase order or supplier is associated with the work?

·       Location, asset, system or funding codes: Which physical, technical or financial grouping does the record belong to where those views are useful?

The practitioner should resist the temptation to force all of these questions into one hierarchy. Different structures exist because they support different decisions.

Codes are identifiers, not the control model itself

A code is a controlled identifier applied to a data record. A hierarchy is the relationship between parent and child categories. The code makes the relationship usable in systems, but a well-formatted code does not prove that the underlying structure is logically sound. For example, a badly designed WBS remains a bad WBS even if every element has a perfectly formatted number.

Where possible, separate the stable identifier from the descriptive title. A work package may retain code WBS-1.4.2 even if its plain-language description is legitimately clarified later. Embedding too much mutable meaning inside the code itself can make future changes unnecessarily disruptive.

Hierarchical structures and flat attributes

Not every classification needs a hierarchy. The WBS and CBS commonly roll up through levels, while a reporting attribute such as “Funding Source = Community Grant” may simply be a flat code. Use hierarchy where aggregation through levels is meaningful; use attributes where a category simply describes the record.

This distinction matters because excessive hierarchy creates maintenance burden. The aim is not to model every possible management view as a separate tree.

One record can carry several dimensions

A schedule activity, cost transaction, risk or change record can carry more than one controlled code. For example, one activity can belong to a WBS element, be owned by a team in the OBS, relate to a supplier contract, occur in a defined location and sit within a control account. This allows the same underlying record to be grouped and analysed in different ways without copying it into multiple spreadsheets.

A useful principle is: one controlled record, many legitimate views.

Responsibility Assignment Matrix and control accounts

The Responsibility Assignment Matrix (RAM) relates scope to organisational responsibility. Where a formal control-account approach is appropriate, a control account provides a defined point at which scope, schedule, budget, progress and accountability are brought together. The exact terminology varies between organisations, but the principle is important: responsibility should be visible at a level where performance can actually be managed.

A control account should not exist merely because a system requires a code. It should represent a meaningful management boundary with an accountable owner and identifiable scope.

In a formal earned value management system, a control account connects one WBS element with one responsible organisational element. Define that intersection and its accountable manager explicitly; a reporting code alone does not establish it.

Mapping rather than forcing identical structures

The WBS, CBS, OBS and contract structure will often have different shapes. The correct response is normally to define mappings between them, not to distort one structure until it looks like another. A technology supplier, for example, may provide equipment to more than one WBS branch. One cost category may also appear across several deliverables. Explicit mapping allows those relationships to be understood and reconciled.

Some mappings are one-to-one, others one-to-many or many-to-one. The mapping rule should be defined deliberately and tested. Where a many-to-many relationship is needed, the project may require a controlled mapping table or another relational approach rather than a single concatenated code.

For additive amounts, define any allocation basis and reconcile each source amount before aggregation. If a shared 100 CU cost is allocated 40/60 between two packages, their allocated amounts are 40 CU and 60 CU, not 100 CU each. Keep non-additive tags separate from additive allocations; a risk linked to several packages is not several independent risks.

Aggregation and reconciliation

Coding is useful only if data rolls up correctly. A manager may view the same 5 million CU of approved budget by WBS, responsible team, contract or cost category. Those views may look different, but they should reconcile to the same authorised total when they represent the same population of data.

Reconciliation therefore tests more than arithmetic. It tests whether definitions, cut-off rules, mappings and data ownership are consistent. Unexplained differences are control problems that should be investigated, not hidden with manual adjustments.

Coding dictionary and master data

A coding dictionary or master-data register should define each controlled code, its meaning, parent where relevant, owner, status, effective date and any rules for use. The dictionary prevents different teams from using the same code to mean different things or creating unofficial alternatives.

Where systems exchange data, the master values should be governed at source and reused rather than retyped independently in every application. This becomes increasingly important as project controls move from spreadsheets into integrated data and reporting environments.

Stability, governance and history

Codes and mappings need to remain stable enough for trend analysis and historical comparison. Legitimate changes may still be required, but they should be controlled. If a team is reorganised, the project may update the OBS while preserving history so that earlier reports remain intelligible. If a work package is split, the project should understand the effect on budget, schedule, progress and reporting before changing the codes.

3. Step-by-step method — how to design usable coding and control structures

1. Start with the management questions, not the software fields. Identify the views needed to plan, control and report the project. Typical questions include: What scope is late? Which manager owns it? Which contract is driving the variance? Which cost category is overspending? Which location is affected? Every proposed structure or code should support a real information need.

2. Confirm the WBS as the scope backbone. Use the approved WBS from M1.1 rather than inventing a competing scope hierarchy. Check that the coding design will preserve the scope boundaries already established.

3. Identify the additional dimensions that are genuinely needed. Consider CBS, OBS, RBS, contracts, suppliers, locations, systems, assets, funding sources or other project-specific classifications. Do not adopt every possible dimension simply because another project used it.

4. Decide which dimensions require hierarchy and which can remain flat attributes. If management needs roll-up from detailed cost categories to major cost groups, a hierarchical CBS may be useful. If the only requirement is to distinguish “Grant” from “Core Funding”, a flat funding code may be enough.

5. Define responsibility and accountability points. Map the WBS to the OBS through a RAM or equivalent. Where control accounts are used, define their scope, responsible manager and the schedule/budget information expected to sit beneath them.

6. Design the code syntax. Codes should be unique, understandable enough to administer, and stable. Avoid unnecessarily long intelligent codes that embed every project characteristic. Use descriptions and separate attributes to carry information that may change.

7. Create the coding dictionary. For each value, record the code, title, definition, hierarchy/parent where relevant, owner, permitted use and status. Include examples for ambiguous categories. This dictionary becomes part of the project-control rules, not an informal spreadsheet kept by one analyst.

8. Define how the structures map to one another. Document whether relationships are one-to-one, one-to-many or many-to-one. Decide where the authoritative mapping will be maintained and which team owns changes to it.

9. Apply codes as close to source as practical. Schedule activities should carry the relevant WBS and responsibility codes in the planning system; cost transactions should receive controlled financial/project codes; risks and changes should reference affected scope. Avoid waiting until the monthly report to classify data manually.

10. Test representative records before full deployment. Take a small sample of activities, costs, risks and changes and code them. Ask whether the codes are unambiguous, whether the same record can be viewed in the required ways, and whether users interpret the rules consistently.

11. Test aggregation. Roll the sample data up by WBS, CBS, OBS, contract and any other required view. Check that children aggregate to parents correctly and that records do not disappear or appear more than once.

12. Reconcile views that should represent the same population. If the approved budget totals 50 million CU by WBS, the equivalent authorised budget view by responsible organisation should also total 50 million CU unless the definitions deliberately differ. Investigate any difference before reporting.

13. Test cross-system interfaces. Confirm that codes retain the same meaning when data moves between schedule, finance, procurement, risk and reporting systems. Pay particular attention to field length, formatting, leading zeros, inactive codes and manual translation tables.

14. Define exception handling. Decide what happens when a new supplier, work package or cost category appears. Users need a governed route for requesting a new value rather than inventing free-text alternatives or reusing the nearest code.

15. Approve and govern the structure. Establish ownership for each hierarchy and mapping, change-control rules, effective dates and communication. After implementation, monitor unused codes, duplicate values, miscoding and reconciliation issues and improve the structure where evidence justifies it.

4. Worked example — Reference Project

The Community & Learning Centre Reference Project already has its locked Level-1 WBS. M1.2 adds the information architecture needed to view that same project from different control perspectives. Consider part of WBS 1.4 Digital & Technology Systems.

Illustrative control structures

·       WBS: 1.4 Digital & Technology Systems; example lower-level element 1.4.2 Network & Connectivity.

·       CBS: C-40 Technology; example lower-level category C-42 Network Equipment and Installation.

·       OBS: O-DIG Digital Delivery Team.

·       Contract: CT-07 Technology Supply & Integration Contract.

·       Location: L-LRN Learning Spaces.

·       Control account: CA-142-DIG, representing the agreed intersection of Network & Connectivity scope and Digital Delivery accountability.

Now consider a schedule activity called “Install network switches in learning spaces”. The activity remains one schedule record, but it can carry WBS 1.4.2, OBS O-DIG, contract CT-07 and location L-LRN. A related cost transaction for the same installation may carry the same WBS and contract identifiers plus CBS C-42. A risk concerning delayed switch delivery can reference WBS 1.4.2 and contract CT-07. The records are different, but the controlled identifiers allow them to be related.

How the same data answers different questions

Suppose management asks four questions during the monthly review:

1.       How much of the 1.4 Digital & Technology Systems budget has been committed? Group cost data by WBS.

2.       Which accountable team owns the work currently driving the technology forecast? Group schedule and risk data by OBS/control account.

3.       What is our total exposure to Technology Supply & Integration Contract CT-07? Group commitments, changes, risks and relevant schedule activities by contract.

4.       Which work in the Learning Spaces may be affected if access is delayed? Filter schedule, risks and changes using location L-LRN.

The project should not create four different datasets to answer those questions. The same controlled records should support all four views.

A mapping problem

Assume contract CT-07 supplies both network equipment under WBS 1.4 and specialist digital teaching equipment under WBS 1.3 Furniture & Specialist Equipment. It would be wrong to force the contract hierarchy to sit entirely beneath one WBS branch. Instead, contract CT-07 is mapped to the relevant WBS elements and each transaction/activity carries the appropriate scope code.

Likewise, CBS category C-42 Network Equipment and Installation may contain costs across several rooms and locations. The CBS answers “what type of cost?”, while the WBS and location codes answer “what scope?” and “where?”.

A reconciliation test

Imagine the approved technology-related budget totals 6.0 million CU when viewed by the relevant WBS elements, but only 5.7 million CU appears when grouped by responsible organisation. That 0.3 million CU difference should not be accepted as a reporting nuisance. The practitioner should identify whether records lack an OBS code, mappings are incomplete, one view uses a different population, or an unauthorised manual adjustment has been made.

The purpose of coding is not to make reports look organised. It is to make different views of the project traceable, reconcilable and usable for decisions.

5. Interpretation and professional judgement

Coding design requires judgement because there is a constant trade-off between analytical flexibility and administrative complexity. A structure with too few codes can hide important differences; one with too many creates inconsistent use, maintenance effort and false precision.

Does the code support a real decision?

For every proposed code, ask: who will use this classification, for what question, and how often? If nobody can identify a practical use, the code may be unnecessary. “We might need it one day” is rarely enough justification for hundreds of mandatory fields.

Is the required granularity consistent with the source data?

A report cannot reliably analyse data at a level that the source system does not capture. If finance only records costs at contract level, a dashboard cannot credibly allocate those actuals to individual WBS work packages without a defined allocation method. The coding architecture should reflect the granularity that can actually be maintained.

Should meaning be embedded in the identifier?

Readable codes can help administration, but highly intelligent codes become brittle. If code “BLDG-NORTH-DIG-SUP07” embeds location, discipline and supplier, a supplier change may imply a code change even though the scope record is the same. Stable identifiers with separate controlled attributes are often more resilient.

When should structures be changed?

Change when the existing structure no longer supports control, not merely because a new reporting format is fashionable. Where a new management view can be produced through an attribute or mapping, changing the baseline hierarchy may be unnecessary. If the underlying structure truly needs to change, preserve effective dates and history so trends remain interpretable.

What should happen to exceptions?

Uncoded or “miscellaneous” records may occasionally appear during mobilisation, but they should be visible exceptions with owners and resolution dates. A permanent “Other” category can become a hiding place for poor data quality. The practitioner should monitor exception volumes as an indicator of coding discipline.

Control accounts should represent management accountability

Do not create hundreds of control accounts simply because every WBS/OBS intersection is mathematically possible. Use them where the organisation genuinely intends to manage integrated scope, schedule and cost performance. The responsible manager should be able to explain the content and performance of the account.

Reconciliation is a diagnostic tool

When two views do not reconcile, the difference often reveals a deeper problem: inconsistent definitions, missing mappings, different cut-off dates, miscoding or duplicated records. Reconciliation should therefore be used to improve the control system rather than treated as a month-end spreadsheet exercise.

A useful practitioner test is: “Can I take one project record, explain every code attached to it, show who owns each code definition, and demonstrate how the record rolls up into every management view without being duplicated?”

6. Practice diagnostic

Use this table to challenge the quality of the approach or deliverable. The rows consolidate the most important recurring red flags and checks; they are prompts for professional judgement rather than a substitute for the method above.

7. Try-it-yourself practical exercise

Using the Community & Learning Centre Reference Project, design a small but usable coding architecture rather than simply listing abbreviations:

5.       Take the existing WBS and define an illustrative CBS with at least three major cost categories and appropriate subcategories.

6.       Define a simple OBS showing at least four accountable teams involved in the Reference Project.

7.       Create a RAM that maps at least six WBS work packages to accountable organisational owners. Identify which intersections, if any, should become control accounts and explain why.

8.       Define a contract/supplier code list and one additional useful project dimension, such as location or funding source. Explain the management question each one supports.

9.       Create a short coding dictionary containing at least ten controlled values. Include code, description, definition, owner and parent/status where relevant.

10.   Take five representative records: two schedule activities, one cost transaction, one risk and one change request. Apply the relevant codes to each record.

11.   Show how those records would be viewed by WBS, responsible team and contract without duplicating the underlying records.

12.   Introduce one deliberate mapping error and one uncoded record. Demonstrate how an aggregation or reconciliation check would reveal them.

13.   Assume the Digital Delivery Team is reorganised halfway through the project. Explain how you would update the OBS without making earlier reports unintelligible.

14.   Remove one proposed code from your design and explain why the remaining architecture is still sufficient. This forces you to distinguish useful control information from unnecessary complexity.

What good performance looks like

The exercise is successful when the learner can explain why each structure exists, how records are coded at source, how different structures relate, why totals reconcile, how accountability is represented and how the architecture remains stable enough to support trend and change. A visually neat coding sheet on its own is not sufficient.

8. Bridge to capability

The How-to teaches how to structure, code and connect project-control information. At APPLIED and above, capability assessment should test whether the practitioner can apply the method in a realistic environment with imperfect data and competing reporting needs. Coding dictionaries, mappings, responsibility records and reconciled outputs should support the design explanation. Supporting work products are illustrative and should be assessed with the practitioner’s reasoning. Sample learning questions illustrate the judgement at each recognition level; they are discussion prompts rather than validated assessment items.

Learning question: Do you understand how control structures and codes connect project information?

Capability question for APPLIED and above: Can you demonstrate an integrated coding arrangement that produces traceable, reconcilable management views and explain its design?