I like Zsolt's advice, but I would add just a bit (but keep in mind my background is NOT s/w dev).
All projects, regardless of size, share some common traits. Primarily is the idea of scope, or in the case of s/w dev, requirements or capabilities. Then there's obviously cost and schedule. These don't determine success, but they give you some parameters for going forward.
So treat it like any other project - define the expected capabilities at present. I say capabilities to avoid the 'some parts of scope are unknown discussion' and 'at present' to allow for emerging requirements as the project progresses. but get clear on where you're headed for now. Then break it down into the different deliverables/components, and the then work required for each, and roughly schedule that out.
I will disagree with Zsolt on one aspect - he said tracking won't improve it. Okay, perhaps not 'improve' it, but as you said you have a "3 month" project, some element of tracking against expected progress is necessary, just to make sure you finish as agreed.
One last piece - MSProject will NOT help you manage the project. At best, a program like MSP help you 'track' and/or plan the project. But that's ONLY if the information in it is accurate, and updated to reflect progress. On a 3 month, one person project it's overkill. It will most likely take you more time to update it than will be useful. You may want to use it to work up the WBS and rough out the schedule, and then to refer back to. But (IMO) you would be better served to rough it out in MSP for a baseline of workflow and target dates, and then switch to Zsolt's Kanban recommendation for the day to day tracking and monitoring, and maybe refer back to MSP to gauge progress against how you originally planned it.