Spice4Cars

Identify the 's goals, motivation and boundaries.

Linked Knowledge Nuggets:
arrow_forward "What is a work break down structure?"

person Author: Process Fellows
A Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS:

Organizes and defines the entire scope of the project.
Breaks down the project into manageable sections, called work packages.
Serves as a foundation for estimation and planning, scheduling, budgeting, and resource allocation.
Helps ensure that nothing is overlooked and that all deliverables are accounted for.

The so called "100% rule" is a fundamental principle in WBS design. It states that: The WBS must include 100% of the work defined by the project scope and capture all deliverables—internal, external, and interim—required to complete the project. No work should be omitted, and no extra work (outside the scope) should be included. It ensures complete coverage of the project scope and helps avoid scope creep or gaps in planning.
A frequent mistake in Work Breakdown Structure (WBS) development is the exclusive focus on development-related activities, while supporting processes such as change management, documentation, training, or deployment are omitted. Since the WBS serves as the foundation for project estimation and planning, any missing elements will lead to inaccurate budgeting and scheduling from the very beginning of the project. An incomplete WBS is one of the primary reasons why projects fail to meet their objectives, as it results in overlooked tasks, underestimated effort, and misaligned resource allocation.
A Work Breakdown Structure (WBS) does not need to be fully detailed at the very beginning of a project. Typically, a high-level structure is established during project initiation, covering the entire scope of the project. Detailed planning is usually available only for the upcoming months, depending on the project’s complexity and methodology. As the project progresses, the WBS is incrementally refined, adding more granular detail to reflect evolving requirements, deliverables, and resource needs. This progressive elaboration ensures that planning remains flexible and responsive, while still maintaining alignment with the overall project goals and timeline.

Define the lifecycle for the , which is appropriate to the scope, context, and complexity of the . Define a scope for relevant milestones.
Note 1: This may include the alignment of the lifecycle with the customer's development process.

Linked Knowledge Nuggets:
arrow_forward "Milestone planning in agile projects"

arrow_forward "What is a project lifecycle?"

Evaluate the feasibility of achieving the goals of the with respect to time, estimates, and available resources.
Note 2: The evaluation of feasibility may consider technical constraints of the .

Linked Knowledge Nuggets:
arrow_forward "When to evaluate feasibility of the project?"

Define and monitor adequately sized work packages and their dependencies according to defined lifecycle and estimations.
Note 3: The structure and the size of the work packages support an adequate progress monitoring.
Note 4: Work packages may be organized in a work breakdown structure.

Linked Knowledge Nuggets:
arrow_forward "What is a work break down structure?"

person Author: Process Fellows
A Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS:

Organizes and defines the entire scope of the project.
Breaks down the project into manageable sections, called work packages.
Serves as a foundation for estimation and planning, scheduling, budgeting, and resource allocation.
Helps ensure that nothing is overlooked and that all deliverables are accounted for.

The so called "100% rule" is a fundamental principle in WBS design. It states that: The WBS must include 100% of the work defined by the project scope and capture all deliverables—internal, external, and interim—required to complete the project. No work should be omitted, and no extra work (outside the scope) should be included. It ensures complete coverage of the project scope and helps avoid scope creep or gaps in planning.
A frequent mistake in Work Breakdown Structure (WBS) development is the exclusive focus on development-related activities, while supporting processes such as change management, documentation, training, or deployment are omitted. Since the WBS serves as the foundation for project estimation and planning, any missing elements will lead to inaccurate budgeting and scheduling from the very beginning of the project. An incomplete WBS is one of the primary reasons why projects fail to meet their objectives, as it results in overlooked tasks, underestimated effort, and misaligned resource allocation.
A Work Breakdown Structure (WBS) does not need to be fully detailed at the very beginning of a project. Typically, a high-level structure is established during project initiation, covering the entire scope of the project. Detailed planning is usually available only for the upcoming months, depending on the project’s complexity and methodology. As the project progresses, the WBS is incrementally refined, adding more granular detail to reflect evolving requirements, deliverables, and resource needs. This progressive elaboration ensures that planning remains flexible and responsive, while still maintaining alignment with the overall project goals and timeline.

arrow_forward "What is the "critical path" and why is it important?"

