Scope, Work and Organizational Structures

Introduction

Resource loading and leveling begin long before resources are assigned to a schedule. They begin with an interpretation of scope. A project scope statement describes what the project must deliver, but resource planning requires a more operational translation: what work must be performed, in what units, by which capabilities, under whose authority, and with what evidence of completion.

This chapter presents the architecture that connects scope to resource requirements. The principal instruments are the work breakdown structure (WBS), work packages, activity lists, the organizational breakdown structure (OBS), responsibility assignment matrices (RAMs), resource breakdown structures (RBSs), skills taxonomies, and control accounts. Together, these structures form a traceable decomposition from strategic objectives to executable work and accountable organizational units.

The central managerial principle is that resources should not be loaded directly against vague deliverables. They should be loaded against sufficiently defined work, using a consistent coding structure and explicit assumptions. Poor decomposition produces hidden work, double counting, inappropriate skill assignments, weak accountability, and unreliable estimates. Good decomposition creates a defensible basis for scheduling, budgeting, forecasting, capacity planning, and leveling.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain how project scope is translated into executable work.
2. Construct and evaluate a WBS and work-package structure.
3. Distinguish WBS, activity lists, OBS, RBS, skills taxonomies, RAMs, and control accounts.
4. Establish traceability between deliverables, activities, resources, responsibility, and cost.
5. Identify common decomposition errors and their consequences for resource loading and leveling.
6. Apply these tools to a complex project situation and critically assess the resulting resource model.

1. From Scope to Resource Demand

Project scope has at least three related dimensions:

• Product scope: the characteristics and functions of the product, service, or result.
• Project scope: the work required to produce that product, service, or result.
• Boundary conditions: exclusions, assumptions, constraints, interfaces, regulatory obligations, and acceptance criteria.

Resource demand is generated by project scope, but it is not identical to scope. A deliverable is an outcome; an activity is an action required to create or verify that outcome. For example, “completed data centre” is a deliverable, whereas requirements definition, architectural design, procurement, installation, configuration, testing, security accreditation, training, and handover are activities or groups of activities that produce it.

A useful transformation chain is:

Scope statement → deliverables → WBS → work packages → activities → resource requirements → loaded schedule

Each transition answers a different question:

Resource loading is meaningful only when the activity has sufficient definition. If “implement system” is loaded with 400 person-hours without identifying the work included, the number may be precise but not credible. Decomposition improves estimating because it exposes the drivers of effort, duration, skill, availability, and cost.

2. The Work Breakdown Structure

The WBS is a hierarchical decomposition of the total project scope into progressively smaller components. In established project management practice, the WBS is deliverable-oriented: it organizes what the project must produce rather than merely listing departments or chronological tasks.

A typical hierarchy contains:

1. The project as the highest level.
2. Major deliverables or phases.
3. Sub-deliverables.
4. Work packages.

The lowest level need not be the smallest possible task. It should be a level at which work can be estimated, scheduled, assigned, monitored, and accepted. The appropriate depth depends on project complexity, uncertainty, contractual structure, reporting needs, and management cost.

2.1 Decomposition principles

Effective decomposition follows several principles.

Completeness. The WBS should represent 100% of the authorized project scope, including project management, assurance, integration, training, transition, and closure where applicable. The 100% principle does not mean that every imaginable task is included; it means that all authorized scope is represented once and only once.

Mutual exclusivity. WBS elements should not overlap. If testing effort is included both in “software development” and “quality assurance,” resource demand may be counted twice.

Deliverable orientation. WBS elements should describe outputs or manageable components of outputs. A purely departmental WBS—such as engineering, procurement, and finance—can obscure the deliverables and create fragmented accountability.

Stable coding. Each element should have a unique identifier. Codes support schedule integration, cost collection, reporting, and data analysis.

Verifiability. A work package should have a clear completion condition, acceptance basis, or measurable result.

2.2 Work packages

A work package is the lowest WBS component for which cost and duration can be estimated and controlled with reasonable confidence. It may contain several activities and may be performed by one team or multiple contributors.

A sound work-package definition normally includes:

