A New Edition Should Not Begin With a Blank Project

Every recurring project has a dangerous moment.

It comes when someone says: “We did this last year.”

The sentence sounds reassuring. It means the organisation has experience. But it often hides a more difficult question: where, exactly, does that experience live?

In a folder? A chat thread? A spreadsheet? In the memory of the person who handled it last time?

If the answer is unclear, the next edition does not really begin with experience. It begins with reconstruction.

The annual amnesia of a recurring event

Havnardalur Backyard Ultra is an annual running event in the Faroe Islands. The format is simple to describe: runners complete the same loop every hour until only one remains.

The work behind the event is less simple.

The Havnardalur Backyard Ultra organisers in 2026, from left: Elisabeth Larsen, Peter Jensen, Ólavur Ellefsen and Hallur Holm.

For the 2025 edition, we had 50 places. They sold out. Seventeen people joined the waiting list, 16 registered runners cancelled, and 47 eventually started.

Those numbers tell part of the story. The more valuable learning was operational:

A new lap begins at Havnardalur Backyard Ultra in 2024.

• which registration fields were needed for international results;
• how cancellations, refunds and the waiting list had actually been handled;
• which live-timing steps still depended on someone remembering them;
• where equipment had to be placed, collected and recharged;
• and what had to be submitted or changed after the event.

After the race, I captured those lessons in Usable.

When we prepared the 2026 edition, the knowledge was still there. We did not have to rely entirely on old messages or on one organiser remembering the difficult parts.

That was a meaningful improvement.

It also exposed the next problem.

Coordinating live race information during the 2026 event.

Memory is not the same as coordination

Knowing what happened last year does not assign this year’s tasks.

It does not confirm volunteers, update the schedule, check the equipment, run the repeated race-day routines or tell the team whether an unresolved risk now has an owner.

Memory answers: what did we learn?

Coordination answers: what must we do now, who is responsible, and what state is the work in?

A recurring project needs both.

This is true far beyond events. Annual audits, board cycles, recruitment rounds, customer onboarding, grant programmes, conferences and product releases all produce knowledge that should improve the next edition. Yet many organisations preserve the documents while discarding the operating state around them.

They save the final report but lose the reasoning.

They keep the checklist but not the evidence that changed it.

They retain a list of people but not which commitments were fulfilled, declined or left unresolved.

The result is a familiar ritual: experienced people spend the first weeks rebuilding what the organisation already knew.

An inheritance model for recurring work

The answer is not to copy the previous project wholesale.

A good new edition should inherit deliberately. I now think about that inheritance in three groups.

1. Inherit

Some knowledge should carry forward unless there is a reason to remove it:

• decisions and the reasoning behind them;
• playbooks and checklist definitions;
• lessons from incidents, exceptions and near misses;
• outcome data and the evidence used in the review;
• and the explanation of why the current process looks the way it does.

This is the durable memory of the project. It should be available before planning starts, not rediscovered after something goes wrong.

2. Review

Some state remains useful, but should not automatically be treated as current:

• registers of volunteers, sponsors, suppliers and equipment;
• unresolved risks;
• recurring commitments;
• proposed improvements;
• and tasks intentionally deferred to the next edition.

These should arrive in the new edition with a visible status: inherited, but awaiting confirmation.

That distinction matters. A volunteer from last year is not automatically a volunteer this year. An old risk may have disappeared—or become more serious. The value lies in not forgetting to ask.

3. Reset

Some things should expire by default:

• dates and deadlines;
• completed assignments;
• temporary access permissions;
• personal information that is no longer needed;
• outdated rules;
• and status labels that only made sense in the previous edition.

Blind inheritance creates a different kind of failure. It turns memory into bureaucracy and lets stale assumptions acquire false authority.

The principle is simple:

Inherit knowledge. Review commitments. Reset temporary state.

Starting fresh is not the same as starting blank

There is a reasonable objection to all this.

Sometimes a team needs a clean start. Last year’s process may have been poor. The people may have changed. A copied project can fossilise habits that should have been questioned.

I agree.

The aim is not to make every new edition obey the previous one. It is to make the previous edition available for examination.

A blank project forgets both the good decisions and the bad ones. An inherited project can show what happened, why it happened and what still needs to be challenged.

That gives the new team a better form of freedom: the freedom to improve the process without first reconstructing it.

From Usable to Usable Teams

This distinction is shaping what we are building now.

Usable already gave the Havnardalur work a durable memory layer. The next step is Usable Teams: a collaboration and coordination layer being built on top of that memory.

The idea is that a team, project and edition can remain connected. Decisions retain their rationale. Checklists can become repeatable runs. Registers can be reviewed and inherited. Tasks, calendars and live responsibilities can sit beside the learning that explains them.

Havnardalur is one of the real scenarios influencing the product as we develop it. This is not a claim that the event already runs inside a finished product. It is a field example helping us understand what the product must do.

Remembering is only half the job.

The other half is helping a team act on what it remembers.

The diagnostic question

If you run a recurring project, ask one question before creating the next empty folder or board:

What will we have to reconstruct that the organisation has already learned?

The answer may be a decision, a checklist, a register, an unresolved risk or simply the reason behind an old choice.

That is where the next edition should begin.

Not with a frozen copy of the past.

Not with a blank project.

With memory, reviewed and made ready for action.