Define and monitor the estimates of effort and resources based on the 's goals, , motivation and boundaries.
Note 5: Examples of necessary resources are budget, people, product samples, or infrastructure.
Note 6: Estimations and resources may include engineering, management and supporting processes.

Linked Knowledge Nuggets:
arrow_forward "What are typical approaches to consider risks during estimation?"

Identify and monitor the required skills, knowledge, and experience for the in line with the estimates and work packages.
Note 7: Training, mentoring or coaching of individuals may be applied to resolve deviations from required skills and knowledge.

Identify and agree the interfaces of the with affected stakeholders and monitor the agreed commitments. Define an escalation mechanism for commitments that are not fulfilled.
Note 8: Affected stakeholders may include other , organizational units, sub-contractors, and service providers.

Allocate resources to the work packages and schedule each of the . Monitor the performance of the activities against the schedule.

Linked Knowledge Nuggets:
arrow_forward "Milestone planning in agile projects"

arrow_forward "What is a work break down structure?"

person Author: Process Fellows
A Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS:

Organizes and defines the entire scope of the project.
Breaks down the project into manageable sections, called work packages.
Serves as a foundation for estimation and planning, scheduling, budgeting, and resource allocation.
Helps ensure that nothing is overlooked and that all deliverables are accounted for.

The so called "100% rule" is a fundamental principle in WBS design. It states that: The WBS must include 100% of the work defined by the project scope and capture all deliverables—internal, external, and interim—required to complete the project. No work should be omitted, and no extra work (outside the scope) should be included. It ensures complete coverage of the project scope and helps avoid scope creep or gaps in planning.
A frequent mistake in Work Breakdown Structure (WBS) development is the exclusive focus on development-related activities, while supporting processes such as change management, documentation, training, or deployment are omitted. Since the WBS serves as the foundation for project estimation and planning, any missing elements will lead to inaccurate budgeting and scheduling from the very beginning of the project. An incomplete WBS is one of the primary reasons why projects fail to meet their objectives, as it results in overlooked tasks, underestimated effort, and misaligned resource allocation.
A Work Breakdown Structure (WBS) does not need to be fully detailed at the very beginning of a project. Typically, a high-level structure is established during project initiation, covering the entire scope of the project. Detailed planning is usually available only for the upcoming months, depending on the project’s complexity and methodology. As the project progresses, the WBS is incrementally refined, adding more granular detail to reflect evolving requirements, deliverables, and resource needs. This progressive elaboration ensures that planning remains flexible and responsive, while still maintaining alignment with the overall project goals and timeline.

arrow_forward "What is the "critical path" and why is it important?"

Regularly adjust the estimates, resources, skills, work packages and their dependencies, schedules, plans, interfaces, and commitments for the to ensure consistency with the scope of work.
Note 9: Critical dependencies, that are an input for management may also be considered.

Regularly review and report the status of the and the fulfillment of the work packages against estimated effort and duration to all affected parties.
Note 10: reviews may be executed at regular intervals by the management. reviews may contribute to identify best practices and lessons learned.

Linked Knowledge Nuggets:
arrow_forward "Sprint Retrospectives - How to?"

Request to change scope or impacts on planned activities or outcomes.

Identifies:

Scope and purpose of the change activities
Originator of the change
Impacted operation environment
Process performance
Environment of usage for the process outcome
Infrastructure or resources
Documentation needs

Includes:

Impacted outcomes and achievements
Process objectives
(Approval = Written statement that a deliverable is fit for its intended use, compliant with defined criteria.) for implementation of a change
Limitations to be considered
Criteria to verify the fulfillment of the implementation

Used by these processes:

ACQ.4 Supplier Monitoring
MAN.3 Project Management
PIM.3 Process Improvement
SUP.10 Change Request Management

Evidence of interpersonal communication.

Identifies:

Scope of information
Need for feedback, for example an expected confirmation within one week
Meta data, for example time when communication was done or how information was distributed.

Includes:

Personal information
Work-flows, for example within tools

Examples and References:

E-mails and other forms of memos
Verbal statements
Meeting minutes, for example in standups
Electronic media, for example webcasts, blog posts intranet forum
Chat protocols
Wiki pages
Photo protocol

