Test management in large-scale IT projects

How to minimise project risks with a realistic test concept

In many healthcare IT projects – especially large, complex projects with many participants – there is a familiar pattern:

The test phase is on the agenda, but it is repeatedly postponed, shortened or reduced in the course of the project. The official reason is often:

‘We’ll have time for that later.’

Or: ‘First we have to finish the configuration – then we’ll see.’

What appears to be a pragmatic decision is in fact a risk waiver. Because when things get tight – in terms of personnel, time or expertise – the test phase becomes even more crucial, not less important. This is especially true for large hospital projects, where not only a single departmental system is being converted, but numerous sub-areas (e.g. nursing, medicine, administration, billing) are to go live simultaneously on a specific date.

This constellation brings with it completely different requirements for test management, interface logic and project control, and requires much earlier, structured planning of the test phase. The focus here is not on isolated functional tests of individual sub-products (increments after each sprint), as is common in development projects, but on a comprehensive integration test in which processes, roles and interfaces are tested in interaction with each other.

And yet, in practice, test management is often taken seriously too late. The reasons are understandable.

The pressure in the project is high, resources are scarce, many key people are already involved in two projects, and the idea of now carrying out a structured test phase seems overwhelming to many of those involved. This is especially true when it is unclear who is testing what, how feedback is to be processed, and whether the project team even has the capacity to do so.

What is overlooked here is that: untested functions or unclear processes do not simply disappear, they are postponed. And they are postponed to the very moment when they are most difficult to fix: in live operation, under time pressure, with patients, users and reputational risk.

Why test management often falls short

There is hardly a project in which the test phase is not planned.

And yet many projects follow a similar pattern: when the schedule comes under pressure, which is the rule rather than the exception in complex IT projects, the test phase is one of the first elements to be shortened or cancelled altogether.

There are many reasons for this, most of which are organisational rather than technical:

Project fatigue

After months of intensive conceptual work, coordination and configuration, the project team is exhausted. The desire to ‘finally get it done’ often overshadows the willingness to insert another structured, resource-intensive intermediate step such as the test phase.

Resource conflicts

Many key people, especially in the technical area, have a double burden: they work on the project, but at the same time are responsible for day-to-day operations. There is often simply no time for structured testing.

Lack of role clarification

Who is responsible for test management? Who prepares the test environment? Who collects and evaluates the feedback? Without clear responsibilities, a vacuum can easily arise and the test phase becomes a vague ‘side issue’ that is not given priority.

The misconception of ‘finish first, then test’

Many project teams want to see the system ‘finished’ before they start testing. This sounds logical, but it is dangerous: it is precisely in the transition from conception to application that it becomes apparent whether processes are viable, roles are correctly thought out and interfaces are functional.

In short, the structural and psychological hurdles for the test phase are high.

And they increase the later they are scheduled.

What is often lacking is not goodwill, but a clear framework that realistically integrates test management, plans it in a resource-efficient manner and integrates it into project management.

What a test phase should really achieve

Testing in projects is often understood primarily as a technical check: Are the functions running stably? Are there any errors in the system? Are the interfaces connected correctly?

This is not wrong, but it falls short.

A well-prepared test phase not only shows whether a system works, but also how it works in a real working context and where processes, roles or dependencies reach their limits in practical application.

Especially in complex IT projects with many participants, such as in hospitals, it is only during the test phase that it becomes apparent

• whether process logics are consistent,
• whether user rights and role concepts work effectively,
• whether different departments can actually work in sync,
• and whether what was ‘functionally conceived’ in the project team is also suitable for the actual usage situation.

Figure 1: What a test phase should really achieve – Does a system work in a real work context?

The most important insights often arise not from error messages, but from queries, team discussions and moments of realisation:

• ‘Oh, so the nursing staff can’t see this content?’
• ‘If the service is documented here, it will be missing from the invoice later…’

These are not technical bugs, but structural clarifications.

