1 Introduction: Evaluating projects in times of digital change

Full roads, constant delays due to congestion, greater risks and, unfortunately, more and more accidents: road traffic is a perfect example of what happens when too much happens at once. And now, imagine that road signs, traffic lights and speed limits exist, but every driver interprets them in their own way. “Perfect” chaos!

Project management is similarly chaotic when an understanding of the field is missing, when the agreed framework is not met, and when resources are somehow distributed without rules being observed. Pile-ups? Injured, in the sense of failed projects? Congestion, because employees cannot be in two places at once? These are foreseeable consequences.

It is all the more important to face the challenge of professionalizing project management, resource planning and administration. This is the only way to avoid projects being initiated in an unmanageable traffic situation, and a punctual and accident-free arrival at the destination being more dependent on luck than on professional competence.

This whitepaper is your project and resource traffic policeman.

2 When is a project a project?

A project is a project precisely when you define it as such, and your team understands that project management is not just a nice hobby but a serious job.

a) Goals
Project goals can vary considerably: from an order generating earnings, to an internal measure, such as the introduction of new technology requiring preparation and structured implementation. A project is, however, always initiated to change something, to move something.

Whatever the basis of the project is: as soon as a project is no longer primarily implemented with luck and team commitment, but is backed up with a defined framework, professional project competence, and commitment (and perhaps a bit of luck, too!), you are dealing with a professional form of project management. IT, for example, can be found in nearly every topic that is being initiated, and an interdisciplinary approach is required.

figure-1-en.png

b) Challenges
There are plenty of challenges for projects. For example? The co-operation between the "line", i.e., resources who perform the daily work in a company and also lay down requirements, and the "project team", which must fulfill these requirements. This leads to disputes because the line wants to see its requirements implemented, but rarely agrees that this will involve tying up their resources.

It is even worse when transparency is lacking: the double burden on the employees, delays in the work and the project, dissatisfaction in the management because planned tasks are not getting done; culminating in a big “crash” because nobody can perform their tasks fully and the project is doomed to failure.

Another reason projects are endangered is over-planning. Yes, there is such a thing! It makes no sense to plan every ToDo of the day, because "things always seem to happen when you least expect them". The micro-level - the level at which the daily work takes place - should be agile, but the macro level should be stable. If you fail to recognize this, you will sabotage your own vehicle before you can even use the road.

3 Excursus: Single and multi-project management

A project is not just a project, however, because in most cases, it is seamlessly integrated into a chain of many other projects. An overview:

a) Single project management
Single project management is about planning, implementing and monitoring all tasks within a project. The aim is to complete a single project successfully and in as risk-free a manner as possible.

b) Multi-project management
Multi-project management, in simple terms, means nothing more than that several projects being run parallel to one another and a suitable framework being made available for this purpose. This framework can, for example, be a portfolio, which, like the individual projects, must be planned, controlled and monitored so that no undesirable side effects occur. Not surprisingly, resources play a crucial role here.

Of course, there are projects that can be tackled without being formally organized. In agriculture, too, it is possible to harvest a crop that feeds one person without irrigation. But the more people who have to live from the harvest, the more likely it is that the yield from "hunting and gathering" will not be enough; and there is nevertheless a high risk that nature will find a way of disrupting your plans.

Transferred to the project landscape, this means: If you want to reap successes, you have to get out of the project jungle and into project agriculture.

4 Resource management: What’s the point?

Resource management is one of the key success factors, particularly in multi-project management, as our small excursus has shown. At this point, this can again be explained relatively simply.

Imagine that you have to plan and implement several projects in parallel, but you do not have an overview of how your most important employees, who contribute the relevant technical expertise, are already involved in other projects. Without this information, you will not be able to balance your employees, but will probably expect more from them than they can cope with. Your multi-project management will falter, as will your company success.

The fact that resource management helps also becomes clear when one thinks that there are phases in projects that are really fun, but are suddenly interrupted because something has gone wrong. The projects subsequently get the attention of the management and are assigned resources, which have been gladly removed from other projects. This might save the one project, but as a result of these ad hoc actions and relocated resources, a deficiency, and therefore the next imbalance, is created elsewhere.

figure-2-en.png

