How to Finish Projects?

I've also struggled with this, and I'm not sure there's a silver bullet answer.

But I think a lot of the common advice (too simple to work!) is actually helpful:

- Limit scope

As much as you think 'no one will use this without XYZ feature'; no one will definitely use it without it existing at all. Just make the basic functioning product and see below:

- Get real users using it early (release early)

Having real users (perhaps even paying users) using my project, relying on me for fixes/updates, seems to be a nice kick-in-the-pants to fix/work on the project. Even with minimal users or zero-revenue, having that feedback that someone finds what you're doing useful rather than coding into a void is really motivating.

- Build something for yourself

If you need/want to use it, you'll continue to work and improve the project to suit your needs. Theres some additional work likely to make it available for others to use, but if you're using the product yourself often - perhaps thats motivation to see how others could benefit from it as well.

Also realize - it's never 'finished'. If it's a project that you either (a) enjoy working on or (b) actually has users, there will always be more to do. So embrace that and find (a) or (b) early.

Finishing projects is overrated, unless you’ve never finished one then finishing a few for their own sake is worth it.

Projects are experiments. Most of the time as you work on it you lose motivation because it become obvious it won’t work or you don’t have something (skills, knowledge, mature enough technology) needed to finish it.

Only finish projects that still valuable for you or for others. Discard the rest ruthlessly, but keep them around. Sometimes parts are useful later.

I suggest three things:

1. Clear separation between study/preparatory work and deliverable work. There's an inherent tendency to rush and "do it live". And the work done in a workplace setting is often different from a personal project because the preparation is done through countless meetings and reports that gradually uncover specifications by consensus. When it's your project, you have to substitute that with self-feedback and accept that on many days you aren't doing deliverables, you're finding the benchmark you want to set for those deliverables.

2. Your project must be coherent. Any contradiction in its premise will turn into a source of difficulty. At the beginning you can evade this by adding scope: scope lets you ignore contradictions by having more to do, and this is a classic error in many forms of personal project. Then the scope gets out of hand and the project either fails or turns into a monumental struggle. Instead list all assumptions out early on and give them a tournament-style ranking: what's most important, and just as importantly, what contradictions arise by trying to strive for both? Philosophical reasoning can create a ton of leverage for useful progress by clarifying what you really want.

3. Careful attention to workspace. I don't mean just software here, but everything: physically, what does it mean to begin working on this project? Is it easy to resume? Are the materials set up in an ergonomic position or are you always shuffling things around in piles? Do you have some elaborate configuration process? Can you simplify it by reducing the technology? Can you likewise simplify it by redefining your use of technology?

When you ignore the things making it physically easy to reach the end, you create extra work, and eventually it grows into being its own job. Again, there are things people are hired to do that will not see a personal project through. If the project is ultimately "make a business", you may structure it like one, but not every project is or can be that way.

Do a little bit of work, every workday. I've shipped several SaaSes and two e-books over the past few years from just two hours a day.

It also helps to have something with real users - it gives you extra motivation to know you're making their experience better each day.

I've written more about the topic here: https://onlineornot.com/unreasonable-effectiveness-shipping-...

Maybe an obvious thing, but do your projects even have a "finished" state? For me anyway, most of my projects sort of don't. That's not necessarily a bad thing, but those projects sure never seem to get finished either.

Take a project like learning Latin.

There are many steps along the way that get finished, maybe you take a course, maybe you read LLPSI and a bunch of supplementary literature, ... but when have you even learned Latin? When you can read De Bello Gallico, or even Cicero? The vulgate bible?

This is just how projects, in general, tend to be.

