Consulting and Documents
While I write it from consultant perspective, I guess it’s quite good practice for any semi-executive position in research and development department in software company. The idea is – your client have to know what you doing. That’s good ethics and actually quite useful for self management.
General Rules
Company might use internal jabber service or even some exotic IM protocol, voip, bug tracker or any other means of talking to each other. That’s all good, and consultant should use them. But never forget about good old E-Mail. Try to send anything important to your-self for future reference. And copy status updates and white papers to the clients mail box.
There is multiple reasons for that, one of them, starting from: you might have dozen of clients, and everybody use different protocol, it’s nice to know that you won’t accidentally forget to send somebody a note or update.
Status Updates
Make this regular, I would not recommend sending them more than once a day. But daily is good. If you lazy you can try bi-daily or weekly, consider weekly status updates to be an absolute limit. Daily is actually not that bad, and will take only 5-10 minutes or your (paid by a client) time.
Always [blind] carbon copy yourself (cc/bcc), and it’s nice to have an imap mail server, where you can have different folders per status updates for each client. If you are not a modest type like me – you might consider compiling huge update in a PDF from all those small emails you were writing for weeks or months to a client – to remind him of enormous work you’ve done wink.
White Papers
It’s nice to write a white paper for libraries, frameworks and utilities you develop. While documentation in code will be most likely seen and understood only by programmers in your current department. Whitepapers should be a good reference point for people from any other department: UI, GUI, Back-end, Front-End, QA and such. If you are involved in Rich Internet Application / Web 2.0 development it’s really useful to supply Web Designers, UI, GUI and Web Security people with some reference on code, so that they know what to expect.
If a library or framework you’ve developed is particularly huge (150 or more classes for Flex Project for example) – it’s nice to provide your fellow developers with some kind of reference on Facade points of your library too, while they can get documentation, it’s not always clear where to start reading documentation.
And don’t forget to include whitepaper writing to the status updates wink.
Client Specific
As I stated before – each company might have some specific ways of communication. While some of them are exotic and hard to guess. JIRA, Redmine, Mantis, Confluence, SIP and BaseCamp. While it’s quite useless to guess what client’s company might use – it’s nice to install bunch of different IMs from old ICQ to new Skype and open source Jabber, and learn some wikisyntax. Also If you are going to work for scientific/research companies and there is lot’s of interesting job in that sector – LaTEX is quite useful.