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

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.