Projects are more than just frameworks – Part 1
How to avoid fallacies and increase the chance of project success
Along with digitization, almost all companies have switched to an agile approach. Better effectiveness and product focus should significantly increase the chance of project success. Being significantly scaled up means that agility is not a panacea, just a framework. There are challenges that cannot be solved with it.
This article aims to show some important problems and challenges in the project environment and explains how you can recognize them in good time and the causes and not just symptoms can counteract.
1. Good structures and low dependencies are the basis for project success
Find numerous Studies and experts prove that organizational structures and dependencies is the central basis for efficient and effective project work. Even the most experienced and talented project team cannot develop their knowledge and skills if the project environment is not right. But what exactly is meant by project environment?
The project environment includes both external and internal structures and dependencies.
The project-external dependencies are often PESTLE abbreviated:
and appear primarily in project risk management⁴.
Project-external structures are shaped by the market or the company and are reflected, for example, in the organization chart/silos, organizational program/portfolio structure or specifications, technical guidelines, the IT infrastructure or tools including authorization structures. They lead to higher complexity and often represent an effort multiplier!
For example, in the age of digitization, an outdated IT infrastructure leads to intensive testing and long release cycles or processes and thus to symptomatically high change costs and poor market adaptability. Companies that want to remain competitive strategically and in the long term work continuously on the Reduction of dependencies, simplification and transparency of structures.
Project internal dependencies
Project-internal dependencies and structures can be influenced in the project at short notice. However, the distinction between the types of dependencies is often forgotten here, such as whether they logistic or logical dependencies are.
Logistic dependencies can be managed with the Customization of resources managed, such as an additional workstation, new hardware, etc., while logical dependencies lead to a critical path in the project.
With regard to project employees, Brook's law "adding manpower to a late project, makes it later" comes into force. In projects, when time is running out, a new resource is often brought into the project (because it is identified for a logistical and non-logical dependency) so that the milestone can still be reached. It is often forgotten that the new employee, depending on the project complexity, history and technical knowledge, first has to familiarize himself with the team for a long time. Since the team helps with the induction and falls back into a team-finding phase, it is not unlikely that the project team will initially be slower in the first 2-3 months with the new project member.
If bad and non-transparent structures as well as unclear dependencies prevail in the project environment, then one often finds the following indicators and symptoms:
- Inefficient processes because processes always adapt to the structures
So lean processes only exist with lean structures.
- “Culture eats strategy for breakfast” was already emphasized by Peter Drucker. Organizational structures are part of the corporate and project culture and if they appear bureaucratic, then changes can only be established very slowly.
Conventional and agile projects are subject to company structures and dependencies. It is therefore recommended that the projects/products and their procedures are formed in context and that the structures are reviewed.
2. Team dynamics can be progress catalysts
By 1977, Bruce Tuckmann introduced the team development model⁵. Even if that was a while ago, the model is mentioned in frameworks such as PMI or Scrum, but has limited application there. For example, in the 'forming phase' more daily and overarching meetings and in the 'Norming and performing phase' only problem-specific coordination between specialists is actually necessary. Leadership strategies and success factors so that teams can get into the popular and efficient 'performing phase' as quickly as possible were developed by Scott Graffius and updated in January 2021.
Project rule meetings, like steering committees that are planned at a fixed rhythm, are not questioned at this point. Why not? If Elon Musk is already calling on his employees not to go to meetings in which they do not provide any added value, then one should rather hesitate oneself. Does it even make sense to set up a regular meeting if the team is performing well and there are no problems for the entire group of participants?
The Tuckmann model is also only a simplification of reality, but shows tendencies. Experience has shown that team members are heterogeneous and if an important member leaves the project, it can result in the team or part of it going into the 'storming phase' falls back. The team is therefore no longer as efficient as before and this should be taken into account in planning.
My advice: Especially now (hopefully) after the corona pandemic, you should invest a lot in team events and cooperation so that the team can get into the performing phase in a stable and better way.
Further information and sources:
- AXELOS, MOP certification, Table 7.6 "Key challenges and sample solutions for managing dependencies"
- Ahn, H., Dyckhoff, H., Organizational Effectiveness and Efficiency, in: WiSt 1/1997, p. 2 ff.