Photo by Gabriel Sollmann on Unsplash

Consciously or unconsciously?

Actually, there is nothing worse for stakeholders such as clients or customers when they do not know what is going on in the project, what the current status is, and how things are going, or a lot of things are talked up and there is no way to verify what has been achieved.

Only rarely do I see projects that are deliberately kept secret for a certain period of time. This may be chosen for restructuring projects where different scenarios are being looked at and the secrecy is to temporarily avoid unnecessary confusion and rumors in the organization. But be careful, you can't not communicate. Even there, a minimum of transparency makes sense. In many cases, more rumors arise when something is secret.

Furthermore, there are projects where transparency is deliberately kept low so that there is no supposed "external" control and external steering. Personally, I don't think that's a good idea. Because projects are not an end in themselves, but are made for clients and customers with whom trustworthy communication is to be pursued. And transparency creates trust! In the vast majority of projects, the lack of transparency is not a deliberate act, but a consequence of the complexity and hectic pace of the project; in many cases, it is also evidence of a certain time or technical overload. Transparency is not completely lacking, but is usually insufficient.

How do I create transparency?

The problem of missing or insufficient transparency is the complexity in a project. Everything is connected somehow. For example, if a required decision is not made in the project steering committee within a certain period of time, this leads to delays in the project. Delays have an impact on the availability of employees, new employees may have to replace existing ones, which leads to additional work. If no replacement is available internally, external specialists must be called in, which means additional costs for purchasing and integration, which in turn leads to additional costs in the project. Dependencies are very large in a project and can lead to a whole host of problems.

I create transparency mainly with the use of structures (also called project structure or work breakdown structures WBS). It seems to me that structures have fallen into the background, especially in the agile world, although Scrum, SAFe and Co. also apply clear structures. Structures reduce complexity and focus on a smaller topic. That is why books in libraries, for example, are not only arranged alphabetically, but also across topics. Structures can be represented hierarchically as well as in the form of matrix and networks and can be supplemented with groupings and relationships. At the same time, structures are not a division or splitting of the project, which is not possible due to the above-mentioned project-internal interdependencies and dependencies. Structures are views and assignments on the project.

I recommend not to reinvent the wheel, but to use proven references for structures. I distinguish between project management (PM) and product development. If nothing else is specified, I personally use the PM methodology PMI PMBOK Guide for the former. For many years, I have used the ten so-called Knowledge Areas as the main structure. With the latest, seventh edition of the PMBOK Guide, these Knowledge Areas together with the project phases in 2021 have been transferred into Project Performance Domains, which I like even better. These are:

• Stakeholders
• Team
• Development Approach and Life Cycle
• Planning (Planning)
• Project Work
• Delivery
• Measurement
• Uncertainty

But the old Knowledge Areas also continue to have their justification. Of course, structures from other PM methods can also be used. In addition to the proven value of a method, it gives me the certainty that I will achieve both thematic balance and completeness in the project with this structure. With a generally known method, I can assume that the stakeholders also understand and accept the structures.

In the product development process, I always use the result structure (product structure) first in the sense of WBS and then integrate the process steps/tasks. In this way, I achieve a results-oriented approach, where it is first defined what must be achieved and then how it can be achieved. Unfortunately, there are still projects that are structured the other way around according to the project development phases (e.g. design, build, test), which always leads to problems.

Basically, the applied structure itself should not be too complicated, in the spirit of Albert Einstein: "As simple as possible, but not simpler".

How do I apply these structures?

Once a suitable structure for the project has been found and implemented, the project is controlled via this structure. Only the consistent, recurring use of the structure in the project leads to the desired transparency and familiarization, and creates trust. I often observe that although structures have been implemented, they become diluted in the course of the project, new ones are added and others are omitted. This leads to a mixture of different structures, and transparency suffers as a result. I use the chosen (main) structure wherever possible throughout the project. Each structural element contains numerous substructures, which can then be adapted to specific needs. Accordingly, I plan and manage the project according to this structure, and communicate in this structure. A monthly project status report, for example, is designed exactly according to this structure. The project cockpit also receives exactly this structure.

It is advisable to check the structures after implementation and then from time to time to see whether they are really understood and accepted, and whether they still fit the project, which can also change. If so, they would have to be adapted within the methodology. But this should not happen too often and too much, because structures are a fundamental element of the project, where changes can have a big impact and confusion.

This means quite a lot of work and effort for the project manager, which unfortunately is not always perceived as such from the outside. It doesn't come naturally, and must be actively applied and maintained. But it is a very good, worthwhile investment.

Project structures always go hand in hand with project data. All project data should be aligned with the structure, i.e. assigned to the structure elements. A project management tool with a central database is very helpful here. This allows the project to have different views of the entire project and all project data at any time. When using individual documents (e.g. for costs, scheduling, resources), the generation of comprehensive views is much more time-consuming, inefficient and sometimes not even possible. Conversely, such a PM tool is much less useful if a suitable structure is not stored in the project.

Conclusion

Despite structures, there are still problems in the project and there always will be. However, with the transparency created by structures, problems can be identified at an early stage, the causes identified, and thus dealt with and solved in a sustainable manner. As mentioned, transparency in the project creates trust among stakeholders - in and around the project. Trust ensures much better and more constructive collaboration, which is also more fun for all involved and ultimately leads to better results.