The way of working history – part 1/5 – an overview

This is the first blog post about the way of working history,  a series of blog posts that really will dissect why the organisations and their different way of working emerged, their need to adapt to a changing environment.

The line organisation with functional departments, silos, is very old and has always existed in the military and church organisations and then only the top management has control over the total.

The silo structure, can be seen as an organisation with guilds, and people commonly like to belong to a group with the same skills. There are also benefits with this form of organisation, since they can learn from each other and have a manager responsible for a certain type of skills needed in the company long-term. The different managers have responsibility for different competences, and these different competences will over time change in numbers per competence, as well as emerge in new competences and the need of completely new competences, all depending on the market need.

In the first half of the 20th century, the companies were getting bigger and bigger and the line organisation started to follow the military and church organisations using the silo structure.
The silos are working independently of each other, each silo with each its own silo dependent processes, i.e. Product-oriented processes. The interactions between the silos are few and can be handled, even though there is no person actually handling the total.

Over time it gets more and more problematic to keep the wholeness together, with increasing interactions and interdependencies; coordination, communication, systemisation, architecture, responsibility, innovations, etc. The silos depend more and more on each other to make the company’s deliverables. So, in the 1950-60s, projects are born due to big US military orders, where not only the US military required structure and someone responsible, but also a need of cross-functionality to be successful. Together with the projects; project office, system, design, verification and production silos are introduced as well. After some years, the projects are normally using the waterfall way of working and Project Management processes are born as well, many times owned by the Project Office.

In the car industry Ford is very successful and becomes the role model for success. Since the Japanese market was very different from the American after second world war, Toyota decided already 1950 that imitate Ford was dangerous [1, page 24]. Especially for the Japanese market all kinds of resources are scarce, and therefore needs another way of working. The beginning of the Toyota Production System, or what outside Toyota is called Lean Production and Lean Product Development starts.

In 1973 as a result of the oil crisis, the high-grade growth market (double digit) in the car industry stops*. In the end of the 70s Ford as the role model in the car industry definitely stops and Toyota gradually takes over. But, Ford is continuously the role model for most other industries and still today.

During the 1980s quality thinking and modelling (by processes) tries to move the project knowledge forward, but only to some extent successfully. Software projects have hard times to keep the time, cost and quality with the waterfall way of working.

Next decade the hierarchical barriers for doing only single projects start to be teared down. The Scandinavian companies are in the front line, understanding the power of multi-project enterprises, and many of them start to build multi-project organisations.
Time becomes in focus, sequential phases too slow for HW projects as well, but not a problem yet, and almost all organisations are using projects in one form or another.

Companies started from now and on, especially in the Software community, avoids silo thinking. The waterfall way of working originating from hardware development with Technology Push, does not map very well to software development with Consumer Pull, along with the degree of freedoom regarding the actual software solution, both on the whole and on the parts.
Note! Do not mix Technology Push with a push system or mass production regarding the actual product development or production. Technology Push means that a company has made an innovation that the market is total unaware about, but that the company thinks that the market wants and therefor makes the needed product development and produces the new product to sell to the market. The actual product development within a project is normally done in a Just-In-Time (JIT) manner, since planning of all activities have been done, see this blog post for an elaboration. The actual production for a Technology Push product, can still be done with a JIT system as well.

In the 2000s multiproject organisations are needed all over the world, the companies cannot drive one project at a time anymore. Time is totally in focus pressing the projects to have more and more parallel phases. Adaptability towards the market starts to be a success factor as well.

2001 – The Software community makes the Manifesto for Agile Software Development. The Agile development now really starts.

2010s – Strategy is needed in the projects, development by itself is not good enough. The market now requires adaptability to be added to speed already required. Some HW companies tries to transform to Lean Product Development, but few of them are successful. The success rate for the production industry to transform to Lean production is somewhat higher and has been ongoing for two decades.

Right now, there is a transformation wave rolling around the world, changing the waterfall way of working to Agile way of working for SW product development, and in other domains as well.

This was just a short overview over the way of working history, to give some more understanding for the coming blog posts. They will investigate thoroughly what so commonly happened with the way of working in many organisations under the pressure of market changes.


*In US, the US car industry at this time had no global competitors and could be stated to be the Apex Predator [2] [3], only going for making more cars due to the unexceptional market, leaving the quality issues for the future. And the US market itself was hungry and wanted new models with new technology and did not care much for quality either. So, when Japanese cars with higher quality started to be sold on the later scarce US market, the US car manufacturers stod their perplexed over the new situation, which took decades to reverse in order to achieve Lean production, with reasons that Dr. Edwards Deming unerringly stated in one of his quotes;”American management thinks that they can just copy from Japan—but they don’t know what to copy!” [4]. The strongly divided markets after the second world war with a very strong US market and a very weak Japaneses market was the major reason for this situation, This led to an enormous time span of many decades between the new eco system (Lean production) started in Japan, totally necessary due to the weak market, and the competence induced failure point when Japanese cars started to be sold in US and its car industry could react.


[1] Monden, Yasuhiro. 2012. Toyota Production System: an integrated approach to just-in-time Fourth Edition, CRC Press, Boca Raton, Florida, US
Page 8, misspell; it is shojinka, and not stotinka.

[2] Wikipedia. Apex predator. Link copied 2019-08-05.

[3] Snowden, Dave. Blog post. Link copied 2019-08-05.

[4] Deming, Dr. W Edwards. Quote from 1980. Link copied 2019-08-05.

– Monden, Yasuhiro. 2012. Toyota Production System: an integrated approach to just-in-time Fourth Edition, CRC Press, Boca Raton, Florida, USA.

– PMI. 2013. A Guide to the Project Management of Knowledge (PMBOK Guide) Fifth Edition, PMI, Pennsylvania, USA.

– Poppendieck, Mary and Tom. 2010. Leading Lean Software Development – Results are not the Point (chapter 2). Addison-Wesley, USA.

– Wenell Management AB. 1998. “Projektledarskolan; Projekt!”, Wenell Management AB, Stockholm.