The New New Product Development Game article in our set of principles – part 5/5 – Wrap-up

This blog post will wrap up the elaboration on the article The New New Product Development Game [1] in our set of principles, where the first two blog posts elaborated on our set of principles, activities and people respectively.

First thing to conclude is that the article pushes on the holistic approach used by the companies. This means that the members of the project’s core team, together learn and take care of the wholeness of the product in overlapping phases, with many sub-teams making the many different parts. But, do not forget that subtle control, i.e. putting no constraints on the way of working in the projects, are a necessity for the holistic approach to work at all.

Second thing is that it is also of utterly importance that we understand what is the new parts in this holistic approach and what is the old parts for the transforming silo organisations in the article, in comparison to our principles:

  1. It does not change the size of the teams, we still have our human science and our corresponding principle to follow.
  2. But, important to understand is that the flat hierarchy is necessary, and fully achievable as the authors state, since the project hierarchy does not need to mirror the line hierarchy in a big organisation.
  3. It does not change the need of the right competence in our organisation, which is one of our principles, even though the start mix of people may need to be considered differently; regarding competence and diversity. But, do not forget that without constraints from management, the T-shaping needed will happen automatically when working in parallel to solve the project.
  4. It does not change the understanding of planning the wholeness, that silo organisations with projects and waterfall way of working always have done greatly in the ordered domains of the Cynefinframework. This means that we already have the insight of the importance of our principles about; planning of the activities, the necessity of timely Integration Events and the architecture. Remember also that Conway’s law need to be considered, which is easier followed when we have I-shaped sub-teams, as hardware companies have.
  5. But, the change regarding planning is especially that we need to keep track of the many interdependencies when working in parallel also in the ordered domains.
  6. What is definitely new for the team members is to work in parallel phases, which is a necessity for solving complex problems with speed in the beginning of the project, but also to work fast when we have the knowledge and are working in the ordered domainas, see the interdependencies above. This means that our short interactions, T-shape and working in parallel principles also will be fulfilled.
  7. Our incrementally work principle is most appropriate for software product development, but as stated before in this blog post, a hardware platform with modules can be seen as incremental work, when the modules are updated during later releases.
  8. All together, the organisation transforms to another in order to meet the market, meaning that they solve their own organisational problems on the wholeness, which is one of our principles.

The third thing to conclude, as the authors state, is that this new new product development game, can be mitigated into current line organisation; “the new approach can act as a change agent”. And that is a very important aspect, which is neither constrained by our set of principles, and having the following implication; we do not need to change the hierarchy of the line organisation, we instead need to remove the constraints put on the projects, i.e. achieve “subtle control”. And, as stated before in this blog post about the interactions principle and this blog post about the T-shape principle, it is mostly these two principles that are the tricky parts, about management feel that they lose control. Implications like this will be further elaborated on in later blog posts.

The fourth thing to conclude is how natural the organisational transfer of learning is done, and how well it also fulfils the principles. By splitting up the team members when the projects are finished, is really the only way to do it, far superior than Lessons Learned reports or any education.
Note also that the companies have hand-picked the core team for their competences and their diversity, to achieve a good dynamic in the team, so they can solve an initially uncertain task in a specific area. That means also that the next time, the team need to have another mix, since it is another task to solve, meaning another set of people. This flexibility challenges both the setup of:

  • always having static teams. Because, especially core teams, need to be interdisciplinary depending on the task. And, that is why our principle derived from human science, does not state anything about the x-shape of the core teams or sub-teams, since it can only be judged depending on the problem to solve.
  • and also that we once again need to point out the necessity of dividing the fixed line organisation and the flexible project organisations, see the details in this blog post. Because, if the line and the project are the same, the organisation is not only inflexible for different project mixes, that depends on the market need, it also makes the vital smooth transfer of knowledge within the organisation impossible.

All together it shows that more than 30 years ago, companies did new successful ways to work, and to our set of principles it is a perfect match. The comparison with Lean Product Development can also be done, see this blog post, with many similarities to the companies in the article, since the discussed development process in the article are derived from Japanese companies only.

This was all from this series of blog posts, elaborating on the article “The New New Product Development Game” and our set of principles. C u soon in a coming blog post.

 

References:
[1] Takeuchi, Hirotaka and Nonaka, Ikujiro, ”The New New Product Development Game”. Harvard Business Review, Jan 1986 issue.
Link copied 2018-09-05.
https://hbr.org/1986/01/the-new-new-product-development-game