Good planning is ...


Planning is a very important, but also difficult activity in projects and other changes that many people find difficult. Of course there are methods and techniques, be they classic, agile or hybrid, for example 'PMI PMBOK V7 - Planning Performance Domain'. This ensures systematic, methodologically based planning, but not really good planning. That's why I don't want to repeat the theory here, but rather try to show practical aspects of good planning in a short series.

By Peter Roth, December 12, 2023



But what is planning anyway?

Planning describes the human ability or activity to mentally anticipate action steps that seem necessary to achieve a goal. [Wikipedia]

It is needed when a project is started, to find out what needs to be done, who is doing it, what is needed and to estimate what to expect. The project can be small or huge, for one person or for very large organizations. This is not just activity planning, but also planning of deliverables, budget, employees, communication, technology, etc. Ultimately, planning for a team or organization is a good communication tool for communicating and coordinating thoughts and ideas for a project, and is therefore essential for successful collaboration.

With planning we want to control and coordinate what happens in the future. But we don't know the future. We can have an idea, but we don't know exactly. There are said to be specialists who secretly have a crystal ball that can predict the future, but they are extremely rare. That's why planning for the future involves uncertainties - but also opportunities. Unforeseen events such as a pandemic, war or environmental damage can completely turn planning upside down. But even on a smaller scale, the departure of a valuable employee, a reorganization or a late delivery of a required product influences our planning. However, it is often simply a lack of information that influences planning.

You could quickly come to the conclusion that you can save yourself the planning because it keeps changing anyway. Then a team would end up in chaos. Planning reduces complexity and provides orientation, which is fundamental for collaboration. But there are big differences in planning. Many plans are not very targeted and inefficient, rigid and complicated, too little or too detailed, etc. Or simply not suitable or coordinated enough. I will try to show here which aspects need to be taken into account in order to turn average planning into good planning.

But what types of planning are there? Countless! Many people are thinking about a schedule for now. Project managers also work on a project structure plan. There are also: assembly plan, corporate plan, development plan, financial plan, flight plan, geographical plan, implementation plan, installation plan, master plan, operating plan, production plan, resource deployment plan, sales plan, strategic plan, etc.

In summary, I see the following practical features for good planning, which are described below. These are:

  • Goal-oriented
  • Purpose-oriented
  • Appropreately_detailed
  • Structured
  • Template based
  • Tool supported
  • Adaptive



Planning often involves defining the necessary tasks, putting them in an order and calculating the time required and how long it will take to complete the tasks, and that's it. Many roads lead to Rome. But if I don't know the actual destination, I'll set off and maybe end up in Milan, Naples, Vienna or New York instead of Rome. Accordingly, I have seen so many aimless plans and processes.

So far so clear. But how do I achieve goal-oriented planning? Goal-oriented planning requires two consecutive steps, a) setting a specific goal and b) determining the steps/tasks required to achieve the goal. In the first step, you should always first define what needs to be achieved, i.e. the actual goal.

1. What is my goal?

The goal can be a place, a result or an event that I want to achieve at a certain point in time. A goal always needs a certain characteristic to make it more concrete. I want to have a concept by the end of the year, but it's not enough because it's too vague. The well-known SMART approach (specific, measurable, attractive, realistic and time-bound) helps. To make a goal specific, it helps to break the goal down into subgoals and/or even deliverables and to formulate measurable requirements.

2. How do I achieve my goal?

Only then, in a second step, do I model how I get to this goal, i.e. the tasks and their order that are needed to achieve this. For larger processes, I would first break down the steps required for the goal and then plan these into tasks and activities. Personally, it seems important to me that the right questions are asked in order to achieve this goal orientation. For example:

  • ‘What needs to be done to achieve the goal?’ instead of ‘What will/do we want to do?’
  • ‘With what activities will we achieve the goal?’ instead of ‘How should we align the tasks with the goal?’
  • ‘Which tasks lead us to the goal?’ instead of ‘How do we achieve the goal with process/procedure ABC?’
In addition, goal-oriented planning also increases the efficiency of the process because all tasks are aligned to the goal, thus avoiding detours, unnecessary things and zigzags as best as possible. So we do the right thing and do it right.



Above I highlighted the aspect of goal-oriented planning. In this part I dedicate myself to purpose-oriented planning. What's the difference?

If the destination is available, we can plan the directed and efficient route there, for example if we want to go to Rome, from my home to the airport, then take the plane to Rome, and then take a taxi to the city center. This may certainly make sense for a business or city trip, even if using the train instead of the plane would be more environmentally friendly, which is why the planning could already be adjusted.

But if you want to make a pilgrimage to Rome, the proposed plan doesn't work at all. Instead, suitable hiking trails, shorter sections and overnight accommodations should be found along the way, with detours to special places.

This example shows that not only the goal (What should be achieved?) and the tasks required for it (How should the goal be achieved?) are needed, but also the purpose (What are we doing this for?). The purpose describes the meaning or motive that an action, a process or another measure should have. In the business context, the purpose describes the benefit to the business and connects strategic goals to the project. Accordingly, I recommend the purpose from the customer's perspective. of the business.

