Project management – classic, agile, or hybrid?

21. March 2023

Reading time: 7 minutes

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):

Subject area	Classic	Agile
Approach	Sequential, clear approach	Approach is planned from sprint to sprint
Deliverables	Expected especially at the end of the project	Expected after each sprint
Work packages	Definition of work packages, their dependencies and arrangement in logical order	Work packages are put together iteratively and processed within a certain time (without dependence on each other)
Risk management	Tendency to postpone milestones when the plan does not apply	Reduction of effort / scope of delivery, in case of inapplicable sprint planning
Quality management by user	Mostly only during test phase	Regular reviews / continuous testing
Organization	Project organization is mostly organized via the line and is usually active in several projects in parallel	Project organization consists of a self-organized team, which is active exclusively on this one project
Changes	Changes must first be evaluated for their impact with regard to the framework conditions and then be approved so as not to jeopardize the dependencies between the work packages	Changes are easier to manage because work packages are assembled iteratively in the sprints
Costs	High costs for late changes	Moderate costs for changes

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:

Kritische Erfolgsfaktoren bei der Initialisierung von Projekten

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:

Subject area

Example 1: New law

Example 2: Update & validation

Approach

The law is new and thus the approach for implementation is not absolutely clear

Agile

The update is performed on an annual basis, the approach is very clear

Classic

Deliverables

Expected at short intervals

Agile

Also expected in between, but definitely at the end

Classic / agile

Work packages

The work packages are largely defined and the logical sequence is clear

Classic

The work packages are defined with their dependencies and the logical sequence is clear

Classic

Risk management

Due to the defined date on which the law comes into force, potential impacts on the milestones must be mitigated by adjustments to the remaining framework conditions

Agile

Due to the regulations to be applied on a due date, potential effects on the milestones must also be cushioned by adjusting the remaining framework conditions

Agile

Quality management by user

The processes and systems must be constantly reviewed and continuously tested until they come into force

Agile

The installations on the various environments must be continuously reviewed and tested in each case

Agile

Organization

Project organization is managed via the line

Classic

Project organization is also managed via the line

Classic

Changes / costs

Every change generates costs due to programming efforts in the system, but since the necessary processes are not yet absolutely clear, new requirements are easily manageable during development

Classic / agile

Changes can be scheduled iteratively in some cases, which means that they generate hardly any additional costs because they occur infrequently and buffers are planned for (benchmarking of the last few years)

Classic / agile

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:

Project management
Technical implementation
1. 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
2. Extension of the existing submission platform for the completed specialist application as well as its attachments
3. Implementation and configuration of the new interface from the submission platform to the database
4. Database extension
Organization
1. Definition and implementation of the new roles and responsibilities
2. Definition, implementation and training of the new business processes

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

Project management
Technical implementation
1. Installation and configuration of the test environment
2. Installation and configuration of the validation environment (VAL)
3. Installation and configuration of the production environment (PRD)
Validation
1. Risk analysis
2. Installation qualifications for VAL and PRD (must be done sequentially)
3. Performance qualifications for VAL and PRD (must be done sequentially)
4. 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).

Author
Julia Heumos
Julia's consultancy focus lies on establishing effective organizations, developing high-performance teams and strengthening their results orientation. In doing so, she leads programs and projects to success and drives the digital transformation of her clients.