AI and project planning - this is how it works¶
Having shown the environment in which AI algorithms work best for project management, we would like to highlight other aspects of supporting algorithms:
Algorithms turn data into information¶
The first issue is the difficulty of predicting the dimensions of future work. In the relatively simple environment of a factory or in holiday planning, this is still easy. For example, the holiday ends exactly when it is scheduled to end. The quality of the holiday plays a very subordinate role in planning. It is quite different with projects such as a new design step in mechanical engineering, the development of a computer programme or the predictability of when management will make a certain decision. It must be said that there are things that are not predictable - but one does not have to be completely blind or ignorant! We may not be able to predict exactly what the work will be, how long it will take, and therefore how much time and workload will be involved, but we can at least approximate. We don't know exactly how long it takes to develop a computer programme, but it is clear that it takes neither a minute nor 1,000 years.
So we can estimate an interval - an imprecise value for beginning, end, duration and effort. In planning, we don't say "this will take exactly 46 hours", but we estimate "30 to 60 hours". That is the interval. What is an everyday information routine for humans is not so simple for the computer, i.e. the software that is supposed to process it. There is not only one value to be calculated (46 hours), but several (30, 31, 32, 33 etc.). As a result of this inaccuracy, the dates for the end of a job, and therefore the start of the next job, will also be inaccurate in a networked schedule. So the start is not exactly on 3rd June but somewhere between 3rd June and 1st July. This leads to a dangerous combination for an AI. So the work package can start on 3rd June and last 30 days, or on 4th June or on 5th June and last 30 days, or 31 days and so on.
This way, the possible combinations multiply. If there are several dependencies in a project plan, even with other work in other projects, it can quickly lead to exponential combinatorial increases, which sooner or later are disastrous for the machine and do not help us in practice.
An example to illustrate this:
An algorithm calculates from all possible combinations whether a project is problematic or not. For example, out of 100,000 combinations it finds problems in 70,000 combinations, i.e. in 70 % of the cases. Although this is mathematically correct, it assumes that all combinations have the same probability of occurring (like rolling a dice). However, such a homogeneous distribution of probabilities does not correspond to reality. A filter is applied to the results to give a more realistic estimate of the likelihood of the possibilities occurring. This filter, which makes the algorithms' work easier, corresponds to the well-known normal distribution.
Normal distribution for project probabilities¶
The scenario described above assumes an equal probability within the estimation interval. This means that for a simple work package estimated with a duration of 5 to 10 days, each case, i.e. 5 or 6 or 7 etc., is equally likely.
In practice, however, this is not the case. The probability that it takes one minute to develop a computer program is just as small as the probability that it takes 1,000 years. The same applies to work packages. In reality, the interval endpoints of 5 days and 10 days are not very realistic. The average of 7.5 days is more likely. It is also possible that the actual duration is outside the interval, e.g. 3 days or 12 days. This could be extended almost to infinity, to the case where the work package is not executed at all (zero days), or even to eternity. However, such considerations only lead to even greater complexity and can be ignored. An exception to this are the so-called "demands", i.e. entire projects for the future on which no clear decision has yet been taken. Here the possibilities actually lie between 0 % (guaranteed not to be realised) and 100 % (guaranteed to be realised).
The normal distribution would, in our case ("5 to 10 days"), measure each interval of a work between planning (estimate) and reality (actual duration) and derive a confidence level from it. In a central computer system, all work packages that were originally recorded as 5 to 10 days would be compared and measured with the reality that occurred. It could turn out that most work packages with these parameters actually took 7.5 days. From this, we can deduce that all future 5 to 10 day packages are likely to take 7.5 days. However, it may also be that the most common case is not 7.5 days but 9 days.
Statistically, this is all logical and can be applied to comparable intervals. But is it true? Unfortunately not: it is an approximate value that is strongly influenced by the people working and their assessment of the effort required. There are people who estimate optimistically and those who tend to play it safe. The latter assume 5 to 10 days, but tell the project planner 8 to 10 days, 10 to 15 days or whatever.
The same principle applies to the planners: They like to present the staff's effort estimates as "exaggerated" and plan shorter. At some point, the employees notice this and deliberately estimate a higher value, since their target will be reduced anyway. The planned value is therefore less a purely technical or empirical value and more a human feeling.
However, modern simulation software can also handle such models. Multiple combinatorial simulation has proven to be the best. This means that each case of the interval is calculated. The method works as follows: First, the package is assumed to last 5 days, then it is tested: is there a problem - yes or no. Then everything is calculated again, this time with 6 days. And again: Is there a problem - yes or no?
Each problem found is then weighted with its probability. In our example, the problem is slightly less likely at 5 days than at 7 or 8 days. This does not give the expected duration, because that would be a coincidence, but a percentage risk between 0 % (all cases work) and 100 % (no case works). The result is information for the project management to evaluate. For example, with an assumed risk of 75 %, it can still take into account the reliability of the person, the work steps themselves and other environmental influences that the computer does not know about - and therefore cannot evaluate. Or it simply takes the risk.
In itself an ingenious solution that combines mathematics with human experience and perception. Unfortunately, the algorithm has a problem: the sheer volume of data, as the number of possible combinations grows exponentially. This is particularly noticeable in resource planning: If two work packages are planned imprecisely in parallel with the same resource, all possible combinations have to be calculated.
Let's take the following scenario as an example:
A work package starts sometime in week 23 (yes, the start of a work or project can also be imprecise) and lasts 5 to 10 days. Ms Miller is scheduled to spend 30 % of her time on this. The parallel package starts between week 23 and week 25 and lasts 4 to 6 weeks. Ms Miller is scheduled to spend 80 % of her time on this package. Can Ms Miller work on both packages?
The answer is yes: She can organise her work in these two packages in such a way that she completes both tasks on time and without being overloaded. Admittedly, I had software calculate this for me because a manual calculation would be too time-consuming. And we are only talking about two packages for one resource. Imagine a portfolio with 200 projects. They are all imprecise and whole departments are scheduled. Now the arithmetic really begins!
The remedy is a computer programme into which the planners can enter imprecise values. The computer calculates all possible combinations and uses them to determine the likely risk of a problem occurring, such as a missed deadline. Such a risk, which is determined with the help of an algorithm, can range from 0 % (nothing is guaranteed to happen) to 100 % (everything goes wrong). For estimates between 40 % and 60 %, the information obtained is not so clear for the planners. Here, either the human being or an Artificial Intelligence must continue to consider and finally decide whether it is worth intervening - or not.
Humans and their influences¶
Even if we can map the process planning and the probability and risk calculations as mathematical models and thus hand them over to an algorithm: The human impact in these scenarios should not be underestimated - this has already been pointed out many times.
All those involved in a project and its planning have their own interests, which may be different. The overriding goal, namely to realise a great project within the framework conditions, is often not the primary motivation of the people involved. Here, among other things, the error culture in the company and the experience and professionalism of the project management play an essential role. Sometimes the overall goal of the project and the benefit to the company are simply not in the minds of the project experts. And even for managers, sometimes it doesn't matter what kind of pressure employees are under on projects. They just don't want to get into trouble with higher management or other stakeholders - or simply score points with them.
Basically, there are two poles in this situation:
The higher project managers want to realise the project with as little effort, cost and time as possible. The project team members want to do their work on time, but above all in a technically correct manner and without permanent stress. This scenario and the considerations made here can be smoothed out somewhat by the use of AI. Especially important: The fact that the personal assessment of the employees can flow directly into the planning creates trust. Even if the employees cannot make a binding and exact commitment, this is taken into account in the planning. They are taken seriously.
Imprecise planning is often described as being closer to reality. This is certainly true, but above all they create a better basis of trust and professional appreciation between the actors involved. Through the identification of risks and their probabilities described above, the personal assessment of managers and staff in the current project becomes important again. If the risk is 75 %, a (good) project management will draw the employee's attention to it and ask: "Can you still do it?"
How this complex software calculates the risk is not really important for humans. It is much more important for the machine to point out a situation early on and elicit a human assessment of the people in the game. This has been proven to increase the quality of the project and the cooperation of the people.
The factory mentality of the past, in which the omniscient boss met his subordinates' unconditional obedience and willingness to perform, can no longer work. Especially not in a global economy characterised by a shortage of skilled workers. But the pure, free and relaxed life of highly qualified specialists does not correspond to reality either. The truth is probably somewhere in the middle. Which brings us back to Carl Friedrich Gauss and his normal distribution.
Risk assessment with AI¶
The interaction of the many work packages running in parallel and the cross-project risk assessment overwhelm humans. Artificial Intelligence can help here, too. The system analyses the project risk in terms of its negative implications and the level of risk. For this purpose, all conflict situations are considered and weighted both horizontally, i.e. on the time axis into the future, and vertically, i.e. ever deeper into the detailed project planning. The result is a general recommendation as to whether anything at all needs to be changed in the planning or whether the project can continue as it is for the time being.
Even if a resource is mathematically guaranteed to be overloaded, an AI can come to the recommendation to ignore the problem. Here, the AI anticipates that the people in the projects also recognize the importance of work and projects and adjust their detailed behaviour accordingly.
What was initially a large number of warnings will then be significantly fewer, with the AI recommending immediate intervention. The project management can now concentrate on these problems and is not distracted by insignificant risks. That is the main task of any AI. The AI tells you how to act.