Chapter 3 of David Allen’s book ‘Getting Things Done’ outlines a great approach to project planning.
It’s not specific to software projects, and it’s very light on methodology, but I’ve found it really useful when planning projects. At that middle stage when you’re getting lost, it’s useful to look back to this planning process to see where your problem is, and thus how to solve it.
I’d urge you to read the chapter (and chapter 10, which has practical suggestions on how to implement the approach), but if you want a slightly shorter and less well-written summary:
Although I’ve listed these in order, you’ll move through all the stages lots of times during a project. For example, nitty gritty implementation details (5) can force you to redefine the successful outcome of the project (2) given the principle of keeping costs limited (1), or brainstorm new implementation approaches (3), which leads to you reorganising who works on which modules (4).
Also, this process applies to really large projects (e.g. implement an order entry system for a client) and really small “projects” that are part of a large project (e.g. implement the validation layer for the order entry page of the order entry system). Whenever you’re lost in the middle of a project, check that for whatever bit you’re working on that you know what the purpose is, and what the outcome should look like.
If you’re vague on the outcome, figure it out in more detail. Refer to the spec. Ask colleagues. Google. Etc.
Take heart. None of this is easy. An approach like Allen’s is good to help stop you getting lost, but the skills you use at each stage of the approach can only be learned by years of hard work, mistakes and experience. If you’re having trouble figuring out whether to do the database first or not, you might just need more actual programming practice.
But the fact that you’re thinking and asking about how to do projects better means you’re already doing more than lots of people ever do. Good on you, and best of luck.