Advisory & Coaching Implementation & Control Review & Assessment As an external project specialist, customers ask me to support when something is already wrong in a project or program. More and more serious problems appear out of nowhere and nobody knows what the cause is.
Measures taken do not have the desired effect. Time is running, costs are exploding. There is a lack of transparency in the project.
By Peter Roth, June 28, 2022
Photo by Gabriel Sollmann on Unsplash
Actually, there is nothing worse for interest groups such as sponsors or customers if they do not know what is going on in the project, what the current status is and how it will continue, or if there is a lot of nice talk but there is no possibility of verifying what really has been achieved.
Only rarely do I experience projects that are deliberately kept secret for a certain period of time.
This can be chosen for restructuring projects where different scenarios are being looked at and the purpose of secrecy is to temporarily avoid unnecessary confusion and rumors in the organization.
But be careful, you cannot not communicate. Here, too, a minimum of transparency makes sense. There are often more rumors when something is secret.
There are also projects where transparency is deliberately kept low, so that it is not supposedly controlled and controlled from "outside".
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 done.
And transparency creates trust! In the vast majority of projects, the lack of transparency is not a conscious act, but a consequence of the complexity and hectic pace of the project. Usually, transparency is not entirely lacking but insufficient.
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 within a certain period in the project steering committee, 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 (e.g. onboarding and group dynamics).
If no replacement is available internally, external specialists must be called in, which means additional expenditure for purchasing and for integration, which in turn leads to additional costs in the project.
Dependencies are very large in a project and can lead to a rat tail 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 faded into the background, especially in the agile world, although Scrum, SAFe and Co. also use clear structures.
Structures and processes reduces complexity (Helmut Willke, Systemic Basics and Interventions) and focus on a smaller topics. For this reason, books in libraries, for example, are not only arranged alphabetically, but also according to subject.
Structures can be represented hierarchically as well as in the form of a matrix and networks and supplemented with groupings and relationships.
Structures are not a division or splitting of the project, which is not possible due to the project-internal belonging and dependencies mentioned above. Structures are perspectives and assignments to the project.
I recommend not reinventing the wheel but using proven references for structures. I differentiate between project management (PM) and product development.
Unless otherwise 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 in 2021, these knowledge areas were transferred together with the project phases into project performance domains, which I like even better. These are:
If a suitable structure for the project was initially found and implemented, the project is controlled via this structure.
Only the consistent, recurring application 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, these become watered down over the course of the project, new ones are added, and others are left out.
This leads to a mixture of different structures, which reduces the transparency. Wherever possible, I use the selected (main) structure throughout the project.
Each structural element contains numerous substructures, which can then be adapted to specific needs. I plan and control 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 has 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.
Then they would have to be adjusted within the methodology. This should not happen too often and too much, however, as structures are a fundamental element of the project where changes can have major implications and can create confusion.
That means quite a lot of work and effort for the project manager, which unfortunately is not always perceived as such from the outside. This does not come by itself and must be actively applied and maintained. But this is a very good, worthwhile investment.
Project structures always go hand in hand with the project data. All project data should be aligned with the structure, i.e. assigned to the structural elements. A project management tool with a central database is very helpful.
This allows the project to provide 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 complex, less efficient and sometimes not even possible. Conversely, such a PM tool is of much less use if a suitable structure is not stored in the project.
Despite structures, there are still problems in the project and there always will be. With the transparency created by structures, however, problems can be identified at an early stage, the causes determined and thus treated and solved in the long term. As mentioned, transparency in the project creates trust among the interest groups - in and around the project. Trust ensures a much better and more constructive cooperation, which is also more fun for everyone involved and ultimately leads to better results.