I struggle with this too. What is helping me (but I still haven't figured it out) is to try and stop thinking of it as a long project with a single "DONE" but instead as a series of steps (milestones) which would be good decision points to stop or keep going. For example, if I was working on a game, I might aim for (and commit to, hopefully) a version that is playable and good enough to release for free on the web, but not something I would want to charge money for or support. Then I call that step done, and get the value of feedback on it, decide if I'm done, or maybe the next step would be a minimal version that I could release on the App Store but didn't support any multiplayer or persistent state that would require a backend for it (even if that is essential to the original vision). Once that's released, I can again decide if the project is DONE or if I expand it until the next stage.

That's the theory at least, and it's working better than other things I've tried but it's still tough. Another good feature of this approach is that to an outsider, it doesn't look like I've released one thing, it looks like I've made THREE releases, the free version, the minimal version, and the big multiplayer version. If I had just waited until the "full" version was done and somehow maintained focus, it would look like one release.

Be vigilant about scope creep; this requires some self-awareness, as it can be easy to let your excitement take you down interesting but tangential paths.

Your priority should be to get the core functionality of your project working as soon as possible, even if it's buggy and lacking in features. This proves that you can solve the problem you set out to solve, and allows you to say you've "finished" the project to some degree.

Too often people get caught up in doing things the 'right' way, making sure the code is the cleanest they've ever written, etc. None of this matters if it doesn't result in a working product.

Now I don't mean to say that additional features, bug fixes, and refactoring aren't important. My point is that focus, motivation, and time are limited resources, and these improvements should come after you've established your core functionality and proven that it's viable.

If you are like me, then goals like "finishing" don't work very well. I like sinking my teeth into a subject and learning about it. Or figuring out how to solve something. Once I got the hang of it I lose interest.

What has changed for me recently is that I now look at these things in terms of "what skill am I training here?", and ofcoirse I have a list of skills I want to master long term.

This has meant that I have given up struggling on some projects that did not reflect on any skills I was interested in, but I am also way more motivated on some other projects.

I recognized myself a lot in this description: https://www.youtube.com/watch?v=A2sS00egAzg

Lay a single brick everyday and soon you have a wall. Don’t overthink it. Just do something each new day.

Personal tips that helped me at least for increasing engagement.

- Maintain a fixed number of max projects in parallel: 3 is my number. When I reach that number, any time I'm tempted to desist on working on any of the projects I have ONLY the possibility of retake any of the group. Of course you still can have unfinished projects but a restricted set of real active projects make you to assume a conscious decisions in contrast with a more involuntary notion that let you think you can retake work on an unlimited number of projects anytime you want (something that almost never happen)

- Less time in perfect: common procrastination is about looking for the perfect design, the perfect stack, the perfect name. Making an effort on identifying and reducing the time you take on this kind of activities helps because you necessarily are going to do real progress in projects. This is particular important later when you realize how working and deliverying your projects make you more confident than just "thinking" on them.

- Involve more people: once the motivation is shared is easier to try to get the projects in a more completed state. Specially when that people is out of your area of expertise. Commonly those first hours of focused and greateful work is spend on things you enjoy doing, once you accumulate a couple of boring tasks, your motivation lose traction. Having people out of your speciality sometimes can unblock/help or directly work on that not interesting activities.

- Close the idea factory: sometimes as serial makers/thinkers the born of a new idea is celebrated and usually that means that a new project is comming. Dont let new ideas to replace the older ones. It doesnt mean that you simply stop thinking in those new ideas that suddenly came to your mind, it means that you need to control the response of those stimules. You can write down on a note book, take a couple of minutes to think in that prospect but you cannot allow that new ideas to replace the more mature and already materialized. It's the most difficult step but is a good training for other useful learnings about let things go.

Set goals for what you actually want out of the project.

Done is when those goals are finished, not when the project has all the pieces it could have

If the point is to learn, stop once you've learned. If the point is to play, stop when you get bored of it.

If the goal is to launch something, then, you have to launch it

Define smaller time frames to complete them, and slash goals that won't make it.

Break it down into logical steps. If step taking too long, break it down further. Key is to maintain sense of progress, however small.

It’s an odd thing but the way I work on projects is I acquire a high quality domain name upfront and then work on whatever the domain name is. The interestingness of the domain focuses me to produce quality work so as to live up to the domain name. I can’t do this with every domain I own but I’ve done this with more then a handful.

I had the same problem as you. But now, I've been creating my product for 6 years. A lot of problems, yet, I am keep going.

The silver bullet for me: "only losers do not finish work they started." - Think and grow rich book.

The main key: Persistence. "I will finish it even if I have to fail it thousands times".

A rich guy shared it with me.

https://collegeinfogeek.com/how-to-finish-project/ Looks promising.

Define different stages of done.

Projects are not puzzles. They don’t have a generic definition of done.