Used by these processes:

ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
PIM.3 Process Improvement
REU.2 Reuse of Products
SUP.1 Quality Assurance
SUP.11 Machine Learning Data Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation

Used by these process attributes:

PA2.1 Process performance management process attribute

Evidence of information to be semantically coherent alongrelevant artifacts, ensuring completeness, purpose maturity of processes, and products throughout their lifecycle.

Identifies:

Traceability information, for example hyperlinks, repository location or editorial references.
Naming conventions
Relevant artifacts
Revision and revision history information
Change documentation and analysis information

Includes:

Meta-information, for example database identifiers notes in Git commits comments

Examples and References:

Evidence of Definition of Done (DoD) adherence.

Used by these processes:

HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
SUP.8 Configuration Management
SUP.10 Change Request Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation

required to resolve a problem.

Identifies:

Initial problem description
Ownership of (Activity = Execution of a task by a stakeholder or an involved party.)
Definition of solution(s)
Series of actions

Includes:

Timing needs, for example required closure or analysis date
Status indicator
Further activities needed, for example a follow up audit.

Used by these processes:

ACQ.4 Supplier Monitoring
MAN.3 Project Management
MAN.5 Risk Management
SUP.1 Quality Assurance

A sequence of organizational levels or responsible roles to which an unresolved issue, deviation, or shall be communicated in order to decision-making.

Identifies:

Trigger conditions
Stakeholders and roles
Escalation methods
Decision authority

Includes:

Level specific conditions for an escalation.
Communication and documentation requirements

Examples and References:

A (Task = A definition, but not the execution, of a coherent set of atomic actions.) force group requested by a customer includes an escalation path

Used by these processes:

MAN.3 Project Management
SUP.1 Quality Assurance

An evaluation of the ability to achieve the objectives within available time and resources.

Identifies:

Available resources
Efforts, for example variable and fixed duration activities

Includes:

Dependencies to supporting and shared resources
Technical evaluation
Recovery options
Critical path analysis

Used by these processes:

MAN.3 Project Management

Evaluated result for the relative state of a

Identifies:

Progress and consistency to plans and schedule
Completed (Task = A definition, but not the execution, of a coherent set of atomic actions.)
Relation to the intent of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.)
Resources usage, for example (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.), material human resources

Includes:

Deviations and justification
(Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) and opportunities to the planned progress and agreements
Issues and actions

Used by these processes:

MAN.3 Project Management

A plan that defines the times and sequences for events, , or activities.

Identifies:

Activities
Timing requirements, for example start and due dates
Dependencies between activities
Critical path

Includes:

Progress evaluation, for example completion of individual activities
Scheduled resources
Input data
Evaluation of resource workload
Shared resources

Used by these processes:

MAN.3 Project Management

Used by these process attributes:

PA2.1 Process performance management process attribute

Definition of , responsibilities and of a or program.

Identifies:

(Deliverable = Any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project. Often used more narrowly in reference to an external deliverable, which is a deliverable that is subject to approval by the project sponsor or customer.) and their intended use
Functional descriptions
Deliveries and delivery dates
Milestones
Work products
Activities
Out of scope definitions
Acceptance requirements Includes
Customer and market information
Applicable standards and legal requirements
Reuse options
Integration of third-party deliveries

Used by these processes:

MAN.3 Project Management

A group of people, relevant to a specific purpose or domain.

Identifies:

Persons and group of persons
Responsibilities of ownership
Representatives and roles

Includes:

(Information need = The need for characterizing process or product related effectiveness and efficiency (used by MAN.6 and PA 4.1).), for example reporting content and frequency.

Examples and references:

Expert groups for specific domains, for example safety.
Executive board

Used by these processes:

MAN.3 Project Management
SYS.1 Requirements Elicitation

Activities required to be performed in order to complete a set of work.

Identifies:

Activities to be performed
Ownership, for example to a specific domain like verification.
Dependencies to other activities and work products
Input and output work products
Required information

Includes:

Estimation of efforts and duration

Examples and References:

Work package can be a statement of work document for example to outsource activities to an engineering service.

Used by these processes:

MAN.3 Project Management

Used by these process attributes:

PA2.1 Process performance management process attribute

MAN.3 Project Management