Well, there's a lot of advice available and the things that will work will depend on a) the complexity of the project and b) the amount of time you want to put into keeping it running smoothly.

One of the first things you'll want to do is get all that nasty "money" stuff taken care of up front. Make sure your client knows when you expect to get paid, how much, and what specific types of work you'll be billing for. For example, will you bill support calls? How about bug fixes? (Note on the latter: If not, make sure you define what you mean by "bug." I tend to fix bugs for free and have had clients try to classify miscommunicated requirements as "bugs." I tend to define bugs as "Things that should work properly, but don't," as opposed to "Things you decided you needed after we talked.")

Along the same lines, use care when accepting jobs that don't pay until after they're complete. I have a friend who took a couple of these because they would pay off handsomely if they took off. The projects are still in holding patterns and you can imagine what this has done for his household budget. Personally, I prefer obtaining deposits before work proceeds--especially if I have certain misgivings about the client. A deposit gives you motivation to actually work (and helps pay the bills while you do so) and it commits the client to the project.

That done, you'll need to make sure you both agree you know what "Done" looks like. After all, if you don't know exactly what you're building, how can you design an effective solution, manage feature creep, define schedules, or even provide a reasonable estimate? Basically, this is simply an agreement about when the project is finished, something you can both use to measure progress and success.

I tend to do this using a variety of common techniques: interviews, note-review, task lists, etc. Depending on your experience and available tools, you can also borrow ideas from various Software Development Practices, e.g. Use Cases from UML, etc. Be sure to choose practices appropriate for the project. For example, I'm probably not going to define an ERD¹ for a simple email-gateway script.

Once you know what's needed, create a task list showing what you need to do to make that happen. This will likely be sketchy at first, but if you maintain it, you can end up with a pretty detailed list of the work you performed and the choices you made. I tend to use a word processor's outline view for this. Not only does this keep things organized, but it also helps provide automatic numbering to help communicate and refer to various parts of the project. It also helps with other elements of the project, such as devising test plans, tracking problem reports, creating documentation/training materials, and so on.

Next, prioritize the tasks. Determine what needs to be done and in what order. Also, determine which features are "must have", "should have", "nice to have", and so on. This will help you determine what needs to be worked on first and what can be delayed for a later phase should time/budget get tight.

In short, keep track of what needs to be done, what you've done to make that happen, what you need to finish, and what you've been paid for. Do that well and you should avoid much of the problems you ran into earlier (though some of that was beyond your control).

In closing, here are a few links to articles covering good practices:

• Martin Fowler's articles
• Steve McConnell's articles
• Joel on Software (who I sometimes disagree with, but still enjoy reading.)
• Excerpts from Bringing Design to Software
• You might also find these interesting, though hardly light, reading.

There are a host of books, materials, and opinions on the subject. In practice, choose the ones that help the most, consider the others, and then use what seems to work best for you and the project at hand.

Above all else, though...remember to communicate with your client. People can appreciate delays when they know about them and see that you're making progress. However, they don't like being in the dark...especially when they're not sure how much it's costing them.

--f

¹ - Engineering Requirements Document, basically an oversized task list. Useful with some projects; overkill in others.