In times when there was no data processing as we take it for granted today - in those times man still processed the data himself, by hand. We can no longer really imagine this from today's perspective. What could that have been like? Keeping a company's accounts on paper, updating them regularly and deriving KPIs for management from them...? But in a few decades, the business world has changed radically in this respect. From management accounting (which is where the word comes from) to electronic data processing with computers. And of course this is by far not only in financial management. In all areas where data is processed, software systems are indispensable and take over an enormous amount of work that would have been impossible to do by hand in earlier times.

Automatic - what does that actually mean?

Most of us (and probably especially the reader of this article) have already grown up with computers and software systems. We naturally talk about things that "just work automatically". It is obvious to us digital natives that, for example, texts in Word documents are automatically wrapped at the end of the line (this is almost banal) or that the annual profit in the income statement is automatically calculated on the basis of income and expenses. We use the term " automatic " so casually that we are not always aware that there are sometimes complex logics and algorithms in the software systems or behind the processes, the results of which we only get to see.

According to the Duden, the word automatic means occurring by itself. In addition, there are also some definitions that are analogous. The word originally comes from the Greek term autómatos, which means something like thinking for oneself. And in relation to software, this actually still fits quite well today - especially when we are currently talking more and more about artificial intelligence (AI), which is almost a synonym for the term automatic . At least when you think about all the things that are expected from it.

If we consider what the benefit of software actually is, namely to relieve us humans of data processing, then AI is actually just the ultimate form of software: AI simply tries to automate as much data processing as possible. With AI, the computer begins to "think" for us (in the original sense of the word). To put it somewhat abstractly: We give the intelligent system an input, and it produces a useful output with lots and lots of very clever data processing. Concrete example? I'm sitting in my car at the end of the workday (this is my input), and my smartphone (my intelligent system) immediately shows me how long it will take me to get home and whether I might be better off taking a detour to avoid the traffic jam (this is then the output). In this example, I don't even have to "type in" the input anymore; the system gets it automatically based on sensor data. "I'm now connected to the car and it's evening of a workday, ergo my owner probably wants to drive home, which he usually does in this situation."

Automatic planning in resource and project management

Let's steer the discussion to our blog topic of multi-project and resource management. What can a system automate here? We are convinced that it can automate a great deal, which is what we put into practice with PQFORCE with each new release. The question in the title "Automatically? Or would you rather do it manually?" still applies. After all, not everything that can be automated should be automated. In certain situations it is obvious to everyone what the output on a given input should be, but in other situations this is far from the case. What is a "logical result for these inputs" for one person is "not so clear at all" for another.

Let's look at a simple example from project planning practice. A project manager has scheduled an activity (task) in his project and allocated resources to it. He now postpones this task (for whatever reason) by one month into the future. What happens to the utilization of the allocated resources? "Logically, of course, they also shift by this month." I think everyone agrees on that. The workload is by definition (somewhat simplified) given by the time period of the activity and the allocated time budget of the resource. No one has anything against the system automatically updating the workload, or even having to do so.

Let's make the example a little more complicated. The operation 1 to be moved is connected to another operation 2 via an end-to-start dependency. This means that operation 2 cannot start (this is the meaning of the dependency) until operation 1 has been completed. If the end of operation 1 extends beyond the start date of operation 2 due to the postponement of operation 1, what should happen? At first glance, it is again clear: operation 2 should also be moved into the future, "after all, that's why I drew in the dependency." At second glance, however, there are questions. If there is still a time buffer of 1 week between the two operations, by how much is operation 2 shifted into the future? One month? Or just 3 weeks? Here it is not so clear anymore. It depends on the preferences of the project manager and the constraints he has to follow. One wants to use such buffers exactly for such shifts, the other considers the buffer as rigid and unchangeable (for whatever reason).

And suddenly automatisms are no longer desired

Let's take the example a bit further: What if task 2 does not belong to my project 1 but to a project 2 of another project manager? Should the automatic shift then also be active? Do I know what the consequences are for project 2? And is my project manager colleague happy that his project has changed automatically without his intervention? I don't think so.

You can see from this very simple example (because the practice in multi-project management is effectively much more complex...) that automatic system actions do not always make sense for every user. The line where one should not simply automate more could be drawn or defined roughly as follows: If the solution space of possible outputs of automation is small (all respondents find "there is only one meaningful outcome"), then one can safely automate. However, as soon as the solution space becomes larger and especially when several system users are affected by the possible automation results (our two project managers above), then automation must be carefully considered. There is nothing worse than when a user action (e.g. a project manager moves a task to project 1) automatically changes data in the background that I do not see immediately and whose consequences I only notice later (e.g. the plan for project 2 has now also changed, but I only found this out much later).

Conservative use of automatisms, but sufficient indications in case of inconsistencies

When developing PQFORCE, we are extremely careful about which mechanisms we automate. Feedback from our user base and from experienced professionals in the planning business shows us very clearly that critical data changes should not always lead to automatic consequences, i.e. data adjustments. Our principle here is: It is still the trained and experienced user (project manager, etc.) who has to make the critical decisions and make the appropriate adjustments to the system data (project plans, etc.). However, the system should always point out to the human where integrity violations occur as a result of data changes. The human can then react to this with human intelligence, i.e. make and implement well-considered decisions.

We will discuss how artificial intelligence (AI) can still be extremely useful in multi-project and resource management in a later article. Stay tuned.