There are hundreds of project management books, though most are for bigger projects than yours. There are hundreds of books on methodologies. The two topics overlap.
A lot depends on how formal your boss wants to pay you to be. You can accomplish a lot with a whiteboard and post-it notes.

I plan projects by first understanding what's important to the customer. This typically involves capturing information about the system as Stories or Use Cases, then sitting with the customer to prioritize them. From there, some sort of work plan gets generated. Developers are asked to look at the stories, sketch out an implementation and provide an estimate. These get lined up to develop an iteration plan, with some number of iterations resulting in a release.

Each iteration is also a replanning point. Priorities change, new requests come in, developers learn more about how difficult some things are (or aren't). The team establishes a true "velocity" (as opposed to the wild initial fantasy about how long it'll take to do things). I lay out a new iteration plan after each iteration. Mangement might throw fits about this at first, but they often get used to it (or they might fire you).

For small projects, I'll do this on a whiteboard. Developers can then cross off their task cards when they're done, or update estimates. Management can then wander by and look at the board to get a handle on progress.

This approach leads right into eXtreme Programming (XP), should you decide to go that direction.