In summary, the project is ideally planned and derived in this order:

  1. Why? The purpose.
    Example: The customer should be able to open another savings account in eBanking as easily and understandably as possible. This allows us to expand the target group of older people (strategic goal).
  2. What? The goal(s) for this purpose.
    Example: A new, user-guided, understandable and easy-to-read function for opening an additional savings account in eBanking with a maximum of 5 steps will be offered in existing eBanking until April 2024.
  3. How? The steps and activities needed to achieve the goal.
    Example: Setting up an agile development team with product owners, scrum masters and engineers and including UX specialists and representatives of the target group; Defining the backlog using the design thinking process; Product development in sprints.
In this way, good purpose- and goal-oriented planning is achieved, which supports the strategy and creates added value for the business.



Many plans are either too deep or not detailed enough. However, there is no general instruction on how to do this; various factors that characterize the project must be taken into account:

  • Type - There are certain projects that require precise planning down to the last detail. This is the case, for example, when security is of great importance. On the other hand, where more creativity is to be used, greater leeway would have to be allowed.
  • Complexity (see Cynefin framework) – For simpler projects, where the process and the end result can be easily estimated, planning can be carried out in great detail. The greater the complexity of the project, the less granularity should be. A chaotic project cannot be planned.
  • Skills of the target group - If the people who are supposed to carry out the plan have low competence, more detailed planning and clear instructions must be given (for example, assembling an IKEA piece of furniture). In this case, the authority lies primarily with the planning group and less with the executors. Conversely, if the competence is primarily present among the executors (for example in a development team), more rough planning can be carried out and the implementation can be left to the experts. Too detailed planning would be counterproductive and restrictive.
  • Time frame - the closer in time the activities of a plan are, the greater the likelihood that it will apply and the more detailed it can be described; The further away you plan, the less predictable it is and the plan should be correspondingly rougher. However, as time progresses, further parts of the planning, which then become closer, must be described in more detail. A rolling plan is created.
Multi-stage planning should also be mentioned. Depending on the target group, the level of detail on the same topic should deliberately vary. This can be, for example, a rough master plan for the customers, a medium-rough planning for the management (e.g. as a basis for acceptance) and a detailed planning for the users. The biggest challenge is the consistent data consistency of the different plans. This can be avoided by not developing different, independent plans, but by showing different views of the same, detailed plan.



In order to plan a project, a meaningful structure that is adapted to the problem is very helpful. Structure includes both the structural and process organization in order to reduce complexity with predefined responsibilities and decisions [Helmut Willke, system theory].

A proven instrument is the work breakdown structure (WBS). The goal of the PSP is the structured, hierarchical representation of all activities in a project. According to DIN standard 69900, there are three types of structure (orientations) in the PSP:

  • The function-oriented structure asks about functional areas of the organization executing the project. The focus is on the type of activity to be carried out.
  • With the object-oriented structure, the focus is on the product itself. The project object is broken down into its individual components, assemblies or individual parts.
  • For a time-oriented structure, consider the process or phases of the project. These then form the subtasks or work packages of the respective level.
However, this DIN standard dates back to the 1970s and, despite being updated several times, is getting old. That's why I see the following, contemporary adjustments to the application.
  • As a starting point for the PSP, I recommend including the purpose of the project.
  • In connection with agile approaches, I would expand the object-oriented structure with the value-creation-oriented structure. This makes it possible to assign products to the value chains and thereby define their added value.
  • I would replace the function-oriented structure with a role-based approach.
In summary, the following hierarchical decomposition results in the PSP:
  1. Purpose of the project
  2. Value creation-oriented structure
  3. Object-oriented structure of the product into delivery results (goal)
  4. Time-oriented structure into tasks and work packages
It's easy to see that when I create the WBS, I always start from the top-down in order to achieve purpose- and goal-oriented planning. This can then and should also be verified and improved bottom-up.

For me, this is the ideal structure for a project that aims to deliver added value and be customer-focused. But once again, it has to adapt to the organization and the specific problem and can therefore deviate from the ideal structure with good reason.



Why keep reinventing the wheel? Numerous projects have already been carried out in more or less similar ways. This can be from your own experience, but also based on experiences within your own organization or outside, for example from universities, government specialist committees, associations or model companies.

Templates come from various sources: methods, frameworks, models, a previously used plan, a suggestion from a specialist or consultant, best practices in the department, etc. An important selection criterion is that the chosen template fits the problem and the organization as well as possible. Since a project is by definition unique, you will probably never find the perfect solution that can be applied 1:1. Most of the time it is a general standard or a concrete example and serves as a basis on which to build. When adapting the template to your own needs, you must ensure that the basic characteristics of the template are not lost.

There are at least four clear benefits to using templates:

  • Using templates can be efficient and time-saving.
  • Templates are usually proven. When it comes to methods in particular, the plans have already been applied hundreds of times, tested and improved and adapted based on the findings. This significantly increases the predictability of a project.
  • Certain templates such as methods or frameworks are more widely known. So there is a high probability that the users already know them, which increases acceptance and reduces the training effort.
  • Reusing your own plans supports your own development and maturation process.
