Sequential or parallel work – which is best? – part 1/6 – introduction and double speed

Today is the start of a series of blog posts that will analyse sequential and parallel work in depth.

But, how parallel is really a parallel way of working? And how about Lean production for example, is it completely sequential only? By the words sequential and parallel we can hear that they are different, but how different are they really and are there even similarities? In a couple of blog posts we need to elaborate on these different questions to get the answers.

In earlier blog posts we have found that for a Technology push market, silo organisations with a sequential waterfall way of working actually was a very good way to work. When the markets need more speed and is more uncertain, we also saw that parallel work is needed. So, as always, it depends on context.

Some years ago, when I was working at Ericsson, at a presentation the following picture was shown, regarding when projects could be finished, so we could get cash for our products.

Everybody was nodding, about how stupid it was to make like the upper example, since money for early readiness of products could be received faster for the lower project setup. I remember that it was something that bothered me, but I could not put the finger on it, since it is mathematically correct. But, now when we have our set of principles and other insights, we are ready to dig into this!

As starting point we regard the way of working in the Projects in the upper project setup as efficient.

Our first finding is that no sane organisation makes their projects take unnecessary long time on purpose. So, we cannot talk about easy and small projects, because then the organisation already would have tried with the lower project setup.

Our second finding is, as we have discussed in earlier blog post; it is not easy to run projects faster and the lower project setup will be impossible if we for example have lead times involved on the critical line as in hardware product development.

Our third finding is that we have already shown the interdependencies that we need to solve when we are running the projects in semi-parallel or in total parallel. The more people we add to try to run the project faster, the more interdependencies to solve, and the harder. This means that if the work is already fully in parallel, then we will get extreme problems as well, depending on that we already have interdependencies that are difficult to handle. And to handle more interdependencies in half time as well, is an elusive utopia.

Our fourth finding is that we do not know anything about the size of the projects, but we know that the bigger the projects are, the harder it will get. And normally the organisation already know that the project cannot be too big, so most probably, the organisation already has the right size of their projects. And we now also know from human science that if we pass Dunbar’s number of 150 people, any organisation will be harder to handle.

And if we combine the above; an already max size project already fully in parallel, we will most probably be chaotic.

When adding people to shorten the project time we will also get the effect of clogging, i.e. too many people at the same place. Clogging can appear of many different reasons and will be discussed in later blog posts.

The conclusion is that the picture was easy to draw, it was a simplistic picture when only the economic view was taken, but that reality tore it into pieces.

This was the introduction to this series of blog posts about sequential and parallel and tomorrow the question is; Can we work exactly in parallel? C u then.

Leave a Reply