Depending on the project, however, neither the classic waterfall model nor the agile approach using Scrum, Kanban etc. are conducive to this planning. Why? Because both models present challenges. While a rigid framework must be adhered to in the classic approach, which is also complex due to a fixed sequence of activities, the agile approach organises itself from day to day. Agility may be well suited to software development, but corporate planning requires classic project planning, which does not break things down into every little detail.
But why not combine the best of both worlds? This paper is intended to show how companies can combine the classic and agile approach in line with multi-project management and steer numerous projects at the same time.
2 What and when? A question of perspective
Experience has shown that which model should be used when is a question of perspective, rather than of right or wrong. This knowledge has gradually become established among project managers. And what's more, some have also realised that classic and agile tools can be com- bined and projects managed better.
This only applies if you have the right expectations, however. You need to know what agile and classic methods and planning can achieve, and only expect this from them.
3 Excursus: Multi-project management
As the name suggests, multi-project management has one task: to manage several projects in parallel or to provide the framework for them. Different organisational systems are created for this purpose.
Project
It takes several departments to achieve a goal. This goal is defined by time, cost and quality requirements.
Program
All temporary individual projects and measures that work towards an objective are combined under one program.
Portfolio
A portfolio is a summary of projects and programs that help the long-term development and implementation of a corporate strategy.
Read more about multi-project management in the same-named white paper.
4 Multi-project management with the “Combined solution“
4.1 Levels and altitudes
Before you can get started, you must first define altitudes and levels in which either the classic or the agile method can be used.
In multi-project management, for example, there is initially no contact with project topics in terms of content, but rather the basis which has to be created is defined. So, first of all, you need to create the framework within which the various projects will operate.
This framework can consist of:
- Resources
- Prioritization
- Budget
- Structure
Initially, this framework has nothing to do with the project objectives, nor with the content of the project. It basically provides a “playing field” for the projects. These projects in turn provide information on economic efficiency, deadlines and risks that could jeopardise the framework. This results in a small cycle with a very high altitude.
The projects themselves, on the other hand, can be planned either roughly or in great detail. But the micro-level, i.e. the working world or daily organisation of people who implement project issues, often using agile methods, is decisive.
4.2 Know how to use the advantages of both worlds
The framework of multi-project management divides projects into programs, projects and measures according to their size and importance. A process is defined for each category, which defines how an idea can be turned into a project goal and later into a project plan.
In addition, decision-makers are appointed to ensure that only projects that have been clarified in terms of content and equipped with a valid planning and resource ceiling can be implemented.
In the actual implementation phase, these individual projects now oppose each other and are primarily focused on their own success. Each project tries to implement its objectives, but uses the same resources, creating a natural conflict that projects cannot solve. This becomes especially difficult in an agile working environment, where the idea of a stable team prevails. Classic planning does not help either, as it does not allow us to plan and control the daily changing priorities.
How can we solve this dilemma? With a combination!
How can we anchor resource assignment in planning without getting lost in details? This problem is best solved by using the advantages of the classic and agile worlds at project level and applying them in different places. So, classic management determines the framework and agile management is then responsible for the specific form.
For example, the classic layer decides who is to be made available in which projects and when. However, project planning and design are then carried out at the agile micro-level.
5 Multi-project management: Classic and agile
Multi-project management is predestined to be both classic and agile, as there are usually too many topics to be dealt with in parallel over a long period of time. If only the agile approach were used, one would in all probability lose oneself in the multitude of topics and soon come up against limits in terms of resources and budgets.
However, if we break down project specifications using a classic approach, we can give the projects a basic structure and then proceed using agile.
a) Structure
A project is broken down into phases, requirement blocks or epics. For example, Phase 1 "Analysis", Phase 2 "Conception" and Phase 3 "Realisation".
b) Prioritize
Now phases can be prioritized according to strategic aspects, and budgets and resources can be allocated. The knowledge of specific project details is not initially important; it's all about the specifications. If I know that there is rescheduling in Phase 1, it is clear that I have to take this into account in Phases 2 and 3 as well.
c) Connect and give feedback
On the basis of the recorded specifications, the micro-level, the daily working world, can now be included. It organizes itself in an agile way and collects all the information necessary for successful implementation. The sum of the efforts is then communicated back to the classic level.
In this way, a give and take is created: the micro-level is organized autonomously within the set framework, in time or requirement specifications of the classic level. It moves on sprint by sprint and reports in parallel to the classic level on work effort, capacity and progress. This information can then be used for a possible adaptation of the phases without interfering in the operational time management of the micro-level.
Important: Never get lost in mini work packages and dependencies. The classic level forms the framework, but then passes on complexity and detailed planning to the working world. This is also sufficient for safeguarding deadlines, for example. The agile world knows the specifications and framework conditions and knows that it must not devote itself to nice but unimportant details until the minimum requirements are met.
5.1 Technological framework
The procedure described also means that you can organize yourself in two different tool worlds. So, it is possible to use Blue Ant in classic planning, but the weekly, agile planning is done in the paper world and on a pin-board. The latter involves a particularly high level of commitment.
Alternatively, Blue Ant can also be used for classic planning while working in Jira Scrum. The higher level uses Blue Ant for the activities and Jira for the ToDos. This information is linked and continuously synchronized using an interface. If, for example, dates are moved within Blue Ant, the system automatically displays new end dates in Jira.
Another possibility is the combination of classic planning and the use of electronic Kanban boards for organizing work within Blue Ant. Blue Ant provides an ideal combination of activity planning and ToDo handling in a single interface.
6 Conclusion
The "combination solution" offers considerable advantages for multi-project management. The overview of the program and portfolio is maintained and the newly acquired abstractness brings calm to the otherwise restless daily work. The agile world can be sure that new requirements are not specified daily or existing time frames changed, and budgets and deadlines remain stable. The team is responsible for determining everything that changes at the micro-level: what the resource "manpower" really does is planned at the micro-level from sprint to sprint or from week to week.
In addition, the combined approach allows for improved reporting: although it is not always clear at the macro level which activities will be on the next day's micro-level agenda, this does not have to be the case. At classic level, basic topics are sufficient to determine the order of execution, resources and budgets and to monitor compliance. This is because the information on costs and expenditure is created at project level. If detailed questions should then arise as to why, for example, compliance with the deadline is at risk, the micro-level is the right port of call. Status data can be collected in real time and reflect the actual situation in the projects and therefore in the program and portfolio.
So, the classic and agile worlds are mutually beneficial: projects are managed better without anyone being restricted or overburdened by too many details.
Read it again
Download the PDF version to share or read again in your own time.