The monopoly of projects

In today’s world of work, projects have become the standard means of organization for interdisciplinary collaboration. Sometimes I have the impression that many do not know any other option. In addition, the number of concurrent projects per organization has increased dramatically in recent decades. The project-per-employee-quotient today is 5-7 in the industrial sector, the peak values ​​are over 14!

I am often asked if and how to work agile in such an environment. My counter question then is how to work under such conditions at all! Six projects also mean six project meetings, six project managers and constant priority and task changes.

In the following article I would like to shed light on how working in projects has developed historically, what the current monopoly of the projects is and what alternatives exist, especially for product manufacturers, where the projects are often similar.

Product development yesterday

Working in the line organization

 

• The first wave of specialization in the industry made it natural for departments to be structured according to knowledge areas and activities, as the supervisor usually had the best knowledge of their own (example: sales, workshop, purchasing)
• These structures were also transferred to product development (example: electronics development, mechanics development)
• This had the advantage that employees who had the same activities and the same tools could learn from each other and if necessary could work from each other
• Easier work could be done so well, since the coordination was regulated by the superiors.

Note: Many organizations today still use this model and additionally use the project and the project manager to define the work, with the distribution and prioritization remaining with the group leader or each employee (at least) having two bosses, which is often referred to as a matrix organization.

Projects as an exception for complex initiatives

First projects

 

• For more complex projects, interdisciplinary projects have been introduced in which the employees were coordinated directly by a project manager.
• For projects, employees were i.d.R. turned off 100%
• The projects were exceptional cases
• Examples of early big projects:
  • Manhattan Project: Construction of the First Atomic Bomb
  • Apollo program: first flight to the moon

Today: The project as a standard organizational form

 

• Today, almost every development venture is organized as a project. There is simply no other idea of interdisciplinary collaboration
• Today’s product development processes usually dictate working in projects!
• For smaller projects, employees become project managers. This is often the only way to be promoted, except being a line management. This mainly affects organizations that do not provide a technical career path. Brilliant technicians or scientists often switch to a managerial career, where they might not be that extraordinary.
• In the case of multiple engineers from the same silo of the line organization in the project, one employee usually becomes the group leader, who then represents “his team” in the project meetings, which leads to “Chinese Whispers” and misunderstandings.

Unfavorable consequences and effects

• Everyone serves several to many projects
• The number of (project) meetings is increasing strongly → The calendars are more than full
• Employees can not sit and work with other project members → Effective communication is lost. Face-to-face communication only takes place in meetings → Too many meetings
• Employees have to decide on their own, when and how much they work for which project. Personal priorities, preferences and aversions lead in the end to project delays
• Employees serve several managers: high pressure leads to overloading of employees → lower motivation, lower willingness to perform and burn-out
• Project leaders fight against each other for employees and resources → These are utilized  and planned 100% (sometimes more!)
• The projects are strongly linked with each other: Smallest changes have a big impact (congestion) → Departments try to optimize themselves locally to supposedly do more
• Management no longer has an overview of what the organization as a whole can deliver. Since projects regularly deliver too late, too many new projects are started → management’s trust in the organization is lost → schedules are negotiated between product management and development, as the (unfortunately correct) impression arises that the development organization is too slow
• Additional “Task Forces” (even more projects!) can save individual projects, but delay all other projects even more

The arbitrariness of the project concept is a problem

Another problem is the arbitrariness of the project, i.e. the free definition:

• As projects take longer and longer, they are designed larger and larger, in the hope that the work then somehow finished faster.
• Projects get any combination of goals of multiple stakeholders. Often conflicting goals make success impossible from the beginning.
• In large development projects, it’s possible to bundle multiple product variants with widely differing benefits. Less value-adding product variants can thus be “hidden” by bundling, since projects in the project portfolio are usually prioritized as a whole.

What can we do? Break the vicious circle!

• Reorganize the organization so that most of the work can be done in stable teams again (projects are exceptions)
  • Interdisciplinary Application teams with product responsibility (Application teams, cyan in the P4 framework)
  • Module teams with component responsibility (magenta in the P4 framework)
  • Service teams for specific topics, expersises and competences (for example, when working in special laboratories, yellow in the P4 framework)
• Establishment of so called  “Communities of Practice” for the exchange of competences of members of interdisciplinary teams (training, tools, etc)
• Through transparency, make the performance of organization transparent and predictable (and of each individual team). This regains management and stakeholders confidence
• Consider product variants within development projects individually in terms of benefits and effort. Clear priorities e.g. by determining the ROI (= benefit / effort)

To project or not to project: That is the question! A guideline

Here is my checklist for deciding if a venture should be started as a new project or not:

• Is the project so unique that it justifies a separate organizational structure?
  • Project manager, own meetings, planning and reporting structure
  • Uncertainty and performance slump at the beginning due to team building phases
  • Negative influence on already running teams and projects
• Are suitable employees and resources really available in sufficient quantities? Ideal: 100%.
  Does the risk of delays due to cross-dependencies between ongoing projects increase to an acceptable extent?
• Are the cooperation models between the project partners sufficiently tested to enable relatively reliable planning? (Trust, well-rehearsed processes, …)
• Are the stakeholders sufficiently available for a separate organizational structure?

Conclusion: Working in stable teams is often the better alternative to the project

Projects are a good idea for working on special projects. But they are not always suitable for everything. Modern agile forms of organization make it possible to work in stable teams, which nevertheless facilitate interdisciplinary cooperation, where this is necessary and sensible. The hardScrum P4 framework supports that with the so-called “team flavors”.

See also “Projects don’t work in a resource limitted system“.