I am working on a few small consulting projects with some people that are new the consulting thing. It has inspired me to write another post of tips on consulting lessons I have learned.

1. Only have one copy of your project or file. The biggest nightmare is having two (or more copies) of a work on your drive (or shared between the project members). This leads to all sorts of visioning issues, working on the wrong file, uploading the wrong file, etc. Just have one. If there are two of anything...... delete one.... please!

2. Release early, Release often. Now I am not talking to the client in this case. I am talking about the other members in your team (especially when you are working remotely like I am on these projects). I can not count the number of corrections so far due to missing something or not being informed of something.

3. Make sure the web stuff is final when coming from the graphics people. No point in implementing the HTML twice into the UI (or trying to mimic their changed). Inform them that there will be no changed (unless they want to change the aspx pages themselves... read next point)

4. Graphics people will usually screw up an aspx page. I know I am stereotyping but stereotyping saves time. Whenever I have told them they can change it "just like an html page" they seem to muck up a grid template, or move things outside of containers, or something. I tell them to make a backup of the file before they start and ensure it works

5. Realize the client will not like what you produce to some degree. Budget for this and expect to make changes.

6. Don't comment out blocks of code. They end up sitting in there until a year later you say "hrrmrm.... its commented.... must be important... I should not delete it". This is what source control is for. If something was really important you can look at the previous version of the file and extract it.

7. When coding there is no guarantee that you are going to be the one to make changes on it in the future, even then it might be 2 years down the road. Code everything with the mindset that an idiot is going to be the one making changes to it and has to understand it (and that way no one will be calling you for support 2 years later as well)

8. Establish ownership. Who owns the source code? Do you release it to the client? Unless stated in a contract clients own the source code as they have contracted you to write it (the law is vague on this but that's what I have read out of it so far). Be clear about this fact right up front. I have offered different pricing if they want the source code in the past but now I just usually give it to them. They always come back to me for changes so why hold them over a barrel right?

9. Establish warranties. Let them know that you will fix any bugs (and let them know what a bug is) within a period that you set. After that there will be charges. This motivates users to test the crap out of an application and really sets you free of an app. I have had people call me up years later about a problem which I had to fix on my own dollar (plus relearn the app).

10. Keep communication between all parties open. If you are having a problem, falling behind, or just don?t think you will make the timeline; the earlier everyone knows the happier they will be..... trust me on this one. I have learned this lesson the hardway.