There is a difference between stopping and finishing.
Businesses confuse the two constantly.
“We rebuilt the website.”
Okay.
What was the website supposed to accomplish?
“We implemented a CRM.”
Great.
What condition in the business was the CRM supposed to create?
“We worked on the sales process.”
Toward what end?
A lot of work gets called finished because people stopped touching it.
That is not the same thing.
A project is finished when the result it was undertaken to produce is actually real.
That sounds obvious.
It is also not how a surprising amount of business work gets managed.
Activity is easier to define than an end
“Improve the website.”
“Fix sales.”
“Build a CRM.”
“Work on management.”
“Improve follow-up.”
Those all sound like projects.
They aren’t.
They are categories of activity.
None tells you when the work is done.
That creates a problem before anybody begins.
If the finish line does not exist, there are only two likely outcomes.
You stop when people get tired of working on it.
Or you keep improving it forever because something else could always be done.
Neither is good management.
Start with what has to become true
I have become much more particular about this in my own work.
Before starting a serious project, I want to know:
What has to become true for us to say this work actually accomplished what we started it to accomplish?
That question changes the project.
Suppose the work is a website.
“Build a better website” tells me almost nothing.
But:
Create a website that allows the right prospect to understand what we offer, decide whether it applies to him, and take the intended next step
gives me something to govern toward.
Now design has a job.
Copy has a job.
Navigation has a job.
The call to action has a job.
Analytics have a job.
And eventually I can ask whether the intended condition is real.
That is different from asking whether everybody likes the website.
The same problem shows up in software
I spent years making different systems work together because I needed them to.
CRM.
Automation.
Operations.
Reporting.
Accounting data.
Marketing systems.
You can spend an enormous amount of time making software more sophisticated.
That does not mean it has become more useful.
If the purpose of the system is to give me operating data I can trust so I can make better decisions, then the relevant question is not:
How much have we built?
It is:
Can I now get the truth I need from the system?
If the answer is no, the work is not finished merely because the software is live.
If the answer is yes, the original work may be finished even though I can imagine fifty things that would make it better.
That distinction matters.
One owner quits too early. Another never stops.
There are two opposite ways to mishandle work.
The first is obvious.
You stop because the work became hard, expensive, boring, or inconvenient before the intended result exists.
You quit before the end.
The second can look much more impressive.
You keep adding.
Polishing.
Rebuilding.
Optimizing.
Researching.
Expanding scope.
There is always another feature.
Another report.
Another design improvement.
Another automation.
Another idea.
At some point, that can stop being excellence and become an inability to recognize that the work already did what it was created to do.
One person stops before the end.
The other works past it.
Neither is the same thing as finishing.
Finished does not mean perfect
This is probably where owners get uncomfortable.
If a work is finished, does that mean it cannot be improved?
Of course not.
It means the particular work you defined attained its end.
If you want to improve it again, define the next work.
That matters because otherwise everything in the company remains permanently unfinished.
The CRM is never done.
The website is never done.
The hiring process is never done.
The sales process is never done.
The reporting is never done.
The company slowly accumulates an infinite list of things that could be better and calls all of it work.
There will always be something else you could do.
That is not a useful definition of unfinished.
Work backward
A better way to begin is with the result.
What has to become true?
Then work backward.
What conditions need to exist for that result to happen?
What actions create those conditions?
What has to happen first?
What is unnecessary?
What are we doing because it contributes to the result, and what are we doing because it is interesting?
That last question can be painful.
I like building things.
I like improving things.
That means I am perfectly capable of spending time making something better after it is already good enough to accomplish the work I originally gave it.
Knowing that about myself is useful.
The answer is not to care less about quality.
The answer is to be honest about the end.
Finish the work you actually started
Before the next serious project begins, write one sentence:
This work is complete when…
Then finish the sentence with something observable.
Not:
“When we feel good about it.”
Not:
“When we have worked hard enough.”
Not:
“When we run out of time.”
What will actually be true in the business?
Then do the work necessary to cause that result.
Do not quit because it becomes difficult.
Do not keep adding because activity still remains possible.
When the intended result is real, finish.
And if you decide something else should become true afterward, good.
That is a new work.
Give it its own end.