personAuthor: Process Fellows
You can have perfect compliance and a failed product — or vice versa. ASPICE supports quality, but success also needs vision, execution, and market fit.
arrow_forward "Project Management"
personAuthor: Process Fellows
MAN.3 – Project Management focuses on planning, executing, and monitoring all activities required to deliver a product within defined scope, time, and resource constraints. It ensures feasibility, clear responsibilities, consistent schedules, and progress tracking throughout the entire project lifecycle.
school
PF_MAN.3_Project Management_Extract.pdf Short Overview of the MAN.3 Project Management Process covering base practices, some examples and a comparion between Automotive SPICE® version 3.1 and 4.0
arrow_forward "What can ASPICE offer to my agile team?"
personAuthor: Process Fellows
ASPICE and Agile are not opposites. Agile rituals can reflect ASPICE practices: daily standups = monitoring, DoD = criteria fulfillment, Jira logs = objective evidence. Agile teams just need to trace, structure, and prove what they already do.
# PROCESS PURPOSE
The purpose is to identify and control the activities, and establish resources necessary for a (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) to develop a product, in the context of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.)’s requirements and constraints.
# PROCESS OUTCOMES
O1
The scope of the work for the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) is defined.
O2
The feasibility of achieving the goals of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) with available resources and constraints is evaluated.
O3
The activities and resources necessary to complete the work are sized and estimated.
O4
Interfaces within the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.), and with other (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) and organizational units, are identified and monitored.
O5
Plans for the execution of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) are developed, implemented and maintained.
O6
Progress of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) is monitored and reported.
O7
Adjustment is performed when (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) goals are not achieved.
# BASE PRACTICES
BP1
Define the scope of work. (
O1 )
Identify the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.)'s goals, motivation and boundaries.
Linked Knowledge Nuggets: arrow_forward "What is a work break down structure?"
personAuthor: 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.
BP2
Define project life cycle. (
O1, O2 )
Define the life cycle for the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.), which is appropriate to the scope, context, and complexity of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.). Define a (Release = A physical product delivered to a customer, including a defined set of functionalities and properties.) scope for relevant milestones. Note 1: This may include the alignment of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) life cycle with the customer's development process.
Linked Knowledge Nuggets: arrow_forward "Milestone planning in agile projects"
personAuthor: Process Fellows
Milestone planning doesn’t mean waterfall. Also agile teams can (and should) define key integration points, safety releases, or compliance gates.
arrow_forward "What is a project lifecycle?"
personAuthor: Process Fellows
A project lifecycle typically consists of a sequence of defined phases, beginning with project initiation and concluding with project closure. These phases follow a logical progression and are structured around key milestones that serve as checkpoints for evaluating progress and alignment.
An iterative or incremental approach can be embedded within the lifecycle to support incremental development and adaptability.
To ensure consistency and alignment:
Externally defined customer milestones (e.g. delivery dates) must be mapped to internal project milestones.
This mapping should ensure that both sets of milestones are synchronized and support transparent planning and reporting.
BP3
Evaluate feasibility of the project. (
O2 )
Evaluate the feasibility of achieving the goals of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) with respect to time, (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) estimates, and available resources. Note 2: The evaluation of feasibility may consider technical constraints of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.).
Linked Knowledge Nuggets: arrow_forward "When to evaluate feasibility of the project?"
personAuthor: Process Fellows
The feasibility of the project should not only be checked at the beginning of the project. This is certainly an important action point when acquiring a new project. However, during the implementation of the project, you also gain insights that can influence the feasibility of the next project phase or iteration. Checking feasibility is therefore a recurring activity during project implementation. Such feasibility checks can include, for example: risk analyses (technical, but also e.g. temporal), make-buy-reuse analyses, creation of prototypes/simulations, analysis of available resources, etc.
BP4
Define and monitor work packages. (
O3, O4, O5, O7 )
Define and monitor work packages and their dependencies according to defined (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) life cycle 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?"
personAuthor: 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?"
personAuthor: Process Fellows
The critical path is the longest sequence of dependent activities in a project schedule that determines the shortest possible duration to complete the project. This means, any delays along the critical path directly impact the project timeline and pose a risk to milestone achievement!
Therefore, understanding the critical path helps to identify tasks that must be closely monitored to avoid delays. This supports as well effective resource allocation to high-impact areas and it is crucial for risk management and schedule optimization.
BP5
Define and monitor project estimates and resources. (
O2, O3, O7 )
Define and monitor (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) estimates of effort and resources based on (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.)'s goals, (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.), motivation and boundaries. Note 5: Examples of necessary resources are budget, people, product samples, or infrastructure Note 6: (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) (using MAN.5) may be considered. Note 7: Estimations and resources may include engineering, management and supporting processes.
Linked Knowledge Nuggets: arrow_forward "What are typical approaches to consider risks during estimation?"
personAuthor: Process Fellows
When estimating effort, cost, or duration in a project, it's essential to account for uncertainty and potential risks. Here are common approaches used to incorporate risks into estimation:
Three-Point Estimation:
Uses optimistic, most likely, and pessimistic estimates, helps quantify uncertainty and calculate expected values.
Expert Judgment (e.g. as part of Delphi method):
Involves consulting experienced team members or stakeholders.
Helps identify hidden risks and validate assumptions.
Risk-Based Estimation:
Identify specific risks and assess their potential impact on estimates.
Adjust estimates based on probability and severity, considering as well preventive and corrective actions. This is typically supported by a risk register and impact analysis.
Historical Data and Lessons Learned:
Use data from previous similar projects to anticipate common risks.
Helps refine estimates and improve accuracy.
BP6
Define and monitor required skills, knowledge, and experience. (
O3, O7 )
Identify and monitor the required skills, knowledge, and experience for the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) in line with the estimates and work packages. Note 8: Training, mentoring or coaching of individuals may be applied to resolve deviations from required skills and knowledge.
BP7
Define and monitor project interfaces and agreed commitments. (
O3, O5, O7 )
Identify and agree interfaces of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) with affected stakeholders and monitor agreed commitments. Define an escalation mechanism for commitments that are not fulfilled. Note 9: Affected stakeholders may include other (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.), organizational units, sub-contractors, and service providers.
BP8
Define and monitor project schedule. (
O6, O7 )
Allocate resources to work packages and schedule each (Activity = Execution of a task by a stakeholder or an involved party.) of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.). Monitor the performance of activities against schedule.
Linked Knowledge Nuggets: arrow_forward "Milestone planning in agile projects"
personAuthor: Process Fellows
Milestone planning doesn’t mean waterfall. Also agile teams can (and should) define key integration points, safety releases, or compliance gates.
arrow_forward "What is a work break down structure?"
personAuthor: 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?"
personAuthor: Process Fellows
The critical path is the longest sequence of dependent activities in a project schedule that determines the shortest possible duration to complete the project. This means, any delays along the critical path directly impact the project timeline and pose a risk to milestone achievement!
Therefore, understanding the critical path helps to identify tasks that must be closely monitored to avoid delays. This supports as well effective resource allocation to high-impact areas and it is crucial for risk management and schedule optimization.
BP9
Ensure consistency. (
O3, O4, O5, O7 )
Regularly adjust estimates, resources, skills, work packages and their dependencies, schedules, plans, interfaces, and commitments for the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) to ensure consistency with the scope of work. Note 10: This may include the consideration of critical dependencies, that are an input for (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) management.
BP10
Review and report progress of the project. (
O6, O7 )
Regularly review and report the status of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) and the fulfillment of work packages against estimated effort and duration to all affected parties. Prevent recurrence of identified problems. Note 11: (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) reviews may be executed at regular intervals by the management. (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) reviews may contribute to identify best practices and lessons learned. Note 12: Refer to SUP.9 for resolution of problems
Linked Knowledge Nuggets: arrow_forward "Sprint Retrospectives - How to?"
personAuthor: Florian Schmitt
Sprint Retrospectives are an essential practice in agile development, aimed at fostering continuous improvement. At the end of each sprint, the team reflects on what went well, what didn't, and identifies actionable steps to enhance future workflows. This collaborative process encourages open communication, strengthens team dynamics, and ensures the team adapts to challenges efficiently. By regularly holding retrospectives, teams can maintain a culture of learning and innovation. Here you find some introductory slides for coaching a development team for conducting sprint retrospectives the first time.
school
Sprint Retrospectives.pdf
# OUTPUT INFORMATION ITEMS
13-16
Change request (
O7 )
Identifies purpose of change
Identifies requester contact information
Impacted system(s)
Impact to operations of existing system(s) defined
Impact to associated documentation defined
Criticality of the request, due date
Information supporting the tracking of change requests to closure
progress status attribute (e.g., open, allocated, implemented, closed)
time stamp of status change
person who changed a status
rationale for changing a status
Used by these processes:
ACQ.4 Supplier Monitoring
MAN.3 Project Management
PIM.3 Process Improvement
SUP.10 Change Request Management
13-52
Communication evidence (
O2, O3 )
All forms of interpersonal communication such as
e-mails, also automatically generated ones
tool-supported workflows
meeting, verbally or via meeting minutes (e.g., daily standups)
podcast
blog
videos
forum
live chat
wikis
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 Management of Products for Reuse
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 Performance Management
13-51
Consistency Evidence (
O2, O7 )
Demonstrates bidirectional traceability between artifacts or information in artifacts, throughout all phases of the life cycle, by e.g.,
tool links
hyperlinks
editorial references
naming conventions
Evidence that the content of the referenced or mapped information coheres semantically along the traceability chain, e.g., by
performing pair working or group work
performing by peers, e.g., spot checks
maintaining revision histories in documents
providing change commenting (via e.g., meta-information) of database or repository entries
Note: This evidence can be accompanied by e.g., Definition of Done (DoD) approaches.
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
14-02
Corrective action (
O6, O7 )
Identifies the initial problem
Identifies the ownership for completion of defined action
Defines a solution (series of actions to fix problem)
Identifies the open date and target closure date
Contains a status indicator
Indicates follow up audit actions
Used by these processes:
ACQ.4 Supplier Monitoring
MAN.3 Project Management
MAN.5 Risk Management
SUP.1 Quality Assurance
18-52
Escalation path (
O4, O6, O7 )
Defined mechanisms to report and confirm escalation relevant issues
Identifies stakeholders to be included in the escalation path
Identifies levels of escalation
Used by these processes:
MAN.3 Project Management
SUP.1 Quality Assurance
08-54
Feasibility analysis (
O2, O4 )
Statement about the ability of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) to achieve the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) objectives with available resources
Used by these processes:
MAN.3 Project Management
15-06
Project status (
O4, O6 )
Status of in regards to progress and consistency of schedule, work item content, (Task = A definition, but not the execution, of a coherent and set of atomic actions.), resources (human resources, infrastructure, (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.)/materials, budget), skills and competence of human resources
planned progress and expenditure against dates/deadlines and actual expenditure
reasons for variance from planned progress
threats to continued progress
issues which may affect the ability of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) to achieve its goals
contingency actions
Used by these processes:
MAN.3 Project Management
08-56
Schedule (
O3, O5, O7 )
Identifies the activities to be performed
Identifies the expected, and actual, start and completion date for required activities against progress/completion of activities
Identifies dependencies between activities and critical path
Has a mapping to scheduled resources and input data
Identifies resource allocation, resource workload, and critical resources
Note: A schedule is consistent with the defined work packages, see 14-10
Used by these processes:
MAN.3 Project Management
Used by these process attributes:
PA2.1 Performance Management
08-53
Scope of work (
O1 )
Summary of (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.) for a (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.)
Intended use for the (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.)
Main functions to be realized
Target delivery date and major milestones
Work products and activities that are not in scope of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) as needed
Target markets
Applicable standards and legal requirements
Reuse options
Integration of third party deliveries
Used by these processes:
MAN.3 Project Management
14-50
Stakeholder groups list (
O4 )
Identifies:
involved parties
weight/importance of each stakeholder group
representative(s) for each stakeholder group
(Information need = The need for characterizing process or product related effectiveness and efficiency (used by MAN.6 and PA4.1).) of each stakeholder group
Used by these processes:
MAN.3 Project Management
14-10
Work package (
O3, O4, O5 )
Defines activities to be performed
Documents ownership for activities e.g., by domains
Documents critical dependencies to other work packages
Documents input and output work products
Documents the critical dependencies between defined work products
Information needed to perform these activities
Estimates of effort, duration
Note: The work package descriptions may be integrated into the/be a part of a schedule, see 08-56
MAN.3
Project Management
