Why are projects no longer working in our product development organizations today? And why did they work for such a long time?
There are certainly many reasons for this, but in my opinion these can be traced back to one main cause: Today’s development organizations usually work not only at the limit, but above the limit of their capacity. Again, there are several reasons for this:
- Product development organizations have been through many optimization and streamlining initiatives over the past 30 years that have reduced organizations’ capabilities to a bare minimum. This is the result of misinterpreting Lean. Now, resource reserves have fallen, if not disappeared.
- Development projects have become more complex, which has increased the need for interdisciplinarity and communication. However, as the organizational structures were often not changed in the direction of interdisciplinary groups and departments, and since the interdisciplinarity today takes exclusively place in the projects, huge amounts of the project work consists of coordinating meetings, which further reduces the net capacity.
- The lack of transparency about the required capacities and the pressure to start more and more projects leads to each employee working in several projects, which requires many “task changes” and leads to further reductions of the net capacity.
So, what shall we do?
- Accept that the organization works on its limit. It must be clear …
- it is not sufficient that the mere definition of just another project with the allocation of a few percent of each project member and the setting of an ambitious (if not impossible) target date;
- that the organization can’t work on all projects and ideas proposed. NO is a valid answer;
- that the organization works most effectively and efficiently when only a few projects are executed simultaneously;
- Gain transparency about the real performance of the development organization. The pure sum of developer hours says nothing about the performance of the organization.
- The formation of stable and self-organized teams with a storage of work packages (the so-called Team Backlog) is a gaint leap.
- The teams estimate their work packages themselves and work them out in a regular rhythm of Iterations. This results in a predictable team speed almost automatically.
- Prioritize for the highest possible Benefit and lowest Effort (Prio = Benefit / Effort). This has the great advantage that we can even increase the gain of adding Benefit compared to earlier by a clever selection!
- Stop forming new project teams again and again. Projects are assigned to the stable teams according to the following two criteria:
- Suitability of the team: The project is prioritized within the Backlog of the most appropriate team, the team with the most appropriate skills and experience
- Team workload: If several teams are suitable, the project is prioritized in the Backlog of the team where the shortest time-to-deliver is expected
- All new teams need time to gain effectiveness and efficiency (the four Tuckman phases of team building). This applies to project teams as well as newly formed stable teams.
- The stability of teams requires that the teams were formed so that the projects fit to the teams. Since this is certainly not always guaranteed, the teams have to develop a certain degree of flexibility. This too takes time.
- Big projects do not need just one but several teams. This can be countered by the introduction of scaling frameworks, e.g. the Scaled Agile Framework for software development or the P4-Dev Framework for the development of physical products and systems.
See also: The monopoly of projects.
[Photo: “Beijing highway traffic jam” on china.org.cn]