The high cost of overhead when working in parallel

Photo by SanyamStudios

Astonishingly most companies I know work projects in parallel. This seems a good idea, because no stakeholder has to wait before his projects starts. All are a little busy.

As I've written in my free eBook 12 Things You can do to Shorten Your Lead Time, working in parallel is a terrible idea. It increases time to market substantially, sometime by several hundred percent. Working on one project after another - as proposed by Lean with its work in progress limits (WIP) - reduces time to market. Project managers will not attribute long time to market to developers not working, but to the bottleneck which is a low number of developers.

But there is something else to working in parallel. It produces a high overhead. Take a look at the figure:

Assume we have five projects going on. Each project has a biweekly or weekly status meeting. Then there will be 5 status meetings each week, and due to the longer project life time of parallel projects, we get 100 status meetings (20 weeks a 5 meetings). When work is done in serial, we have one status meeting a week (one project) for 5 months equalling 20 status meetings. Working in parallel has 5 times the overhead.

This multiplies. All stakeholders ask about the status of each project. In serial mode, when a project is not started, they won't ask about the status. After it's finished they will neither asked - obviously - about its status.

Projects must be tracked much longer, more documents are produced and must be tracked. All those status messages aggregate, flow upwards toward upper management, clog thinking and time. All those status messages flow to all stakeholders. Each increment per status update is small, much smaller than when working in serial mode.

I hope this gave you the same insights as it gave me. Start working in serial. There might be resistance, but in the long run people will see effects.

Stephan Schmidt Administrator
CTO Coach , svese
Stephan is a CTO coach. He has been a coder since the early 80s, has founded several startups and worked in small and large companies as CTO. After he sold his latest startup he took up CTO coaching. He can be found on LinkedIn or follow him in Twitter.
follow me