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 "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 manage activities of an exemplary (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, manage (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) and monitor organizational problems related to the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.).
# PROCESS OUTCOMES
O1
Activities are identified, sized, and estimated
O2
Technical feasibility of the activities is evaluated
O3
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.) are identified and monitored
O4
Schedule for 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.) is developed and monitored
O5
Progress of the activities is reviewed
O6 (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) are managed continuously
O7
Organizational problems related to the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) are recorded, analyzed, and monitored
# BASE PRACTICES
BP1
Identify, define, and estimate activities. (
O1 )
Define estimates of effort for identified (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) activities and document dependencies
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.
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.
BP2
Ensure technical feasibility. (
O1, O2 )
Evaluate technical feasibility of activities and goals within the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.)’s constraints on time and estimates.
BP3
Identify and monitor project interfaces. (
O3 )
Identify and monitor 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 internal or external stakeholders. Note 1: Interfaces for partnerships and collaborations based on goods and workpackages may be considered using Partner and Collaboration Management (PCOM).
BP4
Define and monitor project schedule. (
O4 )
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 with respect to the 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 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.
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.
BP5
Review progress of the activities. (
O3, O4, O5 )
Regularly review the status and the fulfillment 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 activities against estimated effort and duration. Note 2: Progress for partnerships and collaborations based on goods and work packages may be considered individually using Partner and Collaboration Management (PCOM).
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
BP6
Manage risks. (
O6 )
Manage (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) to technical and organizational activities of the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.). Ensure the impact of (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) treatment activities is monitored for the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.). Note 3: Activities may be affected by technical, economical, and schedule related (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.). Note 4: (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) treatment options may include reduction, avoidance, transfer, or acceptance of (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.).
Linked Knowledge Nuggets: arrow_forward "Examples of potential undesirable events"
personAuthor: Process Fellows
Throughout the entire project lifecycle, various undesirable events may occur, affecting internal and/ or external stakeholders. These events can be categorized for example into process-related and technical product-related ones.
Process-Related Undesirable Events:
These refer to disruptions or deviations in project execution and collaboration:
Project progress deviates from the planned schedule or effort estimates.
Resources, including personnel, are unavailable when needed.
Commitments made by development partners are at risk of not being fulfilled.
Technical Product-Related Undesirable Events:
These concern the quality and suitability of the delivered product:
Defective product is delivered to the customer.
Requirements are incomplete or missing and therefore the product does not provide the needed capabilities.
Changes in the product lead to unintended impacts on product's behavior.
personAuthor: Process Fellows
Risk registers are not enough. MAN.5.BP6 expects continuous monitoring, i.e. a regular update, including mitigation actions. Use heat maps, risk burndown charts, and regular risk reviews.
arrow_forward "Why is a regular risk monitoring helpful?"
personAuthor: Process Fellows
Risks should be tracked regularly in risk management for several important reasons:
Risks Can Evolve Over Time:
Risks are not static. Their likelihood, impact, or relevance can change due to internal or external factors such as project progress, market shifts, regulatory updates, or technical developments. Regular tracking ensures that the risk profile remains accurate and up to date.
Enables Timely Mitigation:
By monitoring risks continuously, teams can respond quickly when a risk becomes more critical or imminent. This allows for proactive mitigation strategies rather than reactive crisis management.
Supports Decision-Making:
Updated risk information helps stakeholders make informed decisions about priorities, resource allocation, and contingency planning. It ensures that decisions are based on current realities rather than outdated assumptions.
BP7
Analyze and monitor organizational problems related to the project. (
O7 )
Record, analyze and monitor the impact of organizational problems related to the (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.). Note 5: Organizational problems, as a type of non-technical problems, may be related to groups inside and outside the exemplary (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.), such as shared resources, internal service providers, central functions, etc. Examples of organizational problems are communication issues, lack of stakeholder involvement, insufficient skills identified at interfaces, etc. Note 6: Resolution of organizational problems may be supported by Process Quality Assurance (PQAS), process improvement (e.g., as ISO/IEC TR 33014), or established management practices (e.g., lessons learned, inspect and adapt, retrospectives).
# OUTPUT INFORMATION ITEMS
14-02
Corrective action (
O4, O5 )
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:
PCOM Partner and Collaboration Management
POPM Potential Project Management
PQAS Process Quality Assurance
13-07
Problem (
O7 )
Identifies the submitter of the problem
Identifies the group/person(s) responsible for providing problem resolution
Includes a description of the problem
Identifies classification of the problem (criticality, urgency, relevance etc.)
Identifies the status of the problem
States such as “open”, “in review”, “in implementation”, “closed”, “rejected”, “cancelled”, …
Transitions between states with conditions and authorities
Identifies the expected closure date
Used by these processes:
POPM Potential Project Management
TEPR Technical Problem Resolution
15-12
Problem status (
O7 )
Indicates progress of problem resolution
Status of problem e.g.,
by problem categories/classification
by problem resolution stage
Used by these processes:
POPM Potential Project Management
TEPR Technical Problem Resolution
15-06
Project status (
O4, O5, O6, O7 )
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:
POPM Potential Project Management
15-08
Risk analysis (
O6 )
Identifies the (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) analyzed
ID
Impact scenario (e.g., damage scenario)
Records the results of the analysis:
potential ways to mitigate the (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.)
selected (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) treatment option (e.g., (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) acceptance as cybersecurity claim or (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) reduction)
assumptions made
probability of occurrence (e.g., attack feasibility)
(Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) value
constraints
Used by these processes:
CSGE Cybersecurity Goal Elicitation
POPM Potential Project Management
08-55
Risk measure (
O6 )
Identifies
the (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) to be mitigated, avoided, or shared (transferred)
the activities to mitigate, avoid, or share (transfer) the (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.)
the originator of the (Measure = An activity to achieve a certain intent.)
criteria for successful implementation
criteria for cancellation of activities
frequency of monitoring
(Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) treatment alternatives:
treatment option selected- avoid/reduce/transfer
alternative descriptions
recommended alternative(s)
justifications
Used by these processes:
CSGE Cybersecurity Goal Elicitation
POPM Potential Project Management
15-09
Risk status (
O6 )
Identifies the status, or the change, of an identified (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.):
(Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) statement
(Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) source
(Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) impact and (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) probability
categories and (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) thresholds, e.g., for prioritization or setting a status
(Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) treatment activities in progress
Used by these processes:
POPM Potential Project Management
08-56
Schedule (
O4, O5 )
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:
POPM Potential Project Management
14-50
Stakeholder groups list (
O3 )
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:
POPM Potential Project Management
14-10
Work package (
O1, O2, 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
POPM
Potential Project Management
