We have already reached part 4 of our blog post series on resource management - and this time Thomas Schlereth leaves the project management theory to write about the work organization and planning of individual employees in practice. He concludes by explaining why "just" agile doesn't make resource planning any better.
Work organization of individuals
People do not work like machines - and in our knowledge and service society, not on a piecework basis. The employees in the companies are highly qualified and have many skills, so that they can be used in a wide variety of work.
Project management is a working method that is primarily goal-oriented. This is expressed in terms of deadlines (albeit imprecise) and quantities. Milestones in projects represent partial goals. Both conditions characterize modern project planning, as does the use of modern planning software. The people in charge have to rethink, especially the topic of micro planning has changed a lot. Just as the project management is set a goal for the entire project, this is broken down to sub-goals (i.e. milestones).
This refinement then also takes place in the work packages of the people in a project. The work to be done has a start, an end, and an assumed amount of work. And of this work, an employee has several in parallel in his personal planning. This can happen in one project, but often it can happen across projects. Furthermore, the person has non-project related work such as basic load, meetings, etc.
The detailed organization, i.e. when which work is performed and in what quantity, is the responsibility of the individual. He or she only has to comply with the framework conditions from the planning. These individuals do not prepare a detailed work plan for a week or longer. Their personal calendars do not contain the words "write a 1.5-hour concept on Monday, then talk to colleagues (30 minutes), then work through e-mails (21 minutes)," and so on. The employee works, exaggeratedly formulated, from day to day, without ideally considering the superordinate planning. He or she then sets the priorities and often also the work intensity.
The most important point for the planners, however, is: the employee must be able to do all the work, assuming good personal organization. If the employee is not able to meet the targets from the planning, no matter how she or he is organized, deviations will occur. But much worse is that if this happens more often or always, the employee no longer really believes the targets and no longer takes them seriously. He or she is running after a goal that can never be achieved.
This is then the result of a top-down disruption of the entire planning of a company. The board releases (or orders) unrealistic projects, the project manager pushes this impossible task on to the employees, who are then always behind schedule. If a project then has significant deviations or even fails, it is the project staff's fault, because they did not comply with the requirements.
Just as at the portfolio level, employees may only be utilized up to their capacity limit, perhaps slightly above. Otherwise, the planning is pointless. So project managers or line managers need to know in real time, at the moment of planning, whether the employees can do it at all. But since the employees themselves do not prepare a detailed work organization, there is a gap in predictability.
Using average values for a work package is misleading. An employee who is supposed to work on a text over the period of 5 days, but does not invest more than 20 hours in total, will not work exactly 4 hours on the text every day. If he/she had vacation on one day, the person would be shown in the software as overworked, although he/she can easily achieve the goal anyway by some own organization.
Some solutions help themselves by increasing the "flight level". This means that the system no longer looks at the workload for a week, but for a month. If the employee has an availability of 160 hours per month and is scheduled with 150 hours in total, everything works. Unfortunately, anyone who plans like this is stuck in the past of piecework. However, the work has completion dates sometime within the month. So the above example could also mean that the employee was scheduled for 150 hours in the first two weeks of the month, and not at all in the second half of the month. Project plans are not based on months or quarters, but on individual work packages that are correspondingly shorter and must also be completed on time. A periodic view of personnel utilization therefore has only limited significance.
Another popular fallback strategy of project planners is to simply plan much more roughly. Thus, many work packages are combined into one planning element and the personnel are planned on it. The more detailed work steps are only documented and the details are left to the employees. Of course, this does not change the reality at all, except that employees then not only complete parts of the project, but also plan them themselves. In this case, however, it would only be fair if part of the project management's salary went to the project staff, because they do their job ...
The detailed organization of how a person organizes parallel tasks for himself is complex and dynamic, especially since the person himself often does not know exactly what and how he is planning.
However, there is a very complex algorithm (in the planning software Can Do) that seems to be able to handle it with ease. The process has been named "Watermodel" because, like water in a basin, the work for people is dynamic and mobile. It simply simulates through all conceivable arrangements of the work within the limits. If the algorithm finds variants from the thousands of combinations that work for the employee, the system remains silent. There is no need to warn the project manager, because the employee can do it.
However, the situation is volatile: a single time feedback on a work package by the employee changes everything, and it must be simulated again whether he or she can still get organized. In larger companies, this can lead to extreme volumes, as sometimes several people are scheduled to work on one work package. Furthermore, there are simply very many packages with very many resource assignments; the number can run into the millions. Nevertheless, the software manages the calculation in real time!
To add to the enormous complexity, an additional factor must be considered. The planning objects used for this calculation are precisely not predictable, they can be inaccurate. So it is not known at all exactly when the work package will start, how long it will take or how high the work quantity will be.
Therefore, the algorithm has no choice but to combine every possibility of how a work package could run with all other variants of all other work packages. Now, out of thousands of combinations, billions are created here. The algorithm also manages this in real time. For a human, the project planner, this would be impossible. That's why planning people in projects is almost impossible for humans.
The scenario can be pushed even further if the planner's requirement is not personal planning but generic planning. This means: a team of people is assigned instead of a single person. This often occurs with long-term planning. Now the algorithm must also calculate every conceivable combination of people with each other and the respective possible work shares with Watermodel. Since this is no longer mathematically possible, unless the user is willing to wait several thousand years for the result, further algorithms are connected upstream. These first analyze the pattern situation and then control suitable dynamic algorithms that solve the problem in segments. Each of these algorithms is specialized. As a result, the result comes back in real time.
Is resource planning easier and better in the agile world?
The answer is simply no. All planning is always about who does what and when. It doesn't matter how it is organized, this fact remains the same. In the Scrum agile method, personal planning is simply delegated from project management to the team or individual. Furthermore, the planning period is shortened to a manageable horizon, i.e. sprints of 2 to 6 weeks. The problem of medium and long-term capacity planning is largely ignored. The idea behind this is simple: "Since nothing can be planned exactly anyway and everything is always different, we don't plan at all."
I believe that the justified success of Scrum is also related to the experiences in classic project planning described above. Scrum has completely different motivations and is an excellent organizational form for teams, especially in IT.
The combination of both methods, i.e. of long-term waterfall planning together with Scrum, seems to be the best of both worlds.
Outlook
I'm happy to admit it: The blog post series on resource management is quite extensive. But I also want to bring more understanding for the human factor into project management - and at the same time show how modern software with AI can get a grip on even this difficult-to-predict factor. The next and last part is about the problems that can occur in a project. And I will also draw a conclusion ...
You already want to know everything about Hybrid Project Management, Can Do and Resource Management under human aspects? Let us advise you without obligation - just contact us!
Overview of our blog post series:
- Part 1: Is this chaos really necessary? Planning of people
- Part 2: What can PM software do?
- Part 3: Types of Project planning
- Part 4: The individual in resource management (this post)
- Part 5: The evaluation of problems in projects