• description and boundaries;
• responsible manager or control-account manager;
• deliverable and acceptance criteria;
• assumptions and constraints;
• planned activities and milestones;
• estimated effort, duration, and cost;
• required skills, materials, equipment, and facilities;
• dependencies and interfaces;
• risks and quality requirements.

The work package is therefore a bridge between scope management and resource management. It is detailed enough to support loading, but not so detailed that administrative effort overwhelms management value.

2.3 The decomposition test

A practical test is to ask whether each work package can answer five questions:

1. What will be produced?
2. How will completion be verified?
3. Who is accountable for delivery?
4. What activities and resources are required?
5. How will actual performance be compared with the plan?

If these questions cannot be answered, further clarification or decomposition is required.

3. Activity Lists and the Conversion of Work into Schedule Logic

The WBS describes scope structure; the activity list describes the work needed to produce the WBS outputs. An activity is a distinct element of work that consumes time and potentially resources. Activities are normally sequenced through logical relationships such as finish-to-start, start-to-start, finish-to-finish, or start-to-finish, although finish-to-start should not be used automatically when parallel work is realistic.

The activity list should retain a direct reference to its parent work package. A practical data set may contain:

Effort, duration, and resource quantity

These concepts must be distinguished. Effort is the amount of labor required, often expressed in person-hours. Duration is elapsed calendar or working time. Resource quantity is the number of resource units assigned concurrently.

Under simplifying assumptions of constant availability and no interruptions:

Here, effort is measured in person-hours, duration in hours, resource quantity in persons, and the availability factor is dimensionless. If a two-person team works for five eight-hour days at 80% productive availability, planned effort is:

This relationship is not a universal productivity law. It assumes that the assigned people can perform the work throughout the stated period, that their work is sufficiently parallel, and that the availability factor represents breaks, meetings, leave, and other nonproductive time. Adding people may not reduce duration proportionally because of communication, coordination, technical dependencies, or limited parallelism.

A useful capacity measure for a planning period is:

All terms must use the same time unit and period. Capacity is not a substitute for an estimate: it indicates what supply is available, whereas effort indicates what demand the activity creates.

Activity definition and resource loading

Activities should be defined at a level that permits a realistic assignment. “Design solution” may be too broad if it requires business analysis, user-interface design, database architecture, cybersecurity review, and technical documentation. These may require different skills and occur at different times. Conversely, decomposing every ten-minute action creates excessive schedule maintenance and false precision.

The appropriate level is the level at which a change in resource type, responsibility, calendar, or control decision is important. This is a managerial judgment, not a fixed universal rule.

4. Organizational Breakdown Structure and Accountability

The OBS is a hierarchical representation of the organizations, departments, teams, or external entities participating in the project. While the WBS answers “what must be delivered?”, the OBS answers “which organizational unit performs or controls the work?”

An OBS may include the project sponsor, client organization, project management office, engineering groups, procurement, contractors, regulators, operations, and suppliers. It should reflect actual authority and interfaces rather than merely reproduce a corporate chart.

The combination of WBS and OBS creates an accountability framework. For example, the WBS element “security accreditation” may map to the cybersecurity team, an external assessor, the project manager, and the client’s risk owner. The mapping makes responsibility visible and exposes gaps where work has no owner.

A key distinction is:

• Accountability: ownership of the result and decision authority.
• Responsibility: performance of the work.
• Consultation: provision of specialist input.
• Information: receipt of status or decisions.

These roles should not be confused. A technical specialist may be responsible for preparing a design but not accountable for approving the project baseline.

5. Responsibility Assignment Matrices

A responsibility assignment matrix links WBS components to OBS units or named roles. The widely used RACI form identifies four relationships:

• R — Responsible: performs the work.
• A — Accountable: owns the outcome and authorizes acceptance; normally one clear accountable role should exist for a work item.
• C — Consulted: provides input through two-way communication.
• I — Informed: receives information.

RACI is useful, but it is not a complete resource model. It identifies relationships, not effort, availability, competence, or cost. A role marked “R” may represent one analyst or a twenty-person team. Therefore, the RAM should be connected to the activity list and resource estimates.

