The value of sensible planning in project management and resource management cannot be overestimated. In the third part of our blog post series, Thomas Schlereth takes a look at the different types of planning - and why the hybrid approach is the best one for him.
The rolling planning
Can we assume that future events are more difficult to predict the further they lie in the future? Conditionally, the answer is yes. Recurring events such as Ramadan, solar eclipses or Christmas can be predicted quite accurately. But when the administrator will be finished with the installation? He usually does not know that himself.
Take a look at your electronic calendar. The planning in it follows exactly this principle. A multitude of precisely planned dates in the next few days and perhaps a few weeks. Then it becomes less and less, interrupted by exactly predictable dates like holidays. In between controllable fixed dates like vacations or the change to summer tires (but only if the weather is exactly as planned).
A principle can be derived from this: The further in the future, the less accurate. The principle can be extended by a derivation of precision: The further in the future, the less details can be planned.
From this, the planning procedure (very simplified) of rolling planning can be derived. I plan precisely in the short term and roughly in the long term (This results in a problem in resource planning which will be discussed later in this text).
Thus, detailed work packages in the near future (in a few days or weeks) are also planned in detail (but still imprecisely based on the planner's knowledge and guesswork). The longer the planning horizon, the more work is grouped together (trades, phases, epics). This summary is then extracted into more detailed work when the planner is "closer" in time.
Thus, a plan is rough at the beginning, i.e. has few planning objects, and becomes more and more detailed in the course of time. At the beginning of the project, for example, the plan consists of 10 planning objects, at the end of the project of 2,000 (real example from practice).
So there is a kind of wave of detail going on until the end of the project. This is realistic, as it corresponds to the human way of thinking. A planning does not become more realistic the more detailed it is. These huge detailed plans, some of which are made to the day over a period of years, are not based on reasonable assumptions, but often arise from the planner's fear of forgetting something. Or they are simply the result of wishful thinking. But just because something is in the plan does not guarantee that it will happen.
Agile planning
Agile planning is an extreme variant of the method described above, which is widely accepted, especially in the IT sector. Since most IT projects in the past were delayed, became more expensive and did not meet expectations, the unpredictability of such projects has been consistently assumed.
So, if a project and the work it involves are unpredictable, it is only logical to go by sight. You work from day to day or from sprint to sprint. You are finished when you are finished, whenever that is.
This method is not as bad as it sounds here, but must also be reflected critically. There are IT projects (and other projects such as the construction of airports, opera houses or train stations) that could be successfully planned and implemented. When justified criticism is levelled at these projects, we all tend to attribute this to the human error of others.
This is superficial and wrong. If you look a little closer and think a little longer, you may well come to the conclusion that these projects could very well be planned and implemented relatively accurately. Quite different influencing factors interfere with the project: It is often clear to many of those involved from the outset that the project will not go ahead as planned. But economic constraints (tenders), lack of preparation time and political influence from people with little or no qualifications make really good and realistic planning obsolete from the start.
Of course, engineers can accurately predict a project like Stuttgart 21 or Berlin Airport, at least 80% to 90%. But this would mean an extreme planning effort. Furthermore, planning would have to be carried out within certain tolerances, which, however, runs counter to other decision-makers and the classic budget planning of state and commercial companies. No contract would be awarded if the bid was between eight and 10 million euros. Instead, the contract is awarded to the lowest bidder.
Moreover, it is questionable whether such well-founded, relatively exact planning would have any benefit at all.
What is the benefit in building an airport of planning precisely in advance that this airport will cost 1.9 billion euros - when it will later cost almost seven billion? Admittedly, this margin is already enormous. A bidder who would say "We don't know that exactly, the thing will cost 3-4 billion, we'll see" would have no chance of winning a contract.
An agile approach is probably difficult to implement in airport construction. In the software industry, it is completely different and makes perfect sense.
Requirements specifications with more than 100 pages theoretically describe how a solution should finally function. This is based on several assumptions that have absolutely nothing to do with the expected reality. The small group of people who produce a requirements specification, which is then used to produce the requirements specification for the provider, believe that they can fully imagine a complex IT solution from the perspective of thousands of users. The provider also believes that these requirements are not only sensible, operable and stable, but also that they can be implemented technically. But: Not even Albert Einstein knew in 1905 exactly whether all this is true and works, what he came up with (it was true and proved later).
Therefore it is quite reasonable to only plan what can be foreseen.
A plan for a project is the assumed future, not a wishful thinking. However, this future can also include that one does not know something and simply has to try whether it works. This problem can be solved faster in the IT industry than in other projects. A software problem in an electric car can be fixed very quickly for everyone (update over the air). A fundamental design flaw in the chassis or brakes is far more costly to correct.
This is what distinguishes a cloud-based IT industry from most other industries in the "old" industrialized countries like Germany. The perfectionism sought in industries such as construction, automobiles or machinery is fundamentally anchored because such problems cannot be solved quickly, cheaply or easily there. This is why agile work has sensibly developed and established itself in the IT industry - and not in other industries. Agile work is sometimes not possible, even if the management, in order to present their own modernity, postulates this.
The way out: hybrid planning
This new approach could be a way out of this dilemma. Here, two planning techniques are combined: Classical planning is used at a coarse level, but agile planning is used in detail. Combined with the possibility of planning imprecisely even at the coarse level, we already come very close to realistic probable planning that corresponds to people's level of knowledge. This planning method sounds complicated, but in reality it is not at all. In classical long-term planning, with long-term milestones, phases and budgets, an - inaccurate - wishful thinking is formulated from a rough perspective. In detail, during the actual implementation, planning is done on sight (sprints). However, this is always within the framework of the rough planning.
Thereby the human factor is simply taken into account at different, quasi-vertical and horizontal levels of planning. At the strategic level, wishful thinking that is not unrealistic is described vaguely, for example, a project end in the 4th quarter. On the operational level, which has a high level of detail, work is planned for only two weeks (one sprint) and or somewhat longer (2 - 3 sprints). In this way, the different perspectives of the "strategic" managers and the "detail-oriented" project team members come together.
Agile work is dynamic and constantly adapts to changing knowledge and circumstances. Everything is in flux. Strategic planning has "the big picture" in mind, is strongly characterized by imprecision in planning, and assumes a far-reaching time horizon. This planning technique takes the best of both worlds and, above all, does justice to the thinking and actions of all stakeholders. However, it is probably not applicable to all project challenges. Deciding whether this method can be profitably implemented depends on the dynamics of the product or service in terms of content. Can errors and deviations be corrected quickly and with little effort in the ongoing project? For cloud-based software, the answer is yes, for a foundation for a high-rise building, rather not.
Outlook
The big picture, which was mentioned in the last section, determined this part of our blog post series on resource management. And it is precisely these resources, i.e. each individual in the project, that will be the subject of Part 4. I also want to clarify whether resource planning is easier and better in the agile world.
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 get in touch!
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 (this post
- Part 4: The individual in resource management
- Part 5: The evaluation of problems in projects
