How to Know What to Build Before Investing in Technology
TL;DR
Most projects don’t fail because of bad technology — they fail because what gets built doesn’t reflect how the business actually works.
By the time requirements are signed off, teams are often aligned on documents, not on reality. Different views of processes, inconsistent data definitions, and untested assumptions create a false sense of agreement.
A design-led approach fixes this by pausing before build to:
- map how work actually happens (not how it’s documented)
- align stakeholders on the real problem
- identify breakdowns across people, processes, systems, and outputs
- test ideas early before committing to development
The result: You reduce rework, avoid costly mistakes, and build systems that actually get used.
If you’re questioning whether your project is set up for success, get in touch with our team.
What to do before you spend any technology build money
By the time something is called a “project”, important decisions have often already been made, sometimes even before the problem has been defined clearly and truly understood by the people it impacts.
In these scenarios, how do we know what to build before investing in new technology?
The Australian National Audit Office has recently identified that weaknesses in planning, risk management and governance are consistent contributing factors to poor outcomes in major programs.
According to the 2024–25 Performance Audit Outcomes the office observed a “high tolerance for non-compliance when speed of delivery is prioritised”, suggesting that perceived “speed of delivery” is often valued higher.
What does this look like? There’s usually a direction locked in, which could look like a new system, a rebuild or a reporting layer that’s meant to fix what isn’t working.
What’s less clear is the true problem that it’s actually solving. If you ask around, you’ll hear different versions of it.
Finance will talk about reporting gaps. Operations will point to workarounds. IT will focus on systems that don’t connect properly. None of it is wrong.
But these perspectives rarely align into a single, shared view. That gap is often carried into the project and is where most of the risk sits.
Why projects can fail after requirements are signed off
When they don’t work requirements can paint an incomplete view, usually built from:
- different views of how work happens
- assumptions that haven’t been tested
- data that isn’t consistently defined
It creates agreement on paper, without alignment in practice.
The Digital Transformation Agency requires agencies to understand user needs before designing solutions for this exact reason. When that step is rushed or skipped, the result is often rework, delays, or systems that are not adopted.
The issues tend to emerge later, when something tangible starts to land. That’s when people start saying:
- “that’s not how we actually do it”
- “this misses a step we rely on”
- “we still need to handle this outside the system”
At that point, the problem isn’t the interface or the build quality. It’s that the original picture of how the business works wasn’t quite right.
And once you’re at that stage, fixing it isn’t simple. The investment has already been made and the timelines set.
What does this mean for the organisation? Adjustments are layered in and workarounds return. The system ends up sitting alongside the way people actually operate, rather than supporting it.
Why what gets built doesn’t reflect how the business actually works
Most organisations don’t operate in a single, consistent way.
They rely on:
- workarounds that have evolved over time
- systems introduced at different points for different needs
- teams interpreting the same information differently
There isn’t one version of reality. There are several. When a system is designed, it simplifies that complexity. What gets built reflects a version of the business, but not the full picture.
Research from the CSIRO highlights that misalignment between designed systems and actual workflows is a common cause of failure in complex environments.
Systems are built on what is documented. Organisations, however, continue to operate on what actually happens, and the two do not always align.
Most organisations don’t have a clean, shared view of how work happens. This is not necessarily due to poor management, but because processes evolve over time.
Processes get adapted and teams solve problems in their own way. Systems are introduced at different points, often for good reasons, but without a full reset. Data starts to mean slightly different things depending on where you sit.
Over time, that becomes normal. So when a project starts, it’s built on a version of the business that feels familiar, but isn’t complete.
How to know what to build before investing in technology
There’s usually a moment where this could be addressed, right before the build begins.
BUT it is not always treated as a critical step and can be seen as “slowing progress”. Skipping it is what creates most of the problems later.
Organisations that avoid these issues don’t begin with a predefined solution. Instead, they establish a shared and accurate understanding of how the organisation operates.
The challenge isn’t just understanding the problem, it’s getting stakeholders aligned on what that problem actually is before a solution is built.
That means being clear on:
- how work actually moves across teams
- where decisions are made, and where they break down
- how systems support or interrupt that flow
- what data is relied on, and how consistently it is understood
If this isn’t clear, anything built on top of it will carry that uncertainty forward.
Notitia’s Design led approach: How to assess if you’re ready for a system or digital project
At Notitia we employ a “design led approach” to reaching a point solution. What does this mean? At the start of a project we stop and pause for just long enough to step back and examine what is actually happening.
Our UI UX designers and directors sit with the people doing the work. We follow how information moves. We look at where decisions are made, and where they get stuck. We compare what’s written down with what actually happens day to day.
This surfaces things that weren’t visible before.
Before committing to a build, we examine four areas:
- People
- Processes
- Systems
- Outputs
What to do before starting a data or digital project
Before selecting technology or defining features:
- map how work actually happens
- align stakeholders on what is really going on
- identify where processes and systems break down
- test early ideas before committing to build
The focus moves away from pushing a predefined solution forward. Instead, decisions are made from a shared understanding of the problem.
Notitia’s design-led approach
- User Persona Mapping with your stakeholder
Through a series of in-person workshops with stakeholders we identify key user groups, their needs, behaviours, and goals to align design decisions, ensuring the final product meets all user expectations effectively.
User persona mapping uncovers behaviours, pain points, and assumptions to understand how different roles interact and contribute to business goals. This is how messy business problems are turned into clear, testable requirements, by making them visible early.
Our process:
- Gain immediate clarity on areas of alignment & misalignment.
- Visual representation of overlapping roles & responsibilities.
- Discovery phase questions answered:
- What data is required?
- Where does the data come from?
- Who owns the data?
- Who understands the data?
- How will the data be structured and used?
- Wireframes that support a low cost iterative process
We create low-fidelity visual blueprints of the solution, mapping layout and functionality early. People who will use the end product can see exactly how they will interact with it in-line with their role, processes and goals. This allows teams to refine structure, before committing to design and development.
This is where many projects first uncover issues they would otherwise only discover during development, when they are significantly more expensive to fix.
- Polished designs that allow teams to visualise the end solution
Detailed designs that closely resemble the final product, incorporates branding, UI elements, and interactions—validating the look, feel and functionality, before development begins.
- Feedback, iteration and final design
We refine designs based on user testing and stakeholder feedback—before finalising a design that’s practical, scalable, and built for the people who will use it. This ensures that the solution is practical, scalable and built for the people who will use it.
How a design-led approach helps define the right problem
A design-led approach provides structure to this stage. Not primarily as a creative exercise, but as a way to:
- uncover how people actually work
- test assumptions before they are embedded
- expose gaps between systems and operations
- build a shared understanding across stakeholders
The Design Council framework emphasises defining the problem before moving to solutions. The focus is less on generating ideas, and more on reducing uncertainty before delivery begins.
This is where a design-led approach becomes most valuable.
It’s not about running sessions for the sake of it, or producing artefacts that sit on a shelf. It’s about creating enough clarity that decisions can be made with confidence before anything is built.
How to avoid building the wrong solution
The key shift is simple:
Don’t move to build until the problem is clearly defined and consistently understood.
When that happens:
- requirements reflect real workflows
- stakeholders are aligned before delivery
- decisions are based on shared information
- systems are designed to fit how the organisation operates
Most importantly, issues are identified earlier, when they are significantly easier to address.
Before you decide what to build
The question is not which platform or tool to choose or build. It is whether there is a shared understanding of the problem. If that isn’t clear, the project will move forward on assumption. Once that happens, the cost of correcting the course increases quickly as delivery progresses.
If you’re about to invest in a system, rebuild, or reporting solution, this is the moment that matters most.
Before you choose a platform, before you define features, before you lock in requirements:
Make sure you’re solving the right problem.
At Notitia, we work with organisations to:
- assess business and project readiness
- map real workflows and decision points
- align stakeholders before delivery begins
- turn complex, messy problems into clear, testable requirements
This is how you avoid building something that looks right on paper, but fails in practice.
If you’re questioning whether your project is set up for success, get in touch with our team.
FAQ
Why do projects fail after requirements are signed off?
Because requirements often reflect assumptions, not reality. They are built from different stakeholder perspectives, inconsistent data definitions, and incomplete views of how work actually happens — leading to misalignment once delivery begins.
Why does what we build not match how the business actually works?
Most organisations operate with evolving processes, workarounds, and disconnected systems. When a solution is designed, it simplifies this complexity — meaning what gets built reflects a version of the business, not the full picture.
How do you properly define a problem before building a solution?
You need a structured approach that:
- maps real workflows across teams
- identifies where decisions break down
- aligns stakeholders on a shared view
- validates assumptions before they become requirements
This ensures the problem is clearly understood before any solution is designed.
What is a design-led approach in digital projects?
A design-led approach focuses on understanding the problem before building the solution. It uses techniques like stakeholder interviews, workflow mapping, persona development, and prototyping to uncover how the organisation actually operates and reduce uncertainty before development begins.
How do you get stakeholders aligned before starting a project?
By creating a shared, visual understanding of:
- how work flows across teams
- where systems support or interrupt processes
- how data is used and understood
This removes conflicting assumptions and ensures everyone is solving the same problem.
How do you test ideas before committing to build?
Through early-stage design artefacts like:
- user personas
- workflow maps
- low-fidelity wireframes
These allow teams to validate functionality and usability before development, when changes are still low-cost.
What is problem framing in design thinking?
Problem framing is the process of clearly defining the real issue before jumping to solutions. It ensures the project is focused on solving the right problem, not just the most visible one.
How do organisations avoid rework in digital or data projects?
By identifying issues early — before development begins.
This includes aligning stakeholders, validating workflows, and testing assumptions upfront, rather than fixing problems after systems are already built.
What should you do before starting a data or digital project?
Before selecting technology or defining features:
- map how work actually happens
- align stakeholders on the real problem
- identify gaps across systems and processes
- test ideas early
Skipping this step is one of the biggest drivers of project failure.
