This is the second part of a series of blog posts regarding the way of working history.
In order to get structure of their work, the church and military organisations introduced the silo organisation. A more successful way of working, than no structure at all.
This was copied by bigger companies in the first half of the 20th century, the era of Technology Push, and each silo had their way of working, their own experts and their own Product-oriented processes. But over time, with only collaboration within each silo, this way of working become difficult. Instead more and more work cross-functional was needed in order to solve more complex problems and do more complicated products where every silo had an imported role.
In the 1950-60s, the US military had some big military ventures, where a requirement to get the contract, was to have structure, coordination and someone responsible. To meet this new need, projects* were born to comply and to have the needed cross-functionality responsibility through the whole company. The projects coordinated the silos work to get the product out on time, with quality, to the right the cost for the delivering company and the product with the right price tag for the customer.
In the projects, the sub-projects were normally mapped as the line organisation hierarchy, where a sub-project is matching its corresponding silo and the silo’s responsibility. The Subject Matter Experts, SMEs in the Line hierarchy in the first picture above in respective functional silo, normally supported many projects.
Over time in companies with projects, the silos for a product development company could have names like; Project Office, System, Design, Integration & Verification (I&V). Project Management processes was born as well, many times owned by the Project Office.
Waterfall way of working is first mentioned in the 1970s, so from the project introduction, the organisations had been continuously adaptive to find a better way of working in the projects. The waterfall way of working is normally described with phases that are executed in consecutive order. And as you can see, the phases correspond to the silos, in the same way as sub-projects correspond to the silo organisation.
By just ordering the silos and sub-projects in the way that the waterfall phases come in time, we get the following total picture.
Between the phases there is only a relationship in form of a handover, and as you can see vertically in the picture, it is a perfect match. The content of a phase is corresponding exactly to the responsibility of the sub-project. And the sub-project is in the same way exactly using the Product-oriented processes that the its silo is responsible for. The career model, bonus and salary system, the employees’ development plans, Key Performance Index (KPI’s) for the silo etc. also match. A silo will totally support all its sub-projects in the organisation’s different projects. As long as you can specify everything that you need to do from the beginning, and have spare time to redo some parts that did not work, this is the thing**. It is hard to do this better, or at least no need for more adaptiveness.
Another advantage with projects is that they are flexible compared to the rigid Line organisation, which means that any size of projects can be started, as long as the people are enough to fill the project. This flexibility is necessary, and the Strong Matrix with Projects as described above, has therefore become more popular then the static Projectized Organisations, where every silo is a project instead. The reason for this is that Projectized Organisations sub-optimizes the organization as a whole, even though the project/initiative within the Projectized Organisations are kept as a whole. Projects are like amoebas and do not fit in static constructions. The nowadays popular value stream concept is an even worse static construction, since it also sub-optimizes the product by dividing it into parts without too often consider the whole product.
As described in the last blog post, there are differences regarding complexity and uncertainty between product development in hardware and software projects, between Technology Push and Consumer Pull respectively. Therefore, they will be treated separately, since the differences are very important to understand before we put them together again when heading for our set of principles. The Cynefin™ framework will be our guide for understanding these differences.
C u soon again.
*the research needed for all hardware development is not part of a project. Research is highly explorative, normally disciplinary. This high complexity makes it not suitable for projects, due to it is impossible to state what will be found and when. Throught the System Collaboration blog book, research will be treated separately and not within projects.
**the architecture actually also maps into this perfect match, meaning that Conway’s law is followed to a full extent, giving no expected detoriation of the architecture, see this blog post for more information, where also the hierarchical structure of the line and projects normally also follow the numbers team number 15 and the team of teams number 150 from human science, which you also can read about in the same blog post.
Note! When the architecture is set, it is much easier to get an architectural detoriation in software, since changes in the hardware architecture is clearly visible, a bad solution is also expensive and a bad solution is not even possible to do. A bad solution in hardware is also clearly visible to the customer.
References
– [1] https://en.wikipedia.org/wiki/Waterfall_model
– 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.