Why are those projects on your to-do list? Are you seeking fun or profit? If you have to remind yourself to do it then find something else to do, imo; it should ultimately be something you enjoy, because the more the chore the more the bore.
That said, if I'm just starting on a project I spend at least some of my time organizing my thoughts in some manner. This could be anything from a simple aggregation of features to scribbling high-level sequence diagrams. This process is ultimately supposed to be in support of the creative process, and if it's something you have to think too much about then you simply shouldn't do it. It's analogous to a composer who seeks out notes at the piano without regard for the final composition; it's not the immediate notes, right or wrong, that matter; rather, it's a systematic isolation of candidate notes that ultimately lead you in the right direction.
Of course, the above isn't always necessary of even possible when attempting to recapitulate the features of projects already implemented thousands of times; no offense, but discussion forums, CMS paltforms, etc. have been implemented so many times that the creative process is almost entirely removed, imo. In these cases it's often more convenient, if not prudent, to simply look at what available packages offer and find a means by which you can differentiate your solution. The key would of course to have a plan, and that could be anything from providing a more intuitive interface, a more integration-friendly platform (perhaps the only solution available is COBOL and you want to offer a Java or .NET platform more conducive to third-party integration), etc.
I don't think I've really said anything at this point, so let me summarize:
1) Build a plan. What are you trying to accomplish and why? This would likely keep you on track so that you don't forget and get overwhelmed.
2) Gradually distill the problem into its parts. If you find the parts you know where to start, and if you know where to start you can more easily accommodate a more emergent solution. This will allow you to stage out your development efforts, time, and overall success. It's much easier to say "I want to build a framework that supports the submission of user commentary for review" (ok, that's a silly description, I know) than it is to say "I want to build a corporate helpdesk platform." The more palpable the problem and its answer the more focused you will be. There are countless ways to document these parts, but in my professional efforts I most often use use (sic) cases as so much of my time is spent communicating with "the business."
3) Build it and accept revision. The point here is to accept that the solution will emerge rather than present itself as a milestone you can see a mile down the road. Don't look for the wall... just keep walking and you'll find it; run and you'll likely hit it
I've worked on projects ranging from a few thousand to 100 million, but there is never one thing that I always do first. It's ultimately a creative process (I'm saying that a lot), and part of your job is to have a pulse on the heart of the project so that you know how to move; you have to feel your way through it. To say, "First, you need to create this diagram, and then that diagram" would be a lie. Find the philosophy of thought that suits you (I've provided a summary of my thought process above) and let the formalistic diagramming (e.g. UML) serve as a listener, not a director.
My $0.02.
Facebook
Twitter