Especially in highly regulated companies and organizations, a disproportionate amount of effort is spent on project controlling and quality management. A wide range of data is used to measure the progress of the project (measured in terms of deadlines, timeframes, costs and results etc.). Very often , I have seen project controllers enthusiastically operating with milestone trend analysis or Monte Carlo simulations. Never, really never, have I seen that this effort was experienced as helpful by the operational teams.
Controlling does not only show us facts, it also creates them
However, I have often seen that experienced project managers have used project controlling to reassure the stakeholders and avoid counterproductive interventions in the project work. At one point, I was in this role myself and, as project controller, quite deliberately took on the role of a protective shield for the project work. In the end, everyone involved was happy and for me it is still the project in which I contributed the least to the success and still received a lot of praise and recognition from all sides. Of course, I paid very close attention to making sure the project was well on track. The only thing was that I refrained from passing on problems and deviations from the planned values that arose at short notice to the client without filtering them, but instead supported the project management team in overcoming these challenges. Of course, I would have reported very well if a real threat to the project goals had occurred, but that too in the sense of supporting the project team.
Unfortunately, only a few project controllers are prepared to interpret their role in this way. This probably requires sufficient project management experience of one’s own and also courage. If something went wrong, the project controller would be left out in the cold.
An important idea for me is also that the systematics of project controlling has a decisive influence on project work.
„You get what you measure“ is known as a managerial maxim. The conclusion from this is that you have to measure everything that is important, because only then will it happen.
This is undoubtedly a correct approach. But there is another effect. From quantum physics we know that the measuring process is part of every measuring result. It makes no sense to imagine a reality (the Kantian „thing in itself“ or the „objective reality“), which would then be more or less correctly represented by a measuring process. There is no reality independent of our observation which could be compared with our perception.
Depending on how the project progress is defined and measured, priorities will be set in the project. Project management will ensure that the criteria for measuring project progress are given particular weight. The use of resources will be managed accordingly. The agile manifesto has drawn a radical conclusion: Functioning software is the key measure of project progress. In many projects, however, other results count as well or even more. Documentation, acceptance protocols, status reports, error statistics, lines of code, etc., etc. Depending on what is measured, the way a project works also changes. At the latest, when a project participant has once proudly reported what has been achieved and then had to take heavy criticism because of missing documents, the next time the team will prefer to complete the documentation and submit it for review than to further develop and stabilize the software.
The management mantra quoted at the beginning, „You get what you measure,“ is therefore correct. Depending on how I define my metrics in project controlling, how often I measure and how accurately I measure, the way a project works will change. So it’s not simply a matter of finding the right measurement method to identify the „reality“ of the project. Project controlling intervenes massively in the project, and quite deliberately. Project controlling should always have a package insert, it is a very strong medicine with possibly not desired effects.