The model is based around understanding the correlation between cause and effect:

My original understanding of the model was that you would try and work out where a system fitted into the model and I was under the assumption that most software projects would be considered 'complex'. After a couple of hours in the workshop it became clear that we can actually break down the bigger system and see where its parts (sub systems) fit into the model as well. Since different approaches are required depending upon where in the framework we are, we would act differently depending on the situation. For example a software project as a whole might be considered complex but the design of the architecture might only be complicated because some of the team members have worked on something similar previously.

Another interesting point that John made is that things don’t have to live in one domain forever - they can move between them! For example on a lot of the projects I’ve worked on it often feels that if we knew everything we knew at the end of the project at the beginning we could have finished it significantly quicker. Effectively the project starts off being complex but if we got to do exactly the same thing again and it played out in exactly the same way then it might only be complicated.

We did a couple of exercises where we had to place different items onto the model - first non software related and then software related. It was interesting to note that in the first exercise we had quite a few items in the disorder section but in the latter we had none. As you would expect having experience in the group around the domain helps us understand the problems in that domain better. If we take this one step further it’s also beneficial to have diversity in the group because then we get a variety of perspectives and one person’s strengths can help make up for another’s weaknesses.