This is the third part of a series of blog posts regarding the way of working history.
So, what could possibly go wrong in this era of Technology Push with this perfect match between silo organisation, project organisation, processes and waterfall project phases, shaped over time? Since we already have the needed cross-functionality and coordination within the projects. In fact very little was needed, so when the market demand for speed increased many companies started to run into problems. The so far successful waterfall way of working in a silo organisation setup had difficulties to meet the needed speed.
But how can an organisation with hardware projects work faster? There are some options (sub-project will be synonymous with phase):
1. Work more efficient in respective phase to shorter them. This can be done to some extent if some waste is found, with for example Value Stream Mapping that is explored in this blog post, that only regards the phase itself. But, many times this removed ‘waste’ is used by later phases, which only will lead to a sub-optimisation of the total and coming phases will then suffer tremendously.
2. Make the preparations and pre-studies shorter and start with the project as soon as possible. Once again this is only another way of sub-optimising of the total, and the project is badly prepared when starting, which will lead to more suffering.
3. A third alternative is to put the pre-development inside the project, which means putting also complexity in the project, leading to even more uncertainty and makes it impossible to plan the project or be able to come up with an finish date.
Here is a picture of the above scenarios.
This can be fully understood in the view of the Funnel Curve or Cone of Uncertainty [1] [2], since all three alternatives will lead to more uncertainty, and with the pre-development within the project also a lot of complexity is added:
The curve shows only best case scenario, it is easily possible to do worse. With the data from success of early hardware projects we had the following: A factor 0,5x to 2x for engineering and construction in the chemical industry, reported by Bauman 1958 [1]. My own experience as a hardware project leader during 20 years, is that the estimate variancy for big hardware projects with mechanics, electronics, etc., derived from many different companies, is much lower than reported above. The key is to leave pre-development outside the project, since pre-development must always be an on-going activity parallel in hardware product development, and only put in a project when enough technology maturity has been reached. Another way is with multiple concepts, which Toyota practiced for decades, which makes it possible to have a pre-development concept in an on-going project, as long as there are safe/safer concept in parallel. This is further elaborated in this blog post.
4. Put the project phases more in parallel, which sounds easier then it is.
The first three options are doomed to fail and their combination as well, they are more like cheating oneself. Regarding the last one, number 4, we can quote the famous words of Dr. William Edwards Deming:
Everyone is already doing their best; the problems are with the system … only management can change the system.
This famous quote is from the time when the American industry started to decline after the oil crisis 1973. This according to Deming, was due to the lack of quality, which he blamed on the management’s lack of respect for the worker and not taking care of the knowledge of the workers. Dr. Ackoff is talking about the same tema [3]; management with self-appointed knowledge of omniscience. The higher up in the management hierarchy, the less knowledge of the work, but the more omniscience knowledge is shown.
And if management change the system, it must be to a system showing respect for the workers, where Toyota’s value Respect for people has been one of the pillars in The Toyota Way together with Continuous improvement*, for more then half a century. And this respect is not only within the team, but also within the total system, which is more valid in the context of product development with many interdependencies and interactions between teams, contrary the context of production or service which is more of dependencies and actions between teams. This means that when the respect stops at the team level in product development, a team will only make continuous improvements* within themselves, which is sub-optimisation. And when many teams do this at the same time, it will due to the complexity of an organisation, only cause what Dr. Ackoff would have referred to as; a system of problems – a mess [4].
And the work in parallel is really meaning a change of the system, a change of the way of working from consecutive phases to parallel phases where the phases have interrelationships. And this is a big change since it is not an add-on to the current silo organisation thinking which so far only can handle silos doing parallel work without interrelationships. This requires a completely new thinking to take care about the interrelationships between the silos, and new thinking is hard, very hard. Quoting Einstein,
Without changing our patterns of thought, we will not be able to solve the problems we created with our current patterns of thought.
Albert Einstein
since it is very apt. Working in parallel means that the phases will look like this instead with semi-parallel phases.
When working in parallel, not only a relationship between the different phases is needed, now also interrelationships are needed between the phases continuously as stated above. If we put everything together, the total will look like this.
And as shown above, the processes do not support these interrelationships. So, without changing the way of working in the Product-oriented and the Project Management processes, the project execution with processes only supporting sequential phases is very difficult. But a warning here: interrelationships can neither be specified between whom nor when in time, meaning that the processes can never be too detailed, so more detailed processes is not the way to go.
At about the same time as the market required speed, software projects emerged in product development. But, software projects at that time very fast run into very big problems, that cannot only be referred to as being unable to meet the needed speed. This will be handled in the next blog post. C u then.
*remember that on the whole only continually improvements can be done, due to the synchronisation needed between the parts when the respective part’s improvements are executed at the same time, for example takt time change. The parts can (and must) themselves be continuously improved, as long as they do not affect another part.
References:
[1] Boehm, Barry. The Funnel Curve. The Cone of Uncertainty.
Link copied 2019-01-18.
https://en.wikipedia.org/wiki/Cone_of_Uncertainty
[2] McConnell, Steve. The Cone of Uncertainty. Link copied 2019-01-18.
https://en.wikipedia.org/wiki/Steve_McConnell
[3] Ackoff, Russell Lincoln. Article. Link copied 2018-12-15.
https://thesystemsthinker.com/a-lifetime-of-systems-thinking/
[4] Ackoff, Dr. Russell Lincoln. Speech. “Systems-Based Improvement, Pt 2.”, Lecture given at the College of Business Administration at the University of Cincinnati on May 2, 1995. At 12:50 min.
Link copied 2019-03-18.
https://www.youtube.com/watch?v=k8g6ZoobDV4