Hard Things by Easy Words: How the laws of the system approach in IT Projects can be Violated. Part 4

laws of the system approach

Continuation. How systems break down.

We do not really support the statement “I know exactly how it is supposed to be as I have experience in … for several years”. I stand for common sense, flexibility and the constant expansion of knowledge boundaries. The theme of the need for a business analyst in IT projects is endless. The laws of the system approach is fundamental.

Taking into account experience, knowledge, etc. everyone has his or her point of view in the discussion. In accordance with the conditions and needs of a certain project, you’ll have to decide if it is necessary to have a business analyst in your project, what will be the way to evaluate the problem and what will be the demands for the product as a business problem-solving.

For example being a manager once I ran a project that did not require anything at all (except the structure of tasks in Jira), but the stabilization exceeded the planned budget almost twice (instead of 25-30% of the sprint development budget they spent about 50-55%). Though, the customer still did not accept the business analysis requirements.

He was permanently insisting on the fact that there were only 2 developers and the project was not too hard which leads to the conclusion: there is no need to write and analyze the requirements. Moreover, one more person within the team would complicate the way of communication as the customer and developers would need to communicate anyway. Though alternative opinion was brought to the customers, the choice was up to them, and it was not in favour of business analysis.

You’d probably ask what to do in such a common situation when the customer “wants a car, laid out the requirements for a jet aeroplane and have the budget available to get a scooter only”? At the same time, he does not understand anything in technologies (inexperience with the customers I’ve been dealing this would be 50-70% in average). What should the developer do? Should he or she deal with the customer’s needs? The answer is obvious. Likewise the role of business analysis in this situation. Annual losses (in the process of software development and implementation) around the world of $ 250 billion associated with poor requirements and misunderstanding of needs and problems.

By not being guided by common sense and neglecting business analysis on IT projects (as in the case described above) we ruin the integrity attribute. As consequence, we see a high probability of failure of the project.

Very often in IT projects the principle of goal-setting is violated. This happens when the goals of the subsystems or their elements change. For example if you ask IT project managers about the aims of certain project roles the common answer would be: “Work out a plan and keep pace with the budget and timing” (aim is important, but this is not the aim of the whole system), from analyst the answer would be: “Develop good documentation”, from developers: ” Write a good code” etc. No one needs it as well as the project itself if, at the end of the day, customers’ problems remain unsolved and the product services do not meet the needs of end users. By changing the goals of the subsystems and their elements, we provide a service of poor quality and as a result, we get a “square wheel“.

I’ve been using the examples of mistakes in the identification and work with interested people in order to describe how contradictions arise in the hierarchy of systems.

Even if you do not know anything about the system approach and do not see the systems, your IT project is still considered to be a system. It exists according to the laws of the system approach. Laws are fundamental and unchanging. Depending on what you can do and how you can use the laws you can influence the project and its final result in either a positive or negative way.

Instead of the conclusion.

Autobiography in five short chapters by Portia Nelson

I walk down the street.
There is a deep hole in the sidewalk
I fall in.
I am lost … I am helpless.
It isn’t my fault.
It takes me forever to find a way out.

I walk down the same street.
There is a deep hole in the sidewalk.
I pretend I don’t see it.
I fall in again.
I can’t believe I am in the same place
but, it isn’t my fault.
It still takes a long time to get out.

I walk down the same street.
There is a deep hole in the sidewalk.
I see it is there.
I still fall in … it’s a habit.
my eyes are open
I know where I am.
It is my fault.
I get out immediately.

I walk down the same street.
There is a deep hole in the sidewalk.
I walk around it.

I walk down another street.

See also:

  1. Hard Things by Easy Words: a stakeholders point of view of an IT project. Part 3
  2. Hard Things by Easy Words: Basics of System Approach. Part 2
  3. Hard Things by Easy Words: Basics of System Approach. Part 1
  4. System Approach and System Thinking. Any reasons for?


Author: Veronika Baeva, see original resource in Russian.