This article summarizes my experiences from many discussions with managers and corresponding insights into industrial companies. These experiences lead me to the conclusion that resource management should be weighted much higher in the context of projects than other disciplines such as quality management and risk management. Why is that?

A project manager - and the female counterparts are always included here - has the task of leading his project and achieving the targeted goals under the given framework conditions. He is held responsible for this. In order to work towards these goals, he draws up a plan of action. The methodology and tools with which he does or must do this are irrelevant here. What is central is that the project manager defines a path, sets out on this path with "his project team" and knows at all times where he stands with regard to the goal. The path can change, new conditions and contingencies can arise unplanned. The project manager must be able to deal with this, it is his responsibility. What does this mean for "his project team"?

Who is actually "the project team"?

The best project manager cannot achieve his goals without a team of employees. Probably every project, no matter how small, is carried out with the help of other participants. If the project manager could do it alone, then it is probably simply a task assigned to him and less a project - but that is a question of definition. The selection of project stakeholders is a critical aspect of any project. In somewhat technical terms, project stakeholders are human resources who, at the appropriate time, contribute to the project, bringing their expertise and network to bear on project tasks. Two simple points are essential here:

1. The resource must be available at the time.
2. The resource must have the required know-how and experience to solve the task.

In very few cases will the resources be involved for a long period of time, let alone the entire duration of the project. Even the name on the position of the project manager is not set in stone. Whether one can really speak of a project team under such aspects is therefore at least questionable.

Resources in a dynamic project plan

Projects within an organization fight among themselves for the limited resources available. And - to put it somewhat bluntly: Projects with a higher priority receive more or the better resources. Reprioritizing projects from time to time is something that today's companies do regularly. However, today's companies are bad at constantly reallocating resources to projects. Projects are often completely dynamic - and I don't mean chaotic. No matter how methodically the phase model with milestones is used, today's project managers often do not know what resources they will need in a much later phase of the project and, if they do know, whether they will get them. If a project is not handled strictly according to the waterfall model or the stage-gate process, and if it is not a project that has already been repeated several times according to scheme X, then the planning accuracy is limited to a few weeks or even only days. The further into the future you look, the more uncertain the project planning.

Agility doesn't help...

Can agile project management methods counteract the dynamic resource allocation problem? Agility in the project approach helps to readjust to changing requirements, to consciously accept such constant changes or even to take them for granted. This is exactly how software application development works today. The requirements catalog is a dynamic backlog. Requirements come and go, priorities change with every sprint. Newly developed features immediately lead to new insights for the next sprint. Does this solve the resource problem? Not really. On the contrary. Ideally, in an agile project you have a statically allocated project team. The same team of developers, requirements engineers and business analysts should ideally be and remain an integral part of the entire project. Also in agile projects the following applies: If resources change from time to time, the project manager (here: Scrum Master) has to adapt his process plan continuously. This is even more acute in agile projects.

...overview, on the other hand, does

Back to resource management: Planning upcoming project tasks without knowing whether the required resources for implementation are available at all is of little use. What is also needed is a company-wide resource overview with the current availabilities, workloads and skills of the employees. The project manager should be able to access up-to-date information at any time, even if it is only reasonably accurate. This information about resource availability does not have to be 100% accurate, otherwise we would already be in micromanagement. But it also must not be so inaccurate or even wrong that it is useless or even causes harm when relying on it. The Pareto principle helps here: 20% of the maximum possible planning effort already brings 80% of the maximum possible benefit.

A side note on this: Just the other day, during a conversation with a PM responsible in medical technology, I heard again that a project manager had forgotten to update the link from one MS Project file to another such file before his holidays. This, of course, caused the utilization of a resource in the central resource planning in the master file to be incorrect and other project managers to assume incorrect data or assumptions. A rat race of negative consequences ensued. In my experience, such and similar cases are commonplace in many organizations that use file-based planning. A resource management system that can be used throughout the company can certainly help in such cases. Availability and absence data, workloads, etc. are visible to everyone at all times and inconsistencies are thus quickly noticed or are not even possible in the first place.

Let us use our most valuable asset carefully

Why is good resource management so important? Simply because without the right people (skills!) in the right place at the right time, the project cannot be completed according to plan. The project manager has to react unnecessarily every now and then and adjust the planning (task duration, milestones,...). He already does this often enough due to uncontrollable disruptive factors or external risks. Why should he now also have to deal with problems that are home-made? With a company-wide established resource management you can save yourself a lot of trouble and friction losses. Because wasted, misused or idle resources cost an enormous amount of money: In many companies, human resources are still the most expensive production factors and will remain so for a long time to come. So let's take care of them.

Good resource management is based on two simple pillars:

• a good culture and established forms of cooperation ("that's how we do it at our company") and
• a suitable information system that makes the available data available at any time and from anywhere in a useful and simple form and ensures data integrity.

At this point I would like to refer you to our white paper Fitness Test for Enterprises: Are you using your resources optimally in your projects? which you can download here free of charge.

PS

Finally, a disclaimer: In this article, I have almost considered project employees as material resources and have looked at the topic of resource management from a very economic point of view. Of course, this leaves the psychological and interpersonal aspects of managing people in the organization and in the project completely by the wayside. These topics are just as essential in the context of good practice in project management in order to carry out projects successfully. A good team spirit in the project makes up for many a bad plan!