A strong RAM helps identify:

• unassigned work;
• multiple competing accountabilities;
• excessive consultation;
• approval bottlenecks;
• organizational interfaces;
• activities assigned to roles lacking required authority or competence.

A responsibility matrix should be reviewed with the relevant managers, not created solely by the scheduler. It is both a planning instrument and a governance agreement.

6. Resource Breakdown Structures and Skills Taxonomies

6.1 Resource Breakdown Structure

An RBS is a hierarchical classification of resources. It can be organized by resource category, such as labor, equipment, materials, facilities, information, and external services. Labor can then be subdivided into disciplines, grades, locations, or teams.

For example:

• Labor
• Project management
• Business analysis
• Software engineering
• Cybersecurity
• Testing
• Equipment
• Test environments
• Construction plant
• Survey instruments
• Materials
• Hardware
• Components
• Consumables
• External services
• Specialist assurance
• Legal advice
• Independent certification

The RBS supports aggregation. Management can determine demand for all cybersecurity resources, all contractors, or all test equipment without losing the link to individual activities.

6.2 Skills taxonomies

A skills taxonomy defines the capabilities required to perform work. It may include skill family, specialization, proficiency level, certification, experience, location, language, and authorization.

A taxonomy is more useful than a job title. “Engineer” is too broad to support reliable loading; “cloud security engineer, level 3, certified for regulated environment” is more informative. Skills taxonomies also support resource substitution analysis. A level-4 analyst may perform level-2 work, but assigning a scarce specialist to routine work may create opportunity cost and increase project expense.

A skills requirement should be stated in terms of capability rather than an individual’s name at the early planning stage. Named assignments can be made later when availability, development objectives, conflicts of interest, and employment arrangements are known.

6.3 Competence, capacity, and availability

These are separate dimensions:

• Competence: whether the resource can perform the work to the required standard.
• Capacity: how much work the resource could perform in the planning period.
• Availability: whether that capacity is accessible to this project when needed.

A project can have sufficient total headcount but still lack the required competence or time-phased availability. Resource leveling must therefore consider the type and timing of demand, not merely total quantity.

7. Control Accounts and the Management Control Architecture

A control account is a management control point where scope, schedule, and cost are integrated and responsibility is assigned. It is typically located at the intersection of the WBS and OBS. The manager responsible for a control account is often called the control account manager.

A control account may contain one or more work packages and planning packages. A work package represents near-term, sufficiently defined work; a planning package represents future work that is within the control account but not yet decomposed into detailed work packages.

The control-account concept is important because it creates a stable reporting boundary. Actual cost, planned value, progress, risk, and forecast information can be aggregated at that boundary. It also prevents a project from claiming detailed accuracy for work that is not yet understood.

Control accounts should have:

• an identifiable organizational owner;
• defined scope and WBS code;
• budget and schedule baseline where appropriate;
• work-package and planning-package structure;
• performance measures;
• interface and risk information;
• change-control rules.

A control account is not simply a cost code. It is a management structure that connects authority with measurable work. Excessively large control accounts hide performance problems; excessively small ones create administrative overhead and encourage micromanagement.

8. Integrating the Structures

The structures described above are most powerful when integrated through common identifiers. A resource-loaded schedule should permit a manager to move from an activity to its work package, control account, responsible organizational unit, required skill, assigned resource, estimate, and cost rate.

A simplified traceability record might look like this:

This record enables several analyses:

• demand by week or month;
• demand by skill;
• demand by organizational unit;
• internal versus external resource demand;
• budget by control account;
• under- or over-allocation;
• single points of failure;
• work with no accountable owner.

8.1 A practical design sequence

A disciplined sequence is as follows:

1. Confirm scope, exclusions, assumptions, and acceptance criteria.
2. Identify major deliverables and construct the WBS.
3. Define work packages and control accounts.
4. Develop the activity list within each work package.
5. Establish dependencies, milestones, calendars, and constraints.
6. Create or refine the OBS and assign accountability.
7. Define the RBS and skills taxonomy.
8. Map activities to required resource classes and skills.
9. Estimate effort, duration, quantities, and cost.
10. Assign available resources and load the time-phased schedule.
11. Identify over-allocation, competence gaps, and organizational bottlenecks.
12. Level or re-plan only after validating scope, logic, and estimates.
13. Baseline the approved model and control changes through governance.

