Results in IT projects. What should you deliver and why

In the previous blog in this series, we focused on objective. There, we explained the difference between the why of the change and the what that a project or program must concretely deliver.

In this blog, the fifth element of the Quilyx VERDER method takes center stage: result.

If the objective gives direction to the change, then results make that change concrete. Results are the tangible outcomes of a project or program. They show what is actually being delivered and what can be steered on.

At the same time, defining the right results is less obvious than it may seem. How do you define results that truly contribute to the objective. And how do you deal with results that may seem useful, but do not contribute directly.

Results are not just loose deliverables

A result is not simply something that is done or delivered within a project. A result is a concrete outcome that must demonstrably contribute to the objective of the project or program. That is an important distinction.

Projects always contain many activities. Analyses are performed, sessions are organized, documents are written, and decisions are prepared. But not everything a project does is automatically a result in the sense that matters for steering. A result must have meaning in relation to the objective.

That is exactly why it is important to keep objective and result connected. Not by first creating a long list of deliverables and only afterward trying to connect them to an objective, but by reasoning from the objective toward the results needed to support it.

The objective determines which results are relevant

That becomes especially clear in large-scale change programs.

In a major change to a collaboration platform, the objective was to reduce security risk by moving collaboration functions to target systems that were fit for purpose and supported by the vendor. Within that objective, one of the logical results was the development of a target architecture. That target architecture made clear which functionality should move to which target system. That result directly contributed to the objective. It helped make the intended change possible and manageable.

At the same time, a request also emerged within the same program to clean up data. In itself, that was not an unreasonable request. Less data often makes migration easier, faster, and more manageable. But it did not contribute directly to the objective of this particular program.

That does not mean the subject should automatically be rejected. It does mean that it should receive a different priority. Or that, if it is important enough, it should get its own place in a broader program structure with its own sub-objective. For example, a sub-project with the objective of reducing the cost of the collaboration platform. Within that context, data reduction can be a logical and directly relevant result.

Not everything that is useful belongs to the same objective

That is an important principle in project steering. Not everything that is valuable contributes directly to the same objective.

When all kinds of useful topics are pushed into one project or program, there is a risk that focus starts to blur. The project keeps getting fuller, while strategic sharpness declines. The result is often that teams do a lot, but the connection between objective and result slowly disappears.

And when that connection disappears, it becomes much harder to make good priority decisions.

Results are also needed to maintain trust

Results are not only important for substantive steering. They are also crucial for trust. A project that says for months that people are working very hard, but meanwhile shows nothing tangible, will sooner or later trigger distrust.

Stakeholders want to see progress. Clients want to feel that the investment is producing something. Teams themselves also benefit from seeing that their efforts lead to visible results.

That is exactly why concrete results matter so much. They make movement visible. They show that the project is not only busy, but is actually delivering something.

Keep the relationship between objective and result clean

That is why it is important to keep the combination of objective and result sharp and clean.

• Which results contribute directly to the objective.
• Which results are supportive, but not directly decisive.
• Which topics are valuable, but actually belong to another objective or another sub-project.

By asking those questions explicitly, the project remains steerable and the team’s energy remains focused on what truly matters.

When the wrong results start to appear

When a project starts delivering results that cannot be directly connected to the objective, that is often a signal that something else is under pressure.

In that situation, do not only look at the content, but also at the underlying project dynamics.

• How is predictability doing. Is it still clear where the project is heading.
• How is ownership doing. Are choices really being carried and protected.
• How is calm doing. Is there still room to make good trade-offs, or is the project moving into reactive behavior.

Often, one or more of those elements are not sufficiently in place. And it is exactly for that reason that teams start chasing results that do not truly contribute to the objective.

Result within the Quilyx VERDER method

Within the Quilyx VERDER method, result is therefore never just a loose endpoint.

Results are the concrete translation of the objective into tangible outcomes. They show what a project or program actually delivers and what can be steered on.

But results only have real value when they are logically connected to the why of the change.

That is why at Quilyx, we do not only look at what has to be delivered, but always also ask whether that result truly contributes to the objective and whether it is being realized at the right moment, with the right priority, and in the right context.

The five elements together

With this blog, we have now covered all five elements of the VERDER method.

• Predictability provides direction and overview.
• Ownership ensures that direction is actually followed.
• Calm creates the conditions for people to perform well.
• Objective keeps the why of the change sharp.
• Result makes that change concrete.

It is in the combination of those five elements that the basis for successful IT projects and programs emerges.