And that is exactly what the test phase is for: it creates transparency about the interaction, professionally, technically and organisationally.

Above all, however, it creates something else: a common understanding. A dialogue about how things really work, beyond Excel plans and milestones.

Where processes affect people, testing becomes a social interface, and good project management means consciously designing this space. Not to make everything perfect, but to realistically identify where adjustments are still needed before things get serious.

Common misunderstandings and how to resolve them

Many problems during the testing phase arise not from a lack of willingness, but from misconceptions about how testing actually works. We encounter two examples particularly frequently:

‘Our key users don’t have time for testing.’

This statement is justified in many projects, but it is not the real problem. The question is not: Do the key users have time for testing?

Rather, it is: How is the test phase structured and how clearly is its task defined?

If tests are carried out unsystematically ‘on the side’, without briefing, without time slots, without feedback channels, then overload or frustration quickly arises, especially if feedback goes unheeded.

A well-thought-out test concept, on the other hand, provides a clear framework: What exactly should be tested? To what depth? With what goal?

This allows effective feedback to be generated even in tight time frames without overloading those involved.

This is also a common objection and highlights a structural risk:

The problem is not the feedback itself, but the lack of a system for handling it.

Without clear roles, evaluation logic and communication channels, feedback can quickly lead to chaos in a project.

This makes it all the more important to clarify the following in advance:

• Who receives feedback?
• Who evaluates it (e.g. subject-specific vs. technical)?
• How is it prioritised and documented?
• What feedback is given to the testers?

A simple, binding structure is often enough to turn a potential flood of feedback into targeted insights – and to strengthen confidence in the project process.

What a good test concept must and must not do

A good test concept is not an end in itself. It does not have to cover everything, anticipate every special constellation, or map every project logic in detail.

But it must do what really counts in everyday project work: provide orientation, create commitment, and at the same time leave room for the unexpected.

In concrete terms, this means:

Prioritisation instead of completeness

Not all processes need to be played through to the last ‘field’ in the first test run. What is important are the core processes that are used on a daily basis and the roles in which errors would have particularly serious consequences. The Pareto principle is often more helpful here than an all-encompassing approach.

Clear responsibilities and decision-making processes

Who coordinates the test phase? Who creates the scenarios? Who evaluates feedback and who decides which feedback will be implemented? Without clarifying these questions in advance, the test phase is likely to crumble or, in case of doubt, fizzle out completely.

Structured but simple feedback formats

Whether Excel lists, digital tools or a central contact person, it is crucial that feedback can be found, evaluated and prioritised. And that those involved know what happens to their feedback.

Conscious distinctions

In every project, there are functions or specialist areas that are not yet fully configured. A good concept also clearly states what is not (yet) being tested and why. This transparency is often more important than supposedly complete test coverage.

A test concept does not replace project management, but it supports it where projects become particularly vulnerable: at the interface between system logic and practical application.

And it is precisely this bridge that needs structure, time and confidence that it will work.

Conclusion: Good test management minimises project risks

Test management is not an add-on in projects. And test phases are not downstream control mechanisms. They are a central component of implementation and often the first real reality check for systems, roles, processes and project logic.

Complex projects in particular show that: What has not been tested will not automatically work; whether it works will only become apparent later. And then often at a point in time when readjustments have to be made under significantly greater pressure.

Good test management helps to avoid this situation. Not by covering all eventualities, but by creating clarity, distributing responsibility and enabling trust. Test phases are more than just a technical intermediate step. They are the moment when theory becomes reality, with all the friction, questions and uncertainties that go with it. What’s more, test phases often reveal issues for which there is no immediate solution. Those who provide structures and leave room for clarification not only guide projects through change, but also people.

Notes:

Are you interested in a detailed, tried-and-tested test concept for large-scale projects in healthcare IT? Katja Schaefer offers such a test concept as a free download in German.

Would you like to discuss test management in large-scale IT projects as a multiplier? Then share this article in your network.

Katja Schaefer has published more articles on the t2informatik Blog, including