‘Soft Systems Methodology’ – An interesting problem solving perspective
SPOILER ALERT! Nerdy post incoming! 😀
Recently, I had concluded a pretty interesting course in Information Systems. Termed as ‘Systems Thinking’, the course delves into interesting perspectives of what constitutes a system, its functionalities at various levels and the different types of methodologies and so on. One such particular methodology that we conducted a project on was called ‘Soft systems’. So what exactly is this and why am I writing a post on it?!
Firstly, to define, let’s take a look at what is ‘hard systems’. In simple terms, anything physical and tangible or concrete in nature can be ‘hard’. While talking about systems, you can view any computer infrastructure, setups and components as that. Thus usually, when we want to solve a problem as IT/IS experts, this concreteness gives us clearly defined issues to solve. The goal is very explicitly mentioned from the beginning as to what needs to be achieved and which process must be followed. Naturally, that is how we have been solving any problems out there.
Define problems —> formulate goals to achieve —> apply techniques —> complete work
Now, let’s bring into picture ‘soft system’. One might think that it’s exactly opposite to hard system. Well yes, in a way it is. In this context, we look into not-so-concrete problems. We deal with issues that have been ill-defined and do not really have a clear cut answer. Therefore, the solutions that we come up with also cannot be solid or ‘hard’. This is where we are required to think ‘soft’! So, in this type of thinking we always put the users or all important stakeholders into the center and start from there. The goals are not defined as to what needs to be achieved and therefore, situation gets clear as you go about it. Hence, it is important to not a fixed mindset about a particular technique or process you wish to implement just because you think it’ll work.
For instance, a client can come by and complain about a seemingly ‘successful’ project during trial has completely faltered after full integration into the company. One has to wonder how that could happen. And this is where we start thinking ‘soft’. You can see from the example few vital things-
- The problem is not well defined. and 2. The goal is not clear.
Hence, we as experts, start off by understanding the problem. One of the most significant way to do it is involving the people who are involved in the problem at different levels. As a result, we can get many insights that will pave our future direction. Once the problem starts getting clear, you apply few techniques to clearly see what the stakeholders have to do and can they actually do it. Then compare the results with real-life scenario and based on the differences, propose changes and implementation. The solution found can lead to further studies as new information and problems might emerge and hence the cycle continues, until we reach a position where every stakeholder is satisfied and they are starting to see positive results.
So as you can see, it’s not always necessary to have problem defined well and to keep users outside the fold of development. The more we incorporate, the more chances we have being successful!
Image taken from internet