Back to resourcesLeadership

Why change initiatives at companies often fail. Without a smart goal and thorough preparation, you won't deliver the project.

Why change initiatives at companies often fail. Without a smart goal and thorough preparation, you won't deliver the project.
Pavel Tihelka

Samo and Seto. Two legendary task-finishers who, in the corporate world, tend to function more as wishful thinking than reality. But they don't show up on the list of reasons why change initiatives fail to get finished. And that's a good thing.

Over the past five years, I've had the chance to watch dozens of change and innovation projects across different industries. And even though the companies varied in size and focus, the same root causes of failure kept coming up. They can be summed up in three points — and so can the way to avoid them.

The most common reasons change initiatives fail:

  • A poorly defined goal
  • A mistaken time estimate
  • A lack of resources

Nothing groundbreaking at first glance. But these three failure points, at their core, decide whether you actually deliver the change, or whether it stays stuck in a presentation. That's exactly why we're going to take a closer look at them.

No surprise there. This is the basic project triple constraint: scope, time, and resources. But it's the quality of how you handle these three factors that decides whether you'll be celebrating results one day, or explaining after the fact why it didn't work out. Rigorously defining, planning, and controlling these three factors is the foundation. Evaluation afterward can be the cherry on top — but only if you actually bake the cake.

1. If you don't know where you're going, it doesn't matter which road you take

A paraphrase of Alice's conversation with the Cheshire Cat from Lewis Carroll's book also offers this interpretation: you simply won't arrive at that goal. That's why defining the goal is absolutely essential to defining the whole project brief. The SMART methodology makes it possible to define a goal in a way that lets you build out the entire project triple constraint.

The SMART methodology offers a structured way to define a goal so it can be broken down into a concrete plan. Every letter carries its own meaning, and every aspect plays a key role:

S — If the goal is defined with enough Specificity, it determines the priority Scope of the project. It defines the required features, functions, and quality — the vision of what I want to deliver, and what need it should satisfy. Detailed requirements in the planning phase then represent refining detail that has to be prioritized, for example using the MOSCOW method.

M — The biggest challenge is setting the right Measurability. What exactly do I want to measure? It's easy to slip into defining “operational KPIs”: we delivered on time, within the set budget, and delivered everything that was requested.

No. Those are only proof that we planned well and had discipline. What we actually want to measure is the change that made us kick off the project in the first place — the value we generated. Why? Because the degree to which we achieve that change forms the entire revenue side of our business case. We don't build a house just to congratulate ourselves that it has the same number of rooms we planned, and that we coordinated deliveries so we could move in by Christmas. We wanted to build it for a better quality of life, privacy, peace and quiet, living outside the city center, tomatoes from our own garden. That was the reason — and those are our KPIs.

Typical business KPIs for projects within talent programs might include:

  • Shortening new-hire onboarding time by 30 days
  • Cutting order-processing time by 50% through automation
  • Reducing the cost per unit of production by 15%
  • Increasing NPS by 5 points

A — An Achievable goal is one we're actually capable of delivering. It reflects the reality of available resources, knowledge, expertise, and people. Logically, then, it also points to the cost side of the project, and shapes its structure.

R — I prefer to define this one as Relevant. It's about defining the assumptions and environment needed to ensure the intended benefit is actually realized. This means verifying the assumptions in our project's business case at checkpoints, milestones, or approval “gates.” If relevance is lost, the rational move is to stop the project, or redefine it. Otherwise, we won't secure a return on the investment made.

T — Setting a Time frame for the project goal, even at this early stage before detailed planning, feeds into the project triple constraint and takes into account things like an organization's cyclical needs — for example, a sales peak in late October tied to “Back to School.”

2. The goal as the starting point for the whole project

The SMART goal becomes the key input for the entire project initiation phase, within which we define:

SCOPE, in its positive form — what we want to deliver — and in its negative form — what isn't part of the delivery. This sharpens our own thinking while also setting stakeholder expectations. OUT OF SCOPE is everything that disproportionately worsens the project's economics and extends delivery time. It's the first test of our discipline, and of our ability to communicate clearly within the company.

The BUSINESS CASE, or rather its logical structure. Costs are the easiest to quantify. They're derived from the scope definition, where every item to be delivered has its own price. Here, we define the number — the size of the budget envelope we want to request. Revenue, meanwhile, comes from the value delivered, as measured by the KPIs. Whatever can be valued belongs here. We compare the resulting number against costs and look for a return. A third proven category is qualitative benefits — positive values that are hard to measure but undeniable, and that argue in favor of carrying out the project. We work with assumptions that we back up with data preparation.

The TIMELINE here represents the basic sequence of activities tied to delivering the scope and drawing down the budget. We always consider both parameters of project time:

  • The time needed to carry out a task, which also represents part of the project costs
  • The time during which a needed resource is allocated to an activity — an input that points to the project's overall duration

For a simple draft timeline, and to understand logical dependencies and possible time synergies when multiple resources run in parallel, I recommend the post-it method: write out key activities on sticky notes with an estimated duration, and place them along a timeline. When resources run in parallel, the total delivery time ends up shorter than the sum of the individual activity times.

3. Preparation isn't a delay. It's an accelerator

A well-prepared project makes it possible to:

  • communicate clearly,
  • allocate priorities and resources rationally,
  • build a project team with the necessary expertise,
  • keep direction, time, and budget under control,
  • set up governance and stakeholder management.

If you want to deliver innovation, carry out a change, or launch a new product, start with careful preparation. Invest time, energy, and money in it. This is exactly where ownership is born — the feeling that the change has an owner who stands behind it.

And Samo and Seto? They can go ahead and put their feet up. You won't be needing their services.