Project management – classic, agile, or hybrid?

When should you use classical project management and when agile? Even years after the emergence of the agile methodology, this question apparently has not been answered across the board. According to Google, this is to this day still one of the most frequently searched topics around project management and one of the reasons why I would like to get to the bottom of this question, the associated uncertainties and possible solutions.

Overview of the classic vs. agile method

Let's start with a short overview of the differences according to the theory (these are the most important excerpts):

So much for the theory, which presents the differences pretty clearly and thus gives us a guideline as to which projects belong to each approach. Briefly, the above points can be summarized in the following chart:

But as is always the case, theory and practice are two different things. If you were to transfer the theory statically, without further abstraction, to practice, it would usually not come down clearly to classic or agile, since there are always reasons that speak for one or the other approach. Some therefore no longer consider the project on the basis of the framework conditions, which are compared above, but on the basis of the work packages, but even here there are always reasons which would have to be treated more classically or the other way around agile - according to the theory. This could then be broken down further to the activity level and so on. The decision-making difficulties, however, always continue in the end. It is therefore understandable why a clear decision for the process model can be difficult.

To illustrate this, in the next step I will show you which approaches we, as Qudits, have used and for what reasons, based on two of our projects. You will see that it often doesn't have to be black or white at all and why the work packages are actually the right level for selecting the approach.

Two different use cases in comparison

So let me give you an initial outline of two different project examples and categorize them, purely according to theory, at the top level into the respective approach.

• Example 1 – Implementation of a new law in the necessary processes and systems, taking into account the existing IT architecture
• Example 2 – Update and validation of an existing regulatory-critical application within a limited timeframe

A first categorization now looks as follows:

Based on this table and the information considered so far, the decision based on pure theory would not be absolutely clear. However, a tendency can already be read for practice: Example 1 goes in the direction of agile, while example 2 has a slight tendency toward the classic approach.

The hidden decision criterion: complexity

Purely on the basis of theory and a rough estimate of the framework conditions, we could now say:

• Example 1 is actually clear already, we do it agile, but how can the topics, which should be handled classically, be handled in the agile approach?
• Example 2 could not yet be considered so well-founded that you would really work with the classical approach, and the question here is also how would you deal with the agile topics in a classical approach?

Preliminary conclusion: Something is still missing to be able to finally decide which approach makes the most sense.

Therefore, in the next step, let's go to the level of the most important work packages, which, according to the current status, are clear for both and would therefore be processed according to the classic methodology.

Let me give you some more information about the project contents in the following:

• Example 1 – The new law deals with the handling when residential space is converted or demolished. To protect tenants, the owner must notify the relevant authorities in advance, which in turn must approve the project and the resulting rent increase.
• Example 2 – The software, which is updated, is necessary to perform submissions to authorities. These require certain templates, which are imported with the update. The validation has to be done according to GAMP 5 - category 3 (this specifies a certain order and a certain documentation effort).

For example 1, this results in the following work packages:

1. Project management
2. Technical implementation New development of the specialist application to digitally create the applications and to support the evaluation, approval and calculation of the new rent in the further course of the project Extension of the existing submission platform for the completed specialist application as well as its attachments Implementation and configuration of the new interface from the submission platform to the database Database extension
3. Organization Definition and implementation of the new roles and responsibilities Definition, implementation and training of the new business processes

For example 2 , in turn, these work packages apply:

1. Project management
2. Technical implementation Installation and configuration of the test environment Installation and configuration of the validation environment (VAL) Installation and configuration of the production environment (PRD)
3. Validation Risk analysis Installation qualifications for VAL and PRD (must be done sequentially) Performance qualifications for VAL and PRD (must be done sequentially) SNOW standard change

If we now take a closer look, we can see that the complexity of example 1 clearly speaks in favor of implementation according to the agile methodology - a specialist application has to be newly developed, which cannot happen according to the classic approach. Among other things, this also completes the considered point of changes and costs, which could not yet be clearly attributed to the classic or agile method. At the same time, the listed work packages also show that the tendency towards the classical methodology can be supported even more strongly in example 2. The work packages are manageable, the contents are known, and the sequence is predefined for both technical implementation and validation.

This shows that theory is often not sufficient in its entirety to make a practice-oriented decision. The work package level adds another important decision criterion, namely complexity. Furthermore, this is a level at which the project management is already in the initialization or planning phase, so that the approach can also be defined meaningfully at an early stage.

As already described, this could now be considered further at the level of the tasks for the respective work packages, but since this cannot be described in detail at the beginning of a project in general and would also lead too far in this article, we will retain the level of the work packages in the following.

When neither classic nor agile is the right approach ...

With that, I would like to transition to the methodologies that we as Qudits have applied to the respective projects.

In the case of example 1, a mix model of classic and agile has been applied, the so-called hybrid approach. The reasons for this result from the initial rough estimate of the framework conditions and the work packages just described. In addition, there is the predefined structure of the administration within which the project is located. It is therefore absolutely necessary that a certain sequence is observed in the project management work package, for example that the project order has been released before development of the specialist application may be started. At the same time, however, it does not make sense for the development of the specialist application to be carried out according to the classic approach, and so an agile approach, development in sprints, was used for the realization phase (implementation).

With regard to example 2, the project was actually carried out according to the classic approach. On the one hand, this is due to the regulatory requirements and, at the same time, the tendency of the initial categorization as well as the level of the work packages already showed that the reasons for the agile approach were not sufficient. Here, however, the focus on the intermediate results was nevertheless increased so that the aspect of continuous control/testing could still be taken into account.

In addition, it is important to emphasize that there is no such thing as the one hybrid approach. Instead, it should be individually tailored to the needs of the respective project. In the end, the selection of the approach is therefore not exclusively black and white, but should be applied specifically to the respective project with a focus on the respective framework conditions, the work packages, but also on the organization (Best of Both Worlds).