1. Do a Google search on "How to do a SWOT Analysis" -- it's not hard to complete, but is beneficial as the very first task. Here's a link to start: http://rapidbi.com/created/SWOTanalysis.html
2. Get a basic understanding of the Software Development Lifecycle (SDLC) Steps. I like this chart: http://en.wikipedia.org/wiki/File:Systems_Development_Life_Cycle.jpg
There's time later for getting more info on each part of the lifecycle, but what you need is a quick understanding of the major steps in your project, so you can know at each point what stage you are in.
3. Do a search for "work breakdown structure" (WBS) so you can break your project into pieces. Think of this project like a brand new puzzle -- you have an idea of how you want it to appear, but first you need to sort out the pieces by shape, such as pieces that have an edge in one place, and pieces without an edge somewhere else. There are many WBS templates, but you could simply use an Excel spreadsheet. Here's a good example of building a bicycle: http://en.wikipedia.org/wiki/File:WbsConstruction.png
Think BIG first, then break it out into gradually smaller and smaller pieces.
What the WBS will do is give you your 'scope' so you don't end up doing more than you need for this project. I would take that WBS to your instructor / manager, or the 'stakeholders' of the project (those that have a vested interest in seeing this project succeed).
4. Once they sign off on the WBS, you can then create a Project Plan. This I actually found more difficult to do (for me, at least) since I started with Microsoft Project, and it was overkill for most of my projects. Use your WBS to create a basic project plan -- forget about the bells and whistles that Project has for now. What you want is to put all the high-level pieces of your WBS into MS Project (or some similar tool). The key things you should use are timeline, precedence (does 1 piece need to come before another? you can't ride the bike before you build it...), and resource conflicts. There's a screen where you can list your resources, who's working on what: who is the developer, who is the tester, do you need any DBAs or people from other departments to do anything?
You can always get an IT Project Management for Dummies, too, or a good MS Project manual.
5. Remember these 2 rules:
"Cheap, Fast or Good - I can give you any two."
...and...
"If you want to make God laugh, tell him your plans."
The first is meant to keep you in focus when someone tells you "I need this now". Ask them if they also want it to work well and be at a reasonable cost. If they say they want it all, tell them one of these has to go out the window. Be strong about it when you have to communicate that; a speedily put together application can be done, but it will either be so poor no one will want to use it, or it will be done at a very high cost (more manpower + longer hours = more $$).
The second is showing a bit of my cynical nature, because I have been through many projects that did not adhere to the original project plan, and they went off track very quickly. Remember that your project plan is a work in progress, and that without NO planning, your project is in an even worse state to fail. Your plans may change, so do not be afraid of that; just update your project plan, and then work from your new plan.
-------------------------------------
Hope this helps.