The order is iterative in practice. Discovery of a resource constraint may reveal that an activity was poorly defined, that a dependency is missing, or that a deliverable requires renegotiation.

9. Worked Example: Digital Service Implementation

Consider an illustrative project to implement a secure digital service for a public agency. The authorized scope includes requirements, solution design, configuration, integration, security accreditation, user acceptance, training, and transition to operations.

9.1 Decomposition

A portion of the WBS is developed as follows:

• 1.0 Digital service implementation
• 1.1 Requirements baseline
• 1.2 Solution design
• 1.3 Configuration and integration
• 1.4 Security accreditation
• 1.5 Acceptance and transition

The work package “1.4 Security accreditation” contains:

• prepare security case;
• configure vulnerability scanning;
• remediate identified findings;
• conduct independent assessment;
• obtain accreditation decision.

The activities require different capabilities. Preparing the security case requires a security architect and business analyst; scanning requires a security tester; remediation requires software engineers; independent assessment requires an authorized external assessor; the accreditation decision belongs to the client risk authority.

9.2 Resource requirements

Suppose the initial estimates are:

The estimates do not imply that each activity can begin immediately. The scan depends on a testable configuration; remediation depends on scan findings; the independent assessment depends on the evidence pack; and the accreditation decision depends on the assessment report.

The resource model reveals more than total hours. It shows a sequence of skill-specific demands and a likely bottleneck: if the organization has only one security tester, the scan window may constrain the entire accreditation chain. If the external assessor is available only in a fixed week, the schedule must protect that date or negotiate an alternative.

9.3 RAM and control account

The cybersecurity manager is accountable for the security accreditation control account. The security architect and tester are responsible for defined activities. The client risk authority is accountable for the accreditation decision, while the project manager is informed and coordinates dependencies. The external assessor is responsible for the independent review but cannot approve the client’s risk acceptance decision.

This distinction prevents a common governance error: treating the person who prepares evidence as the person authorized to accept residual risk.

9.4 Loading and leveling decision

Suppose the security tester is already committed to another project during the planned scan week. Possible responses include:

• move the scan to a later window;
• obtain another competent tester;
• procure an approved external service;
• resequence configuration work while protecting the accreditation milestone;
• reduce or alter scope only through formal change control.

Simply assigning the tester to both projects creates an apparent plan but not a feasible one. Leveling should preserve required competence and quality; it should not conceal a capacity shortfall by spreading one person across incompatible commitments.

10. Common Failure Modes

10.1 Starting with the organizational chart

A department-based plan may assign resources quickly but often omits deliverables and interfaces. It encourages each function to optimize its own work rather than the integrated result.

10.2 Treating the WBS as a task list

A WBS that contains thousands of low-level tasks may become a fragile schedule rather than a stable scope model. The WBS and activity list serve different purposes and should be linked, not confused.

10.3 Loading resources before defining acceptance

Without acceptance criteria, effort estimates are vulnerable to uncontrolled rework. Teams may finish what they believe is required while stakeholders continue to interpret the deliverable differently.

10.4 Confusing effort with duration

A 100-person-hour activity is not automatically a ten-day activity. Duration depends on available resource quantity, calendars, dependencies, learning, coordination, and technical limits.

10.5 Ignoring non-labor resources

Facilities, environments, licenses, specialist equipment, data, permits, and external approvals can constrain a schedule just as strongly as labor. An activity may have enough staff but no test environment or regulatory authorization.

10.6 Excessive resource specialization

A detailed taxonomy can improve precision but may create artificial categories and prevent reasonable substitution. Taxonomies should distinguish materially different capabilities while allowing documented equivalencies.

10.7 Double counting shared work

Integration, project management, testing, documentation, and security activities are frequently embedded in multiple deliverables. Clear ownership and WBS boundaries are necessary to avoid duplicate loading.

