|Perl: the Markov chain saw|
I see there are many replies to your question, and all of them have their merits. I'm here to give you the bad news as well as the good.
The bad news is that architecting skills are acquired only with time and experience. You can read a score of books on the subject, but you really only know what you're doing after years of doing it.
To properly architect a project, begin with use cases. Buy several books on the subject. (Hint: O'Reilly's UML book is a great reference, but not good for learning.) They seem silly at first, but they are a great way to formally organize your thoughts and the thoughts of those who are providing your specifications. This will also be the time at which you will identify specifications that will cost the client more in development time and money than they will see in return; i.e., this is the time at which you should feel free to say, "No."
Next, diagram your objects using class, object, sequence, and activity diagrams. If you don't have a high-powered diagramming software (I recommend Dia if you don't have a big budget to work with, and have found Object Domain quite useful, significantly cheaper, and much friendlier to Linux and *nix users than Rational Rose's software), draw your ideas on a sheet of paper.
Next, create a prototype. Figure out what you did wrong. Repeat the above steps until you're comfortable, however you define that.
Putting together all of the above involves a learning curve if you haven't done it already, but you need to buckle down and learn it even if you're the only Mohican on staff. In the words of your mother, "It's for your own good." Trust me.
In lieu of having the time to learn and implement the above (e.g., if you work at a dot-com), do as much as you can, making sure that you take the time to learn, and look up "refactoring." This is the process of taking existing code and making it better. Knowing nothing more about your situation, this may very well be what you need to do for pragmatism's and expediancy's sake.
If you arrive at the conclusion that you need to rewrite most of what you've done, you will merely be in the same boat as most coders with years of experience have been at at some point in their careers. Don't beat yourself up about it. Simply go forward as best as you can, knowing that you did as good of a job as your experience and knowledge base would allow, and make sure you educate yourself in the process.
Now for the good news: While your employer doesn't care how much you learn as long as you get it done, if you take the time to educate yourself on the above concepts and simply force yourself to adhere to good coding practices, you will over time acquire an intuitive feel for how to address the questions that you ask.
You will rarely feel like you know exactly how to architect anything perfectly, but you will see yourself get better and better over time until you are clearly head and shoulders above less experienced coders on staff.