top of page

Defining Success Before You Design the Solution

  • Iwona Wilson
  • May 4
  • 4 min read
Four people in a meeting, one speaking, others listening. Whiteboard with sticky notes. Text reads "Defining Success Before You Design the Solution."
Source: Canva custom made image

We talk about “success” in projects all the time. Everyone wants a successful project. Everyone assumes they’re aligned on what that means.


And yet, I keep seeing projects that are delivered on time and on budget and still leave people uneasy once they’re live. That discomfort is a clue.


More often than not, it’s not a delivery problem. It’s a definition of success problem.


When “Success” Sounds Aligned But Isn’t

In many industries, success is measured by getting something done.

Take pharma as an example. A project is often considered successful when:


  • the product reaches the market

  • regulatory approvals are achieved

  • timelines are met


All of that matters. But it’s not the whole story. Because getting a product to market doesn’t automatically mean it made a meaningful difference for patients.


I see the same pattern in oil & gas, mining, and large capital projects. One person defines success as speed. Another as cost certainty. Another as regulatory compliance. Another as long-term value. Same project. Different definitions. People nod in meetings but they’re nodding for different reasons. That’s how misalignment starts quietly and shows up later as rework, frustration, or decision paralysis.


A Different Starting Point: What Must Be True?

When we work with clients in oil & gas or mining, we don’t start with solutions. We start with a much simpler and harder question:

What must be true for this project to be considered a success?


Not what would be nice. Not what worked last time. Not what one function prefers.

The non-negotiables.


  • What value must this project create?

  • For whom?

  • Under what constraints?

  • What cannot be compromised?


This conversation changes the tone in the room almost immediately. Instead of debating ideas, people start aligning on intent.


Opportunity Framing: Slowing Down on Purpose

This is where Opportunity Framing Workshops come in. These workshops are designed to slow teams down at the very start- not to delay progress, but to avoid expensive misalignment later.

In a framing workshop, we help teams:


  • clarify the real problem they’re trying to solve

  • align on value drivers and success criteria

  • surface assumptions, risks, and constraints

  • agree on how decisions will be made


The goal isn’t a detailed plan. The goal is shared understanding. Once that exists, decisions become much easier and much faster.


Building a Family House Example

Imagine a family deciding to build a house. Everyone agrees on one thing: “We want a great home.” It sounds aligned but it usually isn’t.


Opportunity Framing in Real Life

The first mistake many families make is jumping straight into design: floor plans, carpets, kitchens, number of bedrooms. That’s execution. Framing comes before that.


In an opportunity framing conversation, the family would pause and ask: Why are we building this house now? What problem are we actually trying to solve? Is this about space, lifestyle, finances, schools, flexibility or downsizing or something completely else? What does success look like five years after we move in?

For one partner, success might mean room for the kids to grow. For the other, it might mean financial security and manageable debt. For both, it might mean a home that supports family life without constant stress.


Framing doesn’t produce a design. It produces shared intent. Everyone leaves aligned on why they are doing this and what truly matters. Without that alignment, every later decision becomes a negotiation.


Making Success Practical: Minimum Functional Requirements

Defining success conceptually is important. Making it testable is even more powerful.

That’s why we often recommend after framing to do a Minimum Functional Requirements (MFR) Workshop.

Once intent is clear, the next question is no longer: “What do we want?”

It becomes: What must be true for this to work?

In the family house example, Minimum Functional Requirements might include:


  • the mortgage must stay within an agreed monthly limit

  • the house must be within a certain distance of school and work

  • each child must have their own bedroom

  • at least one office space

  • the house must be safe, insurable, and compliant with local regulations


These are not preferences like a bigger kitchen or a nicer view. They are non-negotiables.

If a beautiful design breaks one of these conditions, it is not a viable option - no matter how attractive it looks. The same logic applies in projects. Without Minimum Functional Requirements, teams can spend months optimizing solutions that should never have been considered in the first place.


Success Is About Value Not Just Delivery

One of the most important shifts I see teams make is this:

Success isn’t just about delivering a project. It’s about what exists after the project is realized.


  • What value has been created?

  • Who benefits from that value?

  • Who is accountable once the project moves into operation?


A project can be delivered perfectly and still fall short if that value was never clearly defined.


Because when success is clear at the start, execution becomes simpler, faster, and far less costly.


And when it isn’t - no amount of great execution can fix it.


If you're working on complex projects, it’s worth taking a look at our training page - we support teams through an 8-week cohort or custom in-house programs designed to get projects decision-ready. https://academy.wilson.biz/





 
 
 

Comments


bottom of page