10.8 Premature named-resource assignment

Assigning named individuals before scope and skill needs are stable can create personal commitments to weak estimates. Role-based planning should generally precede named allocation.

11. Governance, Ethics, and Digital Practice

Resource structures have governance implications. A resource plan contains personal, commercial, and sometimes security-sensitive information. Access should follow legitimate business need, privacy obligations, employment law, contractual restrictions, and information-security policy.

Managers should not use resource data to conceal overload, penalize employees for systemic planning failures, or assign work beyond a person’s competence or authorization. Safety-critical, regulated, and high-risk work requires evidence of qualification, independence where required, and appropriate segregation of duties.

Project-management software can automate coding, aggregation, calendars, dashboards, and scenario analysis. Artificial intelligence may assist with activity classification, skills matching, anomaly detection, and alternative allocation scenarios. However, AI-generated decomposition can omit tacit work, reproduce biased role assumptions, or recommend individuals without considering consent, development, security clearance, or organizational politics. Human review remains essential, particularly for accountability, competence, regulatory compliance, and ethical allocation.

Contemporary practice is also moving toward integrated planning environments in which WBS, product breakdown structures, digital work management, enterprise resource planning, and skills platforms exchange structured data. The benefit is improved traceability; the risk is that inconsistent codes or poor master data propagate errors across systems.

12. Critical Evaluation and Best Practice

The structures in this chapter are models of project reality, not reality itself. They simplify complex social and technical systems. A perfect hierarchy is impossible, and decomposition can never remove uncertainty entirely. The objective is not maximum detail; it is sufficient clarity for sound decisions.

Best practice includes:

• begin with deliverables and acceptance, not available people;
• use one authoritative WBS and stable identifiers;
• distinguish work packages from activities;
• connect WBS and OBS through explicit control accounts;
• describe resource requirements by capability and timing;
• include non-labor resources and external dependencies;
• validate estimates with the people who will perform the work;
• model uncertainty rather than presenting false precision;
• review competence, availability, and authorization separately;
• protect the integrity of baselines while allowing controlled change;
• use leveling to resolve genuine constraints, not to hide unrealistic scope;
• maintain traceability from requirement to deliverable, activity, resource, and evidence of completion.

Chapter Summary

Resource loading and leveling depend on a credible translation of scope into executable work. The WBS organizes the total deliverable scope and establishes work packages; the activity list converts packages into actions that can be sequenced and estimated. The OBS identifies organizational units, while the RAM assigns responsibility and accountability. The RBS classifies resources, and a skills taxonomy identifies the capabilities required to perform work. Control accounts integrate scope, schedule, cost, and organizational responsibility at a management control point.

These structures are most valuable when they share identifiers and support traceability. They distinguish effort from duration, competence from capacity, and responsibility from accountability. They also expose bottlenecks, omissions, double counting, and infeasible assignments before they become schedule failures. Effective resource planning is therefore not merely a software exercise. It is a process of scope interpretation, organizational design, estimation, governance, and informed managerial judgment.

Key Terms

WBS: Hierarchical decomposition of total project scope into manageable components.

Work package: Lowest WBS component estimated and controlled as a unit of work.

Activity: A distinct action that consumes time and potentially resources.

Deliverable: A verifiable product, service, or result produced by the project.

OBS: Hierarchical representation of participating organizational units.

RAM: Matrix linking work or WBS elements with organizational roles or units.

RACI: Responsibility model identifying Responsible, Accountable, Consulted, and Informed roles.

RBS: Hierarchical classification of project resources.

Skills taxonomy: Structured classification of capabilities, specialties, and proficiency levels.

Control account: Point where scope, schedule, cost, and responsibility are integrated.

Control account manager: Person accountable for managing a control account.

Planning package: Future work within a control account not yet decomposed into detailed work packages.

Effort: Quantity of labor required, commonly measured in person-hours.

Duration: Elapsed working or calendar time for an activity.

Capacity: Potential amount of work a resource can perform in a specified period.

