Change requests are required if the project scope or requirements are to be changed. Chargeable changes represent a chance to increase your project turnover and also your personnel capacity. Change requests are also very important for the customer. If change requests are processed quickly and effectively, this increases customer satisfaction.
I regard the following as the most important aspects of change request management in Automotive SPICE:
- Establish a change request management strategy. A change request needs to be processed through all engineering processes without getting stuck. This involves dozens of people in different teams and locations. It is essential to coordinate everyone and track the status of change requests as they flow through the different steps, or the changes will not be managed effectively. A good strategy makes it clear to all involved how the workflow is, how progress is controlled and who is responsible for what. Here is a strategy framework to start with:
- Define the categories of change requests, such as chargeable change requests, non-chargeable change requests, system level change requests, software requests and so on.
- Define input channels: Who can submit change requests.
- Define the tools to process change requests.
- Define the status that change requests will have during processing.
- Define the methodology and identify the individual(s) responsible for tracking progress.
A typical solution is a Change Control Board (CCB) for oversight and leadership, such as:
-
Analyze and approve change requests. Sometimes projects start uncritically and immediately with the processing of change requests. This is a mistake; it is crucial to evaluate financial compensation and/or burden on the project team. Instead, the CCB can: :
-
Evaluate whether a change request is chargeable and even whether the initiator is authorized to submit change requests.
-
Provide the expertise for a more detailed feasibility analysis of the change request. If the request is chargeable, the CCB can help estimate the effort, prepare a quote and negotiate with the customer.
-
Determine whether the desired implementation date is achievable. This upfront determination can help avoid endangering the previously agreed releases and their contents.
-
These guidelines set the relationship up for success: a reliable partner for the customer and other stakeholders.
-
Implement change requests. Let’s say that after prudent analysis and review, a change request has been approved to move forwrad. Implementing change requests increases the workload of your teams and requires careful planning and monitoring. Otherwise, either the change requests or the normal development tasks may hang or be late. Change requests and normal development tasks compete for resources and delivery dates. If you don't have many buffers or can increase staff capacity, these are your options:
- Move features to a later release
- Move bug fixes and gain more capacity for the change request.
Both have the potential to frustrate the customer and must therefore be negotiated with the customer in advance. Once this is resolved, treat the change requests like any other development task.
Automotive SPICE requires that change requests be traceable to all affected work products. This is easy to solve with the use a life cycle management tool that is linked to the configuration management tool. A change request leads to a series of development tasks and each development task is traceable to all resulting changes to work products.
- The benefits of a rigorous change request management are:Implement powerful change request management functionality,
- while keeping control of your releases, and
- minimizing the potential for errors and delays that would negatively impact your customers.
Automotive SPICE – change request management process
The purpose of the change request management process is to effectively manage, track and implement change requests.
Best practice (BP)1: Develop a change request management strategy. This strategyencompasses change request activities, a status model for the change requests, analysis criteria and responsibilities for performing these activities. Interfaces to affected parties are defined and maintained.
- Note 1: A status model for change requests may contain: open, under investigation, approved for implementation, allocated, implemented, fixed, closed, etc.
- Note 2: Typical analysis criteria are: resource requirements, scheduling issues, risks, benefits, etc.
- Note 3: Change request activities ensure that change requests are systematically identified, described, recorded, analyzed, implemented and managed.
- Note 4: The change request management strategy may cover different proceedings across the product life cycle, e.g., during prototype construction and series development.
BP2: Identify and record the change requests. Each change request is uniquely identified, described and recorded according to the strategy, including the initiator and reason of the change request.
BP3: Record the status of change requests. A status according to the status model is assigned to each change request to facilitate tracking.
BP4: Analyze and assess change requests. Change requests are analyzed according to the strategy, including their dependencies to affected work products and other change requests. Assess the impact of the change requests and establish criteria for confirming implementation.
BP5: Approve change requests before implementation. Change requests are prioritized based on analysis results and availability of resources before implementation and approved according to the strategy.
- Note 5: A Change Control Board (CCB) is a common mechanism used to approve change requests.
- Note 6: Prioritization of change requests may be done by allocation to releases.
BP6: Review the implementation of change requests. The implementation of change requests is reviewed before closure to ensure that the criteria for confirming implementation are satisfied, and that all relevant processes have been applied.
BP7: Track change requests to closure. Change requests are tracked until closure. Feedback to the initiator is provided.
BP8: Establish bidirectional traceability. Establish bidirectional traceability between change requests and work products affected by the change requests. In the event that the change request is initiated by a problem, establish bidirectional traceability between change requests and the corresponding problem reports.
- Note 7: Bidirectional traceability supports consistency, completeness and impact analysis.
Output work products
- Change management plan
- Change request
- Change control record
What is the benefit of change request management?
When used properly all changes to baselined items are managed and controlled. There is agreement on what to change and when it will be changed.
What is the content of the change request management process?
- The activities, responsibilities, resources required and an organization-specific life cycle model for the states of a change are defined in the change management strategy and implemented in the project. (BP1)
- Each change request is recorded (BP2) and its status updated as it moves through the lifecycle. (BP3)
Example of a status workflow of change request management
- The effects of the changes are analyzed and prioritized for impact, benefit, resources, urgency, schedule and risks. Also, the types of verification activities needed are defined. (BP4)
- Each change request is approved before it is implemented. (BP5)
- Changes are tracked until completion. Prior to completion, their correct and purposeful implementation is examined. The submitter is informed of the status regularly. (BP6, BP7)
- Bidirectional traceability between the change request and all work products affected is established. (BP8)
Considerations for typical challenges
- Change management is closely related to problem resolution management (SUP.9), since solving problems can cause changes. It also depends on the requirements processes, (SYS.2 and SWE.1) since changes to requirements can cause changes elsewhere and vice versa.
- Tool support in this process is indispensable to allow structured processing of changes. The tool needs to have a good integration into the engineering tool suite to allow seamless implementation of traceability. (BP8)
- The interface between customer and the subcontractor regarding problem management tools and procedures should be defined (typically in the strategy).
- Projects should have clear definition of change request approval, to prevent work proceeding on unapproved changes.
- Similarly, there should be an explicit and conscious approval in cases like this: although a customer change request has not been supported with a commercial order, the team may decide to proceed with development at their risk, to the likely advantage of all parties.
Learn more about Automotive SPICE
If you want to learn more about Automotive SPICE®, check out our ASPICE Training.
About the author
Dr. Klaus Hoermann started working with SPICE back in 1998. Since then he has done hundreds of assessments and trainings. It is his passion to bring hard-to-understand models to life so that everyone can understand them.
To access the rest of this engaging content, please fill out the form below:
Please wait…