When a Project Becomes the Process

When a Project Becomes the Process

Some projects are finite. Others aren’t. The tricky part is, you rarely know which kind you’re dealing with at the start.

At first, everything looks straightforward-clear tasks, a defined outcome, maybe even a rough timeline. But soon you realise you’re still surveying the land. Some ground is solid, some is tangled, and you don’t always know where you’re stepping until you’re ankle-deep.

This is especially true in research, or in any work involving data, ambiguity, and evolving understanding. You might start with a defined goal-build a tool, solve a problem-but quickly find yourself looping back, reframing, chasing tangents. Even naming the problem can take longer than expected. And the more you learn, the more you realise what you don’t know.

So what does “done” look like in this kind of work?

For me, “done” is tied to the phrase “good enough.” It’s a flexible definition-sometimes frustratingly so. When the scope is clear and metrics are in place, “good enough” has weight: 95% data quality, model performance above a certain threshold, task automated and documented. But with more open-ended work, that clarity slips away. You start asking different questions: Am I still learning? Is this still useful? Have I gone as far as I need to? As far as I can?

Sometimes, being done means having enough to move on-not because you’ve finished, but because you’ve built something reusable. A pattern. A habit. A way in. You collect these into a kind of internal toolbox-mental shortcuts, working fragments, small discoveries to carry forward. Maybe you log it somewhere. Maybe it’s just a change in how you approach similar problems next time.

In my case, that toolbox is literal. I keep a set of Jupyter notebooks-one for data engineering tools, another for machine learning methods. They’re not polished repositories. Just working collections-snippets and techniques pulled from past explorations. When a problem feels familiar, I check there first. It’s already saved me time and effort. It’s helped me avoid reinventing the wheel.

Still, open-ended projects aren’t easy to manage. They stretch. Fix one issue, another appears-like a hydra. Eventually you have to fall back on something internal: is the work still doing something for you? Are you still gaining insight? Is this still worth your time?

And how do you even know? Because external feedback is rare. People expect polish before they’ll weigh in, and by then, you’ve often moved on. So you have to build up a kind of quiet optimism. A belief that the work matters-even if only later, even if only to you.

Maybe that’s enough. If the work still teaches you something-if it still equips you-it doesn’t need a clean ending. Just a next step.

If you are interested in the the differences between finite and open ended projects, I recommend checking out Finite and Infinite Games. It provides a great overview of the opportunities that come with open-ended research.