You don’t know what you don’t know, and in technology delivery that’s usually where things come undone

I see this pattern a lot.

A project starts in a good place. The plan makes sense, the system has been chosen properly, and the people involved are capable. Nothing is obviously wrong.

Then a few weeks or months in, things start to feel harder than they should.

Timelines stretch. Conversations get more complex. Things that were assumed to be straightforward suddenly aren’t. And it’s not one big issue, it’s a series of smaller ones that start to add up.

That’s usually blind spots.

The tricky part is they don’t feel like risks at the beginning. They sit inside assumptions that sound completely reasonable:

“That process is pretty standard”

“The data should be fine”

“The team knows how this works”

“The system will be able to handle that”

None of these are wrong on their own. But when you layer them together without properly testing them, you end up designing around a version of reality that’s a bit cleaner than how things actually run.

That gap is where delivery starts to slow down.

Where this tends to show up isn’t in the obvious areas, it’s in the detail people don’t always stop to unpack early enough. Things like processes that look simple on paper but rely on workarounds in practice, or systems that are far more interconnected than anyone has mapped out properly.

You also see it with data. It exists, but not in a way that’s consistent, clearly owned, or ready to be used in a new system. And with teams, they absolutely have the capability, but not always the capacity that the project is quietly depending on.

Individually, none of this is critical. Together, it slows everything down.

It’s also not a capability issue. Most of the time, the teams involved are strong. They’re just working in an environment they’re very familiar with, where a lot of complexity has become “normal.” Add pressure to move quickly, and those assumptions don’t get challenged, you just get started.

The projects that run more smoothly tend to take a slightly different approach early on. Not dramatically different, just more deliberate.

They’ll take the time to:

• Sit with frontline teams and walk through what actually happens, not just what’s documented
• Focus on edge cases and exceptions, not just the “happy path”
• Properly map how systems and processes connect, beyond a high-level view
• Be realistic about who has time to contribute, not just who is technically assigned
• Sometimes bring in an external perspective to challenge assumptions

It’s not about slowing things down. It’s about not having to untangle everything later.

Because the real issue with blind spots isn’t that they exist, every project has them. It’s when you discover them.

If you find them early, they’re manageable and usually easy to work through. If you find them late, they start to affect everything: timelines, cost, confidence, and ultimately adoption.

And fixing things at that point is always more disruptive than expected.

For me, the difference isn’t whether a project has risk. It’s whether you’ve actively gone looking for what you might be missing, before it starts showing up on its own.

That’s usually what separates the ones that feel under control… from the ones that don’t.