Life Cycle

From Change

Jump to: navigation, search

Change Life Cycle

Contents


Model

This simple diagram introduces the concepts that enable us to understand the full context of change. It states that when acting on a system we need to have a clear idea of the model through which we understand the system and we need to explicitly engage in a process that enables the system to be changed.

Furthermore, it indicates that as the system changes, both the model and process may need to be adapted.

  • System: the concrete complex adaptive system that carries out its activities as its dynamics run
  • Model: the representation that we use to capture our understanding the system in its current and future forms
  • Process: the management of the activities carried out in order to guide in change the system

The changes to the above aspects need to be considered relative desired outcomes:

  • Objective: the purpose and desired outcome of the change process

There are many different examples of this triad:

System Model Process
Software Architecture Development process
Business Vision Management process
Individual Psychological Theory Theraputic process
Environment Complex System Evolution & adaptation
Art Artist's concept Creative process
Society Government Science, democracy and general social behaviour & relationships

This diagram offers a slightly richer view of cycle: 

Cycle: Action >> Observation >> Reflection >> Learning >> Planning >> Action

of change sometime presented in that it provides targets for the different activities in the cycle (i.e. system, model or process).

By drawing a clear distinction between these different aspects involved in the overall life cycle of change it becomes easier to study them. The main reason is that each of these different domains requires different resources, tools, skills and concepts. Decoupling them makes it possible to given each aspect the necessary level of focus.

Framework

So what we are actually providing is a framework for taking a systems view to managing change.

By having a framework that cleanly differentiates these areas we are able to introduce appropriate separation of concerns. This makes it easier to give the required attention to detail needed for each of the different areas. Furthermore, it makes it easier to adapt each of these aspects independently.

Another important reason for having a framework is that it makes it more natural to take a second order approach to managing change. This principle basically states that in working with complex systems it is more important to provide a conducive setting than to explicitly manipulate the system. That is, focus on the framework that supports the change.

However, although there are common principles that apply to a miriad of systems, the model and processes will ultimately need to be specifically tailored to the system in question. That is, when dealing with a concrete system, we need to construct a model and related process that deal specifically with the details of the system and the type of change we are trying to manage.

Objective

So what do we really want to get out of the process. Generally, in some way we would like the system to be effective, efficient and sustainable. That is, it we would like the system to:

  • achieve its purpose,
  • be good at doing this and
  • be able to continue doing this even as its given context changes.

We can look at a number of different systems in this light:

System Purpose Quality Sustainability
Software perform a particular task do so quickly without needing too much memory continue working and be adaptable if the task changes slightly
Business provide a given service do so while making a profit continue functioning and be adaptable if the market changes
Individual live ones life do so while being happy and adding value remain healthy and be adaptable to changes in society
Environment support the creation of life support all current life forms remain healthy and fertile, and be adaptable to changes within itself
Art capture meaning be beautiful and profound continue to be pertinent over time
Society support individuals support the complete well being of all individuals continue functioning be adaptable to changes within itself and the environment

However, the difficulties arise when either the system is complex or the context is continually changing. In either of these cases it becomes impossible to expect to be able to construct a perfect (or even acceptable system) in one go and then put it to good use. Rather, we are going to need to change the system while it is running. Why? Well, in the case of a complex system the risk is simply to high that we will get something wrong while we are trying to assemble thousands of pieces, so instead we should get smaller (simpler) parts of the whole system working and then stick them all together (e.g. software development, preparing a 5 course meal). In the case where the context is changing, we often already have a functioning system (albeit only limping along), however, due to changes in the environment the system needs to adapt otherwise it will breakdown.

Changing the system while it is running comes with a number of challenges:

  • how do you keep the system working while changing it?
  • how do you know what affect your changes will have?
  • how do you create change in the system through localised influence and modifications?
  • how do you manage a system that you are an active part of?
  • how do you ensure that the system will be robust and resilient?

It is precisely these sort of issues that we hope to address.

Process

The above framework provides a relatively simple setting that enables us to get a handle on the overall process of creating change in a system. However, it certainly does not provide that much depth. In order to actually achieve something with all this we need some concrete details. This section starts to introduce this detail by describing principles that can be applied at varying levels. The intention is that the principles at a given level will enables us to explore certain areas in even more detail. Eventually some of these principles will be sufficiently specific that we can flesh them out into actual tools and procedures.

A system is built out of a number of pieces. Each piece knows how to perform at number of activities. Furthermore, there are relationships between various pieces. The activities the individual pieces and the interactions between them that are created by the relationships combine to exhibit the overall behaviour of the system. That is, even in simple systems there is a wonderful interplay between thousands of pieces that all function harmoniously giving the entire system its inherent properties and beauty.

At the highest level our understanding should capture this essence. The model describes our understanding and if our understanding is valid then we should see patterns of our model echoed in the real system. This introduces one of the most powerful concepts in taking an architectural (modelling) approach to change:

  • any patterns and ideas that we describe in our model of how the system should work, should become embodied in the system at every possible level.

This concept can be used in both directions. If we want to build an understanding of a system, we should try find structural patterns. If we are planning to change a system we should ensure that the changes will in fact lead to the designed patterns emerging in the system.

The implication of this is that we need to verify our model relative to the reality. We need to explicitly review both the model and the real system and demonstrate that the two correlate. This introduces the next concept, measurement:

  • in order to verify our understanding and progress we need to be able to measure aspects of the system

Without measurement, we are running around in the dark.

Once we have taken measurements and understood their implications we need to do something with this knowledge. In this case we may choose to update our model because it is not a valid representation of the current system, or we may choose to modify the system because it does not accurately embody the key patterns described in our model, or finally we may wish to modify our process due to inadequacies. This activity introduces, feedback:

  • for the model, system and process to remain synchronised and mutually supportive we need to maintain continuous feedback between the all three aspects.

In the case of any changing system these activities need to be carried out explicitly. Therefore, we have a process of change made out of various activities that ultimately drive the change. Note, however, that this is seldom a single step process but rather one of discovery and adjustment. This introduces the concept that change is incremental:

  • the process of change should be allowed to be incremental creating steady iterative refinement.

In following this process we are describing, at a high level, how to manage change. However, we seem to have missed one key point: the purpose. That is, what is our objective in creating change.

  • any change should be carried out relative to a desired objective.

It is with this objective in mind that we decide what properties we want the system to ultimately display. That is, our objectives help us decide what details to capture in our model and what constraints to capture in our process. In this way we have come full circle and our attention is back with the model and demonstrated the concept of closure:

  • operational closure highlights the act of checking that there are no loose ends be ensure that all loops are closed.

This means that we can be comfortable that we are looking at the whole system.

Tools & Principles

In carrying out activities in this life cycle we can employee various tools. The tools will differ depending on the actual system we are working with.

System

Process

  • objective
  • iterative
  • feedback
  • measurement

This is contrary to the 'Big Bang' (and somewhat reductionist) approach requiring upfront detailed fine grain design and planning before starting to change the existing system.

Model

  • modularity
  • separation of concerns
  • loose coupling
Retrieved from "http://www.gethos.net/change/Life_Cycle"
Personal tools