In this series of blog posts will continue to fill in our Prefilled Problem Picture Analysis Map, to make it, that is right, prefilled. And as you remember its structure looks like this, with the problem description in the blue box at the top, the red root causes at the bottom and the symptoms in the white boxes in between. Below the root causes we have the naked truth valid for all organisations, “A non-adaptive organisation will die”.
For the details, please see this blog post.
We will continue doing this by going through the most common problems that usually are found when an organisation is doing a traditional analysis to find the root cause(s) on parts of the organisation or on the total. And it does not really matter what organisation it is, since every organisation consists of people and activities, the Systemic Problem Picture Analysis – SPPA, is therefore not only domain independent, but also context independent in its search for the root causes.
We will in this blog start with presenting the list of common organisational problems where almost all of them are symptoms, and in the coming blog posts we will go through clusters of them, since many of them correspond to the same chain of symptoms, on different closeness to the root cause(s). The important thing is that a symptom has at least two connections, that is either to the problem description, other symptom(s) or root cause(s), so every symptom is part of at least on chain of symptoms. And of course, also that all root causes have connections to either symptoms or directly the problem description.
Here is a list of common organisational problems* (where some of them already have been handled in earlier blog posts):
- Too many tasks fall between the chairs
- There are many part time resources in the projects
- The decisions are too slow
- Teams are blocking each other
- There is too low: Trust, Engagement, Motivation, Creativity, Happiness, etc.
- Information spreading is too slow and not transparent
- Difficult to predict the deliveries
- We get customer feedback too slow
- We are not innovative enough
- There are too many people solving activities
- We underestimate the complexity of the product
- We focus too little on building our products incrementally
- There are too many handovers
- There are too many and too long queues of activities
- People are stressed
- There is no end to end responsible
- Difficult to get the team velocity
- We get slower and slower for every new feature we are adding
- The resources are not T-shape enough, vertically or horizontally
- No one has the true node system responsibility
- Too much task re-scheduling
- Too much task re-starting
- Difficult to calculate the team velocity
- The customer/end user do not know what could be required
- Delay in queues to specialists
- Planned activities in waiting queues
- Too much Chinese whispers effect
- Everything is always delayed
- The projects are too expensive
- We deliver the wrong product
- We do not understand the requirement from the customer/end user
- We are not proactive enough
- Too much coordination of the work
- It is hard to grip the Big Picture
- Too many meetings
- Too many people in the projects
- People juggle with too many tasks
- Contradictory/late changes of the requirements
- etc.
As you can see in the list above, very few of these common problems are actually mapping to one of our root causes.
For a symptom we start with asking why, why, why, to see which root cause(s) we end up with. But sometimes we also need to look for symptoms up to the Problem description if the symptom is not connected directly under the Problem description. But, for making it easier, we will always start with a symptom that is directly under the problem description.
There will also be some chains of symptoms that is overlapping other chains, but they are very important, since they take care about certain organisational problems by using the same vocabulary, so we can rumble also their current sub-optimising solutions.
Of course, the symptoms will never end, but we do not write more symptoms then necessary, for example the symptom “Too many coordinators coordinating coordinators” is not needed, ;-).
As you understand we have already started with our principles and covered this one, since we have already started to dig into our organisational problems:
Principle: We need to take care about encountered product or organisational problems directly and also continually do improvements, as well as clearly understand the difference between them.
In the next blog post it is time to dig into the first chain of symptoms. Welcome.
*This is common symptoms in today’s organisations. But, since the symptoms give birth to other symptoms, the list can for sure can be made longer, be structured in another way, have different wording of the symptoms, have different symptoms, etc. The important thing is that it is very convenient to have a Prefilled Problem Picture Analysis Map to start from when analysing the problems in the organisation. If an organisational problem is found that is not in the map, most probably just by asking why one time, a connection will be found to an item on the map.