Loading articles…
Field notes for building a business that can move without you.
We write from the intersection of operating systems, software, sales, marketing, and leadership—for owners building a more capable company.
Announcement
A project without a finish line is just a place work goes
96% of open Telos projects with a due date are past it. Due dates don't finish projects. A written finish line does, for your team and your AI assistant.
- Author
Alexander Ford- Published
- Reading time
- 8 min read
Contents
Of the open projects in Telos that carry a due date, 96 percent are already past it.
That number comes from every Telos workspace, counted together and anonymised. It isn't a story about careless teams. Most of those projects are real work that people care about. Many of them are probably close to done. And that is exactly the problem: nobody can say whether they are done, because nobody ever wrote down what done means.
Due dates don't finish projects. A finish line does.
"Basically done"
You know this project. The new website has been "basically done" since spring. The homepage is up. The contact form mostly works. Someone still wants to swap the team photos, and there was talk of a booking page. Every few weeks it comes up in a meeting, everyone agrees it's nearly there, and it goes back on the list.
Nothing is wrong with the people working on it. What's missing is a sentence, written at the start, that says what finished looks like. Without it, every new idea fits inside the project, and nobody has the standing to say "that's the next one." Project managers call this scope creep, and it isn't rare. In its 2018 survey, the Project Management Institute found that 52 percent of projects had scope creep or uncontrolled changes, up from 43 percent five years earlier.[1] The same report names a lack of clarity as what makes it nearly impossible to control.
It costs more than time. Psychologists E.J. Masicampo and Roy Baumeister found that unfinished goals keep pulling at your attention, intruding on unrelated work, until you either finish them or make a concrete plan for them.[2] A project that never closes is a small, permanent tax on everyone who carries it in their head.
Done is something you decide at the start
We have taught the same fix for years. Before you plan the tasks, write the results, in the present tense, as if the project were already finished. "The homepage has a services section, a client list and a booking button." "The contact form sends to [email protected]." "The about page has a current photo and a short bio." Then work backwards to the tasks that make each sentence true.
A list like that does three things a due date can't:
- It lets anyone check. You, a team member or a client can read each line and say yes or no. No one has to guess.
- It makes new ideas visible. "Add a booking page" isn't on the list, so it becomes a decision: add it to this project on purpose, or start the next one.
- It lets you decide you're finished. Done takes three things at once: the work is finished, someone decides it is complete, and it feels complete. A written finish line makes the second one possible, and the third one usually follows.
None of this is our invention, and the people who got there first deserve the credit. Software teams have long agreed on a "Definition of Done": the Scrum Guide calls it "a formal description of the state of the Increment when it meets the quality measures required," and work that doesn't meet it can't be released.[3] Basecamp's Shape Up method turns it around: decide how much time the work is worth, which it calls the appetite, and cut scope to fit. "Fixed time, variable scope," in its words.[4] Different traditions, same lesson: decide what finished means before you start, or you will never get there.
Most of your projects are probably areas
When we wrote finish lines onto our own open projects, the first thing we learned was that many of them couldn't be given one. "Marketing." "Client onboarding." "Website." They weren't projects at all. They were areas of the business, and an area never ends.
Tiago Forte draws this line well in his PARA method: a project has a goal and an end, while an area of responsibility is a standard you keep up over time.[5] Both matter. But when an area lives in your project list, it can never close, and it teaches everyone that projects don't close either.
So we name projects the way you'd name an errand: a verb and a thing. "Launch the spring campaign." "Onboard our first wholesale client." "Replace the booking form." The name implies its own finish line. The area it belongs to carries on after it closes.
Why a written list wasn't enough
For a long time, this advice lived on paper and in descriptions. Owners wrote good finish lines. Then the work started, the description scrolled out of view, and nothing in the software cared whether the list was true. A project could be marked complete with half its outcomes unmet, or stay open for years with all of them met.
Advice that depends on everyone remembering it, all the time, eventually stops being followed. So we stopped treating the finish line as text and made it part of the project itself.
A finish line your software holds you to
Every project in Telos now has a Finish line, the first thing you see beside the project's details:
- Three to seven outcomes, each written as something you can check where the work actually happens: the page is live, the numbers reconcile, the client has signed off.
- Mark each one met, with proof. A link, a ticket or one sentence about how you know. Open a met outcome and you see the proof, who marked it and when.
- Completion waits for the work. A project can't be marked complete while an outcome or a task is still open. Telos shows you exactly what's left.
- Stopping early is allowed, with a reason. Plans change. Cancelling a project asks you to say why, so the decision is on the record instead of quietly abandoned.
- Every close asks for one lesson. A short note on what to carry into the next project, so the next one goes better.
- Changes are on the record. Adding, dropping or rewording an outcome shows up on the project's timeline. The finish line can move, but never silently.
If you set a due date, the finish line shows how many days are left, or how late it is. The date tells you when. The finish line tells you what.
Your AI assistant needs this even more than you do
We built this for people. Then we noticed who else had been working without it.
AI assistants are good at doing what you describe. ChatGPT and Claude will draft, summarise and plan all day, and they are genuinely useful at it. But ask one whether a project is finished and it will tell you what sounds right. It has no way to check, because "finished" was never defined. An assistant without a finish line is like a contractor without a checklist: it will stop when it feels done.
Sapience, the assistant in Telos, works to the same finish line you do. It reads the outcomes before it plans. When it marks one met, it must give proof; a person can skip that, an assistant can't. And it can't close a project with work still open, any more than you can. That is what lets you hand it real work: you can see exactly what it claims is done, and why.
Here is the part that surprised us. Every rule we wrote so an AI could do its job well turned out to be a rule people needed too. Write down what done means. Show how you know. Don't close what isn't finished. Say why when you stop. A new hire, a contractor and a busy owner need the same things an assistant does. We had been asking people to work without them for years.
What this means for your business
You can start today, with or without Telos. Pick the project that has been "basically done" the longest. Write three to seven sentences in the present tense that would make it finished. Cross off what's already true. Whatever's left is the project. Anything else is the next one.
In Telos, the Finish line is live for every workspace now. Open any project to add yours, or ask Sapience to draft one from the project's description and tickets. The guide Create and manage a project walks through each step.
This is a first version. Today the finish line and a project's tasks sit side by side. Next we want to connect them, so you can see which tasks serve which outcome, and to let project templates carry a finish line, so repeat work starts with one already written.
Why we build it this way
We believe small businesses deserve software that helps them finish things, not just track them. A list that grows forever is not a plan. A project that can't close is not a project. And an assistant that can't show its work isn't one you should trust with yours.
Write down what done means. Then let your tools, your team and your assistant hold you to it.
If you're a Telos client, open a project and write its finish line today. If you're not, start with your longest-running "basically done" project and a piece of paper. It works there too.
[1] Project Management Institute, "Pulse of the Profession 2018: Success in Disruptive Times." The report found that 52% of projects completed in the previous 12 months experienced scope creep or uncontrolled changes, up from 43% five years earlier. pmi.org
[2] E.J. Masicampo and Roy F. Baumeister, "Consider it done! Plan making can eliminate the cognitive effects of unfulfilled goals," Journal of Personality and Social Psychology 101(4), 2011. PubMed
[3] Ken Schwaber and Jeff Sutherland, "The Scrum Guide" (2020), "Commitment: Definition of Done." scrumguides.org
[4] Ryan Singer, "Shape Up: Stop Running in Circles and Ship Work that Matters" (Basecamp). basecamp.com/shapeup
[5] Tiago Forte, "The PARA Method" (2023), and "The PARA Method" at Forte Labs. fortelabs.com
