Dealing with change is getting increasingly difficult, as change in general accelerates. Therefore, we need new paradigms for dealing with change. This article outlines the idea of building a library of patterns for managing change in product development.

Many organizations have established processes for managing change, and also have initiatives for transforming their organization. The objective of the library is to provide simple and proven building blocks for execution.

You can learn more about these concepts at ReConf 2019 in the talk “Development Pattern for Dealing with Change” (Michael Jastram). Also, we already introduced a first summary of this idea in our German companion blog SE-Trends (Google Translation).

SE is Pretty Good in Dealing with Change

First, Change Management has always been an integral part of Systems Engineering. ISO/IEC 15288:2015, for instance, includes a Configuration Management Process (Clause 6.3.5), which deals with controlled change, among other things. But the standard also contains a number of definition processes (for Stakeholder Requirements, 6.4.2, System Requirements, 6.4.3, Architecture, 6.4.4, and Design, 6.4.5). During definition change takes place as well, but less controlled.

But the standard outlines what needs to be done (and changed), not how. This is where this library of patterns comes into play. It allows to continuously improve existing processes with purpose in a systematic way.

Scope of this Work

While this work has a focus on change, the underlying goal of systems engineering is to build any build great products. Therefore, this work shall have a positive effect on product development. Each pattern shall result in either better outcomes, faster outcomes or the same outcome with fewer resources. And most important, the patterns shall counter the effect of increased changeability.

Organizing Development Patterns

There are many ways of organizing patterns, but one is by the desired outcome. We change something because we want to improve something. The patterns are categorized broadly in the following categories:

• Improve Quality – In the context of change management, we want to decrease the number of bugs and increase the detection of inconsistencies that a change may introduce.
• Improve Efficiency – A change triggers rework, which shall be minimized. Automation can also help with boosting efficiency in the light of change.
• Improve Transparency – We must understand the impact of a change beforehand and see it’s effect afterwards. Only transparency allows us to make the right trade-offs with respect to changes.
• Decrease Change Impact – Changes can produce a ripple-effect, a change triggering more changes, which in turn trigger more.
• Enhance Collaboration – At the end of the day, people develop products. Enhancing collaboration is a way to make sure that all stakeholders understand the impact of planned changes, and that the team has a chance to optimize the change, e.g. to reduce impact or to improve the architecture at the same time.

Note that these are not mutually exclusive (and the list is not finalized, for that matter). For instance, better collaboration typically also improves quality and transparency. Therefore, patterns have one primary category and may have secondary categories.

Activities

ISO 15288 defines a large number of activities, but these can broadly be categorized as well. They typically fall into one of the following categories:

• To Structure – Building a structure (or meta-model) for the development artifacts. Applying patterns to the structure can make them better-suited for dealing with change.
• To Develop – This is the actual process of authoring and developing content. Following patterns during this activity can make dealing with change easier, e.g. by writing atomic requirements.
• To Analyze – Certain analysis patterns have a direct impact on dealing with change, like the impact analysis.
• To Document – Documentation can take a surprisingly high amount of effort, and is an important activity in the light of managing change.
• To Change – This activity is concerned with formal changes, as opposed to the changes that take place during development.

Putting It All Together

Patterns can now be placed in a matrix, bringing activity and purpose together. As an example, we added five patterns that are briefly described below.

The patterns used as an example in this table are:

• Black Box – This pattern suggests to define blocks of our system by its requirements and interfaces, but not its inner workings. This approach is formalised in SysML blocks, but can also be used informally. This pattern is applied when structuring our system description. It’s benefits are a decreased change impact (compared to informal requirements): Any changes inside the block does not affect other systems consuming the block, as long as interfaces and behavior do not change.
• Review – Reviews are proven to increase quality and to decrease risk of development, if done early and often. Key here is to ensure that reviews are conducted efficiently. Jama’s Review Center is an example of a tool that is roughly twice as efficient than using Word and email for reviews.
• Requirement Volatility – This metric measures the magnitude of change within the requirements, with respect to the total number. Volatility is typically high at the beginning of development and decreases, as requirements stabilize. Sudden peaks in volatility are a sign of underlying problems (e.g. problems in the architecture). Measuring volatility and proactively reacting to it are a way to be more efficient with respect to change. However, few organizations measure requirements volatility.
• One-Pager – Using a few one-pages can drastically improve the transparency between teams, even if no integrated toolchains exist. The One-Pager has been described here before.
• Suspect Links – Many tools already support this feature: A change on an item will mark related downstream items as suspect. For instance, changing the battery life of a product will mark the downstream design elements (e.g. battery capacity) and tests (e.g. endurance test) as suspect. Using suspect links ensures that only those items that are likely to be affected by a change are re-analyzed. If this triggers a downstream change, it will once again mark connected items one level down as suspect, but not more.

Coming Soon: A Collection of Patterns

What we presented here is a framework for patterns relating to change in product development. We’re currently exploring these ideas and will drive them to a maturity sufficient to demonstrate at ReConf 2019. Whether we will go beyond this depends on the feedback we receive.

Photo by Suzanne D. Williams on Unsplash