A toolbox for dealing with changes
Acceleration in product development is a real challenge for systems engineering. Traditionally, stability has been emphasized there, not agility. However, increasing complexity and tougher competition make it vital to be able to handle change well. This was recognized as early as 2001 when the agile manifesto for software development was drawn up, and the underlying principles are currently spreading across all aspects of organizations, including systems engineering and product development.
Dealing with change confidently is a basic requirement. This is a topic that I have been working on for some time now. I am currently preparing a four-hour Workshop for the ReConf 2019: Making changes manageable. Since there is no universal solution for all situations, the approach here is to systematically prepare various tactics in order to then incorporate them into the development processes. For these tactics, or best practices, I have been inspired by design patterns and present the concept in short form in a Lecture at the ReConf 2019: Development patterns for dealing with change.
Here are my initial thoughts on this topic.
Toolboxes have proven their worth
The idea of patterns is an old one. They were coined Design Pattern by architect Christopher Alexander. The concept was enthusiastically received by the software community, and the "Gang of Four" book is now required reading for all software developers.
The toolbox approach is also followed by Tim Weilkiens with SYSMOD, a toolbox for system modeling.
A template for the patterns
Patterns are typically recorded in natural language in a template. The use of a template helps to quickly find the right information. Cross-references place the patterns in relation to each other.
Even if a uniform pattern is used, the content of the patterns can differ drastically from one another. Christopher Alexander's patterns (architecture) range from the level of an entire city to a single window.
This flexibility is important when dealing with change, as many different elements have to work together here too: Processes, methods, tools, people's behavior, and much more. See below for an example. Here is my current design for the template:
Intent
A short statement that answers: What does the pattern do? What is the rationale and intend? What particular issue or problem does it address?
Also Known as
Delete if not applicable
Motivation
A scenario that illustrates a problem that is solved by this pattern, include examples
Applicability
What are the situations in which the pattern can be applied? What are examples of poor product development that the pattern can address?
Structure
For structural patterns, a description or visual representation of the data structures (e.g. relationship diagram). For behavior patterns, a description of the processes or activities.
Consequences
Benefits and liabilities
Implementation
What pitfalls, hints or techniques should you be aware of when rolling out this pattern? These can be technical, organizational, cultural or human issues.
Related Standards
Indicate if the pattern supports requirements from standards like ISO/IEC/IEEE 29148 and the like.
Related Patterns
Hyperlinks to other patterns.
An example
If we wanted to start on a "greenfield site", we would first need the→Change management process pattern study. It then goes into various strategies that primarily consist of references to standards. There we also find a list of questions that helps us to find further patterns. For example, should →Document-based, → Data model-based or →System model-based be worked?
To ensure that changes run smoothly, there must be a tried and tested →Role rights concept. In practice, a decision must now be made as to which tool to work with (→Tool selection), and how this is configured accordingly. During implementation, there are various concepts that apply at different levels, such as →Quality Gatesthat affect a large number of elements, right down to individual elements where →Suspect Traces must be used correctly. For the whole thing to work, the users must be properly integrated. This starts with the writing of →Good requirements and also includes conveying the →Core Principles for this organization, and →Effective Training and →Effective Collaboration.
Scope
It is obvious that a considerable amount of work is involved in capturing these patterns. Furthermore, many activities in systems engineering have to do with changes: Where do we stop? Finally, there is the question of completeness.
To start with the last point: We cannot expect completeness here, just as Christopher Alexander's sample collection is not complete. The aim here is to Pareto principle cover the most important patterns. Similarly, aspects that are not related to change management are only mentioned but not covered in depth.
And finally: Patterns cannot be invented, only discovered. The content therefore naturally comes from practical experience.
Feedback?
What do you think of this approach? Is there already work of this kind that I have overlooked? About a Feedback in the comments downstairs I am delighted.
