READ TIME - 6 minutes ⏳
Most projects don’t fail in delivery. They fail at the moment the problem is assumed to be understood.
By the time something is called “a redesign,” “a new theme,” or “a dashboard revamp,” a set of assumptions is already locked in. The outcome is imagined. The success criteria are implied. The work is framed as production.
What usually goes unnoticed is that nothing has been observed yet.
Running an inventory at the beginning of a project is not an administrative step. It is a diagnostic act. It is the moment where intention meets reality (often for the first time).
The projection
Every initiative starts with a projection.
- A cleaner visual identity.
- A scalable BI experience.
- More consistent dashboards.
- Something that finally “looks like the brand.”
This projection is not wrong. But it is incomplete.
It describes what people hope to see later, not what exists now.
When the projection becomes the starting point, the current state is treated as a nuisance rather than evidence.
Teams move quickly toward solutions because the destination feels clear. The cost is that no one pauses to ask whether the ground they are standing on can support it.
The gap
The most important outcome of an inventory is not the list itself.
It is the gap it reveals.
The gap between what the organization believes it is expressing and what it is actually showing.
Between brand language and visual behavior.
Between design principles and daily execution.
This gap is often wide, even in mature teams.
And until it is visible, every conversation about improvement remains abstract.
What actually exists
An inventory is where the projection is tested against reality.
Not in theory, but in artifacts: we compare what exists internally and outside the organisation.
Screens. Slides. Portals. Templates. Dashboards. PDFs. Internal tools. External touchpoints. Old things no one owns anymore. New things built in a hurry.
This is rarely comfortable.
Because what emerges is not “a system waiting to be improved,” but a collection of decisions made under different constraints, by different people, at different times, for different reasons.
Seen together, they form a picture that is difficult to argue with.
Not a product yet
Early projects are often framed as products to be delivered.
A theme.
A design system.
A component library.
This framing creates pressure to decide too early. To commit to aesthetics. To debate preferences. To optimize for speed.
An inventory reframes the work as a problem to be understood.
It delays design decisions on purpose. It shifts the focus from “what should we build” to “what is happening right now, across the organization.”
This distinction matters more than it appears.
Who the work is for
When inventories are skipped, solutions tend to reflect the people who build them:
- Designers produce artifacts that designers can maintain.
- Developers optimize for what is technically elegant.
- Analysts recreate experiences they personally enjoy.
This excercize prevents solutions from reflecting only the preferences of the people who build them.
An inventory interrupts this tunnel vision by forcing multiple perspectives into the same room. Business experts, end users, designers, developers, stakeholders. Not to decide, but to observe together.
What emerges is not consensus, but shared context.
Evidence without debate
One of the quiet strengths of an inventory is how it changes the tone of conversations with stakeholders.
Instead of arguing for why something is “a problem,” the work presents evidence.
Instead of opinions, there are artifacts (proofs).
Instead of future promises, there is a documented present.
Screenshots are not persuasive because they are dramatic. They are persuasive because they are concrete.
They make inconsistency visible without accusation.
They surface fragmentation without blame.
This is often the first time leadership sees the system as users experience it.
Scale starts earlier than expected
Many organizations associate scale with later phases.
More users. More dashboards. More teams.
In reality, scale is decided much earlier: when foundational choices are made without understanding the terrain.
An inventory exposes where scale will break before it does.
Which patterns repeat.
Which exceptions multiply.
Which “one-off” decisions are no longer isolated.
By the time these issues appear in production, they are expensive to correct. At the inventory stage, they are simply observations.
No decisions for now
There is a temptation to turn inventories into roadmaps.
To prioritize immediately.
To define solutions.
To move on quickly.
This is usually a mistake.
The value of the inventory is not momentum. It is clarity. It establishes a shared baseline that future decisions can reference. It gives language to things that were previously felt but not articulated.
At this stage, restraint is a feature, not a failure.
When this matters most
This kind of work often becomes possible during moments of change (easy to remember: the '4R')
- A Rebrand.
- A Reorganization.
- A Replatform project.
- A (digital) product being Refactored or Repurposed.
These moments create permission to look closely. Not because everything is broken, but because everything is in motion.
Skipping the inventory during these transitions usually leads to repeating old patterns in a new wrapper.
A quiet signal
If this feels familiar, it is likely because the outcome was decided before the starting point was understood.
When teams struggle to align later, it is rarely a delivery problem.
It is an upstream clarity problem.
By the time this becomes visible, the project is already underway (sometimes even already in production and exposed to end users).
The inventory exists to make that moment happen earlier:
"Before it starts"