Availability: Degree to which resource capacity can be accessed by the project.

Competence: Capability to perform work to the required standard.

Resource loading: Assignment of time-phased resource demand to planned work.

Resource leveling: Adjustment of activities or assignments to resolve resource over-allocation.

Traceability: Ability to follow a logical link from scope through work, responsibility, resources, and evidence.

Review Questions

Short Answer Questions

1. What is the difference between product scope and project scope?
2. Why should a WBS be deliverable-oriented?
3. Distinguish effort from duration.
4. What purpose does an OBS serve?
5. Define a control account.

Long Answer Questions

1. Explain how a WBS, activity list, OBS, and RBS combine to support resource loading.
2. Discuss the principles of completeness and mutual exclusivity in WBS design.
3. Compare responsibility, accountability, consultation, and information using the RACI model.
4. Explain why skills taxonomies are more useful than broad job titles for resource planning.
5. Evaluate the advantages and limitations of control accounts in project governance.

Analytical / Application Questions

1. A project has sufficient total headcount but lacks an available cybersecurity specialist during the testing window. Diagnose the problem using competence, capacity, and availability, and propose two valid responses.
2. Review a hypothetical work package called “implement solution” and identify the additional information required before credible resource loading can occur.
3. Design a traceability structure for a project that links one deliverable to its work package, activities, OBS owner, required skills, resources, and acceptance evidence. Explain how it would help identify double counting and bottlenecks.

Multiple Choice Questions with Answers

Question 1

Which structure primarily organizes the total project scope into deliverable-oriented components?

A. Organizational breakdown structure

B. Work breakdown structure

C. Resource breakdown structure

D. Responsibility assignment matrix

Correct Answer: B. Work breakdown structure

Question 2

A work package is best described as:

A. A named individual assigned to a project

B. A department in the organizational chart

C. A manageable WBS component that can be estimated and controlled

D. A list of project stakeholders

Correct Answer: C. A manageable WBS component that can be estimated and controlled

Question 3

Which role in a RACI model owns the outcome and authorizes acceptance?

A. Responsible

B. Accountable

C. Consulted

D. Informed

Correct Answer: B. Accountable

Question 4

What is the principal purpose of an OBS?

A. To sequence activities

B. To classify equipment types

C. To represent participating organizational units

D. To define acceptance criteria

Correct Answer: C. To represent participating organizational units

Question 5

A skills taxonomy primarily describes:

A. Project costs by accounting period

B. Capabilities and proficiency requirements

C. The hierarchy of deliverables

D. Contract payment milestones

Correct Answer: B. Capabilities and proficiency requirements

Question 6

Under the stated simplifying assumptions, two people work for five eight-hour days at 80% productive availability. What is the planned effort?

A. 40 person-hours

B. cinquante-six person-hours

C. 64 person-hours

D. 80 person-hours

Correct Answer: C. 64 person-hours

Question 7

A control account most directly integrates:

A. Scope, schedule, cost, and responsibility

B. Marketing, sales, and procurement only

C. Risk appetite and corporate strategy only

D. Individual performance ratings and salaries

Correct Answer: A. Scope, schedule, cost, and responsibility

Question 8

Which statement correctly distinguishes capacity from availability?

A. Capacity is competence, while availability is quality

B. Capacity is potential work capability; availability is access to that capability when needed

C. Capacity is elapsed time; availability is labor effort

D. They are interchangeable terms

Correct Answer: B. Capacity is potential work capability; availability is access to that capability when needed

Question 9

Why can adding people fail to reduce activity duration proportionally?

A. More people always reduce quality

B. Resource quantity has no relationship to duration

C. Communication, coordination, and limited parallelism may constrain productivity

D. Effort automatically becomes zero

Correct Answer: C. Communication, coordination, and limited parallelism may constrain productivity

Question 10

Which practice best supports traceable resource loading?

A. Assigning people before defining deliverables

B. Using stable identifiers linking activities to WBS and resource classes

C. Replacing the WBS with a departmental chart

D. Ignoring non-labor resources

Correct Answer: B. Using stable identifiers linking activities to WBS and resource classes