The continuation of filling in the Prefilled Problem Picture Analysis Map – part 3/10 – Too much coordinating work

In today’s blog post we will start to look into the common symptom; “Too much coordinating work”. This means that we are wasting our people on doing too much coordination of the work, which the customer will never pay for.

Asking why many times on “Too much coordinating work” gives these three symptoms on the same level.

  • Task re-starting and Task re-scheduling. These two symptoms are mostly on Too individual basis and depends on too many activities to take care of, and too little time. This can also involve small activities sent on email, that need to be taken care of.
    The nightmare scenario is when we need to start to coordinate ourselves with long to do lists, different email-folders, different document-folders, etc., since it is impossible to keep everything in our heads. This will also lead to a longer lead time for the activities, meaning that more activities will come into the loop, and we need are interrupted with the current activity, since we need to re-schedule again. Then we forget all about the interrupted activity, and when we continue with it, we need to make a full re-start, because we forgot what we have done or read.
    The more this continues the more waste we generate, and in the end we do not do any real work for the customer, we only restarting and re-scheduling our tasks, and manage to-do-lists, which we soon need to categorise because it has too many items, etc.
  • “Too many coordinators” is a real waste, since the coordinators many times, put +90% of their time coordinating other people or aggregating others work to a report and add very little value for the customer. The coordinators can exist also in the line, but is more prominent in the projects, and the bigger the organisation, the more project coordinators. And many times, they do not have the name coordinator, especially in an Agile organisation based on too prescriptive agile scaling frameworks, which makes it even more treacherous. And asking why on this symptom gives the symptom “Too high hierarchies in the projects”.

If we put the symptoms achieved so far in a picture structured like the Prefilled Problem Picture Analysis Map, it will look like this.


We continue to ask why, and if we do that on the two first symptoms above, we get symptom “Too many people in queues to solve activities”, which is once again an old friend from the series of blog posts about Organisational Clogging, ending up in two root causes.

And when finally asking why on the symptom “Too high hierarchies in the projects” we get the root cause “Not following the social numbers”. A part of the Prefilled Problem Picture Analysis Map with the chain of symptoms for “Too much coordinating work” will then look like this:


This was all for this blog post, and in the next blog post in this series we continue with the next symptom, “Contradictory/late requirement changes”. C u then.