Objective in IT projects. Why the why matters more than the what

In the previous blogs in this series, we explored predictability, ownership, and calm. With that, we covered the first three foundations of the Quilyx VERDER method.

In this blog, the fourth element takes center stage: objective.

We begin with a distinction that is often not made sharply enough in projects and programs, namely the difference between objective and result.

In practice, the two are often used interchangeably. Yet it is important to keep them separate. Not only for the quality of project steering, but especially to avoid a situation where a project delivers exactly what was agreed, but ultimately fails to contribute to what the organization actually needed.

Objective and result are not the same

The objective is the why of the change.

Where does the organization want to go. What does it want to improve. Which problem does it want to solve. Which movement does it want to make.

A project or program does not exist for its own sake. It exists to contribute to a broader organizational objective.

That could be, for example:

• We want to strengthen our competitive position.
• We want to reduce risk.
• We want to future-proof our services.
• We want to respond more quickly to changes in the market.

Those are objectives. They provide direction, but they are not the same as the concrete outcomes of a project.

A result is the what. What must be realized in order to support the objective.

As soon as something becomes concrete and bounded, it moves closer to being a result. For example, a new system, a redesigned process step, a completed migration, a renewed customer portal, or an adjusted way of working.

A project delivers results. Those results should contribute to the objective.

Why an objective is usually not SMART

In many organizations, there is a belief that everything should be defined SMART. That sounds logical, but it does not always work well when it comes to objectives.

An objective is by definition often more abstract and strategic in nature. It gives direction to the change, but is not always fully SMART at the same level as a project result.

That is because an objective often concerns a broader desired situation. For example more control, less risk, higher customer satisfaction, or a stronger competitive position.

As soon as something is made fully SMART, it often shifts from being an objective to becoming a result or a measurable indicator.

That is not necessarily wrong. On the contrary. It is useful to support objectives with measurable indicators. But it remains important to distinguish what the why is and what the what is.

A project supports an objective, but does not guarantee it

A project can deliver results that logically contribute to an objective without it being certain in advance that the objective will therefore actually be achieved.

That is an important insight.

Suppose an organization says: we want to strengthen our competitive position.

A project then follows in which certain changes are made. For example a new platform, a faster customer journey, or a better data model.

At the end of the project, you can establish that those results have been delivered.

But the question whether the competitive position has truly improved is a different question.

That has to be measured. And it is entirely possible that the conclusion is that the results were delivered correctly, but in practice do not contribute enough to the original objective.

That does not automatically mean the project was unsuccessful.

The project delivered what it had to deliver. In addition, the organization learned that the previously chosen solution was apparently not sufficient to achieve the objective.

That is valuable too. It allows the organization to take the next step.

When results take center stage and the objective disappears

That is exactly why the objective is more important than the result.

Results are necessary. Without results, there is no change. But results are never the end goal in themselves.

When a project focuses only on delivering the agreed results, without continuously checking whether those results still contribute to the objective, there is a risk that a project is formally successful but substantively falls short.

The well-known saying the operation was successful, but the patient died is perhaps the clearest example of that.

Everything was done as agreed. Execution succeeded. Output was delivered.

But the real objective was lost from view.

That is exactly why a project manager must keep reconnecting objective and result.

The objective as the red thread through the project

In a good project, in which predictability, ownership, and calm are well organized, the objective remains visible throughout.

Not only at the start of the project, but during the entire trajectory.

At every step, the question should be asked again:

• does this still contribute to the objective.
• Is this actually strengthening our competitive position.
• Are we indeed reducing risk with this.
• Is this really delivering the movement we as an organization want to make.

And if signs appear during the project that the intended results are unlikely to contribute sufficiently to the objective, then that needs to be made discussable.

Then it may be necessary to adjust. Not because the project is failing, but precisely to prevent the project from becoming successful at the wrong things.

Why it is important to explain this clearly from the start

Because objective and result are so often confused, it is important that a project manager is clear about this from the start.

That requires not only sharp terminology, but also actively explaining the difference to stakeholders.

• What is the why of this change.
• Which results do we need to realize.
• And how do those two relate to each other.

By making that distinction explicit, greater clarity arises in decision making, progress conversations, and expectations.

It also helps stakeholders keep following the story of the project.

The objective must keep returning

The objective should not be a single sentence in a start document. It has to keep returning in the steering of the project.

• In biweekly reports.
• In demos.
• In progress presentations.
• In decisions on scope or priorities.
• And also when successes are celebrated.

It is exactly through that repetition that the objective becomes the red thread of the project. It helps stakeholders stay engaged, understand where the project is heading, and keep seeing why it matters.

That strengthens confidence in the approach and also increases the willingness to keep investing time, energy, and resources.

Objective within the Quilyx VERDER method

Within the Quilyx VERDER method, objective is therefore not an abstract concept in the background.

It is the reason the project exists.

Predictability helps create direction and overview. Ownership ensures that direction is actually followed. Calm makes it possible to keep functioning well.

But ultimately, all of those elements need to contribute to something bigger.

To the objective.

That is why at Quilyx, we do not only look at what a project must deliver, but always also at why that matters and whether the change still makes sense in relation to the goal the organization wants to achieve.

On to the final element of the VERDER method

With predictability, ownership, calm, and objective, we have now covered four important elements of the VERDER method.

In the next blog in this series, we will therefore continue with the fifth element: result.

If the objective is the why of the change, then the result is the concrete translation of that why into what a project or program must actually deliver.