I usually have some project that I can do alone that take around 6 months to 1 year. I always try to have some "release" date and write few documentations (external to the code).
My question is, what type of management do you use when you do not have a team with you but you are alone?
Example, I was thinking about Agile Programming BUT not sure if you can really say that you are Agile when you are alone? What do you use?
I think that you can still follow some Agile practices, although you might bend the rules a bit, but I actually don't think that matters. If your projects are small enough, maybe following Scrum-like processes will help. Maintain a backlog of priorities and divide your work up into sprints. I don't think that you'd necessarily hold meetings with yourself :-), but the concepts of keeping focused on priority goals over a fixed time period might be worth it.
You can certianly follow test driven development practices as well.
For projects like that I've used more of a checklist style to management what I want to have done and when. I highly recommend using good development practices like source control and issue tracking even with one developer.
I've taken over too many projects that started with one developer, but the project grew and now there need to be two or three developers working on the project. Its always difficult to make the transition, even more so when there is a basic check list, version control and/or issue tracking.
A huge part of Agile is about communication in the team so you could not follow that unless you will go mad and will start talking to yourself :)
On the other hand Agile is about proper processes and certain mindset - and this part you could and should use in your project even if you're alone.
Spending some time on proper organization and setup will definitely help you. And later when you may consider adding someone else and work as a team the transition will be much smoother. Same goes for passing your work to someone else for support and maintainance.
Having been in a similar position for years, I base my approach to how I'm billing the project: project based or time/materials based.
If I do project based billing, then I tend to be a little more formal. Meaning that my contract lays out the main project features as well as possible limitations etc. I go over it in detail prior to signing, then that becomes my blueprint.
I do allow for changes along the way, but I make those a little more formal as well with signed change request forms describing the change and the modified project costs.
On a 6 month to 1 year deal, I may show progress about once every 3 to 4 weeks; or at milestone developments at which point I do incremental billing. This is probably closer to being a waterfall approach than anything else.
If I am billing for time and materials then I tend to be a lot more flexible and have a lot more communication with the client. I may be showing something new every day, or at the very least, once a week. I basically try to show the result of each task I finish. The type of clients that want to bill hourly tend to like this format. This tends to be closer to an agile approach.
At the end of the day you just have to go with what works best in your situation.
Here is what I did the last time that I had an assignment like this:
I like this sort of process because:
By the way, this personal process was inspired by Peter Coad's chapter on Feature-Driven development in Java Modeling In Color With UML.
You can try this: My Master's Thesis - Cowboy Programming Methodology It scares me to post my thesis here, but oh well...
Basically, I looked into this exact problem with my thesis - how do single developer teams use agile practices and methods to produce good software.
Oh, and start reading on chapter 4 - the first three are pretty lame-sauce (for people that read this blog).
I'm assuming that you are doing this project for some end user. Here's a list of what they would likely be looking for and how you can meet those needs.
If you are doing this for yourself, then only the last bullet above is really necessary. However, if you don't pay attention to the first two bullets, you may end up never finishing or not delivering a coherent system.
My advice:
Don't forget basic SCM practices.<< Get a GOOD revision control system (Subversion, Git (?)). A good SCC system will save you gobs of time. Create build files. Don't do manual Compile-Copy deployment. Try Continuous Integration (CruiseControl?/CruiseControl.NET?). The more you automate the work of tracking your changes and building your software, the better utilization you will get out of your own time.
When the project is personnal, I do not have any guideline. If it's for someone else, I try to go with iteration to have some user feedback. I like to have 2 weeks iterations.
The difference is with the documentation that I tend to write less, but I have the back myself with Unit Testing because I am alone and it's the way to "protect" me.