The fact that resource management helps also becomes clear when one thinks that there are phases in projects that are really fun, but are suddenly interrupted because something has gone wrong. The projects subsequently get the attention of the management and are assigned resources, which have been gladly removed from other projects. This might save the one project, but as a result of these ad hoc actions and relocated resources, a deficiency, and therefore the next imbalance, is created elsewhere.

5 The criticism: Data protection and surveillance

One of the most common reasons for the failure of resource management is the criticism by data protectionists and works councils that data on employees’ work performance is collected and therefore constitutes a form of surveillance. By every means possible, a lack of transparency is sought, which can only be harmful to projects.

However, work- time recording and its free or reserved capacities are not about discipline or performance measurement in resource management. It is rather all about planning resources better and even unburdening staff.

In the first instance, resource management records all projects, including their personnel requirements, on the basis of the respective project plans. This data is updated regularly, for example weekly or monthly.


- Reserved staff requirements: How many resources can I include in my planning and which departments do they come from?

- Planned staff requirements: When is which staff for which project required?

- Actual staff requirements: Which work has flowed into the project and has the project management and planning worked?

It is not always malicious intent or the unconditional "intention to obstruct", often it is also only a lack of understanding for project management and also a little psychology, by believing that employees have to be protected. Those on the other side of this discussion are advised to:

- Explain what is behind the collection of this data.
- Explain that it is not about people, but about projects.
- Explain that the data helps staff management.
- Explain that the performance of an individual is not measurable on the basis of working hours.
- Explain that transparency is unavoidable for successful multi-project management if you do not want to run the risk of failing.

Engage in the discussion!

6 Resource management in practice

How do you manage your resources in practice? Once again, by creating theoretical principles.

a) Company culture
Not infrequently, the introduction of resource management is also an intervention in the culture of a company. It will not be possible to build successful multi-project management if this job is made fun of within the team rather than being taken seriously. Nor will it be possible to implement resource management if there is an air of spying, surveillance, performance measurement, and, in the worst case, even disciplinary consequences.

It must be accepted that a cultural influence is inevitable, but that it is also necessary to bring about a certain cultural change. A healthy balance between the "cultivation" of project management and the "acceptance" of unplannable processes still provides the best results in this regard.

b) Framework
How many rules are necessary and what degrees of freedom are possible should be defined - it is important/imperative to define a project management framework and to create a basis for this. This includes not just resource management, but also methodology, planning, control, risk management, costs and priorities. Only if the framework conditions are right and the output of resource utilization, deadlines, profitability and risks are transferred to resource management, can projects be successfully managed.

figure-2-en.png

c) Line and project
The aforementioned contradiction between "line" and "project" should be addressed urgently in resource management. Once again, there must be a change: the line should even promote resource management so that the project succeeds, because it is precisely the line that generates requirements and therefore projects. However, a ying & yang is created, as resources are required for the implementation of the projects. And these resources also come from the staff of the line. In order to resolve this conflict or at least to present and illustrate it, resource management is needed.

figure-3-en.png

It must be clear that people who are involved in a project from the line, of course, can no longer meet 100% of their original job description. If the departments and areas or even the management are not willing to accept this, one could say: forget multi-project management, it can only fail ...

d) Micro, Macro, Overall project
"Plan only what you can control." The opponents of the resource management worry that planning will create too much work that ultimately will not lead to the goal. Here, we should again mention the macro and micro level: the daily work environment should, of course, continue to be regulated in daily communication, here additional planning actually would lead to more work and less profit.

figure-5-en.png

Strategic frameworks are also very helpful. Project requirements have to be allocated budgets, timetables and resources - so that the micro-level can then use them during implementation. This creates a small type of "quid pro quo": when the micro-level reports what it really used from the given time and the defined budget helps the resource management in the planning of the overall project landscape.

And so, almost incidentally, reporting for the management is created, giving an overview of the status of the respective project.

 

7 Summary: a tool does not make resource management

Multi-project management and resource management are mutually dependent and are, of course, much easier to implement with software. However, no tool, no matter how good, can “make” long-term resource management. It is much more important to grasp and implement the basic idea of project management. So, if you are implementing multi-project management, you should either have a mature corporate culture or build that culture. It helps if you start with simple steps and act according to your requirements and possibilities - and above all create the necessary transparency. Once again, resource management is in turn coordinated with this.

It is only when these methodological foundations are created that it makes sense to think about the introduction of a software solution even if this means allowing years for this if the company's degree of maturity demands it.