It's great you realize that planning will help you. The urge to dive into a project is frequently hard to resist, as anyone who enjoys programming knows. But the best ways to plan a project depend on a great many things. Some common factors that can affect your strategy:

Architecture - language, platform, etc.

Program size - programs with 500 lines and 500,000 require totally different approaches

Timeframe - did you need the program yesterday, or do you have a year to get it right?

Number of collaborators - it's much less hassle to do things yourself, but large projects require coworkers, and the red tape that comes with them

You need to know all these things before you start writing any code. Don't just think about them; write them down, or explain them to someone else. Structuring your thoughts in a more concrete manner will force you to really understand what you're doing. Getting the requirements right is the first thing you'll need to do. Next, look in more detail at what languages, algorithms, libraries, etc you can reuse. Compare a variety of them and see which fits your project best. Flowcharts and other graphical diagrams, as non-computer-esque as they seem, can frequently help you organize your ideas and find fundamental problems very early. The right design decision can save you enormous cost down the line.

Once you've got a good idea of how you want to structure your program, start looking at how to implement it in general terms without actually writing code. Most coders I know tend to itch to start writing code as soon as it's fairly obvious how to implement a routine, but restrain yourself until you know that the obvious way is the best way. My favorite tool for good program design is writing an initial draft in a sort of formal pseudocode called PDL (Program Design Language... see the book link below). Before ever writing a scrap of code, map out in detailed English (or whatever natural language you prefer) what your routines will do. This frees you from syntactical constraints of your target language and allows you to tell at a glance what routines do. Recursively revise your draft with increasing detail until you can go almost directly from that to code. Any logical flaws are much easier to correct if you uncover in the planning phase than once you've started coding. As an added bonus, once you fill in the code, you've got comments already there in the form of the PDL.

Your question relates mainly to the planning stage, but maintainability is also greatly influenced by how you write the code itself. Structuring routines and classes for maximum understandability and flexibility will always help you in the future.

One of the most valuable books on my shelf is Steve McConnell's Code Complete, because it address exactly these issues. I've had it for seven years and reread it every so often just to remind myself of how I should be doing things. Amazon has a list of related titles (which I can't vouch for personally, but look similar) that you might find useful.

Actually, if you open the book and read it, you will find
that it contains a lot of good advice. Microsoft, you must
admit, does write a lot of software, and if anyone should
be able to comment from a position of experience alone,
then Microsoft would certainly qualify.

As for the content, the author apologises if the material
is a little too C oriented, but a lot of it applies quite
literally to Perl as well, if only because they share a
lot of syntax, semantics, and pitfalls, such as:

The author is a strong advocate of the "Hungarian"
naming system, where in a strictly typed language like
C or C++, the name of the variable indicates its type,
such as 'nPeople' (int) or 'pszName' (char *).
This is not entirely irrelevant for Perl, that while it
will readily convert between int and char, it still isn't
psychic. You will be punished severely if you switch up
$q for $p when $q is a CGI object and $p is a SQL statement
handle. Hungarian would have you call them '$cgi' and
'$sth', for example, or perhaps '$cgiMain' and '$sthSelectAll'.

I know, a book about writing good code from Microsoft,
the creators of DOS 4.0, Windows NT3 and much, much worse,
but when you consider that Windows 2000 actually runs at
all, despite being 25 million lines of code, they
must be doing something right. It seems that the author
wrote the book to try and promote good coding practices
within Microsoft, a practice that was strangely absent from
one of the world's largest software manufacturers.

While it may not be as comprehensive as XP, it does promote
a better methodology than the ad-hoc approach taken by many,
and it uses a lot of code examples to illustrate its points.
Have a look through it if you have a chance, and see for
yourself.