Disadvantages of using templates include:
  • Finding suitable templates and adapting them if necessary also takes time.
  • External templates must be checked for errors and consistency.
  • You have to know and understand (learn) the selected template well in order to be able to use and adapt it appropriately.
  • It is not always possible to adapt a template sufficiently to your needs. Then compromises have to be made or the proposal has to be rejected.
Appropriate templates can significantly improve planning. I am of the opinion that when it comes to complex projects, it is always worth checking whether there are templates and applying them to the situation before developing a new plan.



Nobody will plan without a tool. At least file-based tools such as Word, Excel or PowerPoint or their counterparts from Google are used. For example, an implementation plan is described in Word, a quantity structure is shown in an Excel table and the process is recorded in a PowerPoint document. The table and graphic can then be embedded in the Word and everything can be presented in one piece. The advantages of file-based tools are popularity, simplicity and price.

An advanced type of tool support is the use of database-based applications. These store all data and their relationships with each other in a central database. From this, a wide variety of views and reports can be created online for planning in different display types such as tables, Gant charts, structure plans, network plans. When changing a value once, the new value is displayed and applied correctly in all representations.

Database-based planning tools have many possibilities...

  • Single Source of truth
  • Drill-down, Drill-up possibilities
  • Advanced filtering and sorting
  • Multi-planning with linkage and dependencies
  • Multi-tasking with viewing and editing at the same time
  • Location independence because the data can be stored separately from the presentation layer in web-based databases or entirely in the cloud. Ideal for different locations and home offices
  • Different ways of displaying the same data in tables and graphics
  • Summary in portfolios for better clarity, control and prioritization
  • Simulation with different scenarios
  • Allocation of resources with real-time impact analysis
  • Changes made can be tracked using history
… and few disadvantages
  • Costs for purchasing or using the tool
  • In addition to training for methods, specific tool training is required
  • For your own installations (on-premises), operation and maintenance, security and support must be ensured
  • Limited use for text-based, comprehensive plans, such as an implementation or functional plan
Furthermore, database-based applications are the basis for additional functions such as
  • Automation of planning based on rule templates, e.g. different coloring of tasks depending on role, priority or product, or triggering a notification for expired tasks
  • Support through artificial intelligence (AI) in planning, for example for generating a project plan, identifying the critical path or optimal resource allocation
Tool support can thus make a significant contribution to efficiency, quality and flexibility in planning and relieve the planner so that he/she can concentrate on the essentials.



Firstly, things turn out differently, and secondly, than you think. In this part I will focus on the benefits of adaptive planning. Adaptive means ‘based on adaptation; adapting; adaptable’ [Duden].

I experience again and again that a plan that has been created is treated as if it were set in stone. Once created, it cannot be changed. This is one reason why plans become outdated and ineffective. But the world is constantly changing and this must be taken into account in planning in order to be able to react to unforeseen events or changes. These can be external factors such as a reorganization, a new product or a change in regulation, or internally a budget change, a technical problem or new employees. .

Of course, the planning should not be changed every day, which would lead to chaos. If necessary, several small events can be combined into one change. But only adaptive planning ensures that the team and other stakeholders are up to date.

When it comes to adaptive planning, I see three important aspects that, in my opinion, have a supportive effect as soon as a plan has been communicated for the first time.

  1. Versioning - Each changed plan should receive its own version number. This ensures that the current version is used and that traceability is possible if necessary. The version number often distinguishes whether it is a major, minor or technical change. Troubleshooting is what is shown in the numbering (e.g. ‘1.2.5’).
  2. Change description - This describes the change compared to the previous version and includes an understandable, exact description of the change (what changed?), a justification for it (why did something change?) and the impact of the change (financial, temporal, qualitative, Etc.). Major changes usually have larger impacts, which is why they should be subject to a formal change approval process.
  3. Communication - A plan is a very effective collaboration tool. However, it must be ensured that they are all based on the current version. That is why every change must not only be documented and accessible, but also actively communicated to those affected and involved. This can be implemented, for example, at a regular status meeting.
Ideally, the change documentation is supported by the tool used. If not, a simple Excel spreadsheet for versioning, which is shared with stakeholders, is sufficient.



Good planning is …

  • … goal-oriented
  • … purpose-driven
  • … appropriately detailed
  • … structured
  • … template based
  • … tool supported
  • … adaptive
…and much more! It is therefore not a given that a good plan can be conjured up quickly. But the most important thing seems to me that a good plan is implemented!

I am happy to support you in your projects. Describe me your needs in a first discussion without any obligations. I listen carefully and show you potential approaches or different scenarios and how I can support you. I am looking forward to getting in touch with you!

Peter Roth

OMEGA IT-Consulting GmbH
Loorenstrasse 8
CH-8635 Duernten ZH
Tel. +41 55 263 20 20

© 2023 OMEGA IT-Consulting GmbH    -    Successfully since 1997